Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #18677 > unrolled thread

z/PDOS-generic

Back to article view | Back to alt.os.development

Contents

  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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#18789

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?"

> 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 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.

> 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.

> 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. 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, in the least charitable interpretation, pretty
clearly constructed to support the argument they wanted to make.

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.

So why the semantic games? What is the actual *point* to this argument?

[toc] | [prev] | [next] | [standalone]

#18790 — What is an operating system? (was Re: z/PDOS-generic)

In article <20250311124158.0000716c@gmail.com>,
John Ames  <commodorejohn@gmail.com> 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."

I stand by that, though I admit that I don't feel the need to
condescend to those who might see it differently.  However, you
_do_ have to bring a better definition that "lol because it is
because I'm tired of people making fun of it and this is what an
English langauge dictionary says about it."  My copy of Merriam
Webster has definitions for all kinds of common words that have
nothing to do the definition of those same words in specialist
contexts.

>So why the semantic games? What is the actual *point* to this argument?

It may be hard to accept, but words have meaning, and
specialists in the field get to define those meanings, not
dictionary editors.  If you want to talk seriously about
operating systems, then one has to engage with _those_ meanings,
and not what is merely intuitive.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#18795 — Re: What is an operating system? (was Re: z/PDOS-generic)

"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message
news:vqq89k$ak4$1@reader1.panix.com...

> >> 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.

Pardon? DOS "encourages" WHAT? Loading a far address
is as normal as loading a normal linear address in a 68000.
If you are using more than 64k of memory, it is something
you do. If you aren't, there may not be any need. It depends
what you are doing.

Be specific about your apparently specious claim.

> >> 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

Sure doesn't sound like it.

> you miss the point.  In order to manipulate with memory outside
> of a presently loaded segment,

What do you mean a "presently loaded segment"? Far memory
isn't "loaded", it is merely allocated/assigned and accessed.

> a program must first load a
> segment register to point to some segment that contains the
> memory you want to manipulate.

Yes, and on a S/370 or 68000 you load a linear address
for the memory you wish to address. That's just a different
way of accessing more than 64k of memory. You can use
a flat 32-bit address or you can use two 16-bit registers.
In both cases it is unrelated to a separate concept of
memory protection - which doesn't exist on either the
68000 or 8086.

> 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.

Loading a linear address on a 68000 - accidentally or
deliberately pointing to the OS, is also a logically
equivalent identical _explicit_ operation.

> Crude and fallible as it is, MS-DOS (again) encourages stepping
> past even this feeble mechanism to provide some primitive
> semblence of protection.

I have no idea what you are talking about. Be specific.

> >> 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?

Anyone speaking English - both natives and non-natives.

> >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.

Ok, first of all, no group speaks with one voice. So your
"universally" is complete horseshit. It's only true if you
DEFINE "serious work" as "anyone who agrees with me"
and DEFINE "in the field" as "anyone who agrees with me".

And I personally don't mind you calling (someone else's -
Tim Patterson in this case)'s baby "ugly" (although I would
dispute that). But what is unacceptable is calling his baby
an orangutan when it is absolutely definitely homo sapiens.

It's just dishonest. And note that you have a history of being
dishonest - including just above where you claim that an
entire group of "serious" OS developers "in the field" speaks
with one voice as if you've surveyed them all - when reality
is you're just talking about of your ass.

> I stand by that, though I admit that I don't feel the need to
> condescend to those who might see it differently.  However, you
> _do_ have to bring a better definition that "lol because it is
> because I'm tired of people making fun of it and this is what an
> English langauge dictionary says about it."  My copy of Merriam
> Webster has definitions for all kinds of common words that have
> nothing to do the definition of those same words in specialist
> contexts.

The "specialist context" you are talking about is "a select
group of wankers that I associate with".

You are using that "specialist term" in alt.os.development
where everyone who isn't a complete and utter wanker
uses the Merriam Webster definition because we're
TALKING IN ENGLISH.

If you want to say that "alt.os.development" is itself a
"specialist context" - and your non-English use of the
term should  apply, well I can guarantee you that we
don't speak with one voice in this "specialist context"
either.

So you will only cause confusion and/or annoy people.

If you want to do that - deliberately - fine - but you may
as well be lying about something else too - like PDOS
containing code that is copyrighted by others. Oh - you
do that too.

> >So why the semantic games? What is the actual *point* to this argument?
>
> It may be hard to accept, but words have meaning, and
> specialists in the field get to define those meanings, not
> dictionary editors.

No they don't. Not in this group where not everyone is a
wanker and we are speaking in English.

> If you want to talk seriously about
> operating systems, then one has to engage with _those_ meanings,
> and not what is merely intuitive.

If you want to talk seriously about operating systems, where
"seriously" is DEFINED as "wankers like you", you need to
go to that group where all the wankers that speak with one
voice reside. This is alt.os.development - most of us speak
English. You may get the occasional person who agrees
with the wankers, but it's far from universal, and we've
politely asked you to just add an adjective of "protected"
to your use of the word "operating system".

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18783

(And furthermore: what does "real" in this context even *mean,* and why
should anybody care what someone on the Internet does or doesn't count
in that category?)

[toc] | [prev] | [next] | [standalone]

#18777

"Scott Lurndal" <scott@slp53.sl.home> wrote in message
news:CLGzP.935496$t84d.363634@fx11.iad...

> >and I never heard anyone call it a toy at the time.
>
> Then you weren't listening.

I was - I was listening to people who were actually using
MSDOS to do productive work.

Telling me what productive work they had done.

They didn't tell me they spent the whole day getting paid
to play with a toy.


And regardless, English is DEFINED by common usage.

The Wikipedia people have correctly used the term:

https://en.wikipedia.org/wiki/MS-DOS

MS-DOS acronym for Microsoft Disk Operating System, also known as Microsoft
DOS) is an operating system

https://en.wikipedia.org/wiki/Operating_system

For around five years, the CP/M (Control Program for Microcomputers) was the
most popular operating system for microcomputers



You are free to update that and insist "CP/M is a toy, not an operating
system",
but it will be reverted very quickly, because you are wrong, and they are
right.

If you want to be understood by others, you need to create your
own term that would exclude MSDOS.

You could perhaps go with "a REAL (TM) You-Beaut Operating
System as approved by Scott and Dan and various other sophists -
wankers like Tim Patterson and others can go fuck themselves".

Or you can go with some other term.

But "operating system" is already taken, I'm afraid.

I'm not sure what your goal is by insisting on changing the
term. I get it. There are better operating systems than
QDOS etc. So? Why do you feel the need to keep pointing
that out, to the point of even illegitimizing them? Why are
you trying to put the authors down? Are you one of these
hypocritical Christians who instead of "turning the other cheek"
or "loving thy enemy" you instead "attack the innocent" and
hope that when you get to the Pearly Gates you'll fall
back on the "Jesus has me covered, right?" copout and expect
some god to not bellow with laughter?

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18767

"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message
news:vqit96$1kh$1@reader1.panix.com...

> Further,
> the system interface is inexorably tied to the hardware; it's
> defined in terms of synchronous software traps and specific
> register values.

I don't believe the word "inexorably" is appropriate.

If you look at the MSDOS 4 source code, you can
see that Microsoft created wrappers for these things
for their own use. There is a DosOpen() function for
example.

The fact that they apparently didn't publish that - and
then went and repurposed that same name for 16-bit
OS/2 with a (at least nominally) different interface, is
not a technical issue.

I created my own wrappers (since I didn't have access
to the MSDOS 4 source code at the time), but even
without that, there are existing wrappers (like "open"),
provided by Microsoft's C compiler.

I don't see any reason why Unix's open() is considered
to be "proper" but Microsoft's open() isn't. That's more
of a documentation issue. But which documentation
anyway? The INT 80H used by Linux is documented too.
So MSDOS is illegitmate because Microsoft didn't move
the open() function from one bit of documentation to
another bit of (unspecified) documentation?

I don't like the name open() in either MSDOS or Unix.
I like the name DosOpen(). But I don't like what OS/2
did for types. I like what MSDOS 4 did. I may switch
my own Pos* wrappers to Dos* wrappers one day,
now that the reference exists.

BTW, I now have a standalone mainframe, depending
on definition. No Windows or Linux involved. No ASCII
seen. No Intel or AMD either.

https://groups.io/g/hercules-380/message/3143

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18770

"Paul Edwards" <mutazilah@gmail.com> writes:
>"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message
>news:vqit96$1kh$1@reader1.panix.com...
>
>? The INT 80H used by Linux is documented too.

Linux has used SYSENTER et alia since they were
introduced by Intel and AMD.  INT 80 was legacy on 32-bit systems.

>So MSDOS is illegitmate because Microsoft didn't move
>the open() function from one bit of documentation to
>another bit of (unspecified) documentation?

MSDOS isn't portable (nor particularly useful).

Nobody claims it is 'illegitimate'.  It is
not a real operating system, just a glorified
program loader tied to a single, long obsolete
processor architecture (8088/8086).

Useful today for hobby programming by those
interested in historical operating systems.  Not useful
for current or future production software
development.

[toc] | [prev] | [next] | [standalone]

#18776

"Scott Lurndal" <scott@slp53.sl.home> wrote in message
news:wGGzP.935495$t84d.159724@fx11.iad...
> "Paul Edwards" <mutazilah@gmail.com> writes:
> >"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message
> >news:vqit96$1kh$1@reader1.panix.com...
> >
> >? The INT 80H used by Linux is documented too.
>
> Linux has used SYSENTER et alia since they were
> introduced by Intel and AMD.  INT 80 was legacy on 32-bit systems.
>
> >So MSDOS is illegitmate because Microsoft didn't move
> >the open() function from one bit of documentation to
> >another bit of (unspecified) documentation?
>
> MSDOS isn't portable (nor particularly useful).

Says who? Which bit of open() isn't portable?

> Nobody claims it is 'illegitimate'.  It is
> not a real operating system, just a glorified
> program loader tied to a single, long obsolete
> processor architecture (8088/8086).

It's MOSTLY not tied to the 8086 unless you specifically
define it that way.

The defined interface (open() etc) - if you insist on
using that instead of fopen() - isn't tied to the 8086.

And if you simply use fopen() and other C90 functions
(which may as well be included as "MSDOS", just as
they are included in "Posix", it isn't tied to the 8086 at all.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18778

"Scott Lurndal" <scott@slp53.sl.home> wrote in message
news:wGGzP.935495$t84d.159724@fx11.iad...

> >? The INT 80H used by Linux is documented too.
>
> Linux has used SYSENTER et alia since they were
> introduced by Intel and AMD.  INT 80 was legacy on 32-bit systems.

So? Even when INT 80H was used, it didn't mean that Linux
was tied to the 80386 and either the OS or the applications
wouldn't port to the 68000 which has a different instruction
to do an interrupt.

Because a wrapper existed and was expected to be used.

Just as there are wrappers provided by Microsoft for MSDOS.

You can argue (I'm not particularly arguing) that Linux's
documentation was better, or that it was bundled better,
but that is a separate issue.

You could also argue that the specific MSDOS source code
that you see in releases had 8086 assembler included.

So? Linux has assembler source code too. Lots of it.

You could argue that MSDOS has a higher percentage of
assembler source code. So? What's wrong with that? They
can for example create a mostly C version for the 68000
(I have done that myself in fact), and then decide to have
a hand-optimized assembler version also for the 68000 (I
may choose to do that myself too). So? What does that
prove? That just proves that engineers are doing a good
job spending time and effort to write assembler for a
particular platform. Is your complaint that MSDOS never
had that theoretical C version to allow easy porting?
CP/M was written in a language that allowed porting.
If Microsoft saw some market demand for a 68000 version
of MSDOS, I'm pretty sure their engineers could do that.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18785

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <87o6ybbeqw.fsf@example.com>,
> Salvador Mirzo  <smirzo@example.com> wrote:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>Sure - but why not make it available anyway?
>>>
>>> MS-DOS is, was, and always will be a toy.  It's not even
>>> a real operating system.
>>
>>And why is that?  Is it mainly because it doesn't time-share the CPU?
> 
> It depends on your definition of an operating system, I suppose.
> I like the definition Mothy Roscoe (ETH) used in his OSDI'21
> keynote:
> 
> The operating system is that body of software that:
> 1. Multiplexes the machine's hardware resources
> 2. Abstracts the hardware platform
> 3. Protects software princples from each other
>    (using the hardare)

This is oversimplified definition, any definition of similar
length will be oversimplified.  But let us see how this
works.

> It's hard to see how MS-DOS fits that definition in a meaningful
> way.  Does it multiplex the machine's hardware resources?  Well,
> no; not really.

Well, it does.  Origin of name "operationg system" comes from
automating part of work of machine operator.  In particular,
operatining system loads a program and when program is done
operatining system regains control, decides what to run next
and loads it.  Operating system may load multiple programs
at the same time and multiplex between them.  But loading
programs seqentially still is form of multiplexing.  If
you amend definition above excluding such form of multiplexing,
then you get rather narrow definition which exculdes a lot
of historical and even current operatining systems.

Also, you seem to ignore a file system.  For definition
above to make any sense multipling machine hardware
resources must include mutiplexing (coordinating) access
to external storage which is (part of) function of file system.

>  While it does provide a primitive filesystem,
> and exposes some interface for memory management, it only lets
> one program run at a time, and that program doesn't have to use
> or honor DOS's filesystem or memory management stuff.  Further,
> the system interface is inexorably tied to the hardware; it's
> defined in terms of synchronous software traps and specific
> register values.  System calls are numbered, not named.

System calls are numbered in almost all operating systems.
Names are in documentation and/or as part of programming
language support, but actual interface is in terms of numbers.
Clearly system call mechanizm is has strong connection to
hardware and freqently defined in terms of instructions like
SVC.

> Finally, the last one is really the nail in the coffin: MS-DOS
> makes absolutely no effort to protect the software principles
> from each other, or even themselves; a user program can take
> over and just never cede control back to DOS. 

Well, DOS is close to best possible protection given the
hardware.  In modern times hardware protection gained
importance, but putting hardware protection as mandatory
part of operating system definition distorts history
quite a lot.

There is a lot of valid critique of DOS, but saying that it is
not an OS is just silly game of words.  You can pile adjectives
on OS, like "multitasking OS", "proteded OS" (or better
"OS using hardware protection") and DOS will be outside such
restricted classes of OS-es.  But is clearly an OS.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#18786

In article <vqpuko$3kgpd$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <87o6ybbeqw.fsf@example.com>,
>> Salvador Mirzo  <smirzo@example.com> wrote:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>>Sure - but why not make it available anyway?
>>>>
>>>> MS-DOS is, was, and always will be a toy.  It's not even
>>>> a real operating system.
>>>
>>>And why is that?  Is it mainly because it doesn't time-share the CPU?
>> 
>> It depends on your definition of an operating system, I suppose.
>> I like the definition Mothy Roscoe (ETH) used in his OSDI'21
>> keynote:
>> 
>> The operating system is that body of software that:
>> 1. Multiplexes the machine's hardware resources
>> 2. Abstracts the hardware platform
>> 3. Protects software princples from each other
>>    (using the hardare)
>
>This is oversimplified definition, any definition of similar
>length will be oversimplified.  But let us see how this
>works.

Mmm...not really.

>> It's hard to see how MS-DOS fits that definition in a meaningful
>> way.  Does it multiplex the machine's hardware resources?  Well,
>> no; not really.
>
>[snip]
>
>Also, you seem to ignore a file system.  For definition

Funny how in the very next paragraph you quoted, I was talking
about a filesystem.  ;-P

>above to make any sense multipling machine hardware
>resources must include mutiplexing (coordinating) access
>to external storage which is (part of) function of file system.
>
>>  While it does provide a primitive filesystem,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(See note above)

>> and exposes some interface for memory management, it only lets
>> one program run at a time, and that program doesn't have to use
>> or honor DOS's filesystem or memory management stuff.  Further,
>> the system interface is inexorably tied to the hardware; it's
>> defined in terms of synchronous software traps and specific
>> register values.  System calls are numbered, not named.
>
>System calls are numbered in almost all operating systems.

You're talking about the ABI.

>[snip]
>> Finally, the last one is really the nail in the coffin: MS-DOS
>> makes absolutely no effort to protect the software principles
>> from each other, or even themselves; a user program can take
>> over and just never cede control back to DOS. 
>
>Well, DOS is close to best possible protection given the
>hardware.  In modern times hardware protection gained
>importance, but putting hardware protection as mandatory
>part of operating system definition distorts history
>quite a lot.

By the time the IBM PC came along, we'd had systems where the
OS was protected from errant programs for 20 years.  For example
look up the Manchester Atlas system.

>There is a lot of valid critique of DOS, but saying that it is
>not an OS is just silly game of words.  You can pile adjectives
>on OS, like "multitasking OS", "proteded OS" (or better
>"OS using hardware protection") and DOS will be outside such
>restricted classes of OS-es.  But is clearly an OS.

Well, except perhaps it is not.  At least not by a very
reasonable definition that's widely accepted in the field.

I really don't see why people are so upset about this; it's not
a huge deal.  DOS was ok for it's time and for what it enabled
on the original IBM PC; the hardware was very limited, and so it
wasn't nearly as capable as larger systems with "real" operating
systems.  Why is it a priori a bad thing to acknowledge that?

It sure seems like some people are getting worked up about a
very minor thing.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#18788

"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message
news:vqpvef$bpj$1@reader1.panix.com...

> >Well, DOS is close to best possible protection given the
> >hardware.  In modern times hardware protection gained
> >importance, but putting hardware protection as mandatory
> >part of operating system definition distorts history
> >quite a lot.
>
> By the time the IBM PC came along, we'd had systems where the
> OS was protected from errant programs for 20 years.  For example
> look up the Manchester Atlas system.

Irrelevant.

> >There is a lot of valid critique of DOS, but saying that it is
> >not an OS is just silly game of words.  You can pile adjectives
> >on OS, like "multitasking OS", "proteded OS" (or better
> >"OS using hardware protection") and DOS will be outside such
> >restricted classes of OS-es.  But is clearly an OS.

Exactly.

> Well, except perhaps it is not.

It is.

> At least not by a very
> reasonable definition that's widely accepted in the field.

Total nonsense. Only complete jackasses "in the field"
would say that MSDOS is a misnomer that doesn't meet
"the" technical definition of an OS.

Most people I have seen in the field - including the author
of QDOS - do not make that claim.

> I really don't see why people are so upset about this; it's not
> a huge deal.

If it's not a huge deal, then please stop insisting that
MSDOS isn't an OS, and instead just use the correct
adjective, such as "non-protected OS" to describe
MSDOS if you have some point you are trying to
make.

Hint - you have no point you are trying to make. You're
just being a jackass. You're not telling anyone here
anything they don't already know.

> DOS was ok for it's time and for what it enabled
> on the original IBM PC; the hardware was very limited, and so it
> wasn't nearly as capable as larger systems with "real" operating
> systems.  Why is it a priori a bad thing to acknowledge that?

Nobody is not acknowledging that MSDOS was less capable.
That's just your strawman.

All we're doing is saying is that the English words used in
Wikipedia are correct, the OS in MSDOS is not a misnomer,
and please stop insisting that the whole world is using the
English language incorrectly, because you and some of your
jackass friends are trying to change the language.

> It sure seems like some people are getting worked up about a
> very minor thing.

If it's a minor thing, then take your own advice and just admit
you were wrong according to the widespread use of the term
both inside and outside of computer science, and drop it.

Apparently it's not minor, and you are bluffing in an attempt
to delegitimize any OS that doesn't have specific features,
for ulterior motives.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18791

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <vqpuko$3kgpd$1@paganini.bofh.team>,
> Waldek Hebisch <antispam@fricas.org> wrote:
>>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> In article <87o6ybbeqw.fsf@example.com>,
>>> Salvador Mirzo  <smirzo@example.com> wrote:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>>>Sure - but why not make it available anyway?
>>>>>
>>>>> MS-DOS is, was, and always will be a toy.  It's not even
>>>>> a real operating system.
>>>>
>>>>And why is that?  Is it mainly because it doesn't time-share the CPU?
>>> 
>>> It depends on your definition of an operating system, I suppose.
>>> I like the definition Mothy Roscoe (ETH) used in his OSDI'21
>>> keynote:
>>> 
>>> The operating system is that body of software that:
>>> 1. Multiplexes the machine's hardware resources
>>> 2. Abstracts the hardware platform
>>> 3. Protects software princples from each other
>>>    (using the hardare)
>>
>>This is oversimplified definition, any definition of similar
>>length will be oversimplified.  But let us see how this
>>works.
> 
> Mmm...not really.
> 
>>> It's hard to see how MS-DOS fits that definition in a meaningful
>>> way.  Does it multiplex the machine's hardware resources?  Well,
>>> no; not really.
>>
>>[snip]
>>
>>Also, you seem to ignore a file system.  For definition
> 
> Funny how in the very next paragraph you quoted, I was talking
> about a filesystem.  ;-P
> 
>>above to make any sense multipling machine hardware
>>resources must include mutiplexing (coordinating) access
>>to external storage which is (part of) function of file system.
>>
>>>  While it does provide a primitive filesystem,
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (See note above)

You did not state relation with "multiplex the machine's hardware"
and quick "Well, no; not really" suggests that you do not
count this as multiplexing, I think that you should.

>>> and exposes some interface for memory management, it only lets
>>> one program run at a time, and that program doesn't have to use
>>> or honor DOS's filesystem or memory management stuff.  Further,
>>> the system interface is inexorably tied to the hardware; it's
>>> defined in terms of synchronous software traps and specific
>>> register values.  System calls are numbered, not named.
>>
>>System calls are numbered in almost all operating systems.
> 
> You're talking about the ABI.

Yes, that is what matters for programs.

>>[snip]
>>> Finally, the last one is really the nail in the coffin: MS-DOS
>>> makes absolutely no effort to protect the software principles
>>> from each other, or even themselves; a user program can take
>>> over and just never cede control back to DOS. 
>>
>>Well, DOS is close to best possible protection given the
>>hardware.  In modern times hardware protection gained
>>importance, but putting hardware protection as mandatory
>>part of operating system definition distorts history
>>quite a lot.
> 
> By the time the IBM PC came along, we'd had systems where the
> OS was protected from errant programs for 20 years.  For example
> look up the Manchester Atlas system.

Sure, there were system with memory protection.  But a lot
of hardware had not memory protection and even now such
hardware is in extensive use (granted some foljs are not
aware of them and even more would not count them as computers).

>>There is a lot of valid critique of DOS, but saying that it is
>>not an OS is just silly game of words.  You can pile adjectives
>>on OS, like "multitasking OS", "proteded OS" (or better
>>"OS using hardware protection") and DOS will be outside such
>>restricted classes of OS-es.  But is clearly an OS.
> 
> Well, except perhaps it is not.  At least not by a very
> reasonable definition that's widely accepted in the field.
> 
> I really don't see why people are so upset about this; it's not
> a huge deal.  DOS was ok for it's time and for what it enabled
> on the original IBM PC; the hardware was very limited, and so it
> wasn't nearly as capable as larger systems with "real" operating
> systems.  Why is it a priori a bad thing to acknowledge that?

I do not care about DOS.  And I acknowledge limitations of DOS.
I do care about clear terminology.  Terminology where removing
memory protection from Linux (to make it run on hardware not
capable of memory protection) turns it into "not an OS" is
a nonsense.  Concerning widely accepted: I do not think that your
interpretation of definition is widely accepted.  I mean,
putting hardware memory protection as part of definition
may acknowlege its importance for some operationg systems,
but leave it optional in general.  If hardware memory
protection was intended as mandatory thing, then this is
politcal statement with which I think a lot of specialists
disagree.  For example Wirth gives "system Oberon" which he
calls operating system, but which has no hardware memory
protection.

More generally, basic terminology should be incusive.  It
is easy to add extra qualifiers to narrow meaning.  It
is awkward to use phrases "something like OS, but which
does not satify some random guy definition of OS".

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#18792

In article <vqqfj2$3lcdp$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <vqpuko$3kgpd$1@paganini.bofh.team>,
>> Waldek Hebisch <antispam@fricas.org> wrote:
>>>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>> In article <87o6ybbeqw.fsf@example.com>,
>>>> Salvador Mirzo  <smirzo@example.com> wrote:
>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>
>>>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>>>>Sure - but why not make it available anyway?
>>>>>>
>>>>>> MS-DOS is, was, and always will be a toy.  It's not even
>>>>>> a real operating system.
>>>>>
>>>>>And why is that?  Is it mainly because it doesn't time-share the CPU?
>>>> 
>>>> It depends on your definition of an operating system, I suppose.
>>>> I like the definition Mothy Roscoe (ETH) used in his OSDI'21
>>>> keynote:
>>>> 
>>>> The operating system is that body of software that:
>>>> 1. Multiplexes the machine's hardware resources
>>>> 2. Abstracts the hardware platform
>>>> 3. Protects software princples from each other
>>>>    (using the hardare)
>>>
>>>This is oversimplified definition, any definition of similar
>>>length will be oversimplified.  But let us see how this
>>>works.
>> 
>> Mmm...not really.
>> 
>>>> It's hard to see how MS-DOS fits that definition in a meaningful
>>>> way.  Does it multiplex the machine's hardware resources?  Well,
>>>> no; not really.
>>>
>>>[snip]
>>>
>>>Also, you seem to ignore a file system.  For definition
>> 
>> Funny how in the very next paragraph you quoted, I was talking
>> about a filesystem.  ;-P
>> 
>>>above to make any sense multipling machine hardware
>>>resources must include mutiplexing (coordinating) access
>>>to external storage which is (part of) function of file system.
>>>
>>>>  While it does provide a primitive filesystem,
>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> (See note above)
>
>You did not state relation with "multiplex the machine's hardware"

Actually, I did.  Perhaps you are having a hard time
understanding what I wrote?  Is there some way I could make it
claerer?

>and quick "Well, no; not really" suggests that you do not
>count this as multiplexing, I think that you should.

See above.

>>>> and exposes some interface for memory management, it only lets
>>>> one program run at a time, and that program doesn't have to use
>>>> or honor DOS's filesystem or memory management stuff.  Further,
>>>> the system interface is inexorably tied to the hardware; it's
>>>> defined in terms of synchronous software traps and specific
>>>> register values.  System calls are numbered, not named.
>>>
>>>System calls are numbered in almost all operating systems.
>> 
>> You're talking about the ABI.
>
>Yes, that is what matters for programs.
>
>>>[snip]
>>>> Finally, the last one is really the nail in the coffin: MS-DOS
>>>> makes absolutely no effort to protect the software principles
>>>> from each other, or even themselves; a user program can take
>>>> over and just never cede control back to DOS. 
>>>
>>>Well, DOS is close to best possible protection given the
>>>hardware.  In modern times hardware protection gained
>>>importance, but putting hardware protection as mandatory
>>>part of operating system definition distorts history
>>>quite a lot.
>> 
>> By the time the IBM PC came along, we'd had systems where the
>> OS was protected from errant programs for 20 years.  For example
>> look up the Manchester Atlas system.
>
>Sure, there were system with memory protection.  But a lot
>of hardware had not memory protection and even now such
>hardware is in extensive use (granted some foljs are not
>aware of them and even more would not count them as computers).
>
>>>There is a lot of valid critique of DOS, but saying that it is
>>>not an OS is just silly game of words.  You can pile adjectives
>>>on OS, like "multitasking OS", "proteded OS" (or better
>>>"OS using hardware protection") and DOS will be outside such
>>>restricted classes of OS-es.  But is clearly an OS.
>> 
>> Well, except perhaps it is not.  At least not by a very
>> reasonable definition that's widely accepted in the field.
>> 
>> I really don't see why people are so upset about this; it's not
>> a huge deal.  DOS was ok for it's time and for what it enabled
>> on the original IBM PC; the hardware was very limited, and so it
>> wasn't nearly as capable as larger systems with "real" operating
>> systems.  Why is it a priori a bad thing to acknowledge that?
>
>I do not care about DOS.  And I acknowledge limitations of DOS.
>I do care about clear terminology.  Terminology where removing
>memory protection from Linux (to make it run on hardware not
>capable of memory protection) turns it into "not an OS" is
>a nonsense. Concerning widely accepted: I do not think that your
>interpretation of definition is widely accepted.  I mean,
>putting hardware memory protection as part of definition
>may acknowlege its importance for some operationg systems,
>but leave it optional in general.  If hardware memory
>protection was intended as mandatory thing, then this is
>politcal statement with which I think a lot of specialists
>disagree.

As I said, this is the definition due to Mothy Roscoe at ETH.
It was given in the keynote for one of the two major conferences
on the subject.  Perhaps watch for yourself and then judge.

https://www.usenix.org/conference/osdi21/presentation/fri-keynote

>For example Wirth gives "system Oberon" which he
>calls operating system, but which has no hardware memory
>protection.

Speaking of ETH....

>More generally, basic terminology should be incusive.  It
>is easy to add extra qualifiers to narrow meaning.  It
>is awkward to use phrases "something like OS, but which
>does not satify some random guy definition of OS".

Sounds like you have some studying to do, my boy.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#18793

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <vqqfj2$3lcdp$1@paganini.bofh.team>,
> Waldek Hebisch <antispam@fricas.org> wrote:
>>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> In article <vqpuko$3kgpd$1@paganini.bofh.team>,
>>> Waldek Hebisch <antispam@fricas.org> wrote:
>>>>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>>> In article <87o6ybbeqw.fsf@example.com>,
>>>>> Salvador Mirzo  <smirzo@example.com> wrote:
>>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>>>>>>Sure - but why not make it available anyway?
>>>>>>>
>>>>>>> MS-DOS is, was, and always will be a toy.  It's not even
>>>>>>> a real operating system.
>>>>>>
>>>>>>And why is that?  Is it mainly because it doesn't time-share the CPU?
>>>>> 
>>>>> It depends on your definition of an operating system, I suppose.
>>>>> I like the definition Mothy Roscoe (ETH) used in his OSDI'21
>>>>> keynote:
>>>>> 
>>>>> The operating system is that body of software that:
>>>>> 1. Multiplexes the machine's hardware resources
>>>>> 2. Abstracts the hardware platform
>>>>> 3. Protects software princples from each other
>>>>>    (using the hardare)
>>>>
>>>>This is oversimplified definition, any definition of similar
>>>>length will be oversimplified.  But let us see how this
>>>>works.
>>> 
>>> Mmm...not really.
>>> 
>>>>> It's hard to see how MS-DOS fits that definition in a meaningful
>>>>> way.  Does it multiplex the machine's hardware resources?  Well,
>>>>> no; not really.
>>>>
>>>>[snip]
>>>>
>>>>Also, you seem to ignore a file system.  For definition
>>> 
>>> Funny how in the very next paragraph you quoted, I was talking
>>> about a filesystem.  ;-P
>>> 
>>>>above to make any sense multipling machine hardware
>>>>resources must include mutiplexing (coordinating) access
>>>>to external storage which is (part of) function of file system.
>>>>
>>>>>  While it does provide a primitive filesystem,
>>>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> (See note above)
>>
>>You did not state relation with "multiplex the machine's hardware"
> 
> Actually, I did.  Perhaps you are having a hard time
> understanding what I wrote?  Is there some way I could make it
> claerer?
> 
>>and quick "Well, no; not really" suggests that you do not
>>count this as multiplexing, I think that you should.
> 
> See above.
> 
>>>>> and exposes some interface for memory management, it only lets
>>>>> one program run at a time, and that program doesn't have to use
>>>>> or honor DOS's filesystem or memory management stuff.  Further,
>>>>> the system interface is inexorably tied to the hardware; it's
>>>>> defined in terms of synchronous software traps and specific
>>>>> register values.  System calls are numbered, not named.
>>>>
>>>>System calls are numbered in almost all operating systems.
>>> 
>>> You're talking about the ABI.
>>
>>Yes, that is what matters for programs.
>>
>>>>[snip]
>>>>> Finally, the last one is really the nail in the coffin: MS-DOS
>>>>> makes absolutely no effort to protect the software principles
>>>>> from each other, or even themselves; a user program can take
>>>>> over and just never cede control back to DOS. 
>>>>
>>>>Well, DOS is close to best possible protection given the
>>>>hardware.  In modern times hardware protection gained
>>>>importance, but putting hardware protection as mandatory
>>>>part of operating system definition distorts history
>>>>quite a lot.
>>> 
>>> By the time the IBM PC came along, we'd had systems where the
>>> OS was protected from errant programs for 20 years.  For example
>>> look up the Manchester Atlas system.
>>
>>Sure, there were system with memory protection.  But a lot
>>of hardware had not memory protection and even now such
>>hardware is in extensive use (granted some foljs are not
>>aware of them and even more would not count them as computers).
>>
>>>>There is a lot of valid critique of DOS, but saying that it is
>>>>not an OS is just silly game of words.  You can pile adjectives
>>>>on OS, like "multitasking OS", "proteded OS" (or better
>>>>"OS using hardware protection") and DOS will be outside such
>>>>restricted classes of OS-es.  But is clearly an OS.
>>> 
>>> Well, except perhaps it is not.  At least not by a very
>>> reasonable definition that's widely accepted in the field.
>>> 
>>> I really don't see why people are so upset about this; it's not
>>> a huge deal.  DOS was ok for it's time and for what it enabled
>>> on the original IBM PC; the hardware was very limited, and so it
>>> wasn't nearly as capable as larger systems with "real" operating
>>> systems.  Why is it a priori a bad thing to acknowledge that?
>>
>>I do not care about DOS.  And I acknowledge limitations of DOS.
>>I do care about clear terminology.  Terminology where removing
>>memory protection from Linux (to make it run on hardware not
>>capable of memory protection) turns it into "not an OS" is
>>a nonsense. Concerning widely accepted: I do not think that your
>>interpretation of definition is widely accepted.  I mean,
>>putting hardware memory protection as part of definition
>>may acknowlege its importance for some operationg systems,
>>but leave it optional in general.  If hardware memory
>>protection was intended as mandatory thing, then this is
>>politcal statement with which I think a lot of specialists
>>disagree.
> 
> As I said, this is the definition due to Mothy Roscoe at ETH.
> It was given in the keynote for one of the two major conferences
> on the subject.  Perhaps watch for yourself and then judge.
> 
> https://www.usenix.org/conference/osdi21/presentation/fri-keynote
> 
>>For example Wirth gives "system Oberon" which he
>>calls operating system, but which has no hardware memory
>>protection.
> 
> Speaking of ETH....
> 
>>More generally, basic terminology should be incusive.  It
>>is easy to add extra qualifiers to narrow meaning.  It
>>is awkward to use phrases "something like OS, but which
>>does not satify some random guy definition of OS".
> 
> Sounds like you have some studying to do, my boy.
 
Mind you, I know how keynote lectures at conferences work.
I know enough about operating systems to have my own
opinion what an OS is, no need to defer to some external
authority.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#18794

In article <vqqr62$3qp0n$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Sounds like you have some studying to do, my boy.
> 
>Mind you, I know how keynote lectures at conferences work.
>I know enough about operating systems to have my own
>opinion what an OS is, no need to defer to some external
>authority.

Pardon me if I'm skeptical of these claims.  Perhaps you'd care
to cite some sources, or offer some credentials, or something of
that nature, to establish some credibility for your assertions?

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#18796

"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message
news:vqqrr1$pc3$1@reader1.panix.com...
> In article <vqqr62$3qp0n$1@paganini.bofh.team>,
> Waldek Hebisch <antispam@fricas.org> wrote:
> >Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> >> Sounds like you have some studying to do, my boy.
> >
> >Mind you, I know how keynote lectures at conferences work.
> >I know enough about operating systems to have my own
> >opinion what an OS is, no need to defer to some external
> >authority.
>
> Pardon me if I'm skeptical of these claims.  Perhaps you'd care
> to cite some sources, or offer some credentials, or something of
> that nature, to establish some credibility for your assertions?

Which claim? That he knows about OSes? You want him to
list the books he has read or the source code he has looked
at and if you've read more books than him, you are superior
to him, despite the fact that you are a lying jackass who has
trouble understanding the 8086 despite claims to the
contrary?

Superior in your eyes, perhaps.

I can understand why he wouldn't want to defer to some
external authority nominated by you. So that claim?

He's no more likely to defer to your nominated external
authority than you are likely to defer to mine.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18681

On Fri, 19 Jul 2024 18:43:13 +0800
"Paul Edwards" <mutazilah@gmail.com> wrote:

> Sure - but why not make it available anyway? What's the barrier
> to someone doing that? No-one is interested? Too much work?
> It didn't need to be Microsoft personally. And it can be written
> in C to make things easier. Or even some other language - e.g.
> CP/M was written in PL/M I think.

Well, 35 yrs. ago, x86 wasn't even a thing in the "mainframe" (by which
we presumably mean "large-scale, heavy-duty business computing") space;
in 1989 e.g. CompuServe was still entirely a PDP-10 shop, IBM had just
rolled out its AS/400 line, and the IA-32 architecture was still four
years away from even going superscalar. Others here have far more
direct knowledge of the "mainframe" space than myself, and can feel
free to correct me, but AFAIK x86 systems didn't see broad acceptance
in truly heavy-duty business computing 'til the mid-'00s.

And while MS-DOS can certainly be used for classic batch processing, it
has practically no support for multitasking, which was already a thing
in the mainframe space all the way back to the '60s, because any given
batch job will not *necessarily* make maximal use of the computer, and
at large scale it makes no sense to leave available resources idle.
It's possible to set specialized utilities running as TSRs in DOS, but
the system as a whole is not designed for more than one "real" program
to run at a time - so sharing the system between large numbers of
individual jobs in a generalized way simply isn't possible.

So, in short: there was no mainframe hardware platform that it could be
ported to back in the day, and it's not well-suited for that use case.
One certainly *could* get it running on, say, a large x86 cluster as a
novelty, but it's not a huge surprise that, thus far, nobody has been
thus inclined.

[toc] | [prev] | [next] | [standalone]

#18703

"John Ames" <commodorejohn@gmail.com> wrote in message
news:20240719093533.00001ee2@gmail.com...

> And while MS-DOS can certainly be used for classic batch processing, it
> has practically no support for multitasking, which was already a thing
>
> So, in short: there was no mainframe hardware platform that it could be
> ported to back in the day, and it's not well-suited for that use case.
> One certainly *could* get it running on, say, a large x86 cluster as a
> novelty, but it's not a huge surprise that, thus far, nobody has been
> thus inclined.

I'm not familiar with "clusters". Could you tell me what this
"novelty" port would look like?

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#18708

On Wed, 21 Aug 2024 04:20:24 +0800
"Paul Edwards" <mutazilah@gmail.com> wrote:

> I'm not familiar with "clusters". Could you tell me what this
> "novelty" port would look like?

"Clusters" being "large numbers of discrete systems across which work
is distributed," an idea that goes back at least to the Transputer but
which really took off in high-performance computing in the early '00s
(IIRC,) when commodity PC hardware reached a performance level such that
it was practical to use "a bunch of PCs in a network" as a replacement
for a single high-performance computer of some other flavor, depending
on the job.

So, for the sake of argument, let's say you got MS-DOS running on such
a platform - certainly possible, since it's fundamentally a PC (leaving
aside issues of e.g. real-mode BIOS vs. UEFI or getting packet drivers
for the NIC, as well as getting the network stack going.) You then have
a large number of DOS PCs on which you can run one (1) job at a time.

Now, assuming that you're doing this because you have a large number of
jobs which you'd like to power through in a maximally efficient manner,
you'd also need some kind of supervisory system to distribute jobs from
the pile to individual nodes in the cluster. There's no reason this
couldn't also run on MS-DOS; in any case, you'd need software on both
ends to *A.* schedule the job for a particular node, *B.* provide that
node with access to the files/resources needed to do it, and *C.* keep
it rolling from one job right into the next.

Now you've got things going; but it's a far cry from maximum efficiency,
because the hardware on each node in the cluster is almost certainly
capable of multi-threaded operation, but DOS has no support for multi-
processing at all. (It's also probably a 64-bit system, but we'll say
for the sake of argument that you've got some kind of amd64 equivalent
to a DPMI going - has anyone written one yet? - so that your application
can at least make full-ish use of a single CPU core.)

There's two ways you could go about handling this. You could attempt to
extend your single-threaded MS-DOS application into a multi-threaded
one, handling all the scheduling and resource-contention issues within
itself. At this point, you've more or less implemented a different OS
on top of DOS (like pre-NT Windows.) Not terribly ideal, since you are
(presumably) still handling I/O through DOS and your DOS-based network
stack, which are single-threaded and will bottleneck all the other
threads. (This was something that Amiga programmers used to deal with:
pre-emptive multitasking bolted awkwardly to a single-threaded DOS.)

Alternatively, you could choose to virtualize; modern implementations
of the amd64 architecture support this natively in hardware, so you can
put even your 64-bit DPMI-enabled mutant MS-DOS program in a container
such that it thinks it's running by itself on a single-threaded CPU,
and then run as many of those in parallel as you have CPU threads. Of
course, you'll need a hypervisor system in place for this; for the sake
of argument, you could probably *also* run this on MS-DOS, but I very
much doubt anyone's written such a beast, so you'd probably have to do
it yourself. You might also need to extend your supervisor-node
software to parcel out multiple jobs to each machine, unless all the
hypervisor-guest systems appear as individual nodes on the network
(which they certainly could.)

So, to summarize: all you need in order to accomplish this is 1. a DOS-
based hypervisor which almost certainly doesn't exist, 2. a 64-bit DPMI
extender which probably doesn't, 3. DOS-based remote job execution
tools which might conceivably already exist, but may not, 4. your own
particular mutant 64-bit MS-DOS application, and 5. a task sufficiently
large/intensive to justify all this effort on in the first place.

Should make for a nice weekend project!

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | alt.os.development

csiph-web