> Microsoft says that VS2019 runtimes are forward and back compatible with VS2015 and VS2017, however, it turns out that is not always the case, and we definitely encountered one of the incompatible scenarios.
The binary compatibility has documented limitations. As https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2... explains, "The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component." This allowed us to add VCRUNTIME140_1.dll as part of the "FrameHandler4" work that the compiler back-end team did. This decreases the size of exception handling info on x64 for compiled programs, sometimes significantly.
(I work on the Visual C++ team, on the STL. We regularly build Dolphin with our development toolset to prevent shipping compiler/library regressions, and to provide advance notice of source-breaking changes. I've had to report a couple of breaking changes to Dolphin and have been astounded at their prompt fixes - they are a wonderful team!)
> [...] We have ample proof that Avalanche Software was already upset about homebrew and emulation thanks to a crude message found hidden in the data of 2007's Meet the Robinsons, however it's very unlikely that this is anti-emulation behavior.
Can't find more about this by Googling around... anyone knows what the crude message was and where it was hidden?
Tangentially related: IIRC, the demo disc version of one of the PS2 Metal Gear Solid games had a small texture sitting in VRAM that just contained the url http://konami.co.jp/xxx/
If you visited the url, it was just a hit counter. I found out about it on Sony's PS2 registered developer forum. Someone had put the disc through the PS2 "Performance Analyzer"[1] and had a peek at the VRAM. When I hit it site it was in the low hundreds. A few months later it was in the low thousands. A few months after that it was gone. konami.co.jp apparently isn't even a thing anymore.
It would be hilarious if this got a game based on a Disney movie reclassified as M for Mature, kinda like the GTA Hot Coffee mod or how Elder Scrolls:Oblivion got reclassified based on unused art assets on the disc
Avalanche is specifically known for it's anti emulation code.
Previously they've had to deal with a piece of code that is designed only to work with the gamecube's L2 cache, and crashes emulators that don't emulate the cache layers close enough. Which emulators rarely do as it's prohibitively expensive; you're looking at somewhere between an order of magnitude and two lower perf. This code doesn't do anything in the good case, and doesn't have any reason to exist except to be an anti-emulation check.
I'd love to see a Q&A session with the programmers about those games. Putting so many incredible "anti-piracy" or "anti-emulation" pain points into games most people would consider shovelware
Part of me wonders if it was a request from Disney, given that the value of the IP being emulated in an unlicensed product would be undesirable to them.
While on the topic, I always hope that HW manufacturers could start being explicit about what is _supported_ and what is "supported".
We have this problem with CPU manufacturers stating that something is supported, when it is instead emulated (hello checks on CPUID). Disk drives acknowledge writes before they actually write the data to the disk (hello layers of unreliable fsyncs). Network cards claim that packet have been shipped while they never left the circular buffer (hello bufferbloat).
Yeah, it could be patents. The efficient hardware implementation of these instructions was patented by the Princeton researchers that developed it, and this work was sponsored by Intel (and the Department of Defense).
One could reasonably assume that the sponsor of the work would have access to the patent on very favorable terms. Some details at [1].
Your comment breaks the site guidelines. Since you've quoted them recently in other contexts, I assume you know this.
One reason we have that rule is that once users come along and (as they typically do) give corrective upvotes to the unfairly-downvoted comment, a comment like yours becomes false. Unfortunately, such posts don't then garbage-collect themselves—they stick around, adding noise to the thread.
Emulator development is not my cup of tea and I only once tried Dolphin, but the progress reports are always a fantastic read. The Dolphin code base [1] is also fun to read.
The progress report linked to Dragon Quest X (https://wiki.dolphin-emu.org/index.php?title=Dragon_Quest_X:...) and I'm impressed to find an aspect of the Wii library I didn't know existed: a game that expects to be installed to a USB drive to be played.
I honestly thought every game would just be playable directly from a disc, but I guess this one was too large for a single disc.
The binary compatibility has documented limitations. As https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2... explains, "The Redistributable your app uses has a similar binary-compatibility restriction. When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component." This allowed us to add VCRUNTIME140_1.dll as part of the "FrameHandler4" work that the compiler back-end team did. This decreases the size of exception handling info on x64 for compiled programs, sometimes significantly.
(I work on the Visual C++ team, on the STL. We regularly build Dolphin with our development toolset to prevent shipping compiler/library regressions, and to provide advance notice of source-breaking changes. I've had to report a couple of breaking changes to Dolphin and have been astounded at their prompt fixes - they are a wonderful team!)