Groups | Search | Server Info | Login | Register
Groups > alt.os.development > #18784
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Newsgroups | alt.os.development |
| Subject | Re: z/PDOS-generic |
| Date | 2025-03-11 17:28 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <vqprsc$25q$1@reader1.panix.com> (permalink) |
| References | <v7bbdt$2fj5a$1@dont-email.me> <20250310151114.000023e9@gmail.com> <vqnrjl$4a9$1@reader1.panix.com> <20250311083745.000076a4@gmail.com> |
In article <20250311083745.000076a4@gmail.com>, John Ames <commodorejohn@gmail.com> wrote: >On Mon, 10 Mar 2025 23:11:49 -0000 (UTC) >cross@spitfire.i.gajendra.net (Dan Cross) wrote: > >> I already posted the definition I like to use, which came to me >> via Mothy Roscoe, at ETH, but I'll post it again: >> >> He defines the operating system as, >> That body of software that, >> 1. Multiplexes the machine's hardware resources >> 2. Abstracts the hardware platform >> 3. Protects software principles from each other >> (using the hardware) > >You surely did; however, that does not mean that anybody else is >obligated to accept it. Sure. That's why I prefaced this entire subthread by saying, "it depends on your definition." I gave the definition that I like, and explained how DOS does not meet those criteria. Is that unfair? Perhaps, but the question was, "why do you say this?" and that's the answer of why I say it. >Specifically, let me ask: > >1. Why must it multiplex anything, in a single-user system? Multi- > tasking is certainly a nicety, but why should it be considered > a necessary criterion for "real" status? Note, I said multiplexing, not multitasking. CPU is just one hardware resource that can be multiplexed, often via multiprogramming but sometimes via spatial allocation (e.g., in a multiprocessor system). But others include storage devices, memory, peripherals like timers and other IO devices such as serial/parallel ports, maybe a real-time clock, and so on. You like having a file abstraction? Well, that's something that the OS often provides for you, and is _a_ way that e.g. a storage device can be logically multiplexed between multiple programs, even if they do not run concurrently. Similarly with a memory allocator. Getting back to the specific example of MS-DOS, it does provide both, but does Not provide a way to e.g., multiplex IO and computation temporally; so performing a disk operation will just block the program until the operation completes. Don't want that? Go touch the hardware yourself. The control program doesn't really help me here. >2. What is the minimum level of hardware abstraction, and why? MS-DOS > does in fact abstract the details of, e.g., filesystem access, pipes, > and to a lesser extent serial/parallel communications. You seem to be > fixated on the fact that its ABI uses x86 interrupts rather than an > alternative method; why is this important? I would hardly say I'm "fixated" on it. It's simply a fact. Generally, we draw a distinction between an API and ABI; the former is often somewhat abstract, while the latter is the concrete implementation of that abstraction. In a lot of ways, the ABI is irrelevant for workaday programming: you leave it up to a tool, or a system library, or something like that, but you rarely have to think about it. The issue with the DOS API is that it is defined _solely_ in terms of the hardware interface, and moreover it is highly specific to that hardware. Consider the memory allocation API, for example. According to, "Advanced MS-DOS Programming, 2nd Ed", by Ray Duncan, if a user program wants to use expanded memory, the program must do work to a) first determine whether expanded memory is even available, and b) use a different, special, interrupt to delegate to the "expanded memory manager" to actually allocate it. Now, one might argue that this doesn't matter that much. "Who cares? What's the difference between saying that there's a thing called `malloc` and poking a hex constant into %ah and then doing `int 0x67`?" And that's a valid question; one could imagine an interface that has both `malloc` and `expandedmalloc` or something like that to have an API divorced from the specific ABI, but those are _leaky abstractions_: they exist solely to represent hardware artifacts. So while you could "name" those things and not just number them, the things themselves are still very tightly coupled to the hardware. Those aren't great abstractions. >3. Again, in an 8086 environment this is *literally impossible.* There > is no operating system for the IBM PC or XT that *can* implement any > kind of protection. Additionally, in a single-user system, why is > this a requirement rather than a nicety? Yup. An 6802 microcontroller with 128 bytes of RAM doesn't have an operating system, either. That doesn't mean it isn't useful. It's interesting that there was a port of Unix to the XT that was, of course, subject to the same limitations. Sometimes you are just constrained, so you make due with what you have. But Unix at least used the segmentation facilities in the processor to _attempt_ to shield the kernel from errant user processes; DOS made no such attempt. >> >MS-DOS very definitely takes control of the computer - it does not >> >*hold onto it* very tightly, but there's no particular reason it >> >should have to. >> >> Given the above definition, there's a very good reason: how does >> it otherwise protect _itself_, as a software principle, from an >> errant, let alone malicious, program? > >It doesn't, because it cannot. The 8086 offers absolutely no facility >for protection, Not true. It supported segmentation. It's harder to corrupt RAM if it's not in a segment that's currently addressible. >nor does the PC hardware implement any kind of bolt-on >mechanism for this. That did not even become *possible* until the >introduction of the PC/AT in 1984, three years after DOS was released, >and that was limited by the infamously "brain-damaged" protected mode of >the 286. And when the 286 came out, MS-DOS didn't grow to use it, even though it was there. Nor did they try to incorporate larger segments or virtual memory when the 386 came out. But the 386 was designed for the Unix market, not the PC, so maybe MSFT gets a pass on that one. >> Also, a boot loader takes control of the computer, albeit >> temporarily: is that also an operating system? Merely taking >> control of the computer is insufficient. The OpenBoot PROM >> monitor on a SPARCstation could be entered via a keyboard >> shortcut, suspending Unix and the SPARC processor; was that an >> "operating system"? > >In the strict sense, I don't see why not. A primitive one, granted, but >if ROM BASIC counts as an operating system, OpenBoot certainly would. I wouldn't count ROM BASIC as an operating system, sorry. Similarly, the people I know who worked on OpenBoot did not consider it a real operating system in the way they thought of SunOS. Now my question to you: why do you care what specific label people apply to MS-DOS? - Dan C.
Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar
z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-07-18 23:07 +0800
Re: z/PDOS-generic Grant Taylor <gtaylor@tnetconsulting.net> - 2024-07-18 22:40 -0500
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-07-19 18:43 +0800
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-19 16:18 +0000
Re: z/PDOS-generic BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-07-19 17:12 -0500
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-19 23:21 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-19 23:31 +0000
Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-20 01:30 -0500
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-22 07:51 -0700
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-22 15:22 +0000
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-22 09:07 -0700
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-22 17:37 +0000
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-22 18:07 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-22 19:38 +0000
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-22 11:18 -0700
Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-22 14:16 -0500
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-22 20:14 +0000
Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-22 18:03 -0500
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-22 23:58 +0000
Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-22 23:06 -0500
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-21 04:31 +0800
Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-08-28 02:28 -0500
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-28 16:54 +0800
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-28 16:58 +0800
Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-08-28 18:03 -0500
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-29 11:14 +0800
Re: z/PDOS-generic George Neuner <gneuner2@comcast.net> - 2024-08-30 06:49 -0400
Re: z/PDOS-generic George Neuner <gneuner2@comcast.net> - 2024-08-30 10:27 -0400
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-31 10:21 +0800
Re: z/PDOS-generic George Neuner <gneuner2@comcast.net> - 2024-08-31 15:30 -0400
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-09-03 14:27 +0000
Re: z/PDOS-generic wolfgang kern <nowhere@never.at> - 2024-08-30 13:29 +0200
Re: z/PDOS-generic Waldek Hebisch <antispam@fricas.org> - 2024-09-03 23:38 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-09-06 07:46 +0800
Re: z/PDOS-generic J. Curtis <unknown@protocol.invalid> - 2024-09-06 20:08 +0100
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-09-07 08:12 +0800
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-01-22 17:34 +1100
Re: z/PDOS-generic J. Curtis <unknown@protocol.invalid> - 2024-07-20 00:02 +0100
Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-08 14:42 -0300
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-09 02:09 +0000
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-09 15:40 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 12:38 +0000
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 14:49 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 15:00 +0000
Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-10 09:21 -0300
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 13:50 +0000
Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-10 14:10 -0300
Studying the system (was Re: z/PDOS-generic) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 18:29 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 05:38 +1100
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 19:07 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 19:09 +0000
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-10 13:00 -0700
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 20:20 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 07:59 +1100
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-10 15:11 -0700
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 23:11 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 10:51 +1100
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-11 08:37 -0700
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 17:28 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 05:40 +1100
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-11 12:41 -0700
What is an operating system? (was Re: z/PDOS-generic) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 21:00 +0000
Re: What is an operating system? (was Re: z/PDOS-generic) "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 17:30 +1100
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-11 09:04 -0700
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 08:29 +1100
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 05:06 +1100
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 19:01 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 08:04 +1100
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 08:47 +1100
Re: z/PDOS-generic antispam@fricas.org (Waldek Hebisch) - 2025-03-11 18:15 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 18:29 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 05:52 +1100
Re: z/PDOS-generic antispam@fricas.org (Waldek Hebisch) - 2025-03-11 23:05 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 23:48 +0000
Re: z/PDOS-generic antispam@fricas.org (Waldek Hebisch) - 2025-03-12 02:23 +0000
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-12 02:34 +0000
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 18:41 +1100
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-19 09:35 -0700
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-21 04:20 +0800
Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-08-21 09:51 -0700
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-22 13:24 +0800
Re: z/PDOS-generic Grant Taylor <gtaylor@tnetconsulting.net> - 2024-07-19 19:46 -0500
Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-21 04:18 +0800
Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-08 14:41 -0300
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-09 01:58 +0000
Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-10 09:31 -0300
Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 14:28 +0000
Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 14:46 +0000
csiph-web