Comment by chungy | Hacker News Reader

Comment by chungy | Hacker News Reader

> No, as Microsoft has artificially tied MS-DOS 7.xx and Windows 4.xx together and it is not trivial to pry these components apart.

This is a half-truth, due to the word "artificially" -- it implies nefarious intent by Microsoft to not let you run Windows 9x on just any old DOS. Microsoft determined with Windows 95 that Windows would be their primary operating system, and while it was still architecturally similar to the older 1.x-3.x versions that would install and run on top of MS-DOS (including various versions of which), that both components would be improved by developing them together. The original Windows 95's version of MS-DOS ("7.0") added support for logical block addressing and long file names in FAT. The second one in 95B ("MS-DOS 7.1") added support for FAT32. The Windows Me version ("MS-DOS 8.0")... well ok I don't really know of any practical changes aside from no longer parsing config.sys/autoexec.bat.

Still there were obvious compatibility and practical advantages to developing them in tandem. Massive improvements in the file system were feasible in the era that 2GB and larger disks started appearing on the market, simplified boot process as it was assumed that Windows would always be expected, some data structures could be rearranged or axed in order to allow Windows itself to manage resources.

It’s not as clear cut as that. There was a non-Microsoft DOS (might have been Dr DOS but I can’t recall specifically) that would boot Windows 95. Then Microsoft released an update that caused Windows 95 to fail with an vague error message intending to deceive users into thinking there was a technical limitation in other DOSs that prevented Windows from booting. Yet it was later proved that limitation didn’t exist and all Windows was doing was checking if it was MS-DOS, and if not returning an error.

If I recall correctly this case even went to court.

That sounds like the beta of Windows 3.1 and the AARD code, which is most definitely in the “dirty tricks” column for Microsoft.

Ah yes it was. Sorry about that.

I agree. Windows 9x's reliance on internal MS-DOS data structures was not done for "artificial" reasons:

https://devblogs.microsoft.com/oldnewthing/?p=24063

This does not seem like a reliable source about Microsoft's actions in the 90s. What are they gonna do? Blog about how they're guilty of anticompetitive behavior?

I don't remember Raymond Chen ever lying. If there weren't legitimate reasons, Raymond would just not talk about them. Especially since this would be a very elaborate, multi-faceted lie that anybody with an intermediate knowledge of the inner workings of Windows 9x would've been able to call out.

I guess I'm expecting lies of omission here. My guess is that content on Microsoft's blogs, especially about this period is cleared with legal before anything goes up.

Raymond Chen may not intentionally lie, but he can be wrong and has been wrong in the past. One obvious example that I remember is when he said that the reason Pinball.exe disappeared from Windows Vista was because they couldn't port it to 64 bits. And yet as I read every single clickbait newssite parrot what he was saying, I was literally playing 64-bit Pinball.exe on a standard Windows XP x64 edition ...

The comments in his blog disappear every time Microsoft shuffles it around, so these discussions are lost forever.

Not lost, for now: <http://bytepointer.com/resources/old_new_thing/index.htm>. (Thankfully, MSDN blog comments didn’t require JavaScript, or they would now be lost...) Here’s the Pinball piece, for example: <http://bytepointer.com/resources/old_new_thing/20121218_294_...>.

It was probably the 32 bit version of pinball, running on 64 bit windows via WoW64

No. Easily distinguishable by the * (or lack of it) in task manager.

Not much in there require the DOS version to be precisely MS-DOS; on the contrary it was done mainly for compat with 3rd party code which e.g. "knew" where the DOS structures were, and surprise 3rd party DOS obviously had to be compatible on those points.

Now remains the "suck the brains out" problem, and although it could have been easily solved cooperatively IMO, it is illustrative of why people would not have needed 3rd party DOS when Windows 9x was running anyway: the kernel did nothing, the libs were mostly irrelevant (and MS-DOS probably gave that small compat edge even there, simply because its prevalence even before 9x), and the cmd line tools, well a) who cares about the tools b) actually if you do I suppose that was the easiest things to run (and if not: the irony; oh it is scandalous that windows relies on internals of MSDOS -- but not that e.g. Caldera DOS tools relies on internals of their DOS kernel)?

Caldera would have needed a Windows clone to compete. DOS was just becoming irrelevant.

Once you postulate a reality where Windows 95 was an unbundled product, a few things change:

* It becomes much easier to make legal noise about Microsoft pricing. If they're saying "Buy Windows 4.0 and we'll give you MS-DOS 7.0 free, or for some token sum" it's pretty obviously market dumping. If you had to pay, hypothetically $50 for MS-DOS 7 and $50 for "Windows 4", instead of a single $100 package, Caldera can compete with a $30 DR-DOS product even without having a Windows clone.

* There could still be a territory war over the quality of the underlying DOS. This was still a time when you'd have a lot of games, in particular, that required a drop down to DOS mode.

* There was also the opportunity to sell features that still had DOS components involved more modularly. I'm thinking about FAT32 in particular, because I can recall radio advertisements boasting about it to try to sell Win95 users on upgrading to 98 or 98SE. What if you could pay $10 and get a DR-DOS competitive upgrade that supported it instead of a full $100 upgrade with a bunch of features you didn't care about?

In such an environment, there could have still been 5 or so years of DR-DOS as a viable commercial product until the much less unbundlable NT-based Windows went mainstream. That's a significant amount of runway. Their pivot from there is not obvious-- I can imagine some attempt at a Linux distribution with a tightly integrated WINE setup, but that might have been too much to ask for at the time.

I also wonder how a Microsoft that had been clearly slapped and told "you must play well with others" in 1995 or so would have behaved over the next 20 years. The trajectory of IE would have likely been very different, and I wonder if they would have handled some of the other Office competitors with kid gloves to avoid legal scrutiny. Maybe even some healing of the rift with IBM on OS/2, so they could point and say "look, we're interoperable, here's another compatible product."

The trouble with FAT32 being a feature to sell DOS is that Windows 9x doesn't use DOS to access the filesystem in normal circumstances. AFAIK it had a compatability path that could use DOS, but then you'd be slowing stuff down.

I can only imagine bad things happening if Windows and DOS disagree on filesystem aspects.

That's why the Windows 95 CD-ROM version shipped with the "LFNB" long filename backup utility https://jeffpar.github.io/kbarchive/kb/135/Q135315/

> Caldera would have needed a Windows clone to compete. DOS was just becoming irrelevant.

Well, Digital Research had GEM[0] since mid-80's. Development was probably halted after Novell or even Caldera acquisitions.

[0]: https://en.wikipedia.org/wiki/GEM_(desktop_environment)

The LFN portion of the original W95 was implemented in vxd's, not in the base DOS. If one created the boot disk / recovery disk, which then ran a base DOS 7, it had no LFN support.

LFN support did work in windowed command prompts, as there the vxd's were present and provided the extra int21 support. I rather doubt that changed through any of the later versions, as there was no engineering need.

Schulman's book described this in great detail.

The LBA format drives, and using different partition types would be entirely handled in the disk driver level, hence trivial.

FAT32 was a smaller and simpler change, as it would largely be driver level, larger FAT entries, and then treating the root directory as if it was any other directory (hence growable), rather than "special" (fixed) as in prior versions of DOS.

There is also an elephant in the room with all these questions about the messy interactions between Windows 9x and DOS - Windows NT. By 1995 Microsoft’s long view of the future of the PC OS did not involve DOS. Even before NT we had OS/2 as well.

If Microsoft had been “nicer” they could have made it easier for DR to use their DOS to load a GUI that mostly acted as its own OS and bypassed DOS once loaded, but what happens once they get to XP?

(Of course DR / Novell kinda knew this hence stuff like Star Trek, but whatever DR’s vision of the future was never came).

> it implies nefarious intent by Microsoft to not let you run Windows 9x on just any old DOS

Yes https://en.wikipedia.org/wiki/AARD_code#Memos

That was not for Windows 9x.

Ah yeah, my bad, I guess it's just coincidence how the CEO, Co-President, and SVPs explicitly stated they didn't want Windows to be able to run on any non-Microsoft DOS and then the next major version of Windows wasn't able to be "integrated" with any non-Microsoft DOS.

Also total coincidence how the same strategy played out with their web browser a couple years later http://toastytech.com/evil/fof.html :)

From a purely technical point of view, what would you have wanted next? Windows XP running "on" DOS? And the irony is that it was not even that much different on that point: Windows 9x did not really run "on" DOS either. It had some form of "cooperation" (for legacy drivers only) / backward compat. And it was booted form there. And you could still run DOS bare-metal. For most users, the DOS parts were perceived as deprecated anyway; aligned with the fact they officially were...

And well even in the Windows 3 era DOS was merely used as a bootloader on modern machines. Of course Windows 9x took the concept even further. The contextual difference was simply that there was tons of DOS programs and games even when 3.x was out (esp. games) and that even if that continued a little bit for games, it quickly migrated as Windows 9x became a comprehensive platform with the needed APIs (plus more and more people having it). And the default boot UX that was kept as-is by most people.

So from a market perspective, 3rd party DOS + Windows 9x would probably have died well for 98 anyway, and probably become ultra-niche way before (well, was probably niche already just before the 95 launch...)

Not to say MS did not have anti-competitive behaviors during that era (or attempts e.g. the AARD incident), and of course even just strategies to compete. They are actually well-documented thanks to various trials. But there is also the usual taking of random tech dependencies for granted until the main vendor suddenly changes its stack: and OMG you can't run booted from another DOS. Hell even when parts of the tech stacks were actually documented, licensed and supported, sometimes it stopped to be the case on the next iteration: and then you can't use a Cyrix processor on a MB with an Intel chipset anymore. It is not necessarily an abuse of dominant position all the times.

And here the point of the original post was to say there could have been a Win9x capable DR-DOS, so I don't even see why you are talking about "the next major version of Windows wasn't able to be "integrated" with any non-Microsoft DOS" when it clearly could: simply the compatible 3rd party DOS capable of that was not commercialized. Should MS have been forced of cooperating with other companies to have parts of their OS interchangeable? I'm not sure. Apple surely did not have to e.g. thoroughly document and then advertise their PowerPC nanokernel as reimplementable by 3rd parties (not an exact equivalent, but it is impossible to come with exactly the same scope given the two systems are so different, so I'm just taking a random component that can be distinguished from well-known and previously existing one) -- but then if some found an interest in doing that without support, they also could have done so.

There were a lot of games which were DOS only or which required special HW for the windows version. So DOS was, more or less needed. Besides games were also engineering applications for example, who did not had yet a windows version (pspice, orcad) so people really needed DOS. It was later (win 98 era ) when the programs were "ported" to windows.

Performance was truly a major factor for that, even today.

Even if Windows 98 would be installed on the machine, running the software on plain MS-DOS would be drastically faster on those days when having less services/GUI on the background.

They would access the extended memory using the HIMEM.SYS driver and the run the software as bare-metal as possible. Not very different from what happens with linux servers nowadays.

MS could have maintained backwards compatibility if they wanted. https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii... "On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95."

I seem to remember successfully upgrading a machine with IBM PC DOS 7 and Windows 3.1 to Windows 95. There were issues with a few DOS commands later as some had been upgraded and others remained the IBM version.

Reply on news.ycombinator.com