11–20 of 424 posts
I wish there was a backwards compatibility option to give applications a “virtual display” which runs in a window, for old programs which only know how to run fullscreen at 1024x768.
however try running a game from the Windows 95/98 days and you've got a maybe 50/50 chance of it working
e.g. they changed the return code from BitBlt from 95/98 -> XP, they used to return the number of scanlines but switched it to a boolean
same with the heap management functions, directory traversal functions, etc
I wish there was a backwards compatibility option to give applications a “virtual display” which runs in a window, for old programs which only know how to run fullscreen at 1024x768.
I wish there was a backwards compatibility option to give applications a “virtual display” which runs in a window, for old programs which only know how to run fullscreen at 1024x768.
I can't find it right now, and no idea if it'd work on older things but there's some 3rd party app for Windows that will put a full screen game/app into a stretchable windowed mode.
I've always been sad that my old Mac software just won't run. It's one thing for Apple to move to new architectures. Maybe that was necessary. But when the emulators break after a few years, well, that's the part that bugs me. Microsoft's devotion to its customers shouldn't be so amazing-- it's the way that every company should behave.
yes it can run things that don't use much of the API surface (just using libc? probably fine) however try running a game from the Windows 95/98 days and you've got a maybe 50/50 chance of it working e.g. they changed the return code from BitBlt from 95/98 -> XP, they used to return the number of scanlines but switched it to a boolean same with the heap management functions, directory traversal functions, etc
Its famously determined, but I feel that a DOS CLI app isnt much of a challenge since the DOS subsystem is essentially ossified. What would be the result if, say, you tried to run something DOS-y that was demanding or an early Win16 app? Say, Zortech C++ from 1986 with the Pharlap DOS extender or Minesweeper from windows 3.1. Would they work?
That’s not a DOS app, it’s a Win32 console app. DOS apps (16-bit or 32-bit) or Win16 apps would not run natively.
I'm aware of win32s, I used to run it but still it seems unlikely this is a win32 console app unless there's an incredibly unlikely set of circumstances behind this.
Or perhaps it was simply recompiled after all despite what the Twitter post states?
yes it can run things that don't use much of the API surface (just using libc? probably fine) however try running a game from the Windows 95/98 days and you've got a maybe 50/50 chance of it working e.g. they changed the return code from BitBlt from 95/98 -> XP, they used to return the number of scanlines but switched it to a boolean same with the heap management functions, directory traversal functions, etc
Some stuff works fine. See https://twitter.com/mikko/status/1692552661374005450
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.