Visual Studio 2026

[UCyborg]

Older build tools from VS 2022 are still available, so presumably you can use VS 2026 and compile Win7 compatible binaries.



Even Windows XP stuff.

[Moonchild]

Unless you intend to use new features from VS2026's IDE or what not, there's no real reason to upgrade and then using the older toolchains as it won't actually provide a benefit to the resulting compilation.

[UCyborg]

I'm aware.

I haven't used Visual Studio for me in about a decade now. Last time I did, I used 2015 version. Being a student at the time, MS was generous and gave me the version costing thousands for free. Of course, I probably never used most of its features. But for most of my old game hacking projects, I used MS Visual C++ 6.0 from, shall we say, third-party sources. With SP5 + Processor Pack. It generates lean binaries linked with msvcrt.dll, which you only have to install on old versions of Windows 95, but it's been part of Windows ever since, no extra dependencies.

The project at work is bound to be updated to .NET 10 because of course the end of support for .NET 8 is the total end of the world. /S Guess I'll have to warn on the chance I encounter the customer with NT 6.x system. Even if .NET 10 happens to still work, there's dependency on some C++ stuff that will be built with new toolchain. And compatibility goes despite there hardly being any really good reason for it to go.

[UCyborg]

The latest and greatest...it still happens at times that I edit some code, then start the program with debugging, set a breakpoint and it tells me the source code doesn't match the actual program. Then I stop the program (that I'm debugging), start it again and then it works.

Funny that workplace chases latest build tools...but still uses freaking Subversion. TortoiseSVN tends to randomly complain about directory being locked (by itself) and to run clean up. Yesterday, it even crashed out of the blue and opened their website, which said my version is not supported...but it's the latest. It's possible I don't have JavaScript whitelisted, in case it depends on it to work right.

Bleh! Git (and TortoiseGit) just works. At least I don't remember ever having any random problem with it. Besides being unable to clone that Subversion monstrosity of a repo to Git with git svn on Windows.

More on topic, I didn't find anything specific written on the website regarding running Pale Moon under Visual Studio's debugger. Do you just build it according to usual instructions, run the browser, then use the attach to process option in Visual Studio? Asking because most things I messed with came with Visual Studio solution. Or it was generatable with CMake.

[Moonchild]

I didn't find anything specific written on the website regarding running Pale Moon under Visual Studio's debugger. Do you just build it according to usual instructions, run the browser, then use the attach to process option in Visual Studio?

Yeah if I actively debug code I build and mach run, with the symbol path set to the appropriate objdir in VS if it needs that (usually it finds them automatically), and attach the debugger to the running process. It just works grabbing any crashes or breakpoints. I use the same method investigating reported crash addresses (but then of course running release and pointing symbols paths to the release objdir)

[UCyborg]

Ok, one more question regarding ATL and MFC. They seem to come in two variants, with and without Spectre mitigations. Generally, do you decide to use one or another? I'm puzzled by the part of instructions for building Pale Moon dealing with 32-bit build, where for ATL, it says to install both.