I've just finished creating a WASM 1.0 implementation (simple JIT on x86 and x86_64) for plugin usage and I'm looking on how to support more languages beyond C (for which I have "micro-libc" to create really small binaries). In particular C++ and Rust so the article contains useful info for that. C++ that would be more problematic I think, would have to resort to full Emscripten or something... I've tried to compile standalone C++ stdlib but wasn't much sucessful yet.

BTW, I see in the screenshots you also test Firefox, I think it would make sense to test the latest two ESR versions (these are often used by Linux distributions).

You can also compile using old distro and old Glibc to get similar effect. Though you would miss the advances of the newer compilers.

If security was a concern, these hoops would be for all apps, not just unsigned. It just shows the only function it serves is gatekeeping by Apple.

https://www.youtube.com/watch?v=Vncf70UBsr4

Meanwhile Apple is having fun how to creatively pass the EU regulations while defeating every point of it in practical terms.

Maybe in a decade or two there will be something useful from this, but in the meantime it will be worse.

You're not required to do so, not for indexing in search engines and not for having visitor statistics (you can install some open source software instead).

People are allergic to articles and documentation generated/processed by LLM.

You're switching from an active role to a passive one, meaning your skill will suffer over the time. There is a huge difference between doing the things and thinking you know what it's doing. It's harder to review bad generated code because how polished it looks, compared to code made by humans where the difference is much more obvious.

Code assistants seem to work great when dealing with boilerplate, but wouldn't be better to get rid of the need for the boilerplate in the first place?

Seems a better choice to just parse the files than using private APIs as I couldn't see much of the documentation for them (or rather reversed APIs in various projects) + image handling is weirdly complicated in macOS generally so I want to avoid that.

Currently I've experimented by just recreating the graphics from scratch using vector rendering but it's quite cumbersome.

Other libraries, such as Qt, try to draw the native widgets into offscreen image but it's extremely hacky way prone to GUI breaking with any OS update. Java has their own Apple blessed way, but seems quite limited to me and don't want to depend on that either.

I've used Borland C++ and Watcom C/C++ back in the day and MinGW after that. Also COM was invented for interoperation between languages/compilers.

Being a good citizen means to not use the inherently unstable C++ ABI directly. You can use C API or even COM for that. Relying on it is cute but it's accidental and it will break in the future. Microsoft can't guarantee that it will stay stable because C++ is always evolving, forcing to break the compatibility.

Open source projects shouldn't depend on proprietary compilers (they can support them, but not as the only option). It just undermines the purpose of it.

The reasons I use MinGW is because it produces better compatible binaries on Windows, allowing me to support all Windows versions from Windows 2000 to latest with a single binary (and sometimes 64bit if there is a need/advantage) and it doesn't require me to bundle dozens of DLLs (or worse, installing them system-wide) and artifically limit the compatibility for no reason.

Breaking the compatibility is hostile to the users who can't or want to always use the latest Windows.

I never had issues with C ABI, calling into other DLLs, creating DLLs, COM objects, or whatever. I fail to see what is fundamentally incompatible here.

A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.

I don't understand how open source projects can insist on requiring a proprietary compiler.

Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.

This is typically not done, only certain parts such as handling of the crypto keys. That's because it's pervasive and requires reworking everything with that in mind (TLS library, web framework, application).

On the other hand the centralization and global usage of GC in the process allows to modify it to always zero out the memory that it deallocated and to do GC at regular intervals so it can have advantage here (it's very easy to inadvertly leak the secrets to some string).

Another approach was Transmeta where the target ISA was microcoded, therefore done in "software".

Not only is such signing all about control (the Epic case is a great example of misuse and a reminder that anyone can be blocked by Apple) it is also anti-competitive to other programming languages.

I treat each platform as open only when it allows running unsigned binaries in a reasonable way (or self-signed, though that already has some baggage of needing to maintain the key). When it doesn't I simply don't support such platform.

Some closed platforms (iOS and Android[1]) can be still supported pretty well using PWAs because the apps are fullscreen and self-contained unlike the desktop.

[1] depending on if Google will provide a reasonable way to run self-signed apps, but the trust that it will remain open in the future is already severely damaged