One thing I didn't see mentioned was that the resolution of text mode was typically higher than that of graphics mode. This is possible because it uses less RAM on the video card.
80x25 uses 720x400, whereas the default graphics modes were 640x480@4bpp or 320x200@8bpp.
Nothing wrong with text mode. Also, see some amazing uses of text mode in Scream Tracker 3 [1] or text-mode demos or intros, such as Yo! by The Future Crew [2].
I absolutely understand this. However, was there any particular reason why 9x used 3.1 as it's preinstallation environment, as opposed to booting 9x directly? AFAIK, this imposed a lot of very specific restrictions on filename lengths because the preinstall environment didn't understand FAT32 LFN extensions.
In comparison, the preinstall environment for the NT line was always just NT. Same for Linux and Mac OS[0].
[0] OS 9's install media was actually a live CD, funnily enough, mainly because that OS was about as technically sophisticated as Windows 3.x.
I think they already had the 3.x kernel as a modular component, and it was of course smaller than 95 - remember that they had a floppy version of the Windows 95 installation media (a dozen of them). It's well known that 3.x is small enough to boot and run from a floppy, but perhaps 95 was just a bit too big for that: https://news.ycombinator.com/item?id=39489748
Also the 3.1 part is already designed to facilitate upgrades from Windows 3.1, which means that there is no need for debugging two paths (3.1 installer for the 3.1 upgrade path and the theoretical straight-to-95 brand-new installer).
Raymond Chen has an article on this as well[1], the TL;DR is that you have 3 different upgrade paths (i.e. the text mode portions for a clean install, the Win16 portion for a 3.1 -> 95 upgrade, or the Win32 portion for a 95 -> 95 upgrade)
If we're making compromises anyways we could just do text mode right away and move as much as possible to the final stage. NT managed to do so just fine until Vista, including the home-user targeting XP.
> What if I told you that Microsoft already had an operating system that did all the things you are trying to do, and it’s fully debugged, with video drivers, a graphics library, a dialog manager, a scheduler, a protected mode manager, and input methods. And it has a fully staffed support team.
I thought this was going a different place. Surely if you want to run an operating system, running Windows 95 itself would make more sense - then you could e.g. use the same drivers for setup that you're going to use in the real system.
> At the other extreme, you can write Windows 95 setup as a 32-bit GUI program, but that means that if the user is starting from MS-DOS or Windows 3.1, you have to install Windows 95 before you can run Windows 95 setup, which is a bit of a catch-22.
Back then a lot of the time you couldn't just boot from the Windows 95 CD-ROM; a lot of BIOSes didn't support bootable CDs yet, and would have to use a boot floppy as a shim. This would necessitate booting to a MS-DOS environment.
Also, if you didn't have partitions set up, you'd need to use MS-DOS FDISK and FORMAT to get things started, too. No way you'd have enough space in RAM to decompress and cram the entire Win95 UI into RAM to run it.
All in all, it makes more sense to go with the lightweight Win 3.1 intermediary step to bootstrap to the next phase.
That's because Linux is remarkably bad at backward compatibility rather than Windows being remarkably good at it. FreeBSD's stable ABI is if anything better than PE+Wine.
That's too much overbearing for Linux, as the kernel itself tries to maintain backwards compatibility (for userland). It's everything else that breaks backwards compatibility (looking at the most egregious, Gnome, although there are many system-level libraries sharing the blame for this).
Linux distributions tend not to ship them - AIUI there is some unique problem with linux ld that makes it harder to have multiple versions of the same library installed. And lately there's a lot of tight coupling in the whole kernel/udev (or hal, remember hal?)/systemd chain, so even if old dynamic libraries are available, old dbus services might not be and you end up in much the same place.
The lines that follow that only makes the statement worse.
> (Or, if you are being uncharitable, you’re writing an MS-DOS shell.)
> An operating system with exactly one application: Windows 95 Setup.
It's basically what every DOS graphics program has been doing before Windows. I'd say the article is being uncharitable here--a setup program isn't an OS. I'm sure MS made enough from Win 3.x to cover a graphical DOS setup program.
Microsoft actually used Windows as graphical shells for "DOS" applications, it was in fact major source of sales for windows before release of Windows 3.0.
Reusing windows 3.x runtime is exactly what you're telling they should have done, except with less reinventing the wheel and being able to reuse all sorts of drivers including for hardware that wasn't exactly ibm pc compatible (like Japanese specific high resolution video)
MS didn't get rich by writing code they didn't need to.
(Although the Win 95 upgrade process from the previous blog sounds like an example of code they didn't have to write. I wonder why they didn't have the floppies directly load a "Win 95 PE" environment into RAM then run the installer on that.)
For one thing, I'm fairly sure they didn't yet have a PE environment ready to go; another would probably be a lack of RAM. Installing it to disk first lets you load as needed, instead of all at once.
We're talking about making a single setup program that runs in DOS+VGA. None of that's needed. As for the RAM you can assume minimum requirements for Windows 95. Also C compilers (e.g. Watcom) came with DOS 16M memory extender bundled to use 16MB of it as early as 1989.
> Windows setup still follows this pattern of installing a miniature operating system to bootstrap the setup program. But today, the miniature operating system is Windows PE, the Windows Preinstallation Environment.
So, 30 years later, Microsoft followed the approach the article mocks?
Support for USB controllers in DOS and Win3.1 is, of course, basically nonexistent. However, with the correct BIOS settings, a USB storage volume can be treated as a conventional hard drive (naturally requiring a traditional, non-GPT partition table, and will only mount sub-2GB FAT16 partitions).
I've got a bootalble thumbdrive, in fact, set up with Syslinux, and an option to boot a DOS 6.22 drive image (with Win3.1 installed) via memdisk. It works, but on modern hardware, can typically only use standard VGA or VESA video modes, and modern HDA audio devices are usually not AC97 or SB compatible, so usually no audio but PC speaker.
One thing I didn't see mentioned was that the resolution of text mode was typically higher than that of graphics mode. This is possible because it uses less RAM on the video card.
80x25 uses 720x400, whereas the default graphics modes were 640x480@4bpp or 320x200@8bpp.
Nothing wrong with text mode. Also, see some amazing uses of text mode in Scream Tracker 3 [1] or text-mode demos or intros, such as Yo! by The Future Crew [2].
[1] https://en.m.wikipedia.org/wiki/Scream_Tracker
[2] https://m.youtube.com/watch?v=A8S4-H_8ZA8
If you look at the Microsoft "developer blogs", almost all of them just post product updates. Not so Raymond Chen. He actually blogs.
His series on the peculiarities of developing NT for MIPS, Alpha, and Itanium was an experience.
I felt like I was listening to a wizard recounting ancient lore of monsters that roamed the earth and were conquered.
I absolutely understand this. However, was there any particular reason why 9x used 3.1 as it's preinstallation environment, as opposed to booting 9x directly? AFAIK, this imposed a lot of very specific restrictions on filename lengths because the preinstall environment didn't understand FAT32 LFN extensions.
In comparison, the preinstall environment for the NT line was always just NT. Same for Linux and Mac OS[0].
[0] OS 9's install media was actually a live CD, funnily enough, mainly because that OS was about as technically sophisticated as Windows 3.x.
I think they already had the 3.x kernel as a modular component, and it was of course smaller than 95 - remember that they had a floppy version of the Windows 95 installation media (a dozen of them). It's well known that 3.x is small enough to boot and run from a floppy, but perhaps 95 was just a bit too big for that: https://news.ycombinator.com/item?id=39489748
Also the 3.1 part is already designed to facilitate upgrades from Windows 3.1, which means that there is no need for debugging two paths (3.1 installer for the 3.1 upgrade path and the theoretical straight-to-95 brand-new installer).
Raymond Chen has an article on this as well[1], the TL;DR is that you have 3 different upgrade paths (i.e. the text mode portions for a clean install, the Win16 portion for a 3.1 -> 95 upgrade, or the Win32 portion for a 95 -> 95 upgrade)
[1]: https://devblogs.microsoft.com/oldnewthing/20241112-00/?p=11...
AFAIK this was based on Windows 3.1 standard mode which was small enough to package in a mini.cab.
I need dialog boxes, yes.
Do I really need character input? Username and such could be done in the final setup stage that already uses the new install.
The "fancy new controls" work sounds like it happened anyway.
Those simple animations don't sound like they need a real scheduler, and I'm very skeptical of the idea that the above won't fit into 640KB.
I'm not saying a 3.1 runtime is the wrong choice, but I think the article might be exaggerating the amount of work by a lot.
If we're making compromises anyways we could just do text mode right away and move as much as possible to the final stage. NT managed to do so just fine until Vista, including the home-user targeting XP.
> What if I told you that Microsoft already had an operating system that did all the things you are trying to do, and it’s fully debugged, with video drivers, a graphics library, a dialog manager, a scheduler, a protected mode manager, and input methods. And it has a fully staffed support team.
I thought this was going a different place. Surely if you want to run an operating system, running Windows 95 itself would make more sense - then you could e.g. use the same drivers for setup that you're going to use in the real system.
From the original article:
> At the other extreme, you can write Windows 95 setup as a 32-bit GUI program, but that means that if the user is starting from MS-DOS or Windows 3.1, you have to install Windows 95 before you can run Windows 95 setup, which is a bit of a catch-22.
Back then a lot of the time you couldn't just boot from the Windows 95 CD-ROM; a lot of BIOSes didn't support bootable CDs yet, and would have to use a boot floppy as a shim. This would necessitate booting to a MS-DOS environment.
Also, if you didn't have partitions set up, you'd need to use MS-DOS FDISK and FORMAT to get things started, too. No way you'd have enough space in RAM to decompress and cram the entire Win95 UI into RAM to run it.
All in all, it makes more sense to go with the lightweight Win 3.1 intermediary step to bootstrap to the next phase.
Plus I imagine win95 was still under development while they were writing the installer. Better to grab a mature component.
Windows 95 was also shipped on like 15 floppy disks so there was no live booting beyond the dos bootstrap disk
Some versions over 20!
https://www.reddit.com/r/RetroWindowsGaming/comments/ddwcz9/...
It is curious that you can upgrade all versions of Windows in a sequence and it does work.
Not anymore. Microsoft dropped 32-bit support and there is no 32-bit to 64-bit upgrade path other than a fresh installation.
None that are official anyway, there are ways to trick Windows into doing a 32 => 64 bit conversion. Very unsupported, but it is possible.
Looks like we both commented this at about the same time :)
Can you update from 32-bit Windows to 64 bit Windows? Windows 11 is 64-bit only, so the chain might be broken.
This isn't that surprising. Each new version of windows that came along had great effort put into allowing existing users to upgrade each time.
Rather than one big hugely impressive thing, it's less than ten pretty impressive things in sequence.
Microsoft is, generally, very very good at backward compatibility.
Indeed, PE+Wine is the most stable Linux ABI.
That's because Linux is remarkably bad at backward compatibility rather than Windows being remarkably good at it. FreeBSD's stable ABI is if anything better than PE+Wine.
That's too much overbearing for Linux, as the kernel itself tries to maintain backwards compatibility (for userland). It's everything else that breaks backwards compatibility (looking at the most egregious, Gnome, although there are many system-level libraries sharing the blame for this).
nothing stops you from using the old libraries and all that stuff forever?
Linux distributions tend not to ship them - AIUI there is some unique problem with linux ld that makes it harder to have multiple versions of the same library installed. And lately there's a lot of tight coupling in the whole kernel/udev (or hal, remember hal?)/systemd chain, so even if old dynamic libraries are available, old dbus services might not be and you end up in much the same place.
As are most commercial UNIXes.
> Microsoft is, generally, very very good at backward compatibility.
It was. A long time ago. Running old games in Win10 has become a big challenge.
Haha, I had to look up to see...
https://www.youtube.com/watch?v=jdnqoVd7wY8
There's nothing wrong in principle with the text interface installer.
I liked it, back then.
I'd definitely prefer drawing dialogs manually using some basic graphics library (e.g. BGI for Turbo Pascal and C) over Windows 3.1.
Visual Basic for DOS was released in 1992, was from Microsoft, and had a very Windows-like TUI with a form designer and all.
They could have used that…
Why?
> Now take a step back and look at what you’re doing. You’re writing an operating system.
Whoa whoa whoa, buddy. I'm a software developer. I don't take a step back and look at what I'm doing. I don't even know what I'm doing half the time.
The lines that follow that only makes the statement worse.
> (Or, if you are being uncharitable, you’re writing an MS-DOS shell.)
> An operating system with exactly one application: Windows 95 Setup.
It's basically what every DOS graphics program has been doing before Windows. I'd say the article is being uncharitable here--a setup program isn't an OS. I'm sure MS made enough from Win 3.x to cover a graphical DOS setup program.
Microsoft actually used Windows as graphical shells for "DOS" applications, it was in fact major source of sales for windows before release of Windows 3.0.
Reusing windows 3.x runtime is exactly what you're telling they should have done, except with less reinventing the wheel and being able to reuse all sorts of drivers including for hardware that wasn't exactly ibm pc compatible (like Japanese specific high resolution video)
MS didn't get rich by writing code they didn't need to.
(Although the Win 95 upgrade process from the previous blog sounds like an example of code they didn't have to write. I wonder why they didn't have the floppies directly load a "Win 95 PE" environment into RAM then run the installer on that.)
For one thing, I'm fairly sure they didn't yet have a PE environment ready to go; another would probably be a lack of RAM. Installing it to disk first lets you load as needed, instead of all at once.
We're talking about making a single setup program that runs in DOS+VGA. None of that's needed. As for the RAM you can assume minimum requirements for Windows 95. Also C compilers (e.g. Watcom) came with DOS 16M memory extender bundled to use 16MB of it as early as 1989.
> MS didn't get rich by writing code they didn't need to.
Well, they didn't always follow that rule of thumb:
https://en.wikipedia.org/wiki/List_of_Easter_eggs_in_Microso...
> Windows setup still follows this pattern of installing a miniature operating system to bootstrap the setup program. But today, the miniature operating system is Windows PE, the Windows Preinstallation Environment.
So, 30 years later, Microsoft followed the approach the article mocks?
Presumably Windows PE is much more suited to computers 30 years newer than what Windows 3.1 ever supported.
To be fair, Windows 3.1 can still be run on modern computers.
"Can be run" and "makes for a good setup experience" are two very different things. How's the USB support?
Support for USB controllers in DOS and Win3.1 is, of course, basically nonexistent. However, with the correct BIOS settings, a USB storage volume can be treated as a conventional hard drive (naturally requiring a traditional, non-GPT partition table, and will only mount sub-2GB FAT16 partitions).
I've got a bootalble thumbdrive, in fact, set up with Syslinux, and an option to boot a DOS 6.22 drive image (with Win3.1 installed) via memdisk. It works, but on modern hardware, can typically only use standard VGA or VESA video modes, and modern HDA audio devices are usually not AC97 or SB compatible, so usually no audio but PC speaker.
The article isn't mocking the approach, it's explaining why it was the best option, even though it sounds silly at first.
Now they don’t face the same resource and compatibility limitations they did then.
Windows PE is based on real Windows 11, it's not a custom thing.
To be fair, they had to ship first.
I need a saw to make a saw.
It happens even after creation, sometimes we -
.. no longer have tools because i've destroyed my tools with my tools.
- Mickens.