Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Wednesday September 25 2019, @10:02AM   Printer-friendly
from the MS-what? dept.

Submitted via IRC for Bytram

How did MS-DOS decide that two seconds was the amount of time to keep the floppy disk cache valid?

MS-DOS 2.0 contained a disk read cache, but not a disk write cache. Disk read caches are important because they avoid having to re-read data from the disk. And you can invalidate the read cache when the volume is unmounted.

But wait, you don't unmount floppy drives. You just take them out.

IBM PC floppy disk drives of this era did not have lockable doors. You could open the drive door and yank the floppy disk at any time. The specification had provisions for reporting whether the floppy drive door was open, but IBM didn't implement that part of the specification because it saved them a NAND gate. Hardware vendors will do anything to save a penny.

[...] Mark Zbikowski led the MS-DOS 2.0 project, and he sat down with a stopwatch while Aaron Reynolds and Chris Peters tried to swap floppy disks on an IBM PC as fast as they could.

They couldn't do it under two seconds.

So the MS-DOS cache validity was set to two seconds. If two disk accesses occurred within two seconds of each other, the second one would assume that the cached values were still good.

I don't know if the modern two-second cache flush policy is a direct descendant of this original office competition, but I like to think there's some connection.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by DannyB on Monday September 30 2019, @03:16PM

    by DannyB (5839) Subscriber Badge on Monday September 30 2019, @03:16PM (#900811) Journal

    As a developer, I had plenty of crashes.

    I am vaguely aware of PAE. My understanding is that it allows a 64-bit OS, with more than 4 GB of memory to map multiple 32-bit processes to a "full" 4 GB of physical memory -- located at different pages in physical 64-bit space. If I had 16 GB of memory, and two 32-bit processes running, they could each get 4 GB of physical RAM. Of course, userland processes get some part of their address space mapped to kernel space as I understand things.

    Classic Mac did not have any build in command line shell. In this sense Shell probably meant The Finder. Consistent with Windows terminology (but which came first?) The only CLI was if you installed a (rather large) application called MPW (Macintosh Programmer's Workshop). How this was implemented was very interesting. It was clearly inspired by Unix, but on the single-process cooperative multitasking Mac OS. There wasn't a "terminal" type interface. It was all "Notepad" style editor windows. Hitting Ctrl-Enter would execute the current line as a command. Or you could select any range of text and Ctrl-Enter to execute all of the selection as text. You had pipes and Std IO/Err redirection. Using any Apple or third party compilers you could write simple plain jane text programs in Pascal, or C/C++ and they would work with no GUI -- within the MPW environment. This is how all of the Unix-like tools worked. There was make, link, res and deres. (pronounced rez and derez, like Tron the movie) These were the resource compiler an decompiler. Every Mac file could potentially have a 2nd fork that contained a database of resources. Resources were addressible by type (4 chars) and ID (integer). So a program could use a simple API to load, say, ICON 128, or JPEG 314, or CODE 81. Developers could invent their own resource type with their own custom binary format. There was a language to define binary formats for resources, very powerful, including iterated arrays of binary subtypes with zero or one based indexes -- this made it easy to write high level Rez source code to be compiled into binary resources and added to a file's resource database.

    Before PowerPC, all 680x0 apps code were CODE resources within the resource fork. The "data" fork part of the application file was empty. So if you tried to read the bytes out of an application, it had zero bytes of data. When PowerPC was introduced, Apple used some industry standard binary format (COFF? my memory might be fuzzy) and stored that binary format into the data fork of the application -- like Windows and Linux would do. Thus it was possible to build "fat" applications that had 680x0 code AND PowerPC code. But 680x0 code would run on PowerPC (emulated) but PowerPC code would not run on a 680x0 Mac.

    Other interesting things about MPW. Pathnames on Mac were the Disk name first, then other pathname elements separated by colons. So if disk icon on the desktop was named "Hard Disk", then a path might look like "Hard Disk:My Letters:Dear Aunt Jane 6/13/1987". Note no filename suffixes. Ever. Every file had a Type and Creator attribute -- again both 4 characters (eg, a 32-bit integer to a developer). The TYPE indicated what kind of data a file contained. But the CREATOR indicated which application should be launched. Unlike Windows and Linux, you could have several TEXT files, but one of those might open in Notepad, and another might open in MPW. You could still open ANY TEXT file in, say, MPW, but double clicking that file's icon might launch it to a different application depending on the file's CREATOR attribute. Think of it like if Linux and Widows had TWO file extensions such as MyFile.txt.notepad, or YourFile.txt.mpw. The 2nd suffix indicates which app gets launched, while the first suffix indicates what type of data the file contains. Two different JPEG files might launch into say, Paint or Photoshop. Also the Finder would display the file's Icon based on BOTH the Type and Creator together. The app that is the file's creator would have resources specifying what a Photoshop JPEG icon should be, where Paint would have its own resources specifying what a Paint JPEG file should be. Yet Photoshop might also open GIF files, and would have it's own notion of what a Photoshop GIF icon should be. While, say, GraphicConverter would have it's own unique branded family of icons indicating what it's GIF icons should look like. So all Photoshop icons looked like they went with that app. But all GIF icons looked like they contained a GIF. I hope that makes sense.

    I can't say I recognize that bag. But that doesn't mean it wasn't created after I went with the accounting software -- which in hindsight was a great move.

    During the Timbuktu days, I went to trade shows, etc. Went to a MacWorld award show to receive the MacWorld annual award for Timbuktu/Remote 2nd place -- I think that was Jan 1993 as I recall. I had to have someone at home tape (vhs) Babylon 5 pilot movie so I wouldn't miss it. Or maybe that was a separate trade show. It's somewhat blurry now. But I do remember that when Kosh first meets Sinclair in the hangar bay, Kosh greets him as "Enteelza Valen".

    Mac developers had all kinds of cool utilities. It was very easy to change simple things like a file's type/creator, for example. Or even in batch -- by drag dropping all of their icons onto the icon of a utility program that did this. It was really cool stuff. Sadly Microsoft couldn't copy more of it into Windows because they were locked into the drive letter scheme, and the MS-DOS compatibility, short file names, etc.

    --
    The anti vax hysteria didn't stop, it just died down.
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3