In a comment to my discussion of the Windows 95 patch system, commenter word merchant wondered whether there were any Windows 3.1 programs or drivers that were so incompatible with Windows 95 that there was no point trying to patch them.
Yes, there were problems that were so bad that the program was effectively unfixable. The largest category of them were those which took various types of handles and figured out how to convert them to pointers, and then used those pointers to access (and sometimes modify!) the internal implementation details of those objects.¹ Not only did the implementation details change, but the mechanism they used to convert handles to pointers also stopped working because Windows 95 used a 32-bit heap for user interface and graphics objects, whereas Windows 3.1 used a 16-bit heap.
Sometimes the programs were kind enough to do strict version checks to confirm that they were running on a system whose internals they understood. Sometimes their version checks were themselves broken, like one program that assumed that if the Windows version is not 3.0, 3.1, or 2.1, then it must be 2.0!
There were other one-off problems, like programs which detoured APIs in a way that no longer worked, but the ones that dug into operating system internals were by far the most common.
¹ What’s particularly frustrating is the cases where the program did this to access internal implementation details, when the information they wanted was already exposed by a public and supported API.
I remember doing this once. I wanted to draw custom window title bars for a window I did not create, but I didn’t know how to tell whether the window’s caption was active or not; in particular, I needed to be able to query the current FlashWindow state during WM_NCPAINT.
The official way to do it probably involves tracking WM_NCACTIVATE messages using SetProp.
(The code wasn’t relevant to Windows 95, so I didn’t need it to work there.)
It’d be nice to have examples of that kind of applications, especially those that did strange things just to access what was made public by an API!
I know you’re limited in what you can expose here, but on the other hand I don’t think real names are needed.
“especially those that did strange things just to access what was made public by an API!”
You sound surprised. But function calls have an overhead, and (AIUI, having not been alive then) computers in the 80s and 90s were so constrained that people were willing to do unsupported things to elide a few opcodes.
Of course after this third-party vendors never coded version checks incorrectly ever again. Like major >= 5 and minor >= 1, which would prevent them from working properly on Windows Vista (6.0) or checking the version name started with "Windows 9" because surely the only versions of Windows with that prefix would be 95 and 98. Supposedly this is why Windows went from 7 -> 8 -> 8.1 -> 10.
And as for Windows 3.1 apps that were never updated, my candidate is: Win32s, a 32-bit runtime for Windows 3.1. It should be obvious why it was never supported (at least,...
Were these badly misbehaving programs somehow blocked, or were Windows 95 users free to run them and experience the inevitable crash?
As someone who created database for DOS using Ashton Tate and Borderlunds Dbase II through IV, and then mid 1980s, I seem to recall that Microsoft Access 1.0 through 2.0 were designed for 16-bit systems, such as Windows 3.1 and did not port to Windows 95 and its 32-bit system. I think Harvard Graphics 3.0 for DOS did not port well to Win95 either.