SoylentNews is people
SoylentNews
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.
(Score: 3, Interesting) by DannyB on Thursday September 26 2019, @02:16PM (6 children)
I'll just say: ever hear of a screen sharing product called Timbuktu? (think VNC) Just a few years back, I got an email to join some of the old developers from long ago for a "wake" for that product, which was finally dead. It was a fun reunion. I wrote that code from August 1987 to Dec 1 1987 when it shipped 1.0. I wrote the entire back end "system service" you would call it today. Another co-worker wrote the "desk accessory" part with the UI since he was new to Mac development. I, at that point, could write the system service, since I had a few years under my belt and knew the inner workings quite well. I had to patch every single QuickDraw call, with the potential to capture every drawing operation and send a message for it over the wire to a remote machine which would draw the same things. The 68000 was wonderful. Nice 24 bit clean flat address space. Later 32-bit. Meanwhile we were always laughing at the PC guys hamstrung by Intel's segment registers. But the list of ways MacOS was superior was so long I have forgotten many of them. I was a card carrying Mac fanboy and we were all very smug indeed.
Aside: this is one of the reasons why, today, I snicker at guys (especially on SN who should know better) who think I don't understand low level things just because I now use and enjoy Java, Lisp and other higher order abstract languages. Back in the day I spent $495 of my personal money (probably $1000 in today's money) to buy Macintosh Common Lisp -- and I loved it! I got more enjoyment for years out of that single purchase than I could have imagined. And you could write Mac GUI code in it. :-)
I still have tons of old Mac disks, and a dusty but last known to be working PowerMac G3 (not tower, but desktop box style with monitor sitting on top). It belongs to my company, is in my office, but probably would be mine for the mere asking.
I was also bummed about OS X. That is when Apple and I parted ways. I do understand why though. Apple was already on its third attempt at developing a modern OS. I wish they had acquired BeOS instead of NeXT. But I guess they just had to get Jobs back. Which IMO was a mistake. That is when Apple turned into a fashion company instead of a technology company. There WAS A REASON why Jobs was stripped of power. He had goals that limited things like color Macs, or having a separate CPU / separate monitor on top, or plug in slots, and quite a few other things -- which Jobs then went right out and did anyway with his NeXT computer. Right at the time of OS X, as Steve Jobs made all my expensive hardware instantly obsolete, I was already studying all about Linux. The timing was perfect. About a year later, in June 1999, after extensive reading, I got my first Linux PC. SuSE Linux 5.1.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Friday September 27 2019, @02:02AM (5 children)
I do remember Timbuktu, but I don't think I ever had my hands on it. I salute you, thank you, you did a great thing.
And very cool you're doing Lisp. I have not, but I think I'm missing out.
I did a tiny bit of Forth- in Open Firmware. Someday someone please tell me how someone ate mushrooms and instead of Alice in Wonderland, they invented Forth.
You know what's also funny? The Intel CPU can run in flat mode too, but we kept it a secret. It was too funny hearing the Moto guys' smugness about flat model. :)
Novell's Netware OS ran in pure flat model for speed, and it really was fast.
And truth be told, I actually like the segment (selector) model, but I'm a divide-and-conquer guy so it fits. I dunno, the math never bothered me, and compilers do it for you.
It was all about memory protection, as you know. I'm still not sure why there are problems with memory protection, other than people not coding OS kernels (MS) correctly.
The 68000 had an MMU, iirc. Did that have a memory protection mechanism? Maybe I'll go look it up ... Hmmm, lookee thar, segmented protection. Ahem. Cough cough.
(Score: 2) by DannyB on Friday September 27 2019, @03:25PM (4 children)
If you ever get your hands on Timbuktu, or Timbuktu/Remote, especially in the earlier years from 1987 to about 1993. Just check the About box.
I started dabbling with Lisp in 1986. XLisp on classic Mac. I had purchased a Lisp book, and was learning it. It was fascinating. Then it was amazing. I had to know more. (downloaded XLisp from CompuServe if you know what that is.)
A few years later Apple stopped shipping a monthly gigantic stack of bound paper documentation along with some floppy disks to each developer. Every month. Apple started shipping a smaller stack of paper, maybe only about 1/2 to 1 inch thick along with a CD-ROM. At one point during this time was include a free Perl Lisp. (forerunner to Macintosh Common Lisp (MCL)). That was more amazing than XLisp, so I started using it. When I learned that MCL was based on Perl, I had to buy it for $495, along with CLtL 1. I started buying every decent CL book I could find. The things I learned was amazing. The last, but best book I got was from Peter Norvig: Paradigms of Artificial Intelligence in Common Lisp. (Title was something like that, I hope I'm not mangling it to badly, that was about 1992 ish) Learned about unification matchers. I built my own pattern match compiler which didn't execute the pattern match, but generated a LAMBDA expression which would match. I was working on a similar compiler for a unification matcher, but life called and I never got around to finishing it. At that point, with a kid, I was too busy to play with lisp quite so much.
I wish I had known that at the time. But everything in PC land seemed to be segment registers all the way down. Probably Microsoft is to blame since Netware could do it right.
I wouldn't complain if it were full 32-bit. But compilers just never did quite seem to give you a transparent higher level view. There were always various silly 64 K limitations on either strings, array lengths, procedure sizes, etc. I'm sure a compiler could make these unlimited to the higher level language, and some probably did, that I don't know about.
I seem to think it did but Apple didn't use it. Their new OS would have used it. Apple did use MMU for virtual memory, but NOT for memory protection. Just a consequence of classic Mac OS single process beginnings with no notion of multi-user or even multi process. A bug in any single application could bring the entire system down, and often did. In this case, I could more often than not recover the system in order to save things and do an orderly shutdown. I would push the Debug switch. (A little plastic insert thingy a developer would snap on the side of the machine.) Then type two commands:
SM 0 A9F4
G 0
That would do an "ExitToShell" in the crashed program, and other running programs could often then be saved and shut down orderly before restarting.
Those were fun, fun days.
The lower I set my standards the more accomplishments I have.
(Score: 3, Interesting) by DannyB on Friday September 27 2019, @03:29PM (3 children)
BTW, that SM 0 A9F4 trick was something I figured out. I tried to pass that knowledge around. But this was pre intarwebs days.
The lower I set my standards the more accomplishments I have.
(Score: 2) by RS3 on Saturday September 28 2019, @01:58AM (2 children)
Very cool trick! I never dug into the Mac Classic OS. Wanted to, no time. I rarely had app crashes. :) I can't really remember any. I mostly used it for audio recording, editing, mixing, etc. Probably some video editing too, but I think I had something hotter by then (dual G5 on OS/X).
Yeah, one of the big gripes about Netware was that with Intel in flat-memory mode, there's no memory protection (IIRC). But instruction execution clock cycles are far fewer in flat mode. ("Real" mode is fastest and great if you need less than 1 MB RAM...)
I guess people are unaware, but Intel CPUs have had "PAE" - Physical Address Extension, for a very long time- early Pentiums, or P-II. It's 36-bits of address. Linux finally started using it in "huge" memory mode. Win 7 still won't use it. There's a patch, and I tried it, but it doesn't seem to work, probably because the NT kernel has been updated many times and the patch is old.
So in Mac Classic, "exit to shell" - was it a CLI? Or just that Finder somehow survives and you can restart? (all this is bringing back some very faint dusty memories... of all kinds of cool tools and utilities and tweaks...)
Come to think of it, I rarely ran more than one Mac app at a time.
https://www.ebay.com/sch/58058/i.html?_nkw=Timbuktu [ebay.com]
(Score: 3, Interesting) by DannyB on Monday September 30 2019, @03:16PM
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 lower I set my standards the more accomplishments I have.
(Score: 3, Informative) by DannyB on Monday September 30 2019, @03:30PM
A bit more about MPW.
On a command line you could of course use file names, much like you would in Bash on Linux.
Text files in MPW would remember their "selection". That is, if you selected a range of text, then saved the file; when you re-opened that file later, it would still have that range of text selected.
Now, on a command, if you referred to a named pathname of a file, and suffixed that with .S (eg, dot S), but the S wasn't really the letter S, but some other squiggly unicode character. (But before unicode) This syntax didn't refer to the text within the named file, but rather to the selected text within the file. So, suppose I used I/O redirection to redirect Std In, Std Out or Std Err to/from some file name with the ".S" suffix, it redirected into our out of the selected text. When writing to the selected text, the text selection range would collapse into zero characters, and then expand with the written characters replacing what was the selection. This inserted what was written into the space occupied by the selection. I hope that made sense. It was very cool.
Example: I have a large file of text. I select one line (or indeed only one character, such as a space). Save the file. Now use a command like:
foobar > myfile.S
Then the single line or space selected in myfile expands and grows to however much text the foobar command generates. Got that? When I later open 'myfile', that single selected space character is now a large amount of selected text, but all other text within the file, both before and after the selection remains fully intact.
And remember a C or Pascal program would just read/write to Std IO/Err. No magic within your program. MPW trapped the I/O operations of command programs and implemented this magic.
It was also handy to write MPW commands in source code comments. You could be reading a Pascal program, then within a comment, select an MPW command and hit Ctrl-Enter to execute it. It's StdOut would be written right into the comment of your code, after the command you had selected. This is very different than using a "terminal" type interface. But you could just type commands and hit Ctrl-Enter like using a TTY. Thing is, since it's all in a text file, you just hit File->Save to save your "history". In fact, you could have as many text files as you want with commands or templates of commands. So to use the "command line" you simply open (or create a new scratch) text file and start typing, using Ctrl-Enter to execute.
And of course you could write powerful scripts in MPW's bash-like sorta language. With utilities like compilers, make, link, rez, and generate an application.
The lower I set my standards the more accomplishments I have.