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: 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 anti vax hysteria didn't stop, it just died down.
(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 anti vax hysteria didn't stop, it just died down.