From: mutazilah@gmail.com
"Dan Cross" wrote in message
news:vqprsc$25q$1@reader1.panix.com...
> In article <20250311083745.000076a4@gmail.com>,
> John Ames 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?
Yes, it is unfair because you are using your own definition
of a term from the English language. You can call a dog a
cat too. It's not common usage. If you want to talk in a
foreign language, so be it. In fact, posting in Swahilli would
literally be better than redefining the English language just
to confuse people or more likely - try to pull the ladder up
from under you.
> 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.
Nonsense. There are some functions (like memory allocation
and exec) that introduce the concept of segmentation, but
even those can be masked by the C90 equivalents in the
same way Posix does.
> 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
Expanded memory is exactly that - not normal memory. So it
is basically accessing some non-standard device, and you
could use a device driver or some other method to access it,
it is not really something you expect to be provided by an
API. And has no concept in C90 either. If there happens to
be a DOS API to access this particular bit of hardware - so
be it. There are DOS APIs to access the CDROM too. But
that should be considered "iciing on the cake". There is no
requirement for an OS to provide access to either device
and still be an OS.
> 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 - live within the constraints of standard memory.
> 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.
Nonsense. And regardless, now do the same analysis
for accessing a file using the open() DOS API as
exposed and documented via Microsoft C.
> >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.
Porting Unix to the XT, and losing memory protection in
the process, does not stop Unix from being an OS.
Even if the XT was the original port, Unix was an OS then too.
> 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.
Pardon?
> >> >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.
Nonsense. All conventional memory is addressable by
any program. And if the program was compiled using
the compact, large or huge memory model, then any
data pointer at all, can accidentally trash the OS if
corrupted.
> >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.
Irrelevant. There is no technical barrier to doing that, depending
on your definition of "MSDOS".
> 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.
A "pass" for following a business direction not approved by you?
> >> 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
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
