From: cross@spitfire.i.gajendra.net
In article <20250311124158.0000716c@gmail.com>,
John Ames wrote:
>On Tue, 11 Mar 2025 17:28:44 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> 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.
>
>I mean, asynchronous I/O is certainly a nicety, but why does not having
>it make an OS not "real?"
I did not say that it did not.
I said that MS-DOS does very limited multiplexing of hardware
resources, that multiplexing of such sources doesn't only mean
timeslicing the CPU as you seemed to suggest, and used
overlapped IO and computation as an example in answering your
question of why this might matter for a single-user,
single-tasking system.
I pointed out that MS-DOS does not, and _cannot_ support this.
You'll note that I did acknowledge ways that DOS _does_
multiplex some resources, such as providing a file abstraction
and providing a memory allocator. But it's anemic.
>> 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.
>>
>> 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.
>
>So an OS that is specifically tied to a particular architecture and
>uses specific sequences of instructions is "not a real OS?" Funny, you
>never hear that against ITS.
It's funny that you entered this thread by accusing someone else
of moving the goalposts, and yet now you yourself do so.
You asked about how much abstraction of the hardware is enough?
That is a debatable point worthy of discussion, but DOS does
none.
>> 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.
>
>Absent any means of hardware protection, "segmentation" on the part of
>the OS is a gentle suggestion at best; it cannot even protect against
>an *errant* process, let alone a malicious one. DOS also uses the
>segmented model to allocate space to applications/drivers/etc., but
>pretending that this actually impedes hazardous behavior is just empty
>security theater.
The point is that DOS actively encourages users to side-step it
and do their own thing.
>> Not true. It supported segmentation. It's harder to corrupt
>> RAM if it's not in a segment that's currently addressible.
>
>Again *there is no protection.* None whatsoever. Altering the segment
>registers is a non-privileged operation on the 8086, and the address-
>translation mechanism is a simple shift-and-add; it is trivial for any
>process to write to any part of memory, whatever its initial segment-
>register values were.
I'm aware of how the 8086 segmentation model works, thanks, but
you miss the point. In order to manipulate with memory outside
of a presently loaded segment, a program must first load a
segment register to point to some segment that contains the
memory you want to manipulate. Conversely, if no such segment
is loaded, that memory cannot be manipulated, even if I know its
linear address. Loading the segment registers is an _explicit_
operation; a random store won't necessarily overwrite memory.
Crude and fallible as it is, MS-DOS (again) encourages stepping
past even this feeble mechanism to provide some primitive
semblence of protection.
>> 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.
>
>MS and IBM did in fact try to extend DOS using the capabilities of 286
>protected mode, under both Windows/286 and OS/1 v.1. Neither worked
>well or saw wide adoption, because the 286 was terrible.
Oh, I'm sorry, I didn't realize you worked for Microsoft when
this was going on and knew that's why those efforts failed. Are
you still in Seattle? Maybe you know some folks I know who were
there around that time? Most of them were Windows kernel folks,
but a few were around in the DOS days.
>By the time
>the 386 was gaining significant acceptance, MS was already moving on to
>Windows NT, which eventually did offer protected (if limited) DOS
>support via NTVDM.
>
>> Now my question to you: why do you care what specific label
>> people apply to MS-DOS?
>
>Primarily because Certain Types insist on parroting the same pithy
>dismissals over and over again, year after year after year, for no
>readily apparent reason and despite their arguments being predicated on
>nonintuitive definitions of common terms, which are in the best case
>overly narrow and,
"Nonintuitive" to whom, exactly?
>in the least charitable interpretation, pretty
>clearly constructed to support the argument they wanted to make.
Honestly, it strikes me that it's really the other way around.
Some people appear to have gotten much of their identity wrapped
so up in the idea that MS-DOS is an "Operating System" that the
suggestion that that might not be how people doing serious work
in the field universally see it, that it's akin to someone
calling their baby ugly.
>Now, in fairness to yourself, Scott is the one who's really been
>tossing cherry bombs in the toilet here, and I think you're catching
>some flak that really ought to go his way; but you *also* are insistent
>on defining common terms in such a way as to exclude things that pretty
>much anybody without a partisan stake wouldn't hesitate to count in
>with the group - it's not enough, apparently, to say that MS-DOS is a
>*simplistic* OS, or even *not a particularly good one,* but that it's
>somehow not *really* an OS at all, even though you yourself admit that
>it does fundamentally fill the role of one:
>
>> So it's hard to see how DOS really qualifies as an OS, despite
>> the OS-like abstractions it provides.
I said it is difficult to see how DOS qualifies as an OS, given
the definition I presented. I don't get where you are saying
that I "admit that it does fundamentally fill the role of one."
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
