Some Windows 3.1 apps were simply "too evil" for Windows 95 to support, says Microsoft veteran

[Alfonso Maruccia]

Micro-Soft: In an attempt to cater to a larger number of PC users, Windows 95 developers tried their hardest to keep existing software up and running in the new operating environment. But for some specific software products, maintaining compatibility was an unattainable goal.

Microsoft veteran Raymond Chen is once again spilling the beans on how Windows 95 became one of the most influential operating systems ever. Back in the Nineties, Microsoft developers were busy working on many custom solutions to make the new OS compatible with previous software products. However, a few programs designed to run on Windows 3.1 were not going to work with Windows 95 no matter what.

Chen recently answered a visitor who asked about some applications or drivers that were simply too "evil" to run on Windows 95. The Microsoft developer said that these troublesome programs did indeed exist, and they were so bad that no fix was possible under Windows 95. The unnamed products were simply going to be completely incompatible with the new operating system.

The largest category of totally incompatible programs included products that were doing some weird things with memory and memory allocation, Chen said. These evil programs were taking various types of handles, which refer to memory resources already in use by the OS, and converting them into pointers storing a memory address. These pointers were then used to access or modify the internal implementation details of the original objects.

Chen explained that the programs were taking roundabout routes to access internal implementation details, which were already exposed by public, officially supported APIs to begin with. The mechanism used to convert handles into pointers in Windows 3.1 did not work in Windows 95 because the new OS used a 32-bit heap for memory allocation tasks while Win 3.1 used a 16-bit heap.

Other incompatible programs were performing some broken OS version checks – they assumed they were running on Windows 2.0 because the currently running system was not identified as Windows 3.0, 3.1, or 2.1. The Microsoft veteran confirmed that the programs having the most common compatibility issues were the ones designed to mess with the operating system's innermost parts.

The Windows 95 team had to ensure compatibility with three different software architectures: MS-DOS executable programs, 16-bit Windows applications, and brand-new 32-bit Win32 software. The mission was somewhat accomplished, and Windows 95 became the fundamental building block of Microsoft's everlasting reign over the PC software industry.

Redmond programmers employed every kind of weird programming "trick" to improve Windows 95 compatibility, including the adoption of compatibility flags, special operating modes, and on-the-fly in-memory patches to the original misbehaving code. As Chen's posts often reveal, the widespread stability problems every Win9x user has experienced over the years were just an unfortunate consequence of this herculean coding effort.

Permalink to story:

Some Windows 3.1 apps were simply "too evil" for Windows 95 to support, says Microsoft veteran

 

[Plutoisaplanet]

Playing with pointers to memory locations is something that continues to this day on Windows 11. It was really just the fact that addresses would need to be stored in a 32 bit number (0-4B) instead of a 16 bit number (0-65535). Back then, this was way more common with C.

 

[GeoffreyA]

Playing with pointers to memory locations is something that continues to this day on Windows 11. It was really just the fact that addresses would need to be stored in a 32 bit number (0-4B) instead of a 16 bit number (0-65535). Back then, this was way more common with C.

Handles were meant to be opaque on Windows.

 

[Plutoisaplanet]

Handles were meant to be opaque on Windows.

And yet it is still possible to write to arbitrary memory directly without handles, and with Windows 3.1 this was obviously common enough to render programs that did this incompatible with a 32 bit address space.

 

[GeoffreyA]

And yet it is still possible to write to arbitrary memory directly without handles, and with Windows 3.1 this was obviously common enough to render programs that did this incompatible with a 32 bit address space.

Accessing memory through pointers is standard practice in C and C++, and with Win16's segmented memory, a lot of pointer arithmetic was done. But Windows handles are opaque by specification, and one is supposed to access the resource through the API. Of course, one could try to access the OS's data structures by converting handles to pointers, but that would be breaking the API's contract, that the handle is opaque, and coding to an implementation detail. So, when the implementation details changed, such code broke.

 

[J Oelschl]

I had to write a loader to load programs into EMM memory in 64k pages because we could not fit our entire application into the amount of memory available. So the loader would load 64k chunks of the into the EMM AND THEN BEFORE THE CODE WAS EXECUTED I had to make sure the proper EMM page was loaded before calling whatever routine was needed. One other crazy thing I did was to use 64k on the graphics card to store some "extra code". I dont remember the reason but I still have the code here someplace. Fun times some of the crazy stuff we had to do.

 

[Endymio]

I had to write a loader to load programs into EMM memory in 64k pages because we could not fit our entire application into the amount of memory available. So the loader would load 64k chunks of the into the EMM AND THEN BEFORE THE CODE WAS EXECUTED I had to make sure the proper EMM page was loaded before calling whatever routine was needed. One other crazy thing I did was to use 64k on the graphics card to store some "extra code".

I have somewhere a Dr. Dobbs editorial from the early 80s, in which the author was angry -- literal tooth-gnashing rage -- over PCs being released with more than 64K of RAM. His rationale was that, since any computer program could be written in less space than that, the extra memory would simply encourage 'sloppy programming practices'.

 

[amghwk]

What ARE those programs that cause these issues in Win9x??

 

[bviktor]

I have somewhere a Dr. Dobbs editorial from the early 80s, in which the author was angry -- literal tooth-gnashing rage -- over PCs being released with more than 64K of RAM. His rationale was that, since any computer program could be written in less space than that, the extra memory would simply encourage 'sloppy programming practices'.

He wasn't wrong. Look at VS Code. GPU accelerated, eats up gigs of RAM, and still way slower than... Notepad++.

 

[scoffer]

Ah.........I remember my youthful days........POKEs and PEEKs on my trusty Atarai 800...........

 

[GeoffreyA]

He wasn't wrong. Look at VS Code. GPU accelerated, eats up gigs of RAM, and still way slower than... Notepad++.

Being frugal has gone out of the window with web-based languages, frameworks, and abuse of object-oriented style, along with modern computers masking the performance problems.

 

[GrayDragon]

Being frugal has gone out of the window with web-based languages, frameworks, and abuse of object-oriented style, along with modern computers masking the performance problems.

And don't even get me started on formatted email. Bunch of crap that could just be text and not hide viruses and such.