Knowing GOG they'll wait until the community finds a fix and then integrate it without much visibility to the original source of the fix.
They are right in a way that MS should update their sdb and fix their files/shims since MS is supposed to care about backwards compatibility but if they don't then the only solutions would be to modify the game and/or create wrappers and/or use emulators/ports.

Probably best best is visibility if you want MS to "fix". If you have a list of these games then make it known far and wide that Windows 11 is breaking games and the only response you are getting is the usual useless "repair Windows", well known websites reporting that Windows 11 is breaking games may have an effect.

DosFreak wrote on 2023-01-02, 14:17:

Knowing GOG they'll wait until the community finds a fix and then integrate it without much visibility to the original source of the fix.
They are right in a way that MS should update their sdb and fix their files/shims since MS is supposed to care about backwards compatibility but if they don't then the only solutions would be to modify the game and/or create wrappers and/or use emulators/ports.

Probably best best is visibility if you want MS to "fix". If you have a list of these games then make it known far and wide that Windows 11 is breaking games and the only response you are getting is the usual useless "repair Windows", well known websites reporting that Windows 11 is breaking games may have an effect.

I used the feedback hub tool to report, and I got an actual reply that basically said "lack of details". I reapplied on the feedback hub, with more details and test cases for them. I tried to explain them at as "beginner level" as possible since their reply looked like they heard things like it for the first time. Hopefully this gets seen by them as well, too bad their screenshot tool only allows 25 at most. The one who commented is an experienced engineer (you have probably seen some of his guides on the internet earlier) so him not knowing about this makes me wonder if they will even fix it.

And of course, it is not easy to make heap patches for every game, DxWnd did for Mech2 and Jane's Longbow and they still live on while being one of the buggiest, there was one made for Midtown Madness 2 as well...

I wouldn't expect Microsoft to care about the problem based on reports from gamers. They care if some enterprise software breaks, which might be the case if a compatibility mode is broken.

For gamers it's probably best to hope for someone to create a third party solution, I think hoping gho can eventually improve his implementation is the best bet, but it seems to work fine for M1 Tank Platoon 2 already?

Also not sure why you would think the GOG releases would be special; they very very rarely are and just use existing fixes.

BEEN_Nath_58 wrote on 2023-01-02, 15:03:

DosFreak wrote on 2023-01-02, 14:17:

Knowing GOG they'll wait until the community finds a fix and then integrate it without much visibility to the original source of the fix.
They are right in a way that MS should update their sdb and fix their files/shims since MS is supposed to care about backwards compatibility but if they don't then the only solutions would be to modify the game and/or create wrappers and/or use emulators/ports.

Probably best best is visibility if you want MS to "fix". If you have a list of these games then make it known far and wide that Windows 11 is breaking games and the only response you are getting is the usual useless "repair Windows", well known websites reporting that Windows 11 is breaking games may have an effect.

I used the feedback hub tool to report, and I got an actual reply that basically said "lack of details". I reapplied on the feedback hub, with more details and test cases for them. I tried to explain them at as "beginner level" as possible since their reply looked like they heard things like it for the first time. Hopefully this gets seen by them as well, too bad their screenshot tool only allows 25 at most. The one who commented is an experienced engineer (you have probably seen some of his guides on the internet earlier) so him not knowing about this makes me wonder if they will even fix it.

And of course, it is not easy to make heap patches for every game, DxWnd did for Mech2 and Jane's Longbow and they still live on while being one of the buggiest, there was one made for Midtown Madness 2 as well...

As someone who works at a company similar to MS I can say with confidence that the people who read these requests know how to do a handful of things and not much else. They aren't engineering, and there is a pretty good chance that any feedback going back to engineering is a long, convoluted path with an an engineer on the other end who has plenty on their plate already and isn't much interested in adding to it. There is also a good chance that MS knows exactly what they broke when they broke it and made a conscious decision to leave it broken anyway.

ZellSF wrote on 2023-01-04, 20:52:

I wouldn't expect Microsoft to care about the problem based on reports from gamers. They care if some enterprise software breaks, which might be the case if a compatibility mode is broken.

For gamers it's probably best to hope for someone to create a third party solution, I think hoping gho can eventually improve his implementation is the best bet, but it seems to work fine for M1 Tank Platoon 2 already?

Also not sure why you would think the GOG releases would be special; they very very rarely are and just use existing fixes.

On Feedback Hub, my problem was read but they asked me to report back with more details. Hopefully I didn't exhaust my quota to report an issue.

DxWnd implementation of EmulateHeap aka shim:EmulateWin9xHeap is just hooking EmulateHeap to DxWnd, it doesn't change the heap in any form and thus you won't see any source of it in the DxWnd sources too, just the hooking method is there. And no, it doesn't work fine for M1 Tank Platoon 2, it does for Win11 21H2 and earlier as it should but not on 22H2.

mothergoose729 wrote on 2023-01-04, 21:02:

As someone who works at a company similar to MS I can say with confidence that the people who read these requests know how to do a handful of things and not much else. They aren't engineering, and there is a pretty good chance that any feedback going back to engineering is a long, convoluted path with an an engineer on the other end who has plenty on their plate already and isn't much interested in adding to it. There is also a good chance that MS knows exactly what they broke when they broke it and made a conscious decision to leave it broken anyway.

The engineer who replied back was at least better than the sfcscannow guys, but he looked clueless for the most part; he should have known what a compatibility shim is and how to apply them on the aforementioned programs. Although I said "applications crash", they asked to "describe the issue I was facing". Let's see what comes up next, memory violations are something that I am pretty sure everybody hates to handle.

BEEN_Nath_58 wrote on 2023-01-05, 07:48:

DxWnd implementation of EmulateHeap aka shim:EmulateWin9xHeap is just hooking EmulateHeap to DxWnd.

DxWnd has a "Virtual Heap" option (compat tab), I'm not sure what it does but it works for M1 Tank Platoon 2. I'm guessing it does some part of what Microsoft's heap emulation does.

ZellSF wrote on 2023-01-05, 09:44:

BEEN_Nath_58 wrote on 2023-01-05, 07:48:

DxWnd implementation of EmulateHeap aka shim:EmulateWin9xHeap is just hooking EmulateHeap to DxWnd.

DxWnd has a "Virtual Heap" option (compat tab), I'm not sure what it does but it works for M1 Tank Platoon 2. I'm guessing it does some part of what Microsoft's heap emulation does.

It does but that crashes just like EmulateHeap. However you gave me an idea, and now it turns out the MechWarrior 2 heap (patch:SafeHeap) is able to run the game.

BEEN_Nath_58 wrote on 2023-01-05, 10:47:

ZellSF wrote on 2023-01-05, 09:44:

BEEN_Nath_58 wrote on 2023-01-05, 07:48:

DxWnd implementation of EmulateHeap aka shim:EmulateWin9xHeap is just hooking EmulateHeap to DxWnd.

DxWnd has a "Virtual Heap" option (compat tab), I'm not sure what it does but it works for M1 Tank Platoon 2. I'm guessing it does some part of what Microsoft's heap emulation does.

It does but that crashes just like EmulateHeap.

It works fine for me. Where is it supposed to crash?

ZellSF wrote on 2023-01-05, 10:49:

BEEN_Nath_58 wrote on 2023-01-05, 10:47:

ZellSF wrote on 2023-01-05, 09:44:

DxWnd has a "Virtual Heap" option (compat tab), I'm not sure what it does but it works for M1 Tank Platoon 2. I'm guessing it does some part of what Microsoft's heap emulation does.

It does but that crashes just like EmulateHeap.

It works fine for me. Where is it supposed to crash?

Start the game, crash before the menu. And yes, Win11 22H2 if you don't have it.

With a debugger-
Unhandled exception at 0x1003F2C8 (dxwnd.dll) in M1TP2.exe.noshim(1).2944.dmp: 0xC0000005: Access violation writing location 0x01040790.

I can play the game just fine, so there's something wrong with your setup. It gets ingame. With 3D rendering, sound and all that fancy stuff.

Just to be obvious: you need to disable shims when using virtual heap, and the game seems to need async blit.

ZellSF wrote on 2023-01-05, 10:59:

I can play the game just fine, so there's something wrong with your setup. It gets ingame. With 3D rendering, sound and all that fancy stuff.

Just to be obvious: you need to disable shims when using virtual heap, and the game seems to need async blit.

Don't know, I just tested on a Win11 22H2 VM and it crashes at menu. Once I enable SafeHeap, it works just fine. Yes I disabled shims before using virtual heap, tbh I never got virtual heap to work in most apps ever.

MS Application Compatibility Toolkit (MS ACT) will allow you to edit the supplied fix and fiddle with different shims. It's a .sdb file included on the game's folder. ACT is included on the lastest Windows ADK (Assessment and Deployment Kit).
I've been having issues with GOG games myself too, but I'm not sure if these are related to compatibility modes.

filipetolhuizen wrote on 2023-01-22, 17:35:

MS Application Compatibility Toolkit (MS ACT) will allow you to edit the supplied fix and fiddle with different shims. It's a .sdb file included on the game's folder. ACT is included on the lastest Windows ADK (Assessment and Deployment Kit).
I've been having issues with GOG games myself too, but I'm not sure if these are related to compatibility modes.

The specific issue is with Windows 9X heap management. There's no alternative shim to it other than EmulateHeap

ZellSF wrote on 2023-01-04, 20:52:

I wouldn't expect Microsoft to care about the problem based on reports from gamers. They care if some enterprise software breaks, which might be the case if a compatibility mode is broken.

For gamers it's probably best to hope for someone to create a third party solution, I think hoping gho can eventually improve his implementation is the best bet, but it seems to work fine for M1 Tank Platoon 2 already?

Also not sure why you would think the GOG releases would be special; they very very rarely are and just use existing fixes.

Exactly! That’s why I always have a older version of Windows available to play these games. Sad but that’s the only thing you can really rely on.

Luckily GOG has offline installers for the case that a game would work best on a OS that no longer supports GOG Galaxy… shame on you Steam 😁

Retroview wrote on 2023-01-22, 23:36:

ZellSF wrote on 2023-01-04, 20:52:

I wouldn't expect Microsoft to care about the problem based on reports from gamers. They care if some enterprise software breaks, which might be the case if a compatibility mode is broken.

For gamers it's probably best to hope for someone to create a third party solution, I think hoping gho can eventually improve his implementation is the best bet, but it seems to work fine for M1 Tank Platoon 2 already?

Also not sure why you would think the GOG releases would be special; they very very rarely are and just use existing fixes.

Exactly! That’s why I always have a older version of Windows available to play these games. Sad but that’s the only thing you can really rely on.

That's why I got into virtualization in the 2000s.
At some point, the most reliable way of run something is by re-creating the original environment it was made for.
In case of Windows, this might be Windows 3.1+16 Bit QuickTime or Windows 95 RTM+32-Bit QuickTime. Or Win31/95+WinG.
I especially say Windows 95 RTM here, because early 3D games pre-date DirectX and use S3D or Metal or one of the other 3D APIs.
Same goes for DirectX versions. Certain games were written with DirectX 1, 2/3, 5, 6 etc in mind and may not work correctly with later versions.
In such a situation, a little Windows 9x VM can be helpful - even without hardware acceleration. The software rasterizer will run via GDI/CPU.

Awesome info! Also great to point out the DirectX Versions.
I also have seen that some just don’t work as good as others for certain games. It also depends on your hardware. For example, in Might and Magic 7 my SB live 5.1 resets to 2 speakers from 5.1 speakers when I start the game with DX8 installed. Same Conputer with DX7.1 does NOT do this…
Also when you use a Voodoo5 it‘s a good idea to stay approx at DX 7 and 8. Often higher versions don’t make sense anyway because the games that need DX9 are to demanding for the old hardware… Virtual machines are good solutions, too. Sadly they don’t work for 3D right? I never tried much in that area, I always kept previous PCs as much as possible and have quite a collection today 🤣

ZellSF wrote on 2023-01-04, 20:52:

I wouldn't expect Microsoft to care about the problem based on reports from gamers. They care if some enterprise software breaks, which might be the case if a compatibility mode is broken.

Honestly enough, I don't think they are much all that useful to businesses either (unless you are literally paying their engineers by the hour).
Through some sheer happenstance, I got lucky enough to get a free pass to their tier-2 support, in turn getting me in touch with some tier-3 guy.
No matter what I was trying to explain to them about even their documentation being wrong, they didn't seem to comprehend. Not our monkeys, not our problem, amirite?

Jo22 wrote on 2023-01-23, 01:14:

That's why I got into virtualization in the 2000s.
At some point, the most reliable way of run something is by re-creating the original environment it was made for.

Meanwhile you can install DOSEMU2 in linux, and you could literally run 40yo programs natively.

Jo22 wrote on 2023-01-23, 01:14:

In case of Windows, this might be Windows 3.1+16 Bit QuickTime or Windows 95 RTM+32-Bit QuickTime. Or Win31/95+WinG.

It would certainly be pretty funny if those happened to work with ntvdmx64 or winevdm (even though they are both technically emulated).

Retroview wrote on 2023-01-23, 21:18:

Virtual machines are good solutions, too. Sadly they don’t work for 3D right? I never tried much in that area, I always kept previous PCs as much as possible and have quite a collection today 🤣

Hi there! 3D acceleration isn't absolutely required for DirectX up to 6.1 or 7.
Up to this level, the software renderer in DirectX is fully capable of doing this all on its own.
Generally speaking, of course. Maybe there are exceptions.
What I mean to say is, that at the time, the software renderer was the reference, still.
3D hardware was still catching up with the Direct3D software renderer.
For a short time, MMX (introduced with later Pentiums) was able to assist DirectX, too. Or so it seemed.
Together with DirectDraw and a 2D accelerating graphics card, Direct3D did its magic*.
By the end of the 90s, the tides slowly turned. It was the 3D hardware which then took the lead.

Edit: Edited. OpenGL, Glide/MiniGL and other APIs existed in parallel, too.
Especially in the early Windows 95 days, various graphics APIs competed with each others.
Windows 98SE included OpenGL v1.1, albeit merely software rendered by default.
An update was available for Windows 95 OSR2, too.

Edit: Beware of VBE9x, as a video driver for Windows 9x in modern virtualizers.
VESA VBE is dog slow. I used it on Linux in the past, on real hardware. Everything used to cause a huge CPU utilization.
While VBE is nice as a fall-back, it's unsuitable for gaming. That's what VBE/AF was intended for.
At common desktop resolutions of 1024x768 up to 1600x1200 pixels, the pixel data to be handled unaccelerated solely by the CPU is just huge (an old S3 Trio as an accelerator runs circles around it).
Unfortunately, VBE/AF never made it. It was too late. Windows was already providing 2D acceleration back then, making it seem superfluous in the software industry.

(*That's why Virtual PC 2004/2007 used to so nice as a Windows 9x virtualizer, by the way.
The emulated hardware included an S3 Trio card, a fine 2D GUI accelerator.
It was chosen by Connectix in the 90s, when Virtual PC was meant to emulate a PC on a Power PC Macintosh.
Windows 95 was what Virtual PC aimed to support best.
Versions 2 and 3 could pass-through Voodoo 1 and 2 cards, because the endian-nes was compatible.
That's why Virtual PC was so much better for 9x than VMware and Virtual Box.
The emulated hardware was DOS/Win9x friendly. And OS/2 friendly, too.)

Retroview wrote on 2023-01-23, 21:18:

Awesome info! Also great to point out the DirectX Versions.
I also have seen that some just don’t work as good as others for certain games. It also depends on your hardware. For example, in Might and Magic 7 my SB live 5.1 resets to 2 speakers from 5.1 speakers when I start the game with DX8 installed. Same Conputer with DX7.1 does NOT do this…
Also when you use a Voodoo5 it‘s a good idea to stay approx at DX 7 and 8. Often higher versions don’t make sense anyway because the games that need DX9 are to demanding for the old hardware… Virtual machines are good solutions, too. Sadly they don’t work for 3D right? I never tried much in that area, I always kept previous PCs as much as possible and have quite a collection today 🤣

Ryzen doesn't even let Win9x to work through virtualization because of missing/broken cpu instructions