VS2026 compatibility

[SimonAfek]

Changes to .vcxproj and .props files so it builds in VS2026

[Jules-A]

Doesn't that drop ancient VS2017 or older? If you're going to do that (which I doubt zeromus will like) then you might as well drop the other stuff that's specifically there for the older versions?

I didn't know how to do it back when I changed it for 2019 support but you can do (at least until the target changes):

  <PropertyGroup Condition="'$(VisualStudioVersion)' &lt; '16.0'" Label="TargetPlatform">
    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
  </PropertyGroup>
  <PropertyGroup Condition="'$(VisualStudioVersion)' &gt;= '16.0'" Label="TargetPlatform">
    <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
  </PropertyGroup>

[SimonAfek]

That's a good point - it confused me the way it was written, where it specifically set the Windows SDK to 8.1 for all VS versions except 16 (2019). I'll try that out - certainly don't want to break anything for older VS versions.

[Jules-A]

That's a good point - it confused me the way it was written, where it specifically set the Windows SDK to 8.1 for all VS versions except 16 (2019).

That's what it was set to for all versions before I added support for 2019, back then it was fine since it was only 2019 that needed 10, sure it wasn't forward thinking but figured whoever added support for the next VS would make it less awkward but instead they made it look even worse lol, it still works fine, it just takes up more lines and would break in the next VS version.

[zeromus]

I don't have anything but 2022 installed anymore so I couldn't verify whether it works on the older ones. I don't care about them anymore. I think it's likely better for the project if we adopt 2022 and 2026 and up to c++20, so there are no impediments for new contributors. Check with @rogerman though, maybe they test windows builds in an ancient VM. I'm hardly relevant anymore, but I'll get on the record as withdrawing my insistence on 2019 and earlier on case I am the last holdout.

[rogerman]

Backwards compatibility going back to VS2012 is actually quite easy.

Looking at the stuff in the current DeSmuME.vcxproj and desmume.props files, it appears to have support going all the way back to VS2010. Therefore, on my Windows 11 25H2 PC, I've installed every version of Visual Studio going all the way back to VS2010 using installers from this page:
https://gist.github.com/Postrediori/10523cbd60dbb8ec45cddc2b77ac4143

For my build tests, I have modified DeSmuME.vcxproj and desmume.props using @SimonAfek's changes in this PR. I'm also using the TargetPlatform check that @Jules-A posted because it is the easiest and most sensible way to set WindowsTargetPlatformVersion, which promotes the best compatibility across all Visual Studio versions.

Build Results:

• VS2026: Works using the modifications noted above.
• VS2022: Works using the modifications noted above.
• VS2019: Works using the modifications noted above.
• VS2017: Works using the modifications noted above.
• VS2015: Works using the modifications noted above.
• VS2013: Works using the modifications noted above, but requires additional workarounds:
  • desmume.props: Add a line for "VS2013" to NDS_VisualStudioName.
  • DeSmuME.vcxproj: Add a line for "v120_xp" to PlatformToolset.
  • The "Release" build doesn't work due to memory limitations on VS2013's 32-bit C++ compiler. Use the "Release Fastbuild" instead.
  • A few source files required very minimal modification to work with the older compiler.
• VS2012: Works using the modifications noted above, but requires additional workarounds:
  • desmume.props: Add a line for "VS2012" to NDS_VisualStudioName.
  • DeSmuME.vcxproj: Add a line for "v110_xp" to PlatformToolset.
  • The "Release" build doesn't work due to memory limitations on VS2012's 32-bit C++ compiler. Use the "Release Fastbuild" instead.
  • A few source files required very minimal modification to work with the older compiler.
• VS2010: Does not work due to DeSmuME.vcxproj having too new of a file format for VS2010 to handle.

Due to the ease of getting VS2012 to work, as well as being a predominantly Apple macOS developer that only dabbles in Win32 development only when I must, here are my thoughts on the matter:

• I don't care about VS2010. The only reason for anyone to care about VS2010 is if someone wants to develop on Windows XP, as VS2010 is the latest version of Visual Studio that can still run on Windows XP SP3. This is legitimately useful for debugging Windows XP specific issues. However, VS2010 requires a completely different file format for the .vcxproj file. I remember back in the day when there actually were separate VS2010 and VS2012 .vcxproj files, but the VS2010 .vcxproj file got scrapped at some point. I guess this was for easier maintainability. In any case, I don't think anybody cares about running DeSmuME on Windows XP these days, as I'm assuming that all those retro users have moved onto Windows 7 at this point.

• VS2012 and VS2013 should be unofficially supported, but strongly deprecated. It was quick and easy to get VS2012 and VS2013 to build, as the source file modifications were very minimal and already in-line with the current code design patterns used in DeSmuME. So we lucked out on these older Visual Studio versions this time. However, the 32-bit compilers really hurt build times and seriously limit the amount of memory that can be used for program optimizations, which makes working with VS2012 and VS2013 unpleasant. I won't shed a tear if VS2012 or VS2013 stopped working in the future, but we can plausibly keep these on life support for now.

• VS2017 should be the oldest officially supported version. VS2017 worked perfectly without fuss. It also supports the Windows XP platform toolset for people who still want to build DeSmuME for Windows XP using a modern PC, as well as the normal platform toolset for everyone else. You really don't lose anything with VS2017. I'm recommending VS2017 over VS2019 because, while VS2019 also technically supports a Windows XP platform toolset, there are some rumored issues with VS2019 building for Windows XP. To be honest, I don't know exactly what the rumored issues are, and so I might be mistaken about VS2019 having any practical issues with building DeSmuME for Windows XP. If the issues aren't that bad (or better yet, non-existent), then I'll change my recommendation to VS2019 as the oldest officially supported version, but for now, I'm sticking with VS2017.

• The C++ language standard should remain at its default settings (C++14 from VS2019 - VS2026). First off, I don't care what frontend code does, as frontends should be custom-tailored to the platforms that they serve. Frontends can use C++23 if they want, or not even use C++ at all. In fact, the Cocoa Port uses Obj-C++, not actual C++. But for the core codebase, I've kept a strict philosophy on maintaining a C99/C++03 coding style for the following reasons:

  • Originally, the DeSmuME code was in straight C. Later on, it changed to C++, probably because of Visual Studio's poor support for C99 back in those days. But even then, it took many years for proper C99/C++03 to make its way into the codebase, and still today, there are big sections of code that still look like they're in C89. So I still see C99/C++03 as quite forward-looking for DeSmuME's codebase today. Personally, I would like to see the core codebase return to its C89 roots to maximize compatibility with all possible platforms, but we're already deeply entrenched into C99/C++03 at this point, so we just need to keep going with it. Once the entire codebase has reached that point, we could consider throwing in some advanced C++ features (and in some cases, we already do), but the codebase still hasn't reached that level yet.

  • The benefits of adopting even C++11 features is dubious. The reason for this is because types.h, task.cpp, and libretro-common already take care of all the high level features that C++11 handles, such as atomics and thread handling. In fact, these files can even work in C89/C++98. As for other advanced C++ features, like advanced STL features, auto variables and lambdas, these really aren't necessary. If an advanced STL feature seems necessary, it is better to write a custom version of it for performance reasons, and we already do this. Also, DeSmuME makes very judicious use of inline functions, which negates the need for lambdas. And auto variables are actually a hindrance for our low-level emulation code where strong data types of fixed sizes, and knowing exactly what they are at every given moment, actually do matter. In short, the vast majority of the extra features in C++11 and later aren't all that helpful in the core codebase.

  • I personally use my PowerPC Macs running Mac OS X Leopard on a semi-regular basis for testing, as it is the best platform for testing DeSmuME on a big-endian system. Big-endian support is actually a unique feature that only DeSmuME has (no other NDS emulator supports big-endian as of this writing), and has improved by leaps and bounds over the years, and so I really want to keep the feature as much as possible. Unfortunately, this PPC-Leopard platform can only run Xcode 3, which is stuck on C99/C++03 (but it does have some GNU++11 extensions), but this is very easy to support on the current codebase. You may think, "Why don't you use Linux for PowerPC so that you can run a newer compiler?" The first reason I don't is because the Linux ports are way way way behind the Cocoa Port, not having nearly the same level of features and performance. This makes running DeSmuME on any Linux a poor experience compared to running DeSmuME in Mac OS X Leopard on a PowerPC Mac. The second reason is that I have found all the free Linux IDEs to be really crappy to work with. They are so bad that I find CodeWarrior Pro 4 on a 68040 Mac running System 7 to be a far more pleasant experience than any IDE that Linux has to offer. The best that I could do is make a Code::Blocks project for myself, but there are bugs when trying to use it on PowerPC, as well as issues integrating it with gcc-powerpc. But Mac OS X Leopard and Xcode 3 work very well without any fuss, where literally the only compromise is that the compiler is limited to C99/C++03. Again, I find this compromise very easy to make.

  • Other emulator frontends that make use of DeSmuME's core codebase, such as RetroArch, run on even older platforms than DeSmuME itself. AFAIK, libretro-common is written in C89 for maximum compatibility. I would rather not use advanced C++ features to preserve compatibility with users that compile DeSmuME for their own projects, and so C99/C++03 is the perfect compromise.

  • I will still support the DeSmuME project for years to come. Even though my pace of development has slowed considerably due to personal time constraints, I'm still dedicated to this project. This means that I'm willing to modify the code of new developers writing in C++11 and later to use C99/C++03 instead, which I have already done numerous times. Because DeSmuME's core codebase doesn't naturally require advanced C++ features, the code modifications are quick and easy to do every time. It's never been a problem for me, and as far as users and other developers are concerned, it hasn't been a problem for them either.

That's all my thoughts on the matter. As I've already mentioned: I have everything working from VS2012 - VS2026, which incorporates @Jules-A's suggestion and modifies a few more files more than what this PR did. If you want, I can do the commit using @SimonAfek's PR as inspiration.

[zeromus]

C is awful but I don't mind sticking to an old c++. I just added a too-new smart pointer, feel free to reprogram it with manual memory management.

[rofl0r]

The C++ language standard should remain at its default settings (C++14 from VS2019 - VS2026).

i second that. myself and other got lots of systems with only C++14 compilers available, so let's not unnecessarily raise the bar. apart from that, C++20 is like 10 languages in one, and every contributor will use his favorite part/idiom but the maintainers will then have to understand whatever new language subset they used as soon as a change is desired.

[SimonAfek]

If you want, I can do the commit using @SimonAfek's PR as inspiration.

Totally fine by me.

[rogerman]

Implemented via commit 39f27d3, which incorporates changes from @SimonAfek and @Jules-A. Thanks!