Dolphin is a GPLv2+ application, and the runtime is under a proprietary license. We currently rely on the "system libraries" exception in the GPL to allow linking with the runtime in the first place. If we ship the runtime with Dolphin, it might not be considered a "system library" anymore.
Honestly, given the feedback on the Microsoft site, that makes sense: the redistributable is backwards-compatible, not forward-compatible. Same as with glibc.
IMO, the correct option here is to compile against an older version of the build chain. This is the solution offered by Microsoft, and something you would do on Linux for glibc compatibility as well.
The other option would be to compile without MSVC, using mingw, wine headers, etc.
I believe there are a few open source projects (such as Inkscape[0]) that provide Windows builds this way rather than having to deal with Microsoft's toolchain and runtime. But given its heavy reliance on DirectX APIs and other system libraries, I'm not sure how feasible that route would be for Dolphin.
I do wonder if there would be a performance benefit to compiling with GCC/clang on Windows, as I've seen fairly recent builds of MSVC emit some pretty lousy code in certain cases, and it lacks many of the options that GCC/clang provide, such as an exact equivalent of -fno-math-errno and the like.
It's technically supposed to be a paid service on iPhones too, but Apple recently extended the free trial, so nobody is actually paying for it yet. [0]
This is frankly awesome news, we now know Voyager 1 just needs a Windows Update(tm) to keep on flying. Of course, "just" is putting it mildly to say the least, but I don't want to think how worse the diagnosis could have been.
Notably, Apple still does not allow non web browsing apps to use JIT recompilers. This precludes emulators for 6th generation and newer consoles (GameCube, etc) from running on the platform even with this guideline change.
I submitted a DMA interoperability request for JIT recompilers, but Apple denied it on the grounds that it doesn't fall under Article 6(7) for "multiple reasons", including that JIT is only used by web browsers on iOS.
Historically the justification for limiting the use of JIT compilers is for security reasons, which does actually stack up.
JIT compilers are one of few use cases where an application absolutely needs the ability to write data to memory, mark that memory region as executable, and then execute the op codes in that memory region. On iOS, other than Safari, no application, either built in or installed via the App Store is allowed to change memory permissions from writable to executable, and that acts as a cornerstone in iOS application sandboxing.
Now there’s perfectly good argument that the security argument doesn’t really stack up anymore, given that sandboxing technologies have progressed a lot, and it should be possible to properly sandbox a JIT compiler or similar. But there’s no denying the fact that removing the ability for an application to execute arbitrary created op codes is a very good way to completely eradication a huge surface area for exploits. Especially when such restrictions are paired with static scanning of binaries before signing (which happens when any binary is produced for iOS, via Apples signing service).
All of that is to say, there is a possible world where ROM are transpiled for iOS devices (using something like Rosetta), and loaded as signed binaries via emulation wrappers. But at point you’re basically having to create your own App Store, and sign a new app for each transpiled ROM.
In short, it doesn’t seem likely we’ll see JIT powered emulators on iOS anytime soon, and, at least in this specific instance, Apple has a legitimate security reason for restricting their usage.
If Apple is compelled to allow users to run unsigned binaries (like Android) - would that allow for JIT emulators to run or is there something fundamentally blocking the execution of JIT code in iOS that prevents this?
iOS itself almost certainly also blocks usages of that API as well, unless the binary is signed with the correct entitlements.
But if Apple was forced to allow any binary to execute, and utilise any entitlement/API, then yeah there’s nothing stopping a JIT emulator running on iOS. But I think it’s very unlikely the EU would go that far, I don’t think such actions are needed for the EU to achieve their aims (liberalisation of app economy and markets).
That doesn't really help unless you bundle the game code inside the app executable. Otherwise you still need a JIT entitlement in order to map code as executable.
There is a lot of space between interpreters and a full JIT that is under-explored. Because developers typically skip straight to a JIT when they find a interpreter isn't fast enough.
Dolphin does have the cached interpreter, which eliminates some of the decoding overhead of a traditional interpreter, but I think you could go a lot further. Convert the PowerPC instructions to a optimal bytecode and apply various optimisations to that bytecode (function inlining, constant propagation). Common pairs and sequences of instructions can be replaced with a single bytecode implementation.
Given how fast Apple's cpu cores are, I suspect it might be possible to get a optimising bytecode interpreter fast enough so GameCube and other 6th gen console emulators can run at full speed.
Considering the number of ads I see for "gaming browsers" like Opera GX, I wouldn't be surprised if someone tries to sneak an emulator onto the store that way
Earlier than the GameCube even. The N64 audio was a programmable chipset (it’s late in my timezone so please forgive me for not including the full technical details here)
fwiw, I submitted a DMA interoperability request for JIT access on non-browser apps.
Apple denied it on the grounds that it doesn't fall under Article 6(7) for "multiple reasons". One such reason they gave is that JIT is only used for web browsers on iOS.
Yeah but weren't they making specific patches to accommodate an early leak of Tears of the Kingdom? At that point, they were kind of directly facilitating piracy; no one could argue that they were working with a legitimately obtained ROM.
Of course, I don't know the details, I've never actually gotten Yuzu working in any capacity (since I run macOS) and thus I wasn't part of their Patreon or Discord, so maybe I'm mistaken?
I see a lot of falsehoods (like "nobody ever sold an emulator before," when Apple showcased commercial PlayStation emulation at a keynote event in 1999) going around and I assume the reason is people don't like the implications of this case and are substituting a more palatable version of events that didn't really happen.
Not only did Apple showcase it, Sony sued Connectix and lost, thus formally making emulators "legal". [1] Similarly though, it looks like they were able to basically shut it down by getting injunctions on it while the case was pending, and eventually buying and discontinuing it.
NEX is still used by many games on the Nintendo Switch, so I don't think it's another GameSpy situation.
That being said, Nintendo has started using an in-house replacement system called "NPLN" in some of their more recent titles. Some examples include Splatoon 3 and Pokémon Scarlet/Violet. (They've shown no indication of converting older titles to the new system, however.)
> Sucking at something is the first step to being amazing at something, and it's a step everyone goes through, no exceptions.
The thing that gets me about OP's remark is that pannenkoek2012 himself made a YouTube comment in 2013 asking how to make Mario kick in the air without pressing the A button to jump. [0]
There's some past discussion in this PR, where we made a change to automatically install the runtime DLLs but ended up reverting it: https://github.com/dolphin-emu/dolphin/pull/11068
(this is based off my own recollection of what others have told me, it might be out of date or wrong)