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.
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.