A blast from the past: Disassembling DOS (2020) | Hacker News Reader

A blast from the past: Disassembling DOS (2020)

softwarelitigationconsulting.com

81 pointsuserbinator19 comments

I always wondered how it is possible that MSCDEX is not an actual driver but mere TSR and now I know: CDs look like network shares to DOS. I suspect that there is some reasoning behind this “design” (different filename conventions on ISO-9660?), but it stills seems like one giant kludge.

Starting with DOS 3.0, the way to do installable file systems was identical to adding a network drive. (DOS 4.0 had explicit IFSes; nobody used them to my knowledge and it chewed up RAM, and the code was removed in 5.0.)

A “network redirector” basically hooks every possible file I/O operation; DOS simply dispatches to it for any operations on that drive letter.

DOS only supports two kinds of device drivers: character devices and block devices. It does not have any kind of support for custom file system device drivers, as block device drivers will only use FAT. So in order to support ISO9660, sectors that aren't 512 bytes, device sizes larger than 32MB (65536 * 512), the device driver (for example ATAPI.SYS) is actually a dummy character device and MSCDEX talks to it to expose the filesystem as a network drive.

Alternatively, the abstraction of a network drive just happens to be the right one for local filesystem drivers too. There's some more interesting details on the redirector API development here: http://www.os2museum.com/wp/redirectors-and-dos-3-0/

> It does not have any kind of support for custom file system device drivers

This was true of MS-DOS 1.x and 2.x but not subsequently.

The IFS layer was added in MS-DOS 3.1:

http://www.bitsavers.org/pdf/microsoft/_MSDOS_releases.txt

Although Wikipedia claims MS-DOS 4:

https://en.wikipedia.org/wiki/Installable_File_System

DOS 3.0 had the first “network redirector” support, which was also very buggy.

It was rewritten for 3.1 (in an incompatible way) and that has been the standard since.

4.0 tried having a generic IFS which never caught on. Network clients preferred the old interface, and 4.0 was unpopular as it chewed up RAM compared to 3.30. 5.0 reverted to doing network redirectors exactly like 3.30 did.

> The "what" part is difficult to answer, except to note that DOS is in many ways what textbooks on operating systems call a microkernel. DOS provides a small bare minimum of services, on top of which other, more sophisticated, services can be built.

I think I heard Tanenbaum twitch.

I think DOS is closer to a "library OS" or unikernel.

https://en.m.wikipedia.org/wiki/Unikernel

OS virtualization can overcome some of these drawbacks on commodity hardware.

...and that's exactly what Windows/386 and later did.

DOS is basically a wrapper around the BIOS.

Functionally (not conceptually) like UEFI, kinda?

Yes and no. DOS did far more, it even had external Glide libraries.

I saw Schulman present how he discovered the dirty tricks Microsoft used to hobble Windows betas on DR-DOS, using similar techniques. This was at Ralph Nader's Appraising Microsoft conference in 1997.

It's covered in another of his books, Undocumented Windows.

Impressive work, and very brave at the time.

This was called the AARD code:

https://en.wikipedia.org/wiki/AARD_code

And it was Geoff Chappell, not Andew Shulman. Shulman helped write it up for publication.

https://www.geoffchappell.com/notes/windows/archive/aard/ind...

Thank you!

This is some brilliant interpretation. Wish he would take a look at both the origin of task switching and the Xenix boot loader.

Why does this have so many layout errors or typographical errors or something going on? There are just a lot of repeated paragraphs or sentences for seemingly no reason.

This is from a book that was formerly intended for print only. From the bottom of the page:

"[Many thanks to Samuel Okei from Texas Tech Univ. for his skilled conversion and reformatting of what was a complex 25-year-old file with obscure and obsolete typesetting codes, into HTML.]"

Probably troff o nroff

No tan dificil hombre

Groff no es difícil, pero (g)eqn/pic/tbl... sí ;)

Reply on news.ycombinator.com