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