-1

For many years (long after the introduction of Windows XP) I ran a collection of old Windows 9x desktop PCs. Basically, these machines were too low-spec in their hardware to be upgraded to XP (and had cost a lot of money), so I continued to use them, with their original software: various installations of Windows 98SE and Windows ME (all running as 32-bit versions).

In the event, I never used XP. The Win9x machines were so reliable that they were still working long after XP and Vista had come and gone. But I eventually had to migrate, over a period of time, onto Windows 7 64-bit.

I am not about to do something really dumb, such as ask why such-and-such a program won't run on Win7 64bit! :-)

Without exception, all the software I had been running on 32bit Windows 98SE worked out-of-the-box (so to speak) on Win7's NT 64bit architecture. Today, I still use a variety of this software, especially the word processing programs and HTML editors that I use routinely.

Is there a technical reason why I never experienced the difficulties I had expected in running Windows 9x programs on 64bit NT? I've been told about 'compatibility' settings on Win7, but have never had to run a program in "compatibility-mode".

I'm aware of Windows 7 keeping 32-bit and 64-bit software in separate locations, and handling them differently: but I had expected that this was related to 32bit and 64bit programs written for Windows 7.

I am surprised that Windows 98 32bit programs seem to be entirely compatible with Windows XP/Vista/7 32bit programs, and would like to understand why this is so. Is there really no difference between them?

Also, many of the old Windows 9x programs were/are portable. I have been in the habit of putting them on USB sticks, or on the Windows 7 desktop, and just running them. I've not experienced any problems. Even though they are not being run from a Program Files folder. Again, I'd like to understand why does the O/S not object to this, from a technical perspective?

Am I doing anything unsafe? The Windows 7 O/S seems very stable: but I would like to know whether I am asking it to do things that I ought not to.

2 Answers 2

3

You must be the first user who complains because he/she has no problems whatsoever. ;)

While the mainstream media has gone to a great length to give Windows an undeserved reputation in app compatibility area, the fact is that Microsoft has invested greatly in backward compatibility and the vast majority of apps written for Windows 98 are still usable on Windows 7. Plus, Windows 7 is the most stable operating system Microsoft has ever developed. Make no mistakes, the difference between Windows 7 and Windows 98 is vast but:

  • Windows 98 took advantage of a rich Windows API which Microsoft didn't go out of its way to re-write just because! For example, the interface for drawing a rectangle on the screen, creating a window or displaying a menu bar is still the same.
  • Windows 7 has implemented measures intended to address the compatibility issues of the legacy software. One of them is the UAC Virtualization. Windows 98 apps wrote their app data to their installation folder. Windows 7 does not allow that anymore; however, for legacy apps, UAC Virtualization redirects the data writing operation outside the app installation folder to %LOCALAPPDATA%\VirtualStore.

Windows 98-era apps that no longer work in Windows 7 include 16-bit apps (which do not run on 64-bit Windows but sometimes run on 32-bit Windows) and apps that rely on either hacks or arcane legacy OS services.

5
  • 1
    tldr: They maintained API and ABI compatibility ;)
    – Journeyman Geek
    Jan 14, 2017 at 14:08
  • ... and implemented compatibility measures like UAC Virtualization
    – user477799
    Jan 14, 2017 at 14:18
  • @FleetCommand: I opened %LOCALAPPDATA%\VirtualStore and, curiously, the folder is empty. There are a ton of entries in its parent directory, %LOCALAPPDATA%, but zilch in \VirtualStore. Incidentally, I was being wholly accurate when I referred to using 32bit Win9x software, I long ago ditched any remaining legacy 16bit programs.
    – Ed999
    Jan 14, 2017 at 15:14
  • 1
    The lack of 16-bit support has to do with Intel's decision on how long mode works , and how it disables support for the instructions required for 16-bit applications to function when long mode is enabled. Which I realize is a random factoid
    – Ramhound
    Jan 14, 2017 at 19:18
  • 1
    @Ed999: Again, this can only be good! You have civilized apps as it stands. Of course, you did mention that "many of the old Windows 9x programs were/are portable" and "they are not being run from a Program Files folder". So, no UAC virtualization for file system. (We have UAC virtualization for Registry too.)
    – user477799
    Jan 15, 2017 at 5:07
1

You're asking a lot of questions here, some rather complex, but the basic answer is "Microsoft puts a ton of effort into maintaining backward compatibility". Honestly, a better question might be "why wouldn't it work?", since both Win9x and NT (including Win7) use the Win32 API and the x86 instruction set (AMD's 64-bit extensions to Intel's x86 instruction set are backward compatible; an "x64" processor running in 64-bit mode can also run 32-bit programs).

The most likely reason things wouldn't work would simply be because of access controls. Win9x didn't support any kind of access controls at all; any program could do anything it wanted to. Used maliciously, this made writing malware really easy. Used non-maliciously but lazily, this means a lot of developers wrote their programs such that the programs wrote data into their install folders. This is a bad idea for a number of different reasons, not least of which is security; on a "real" OS, the default location to which files are installed does not allow non-administrators to write to files, and you're supposed to run as a non-administrator except when installing/updating software.

Of course, this whole "write to the directory you're running from" thing is easy (I did say the devs were being lazy...) and yes, it also makes software "portable" in the sense that you can put it on a flashdrive (which is usually also completely lacking access controls, as they use variants of the FAT file system and FAT doesn't support file permissions). Running software this way is less secure than installing it to an access-restricted area and running it from there (as a non-admin user), but it's probably OK as long as you don't share the computer with other people.

As for why the OS doesn't object... why would you expect it to? Program Files isn't a special folder in any way, it's just the place where, by convention, you install programs. (This is actually a really stupid convention, because some software breaks if you install it to a location with spaces in its path, but maybe MS wanted to ensure developers weren't being quite that lazy...) The only special thing about Program Files is that on 64-bit systems, when 32-bit processes ask for the "Program Files" folder they actually get directed to the Program Files (x86) folder. Beyond that... the OS lets you run programs from anywhere that you, the user, have access to. Some programs intentionally install in your user profile, or in their own folder on the root of the drive (C:\Python27 is a common folder to see on a developer machine). Those programs work just fine.

4
  • I disagree a bit with your pounding on 'developer lazyness' - the security concepts were unknown or not required in those times, and a developer is typically not allowed to spend many hours for something deemed irrelevant. What you are doing is like blaming the people in the 17th century for not making the streets wide enough for cars. Otherwise good answer.
    – Aganju
    Jan 14, 2017 at 13:48
  • 1
    @Aganju: "Unknown" only if you knew nothing about the computing world, in which case you probably weren't a dev. The basic principles of security in a multi-user operating system date back to Multics, released in 1969. Unix, a simpler (but still secure) offshoot of the language, was first released in 1973 and widespread by the late 70s. Microsoft themselves sold Unix (Xenix) starting in 1980. the Windows NT family, which owes much to Unix (including in security), was first released in 1993 (Linux, BSD, and many other *nix OSes all existed by then). By 1998, there was no excuse for ignorance.
    – CBHacking
    Jan 14, 2017 at 23:49
  • I have been developing since the 70ies, but the people that pay the bills wouldn't want to hear about spending a penny on security. I only see this change since ~2005
    – Aganju
    Jan 14, 2017 at 23:51
  • 1
    @Aganju: As for "not required", that's completely false. It was as required then as it is now, and it is very much required. Win98 (or even 95, with some post-release upgrades) was ostensibly a multi-user system, for all that it had no mechanism for enforcing inter-user security. There was no protection against malicious software (and there was tons of malicious software). Businesses (and some homes) were using NT, though, which had those features. As for "many hours", umm, no. It's not exactly hard to write to %APPDATA%\ProgramName\Filename instead of just to Filename! Pure laziness.
    – CBHacking
    Jan 15, 2017 at 0:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .