I'm going to go with buggy. It essentially broke WMR by introducing some kind of bug in their logging instrumentation that causes extreme stuttering unless you run a command line to stop the logger every time you plug in a headset. After almost two months they are supposedly releasing a patch in next week's dump to fix it. Now that is some laggardly response time for you.

The crazy thing is apparently it was a problem even back when 22H2 was an insider build. It's like they don't do QA anymore. Something tells me there isn't a team looking at 20+ year old games.

These big feature updates have always been a step forward and a step backward. Though I'm not sure what the step forward is this time 🤣

Does Microsoft even *care* about backwards compatibility with these things? I have had far better luck running a lot of these old games under Wine ever since I moved to Linux.

I always thought all the compatibility shims were doomed to be forever broken moving onward. It's why I stuck with Windows 7 as long as I've had.

swaaye wrote on 2022-12-03, 19:37:

These big feature updates have always been a step forward and a step backward. Though I'm not sure what the step forward is this time 🤣

I think it is "preventing GOG games from working" in name of security (through whatever is called, some isolation mode that only allowed some signed apps to run?)

DracoNihil wrote on 2022-12-03, 20:25:

Does Microsoft even *care* about backwards compatibility with these things? I have had far better luck running a lot of these old games under Wine ever since I moved to Linux.

I always thought all the compatibility shims were doomed to be forever broken moving onward. It's why I stuck with Windows 7 as long as I've had.

Things definitely get broke. The EmulateGetCommandLine shims works on usage of a DOS supported filename, but Windows 10+ doesn't guarantee it 🤣. Windows 7 had and has its fair share of problems, the most issues I had was with rundll32.exe as it is very lagged and causes external hooks to fail. For things supported on Win10 and 11, the support instead got better imo, but for things that were removed, you know the story (Ramp renderer, default short filenames, old DRMs)

DracoNihil wrote on 2022-12-03, 20:25:

Does Microsoft even *care* about backwards compatibility with these things? I have had far better luck running a lot of these old games under Wine ever since I moved to Linux.

That's one of the reasons why me next daily driver would be a Linux machine. Still holding on to Windows 7, but eventually there will be no more (new) hardware that supports it properly, and I couldn't always rely on new old stocks.

So for GTA gamers, the old titles such as Vice City and San Andreas has issues on multi-core systems. To avoid modding, I enabled the Windows 98/ME compatibility mode because the game works correctly with that mode, and it also supported that OS. Now guess what, that method doesn't work anymore (EmulateHeap in action), because of the same damn issue, heap exceptions on sound processing!

BEEN_Nath_58 wrote on 2022-12-04, 05:15:

I think it is "preventing GOG games from working" in name of security (through whatever is called, some isolation mode that only allowed some signed apps to run?)

The "memory integrity" / "core isolation" / HVCI thing? Breaks old drivers too like XFi cards and is part of why they want you on recent CPUs. It is annoying but it is easily disabled and is only on by default with the newest hardware. Maybe it has some value for protecting the typical helpless/hopeless userfolk.

swaaye wrote on 2022-12-04, 17:57:

BEEN_Nath_58 wrote on 2022-12-04, 05:15:

I think it is "preventing GOG games from working" in name of security (through whatever is called, some isolation mode that only allowed some signed apps to run?)

The "memory integrity" / "core isolation" / HVCI thing? Breaks old drivers too like XFi cards and is part of why they want you on recent CPUs. It is annoying but it is easily disabled and is only on by default with the newest hardware. Maybe it has some value for protecting the typical helpless/hopeless userfolk.

And that Smart App Control thing. On second boot, I was astonished why no aWin32 apps would run (first instance was in Bioshock). That's all the security upgrade we see in the surface; as always MS has implemented new security things, that don't make the headlines.

I took some time to test the games which had the problem. First of all, Program Compatibility Assistant does something with the application that changes the exception point. With that change, I managed to find an mss32.dll that takes the game to the main menu and then crashes, instead of crashing in the intro video. That doesn't improve things, but that points to what was done to have the same problem.

I will try and test most games on this issue. The most problematic scenario will be for those games, that have Win95 compatibility set by default, or EmulateHeap set by default, or a guide on the Internet to manually do either of the one. Now I am worried I can't read books in Longbow 2 anymore. The ddraw wrapper DirectDrawCompat had to add a WinVerifyTrust function so that the ddraw.dll doesn't crash games, this problem may relate to the EmulateHeap issue as well.

So I had Windows 11 updated today with a cumulative update, and they probably fixed one problem. Now MechWarrior 2 Autorun runs with the emulate heap shim enabled. You still lose the sound, but its better than aimlessly enabling 16-bit color mode or 640x480 video mode to achieve the same.

Some more discoveries...

It turns out the EmulateHeap crashes, that are occurring with Win95/98/ME compatibility modes, can be countered by setting a FaultTolerantHeap shim on the application. Note that this will disable the EmulateHeap part of the mode.

23H2 out, and EmulateHeap is still broken...

I went on and on upto the 2nd preview of Win11 22H2: 10.0.22454.1000 and the bug exists there too!