Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #18677 > unrolled thread
| Started by | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| First post | 2024-07-18 23:07 +0800 |
| Last post | 2025-03-10 14:46 +0000 |
| Articles | 20 on this page of 88 — 13 participants |
Back to article view | Back to alt.os.development
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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-09 15:40 +0000 |
| Message-ID | <HDizP.341661$eNx6.233542@fx14.iad> |
| In reply to | #18756 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >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) > >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. 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. To partially aleviate these defects, a concept called TSR (Terminate and Stay Resident) was developed for MS-DOS. However, conflicts between various TSRs were endemic and there was no hardware protection between them or between them and the application code. https://en.wikipedia.org/wiki/Terminate-and-stay-resident_program#Faults > 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. >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. > >So it's hard to see how DOS really qualifies as an OS, despite >the OS-like abstractions it provides. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-10 12:38 +0000 |
| Message-ID | <vqmmf8$gqu$1@reader1.panix.com> |
| In reply to | #18757 |
In article <HDizP.341661$eNx6.233542@fx14.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <87o6ybbeqw.fsf@example.com>, >>Salvador Mirzo <smirzo@example.com> wrote: >>>scott@slp53.sl.home (Scott Lurndal) writes: >>>> 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) >> >>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. 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. > >To partially aleviate these defects, a concept called TSR (Terminate and >Stay Resident) was developed for MS-DOS. However, conflicts >between various TSRs were endemic and there was no hardware >protection between them or between them and the application >code. > >https://en.wikipedia.org/wiki/Terminate-and-stay-resident_program#Faults Oh gee, as a form of mental self-protection, I had blanked that madness out of my mind. What an awful interface. I do hand it to people who were writing DOS programs; without any real form or protection between programs, let along between DOS and programs, it's amazing that anything there worked at all. Still, lack of multiprogramming shows that they were targetting an audience that was pretty unsophisticated. I get that the hardware was limited, but Unix on the PDP-7 supported multiple users in 8KiW of 18-bit memory in 1969. A 16-bit system 12 years later could have supported a real OS, albeit without useful memory protection (CPU rings and the CPL didn't show up until the 80286). I suppose one could have played games with segmentation to isolate a small kernel; as I understand it, that was how the various Unix ports worked. It's weird to me how the 8086 included support for multiprocessing systems, but not a mode bit for a kernel. It's fun to speculate how the world could have been different: had Intel chosen the 68000 for the IBM PC, I imagine we could have had much more reasonable software rather quickly. The ripple effects of the legacy of DOS and the 8086 are unfortunate, at best. Oh well. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-10 14:49 +0000 |
| Message-ID | <k_CzP.209128$zz8b.99328@fx09.iad> |
| In reply to | #18760 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <HDizP.341661$eNx6.233542@fx14.iad>, >Scott Lurndal <slp53@pacbell.net> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes: >>>In article <87o6ybbeqw.fsf@example.com>, >>>Salvador Mirzo <smirzo@example.com> wrote: >>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>>> 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) >>> >>>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. 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. >> >>To partially aleviate these defects, a concept called TSR (Terminate and >>Stay Resident) was developed for MS-DOS. However, conflicts >>between various TSRs were endemic and there was no hardware >>protection between them or between them and the application >>code. >> >>https://en.wikipedia.org/wiki/Terminate-and-stay-resident_program#Faults > >Oh gee, as a form of mental self-protection, I had blanked that >madness out of my mind. What an awful interface. I do hand it >to people who were writing DOS programs; without any real form >or protection between programs, let along between DOS and >programs, it's amazing that anything there worked at all. > >Still, lack of multiprogramming shows that they were targetting >an audience that was pretty unsophisticated. I get that the >hardware was limited, but Unix on the PDP-7 supported multiple >users in 8KiW of 18-bit memory in 1969. I cut my teeth on https://en.wikipedia.org/wiki/TSS/8 Which supported multiple users in 8KW 12-bit memory in 1967.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-10 15:00 +0000 |
| Message-ID | <vqmupg$d5$1@reader1.panix.com> |
| In reply to | #18764 |
In article <k_CzP.209128$zz8b.99328@fx09.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>Still, lack of multiprogramming shows that they were targetting >>an audience that was pretty unsophisticated. I get that the >>hardware was limited, but Unix on the PDP-7 supported multiple >>users in 8KiW of 18-bit memory in 1969. > >I cut my teeth on https://en.wikipedia.org/wiki/TSS/8 > >Which supported multiple users in 8KW 12-bit memory in 1967. My point exactly. :-) I get how PC designers may have wanted to avoid timesharing, "hey, it's _my_ *personal* computer!", but there was no excuse for not supporting multiprogramming. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2025-03-10 09:21 -0300 |
| Message-ID | <87ikoh13fx.fsf@example.com> |
| In reply to | #18756 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > 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) Thanks for the definition and the reference. > 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. 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. > 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. > > So it's hard to see how DOS really qualifies as an OS, despite > the OS-like abstractions it provides. Thanks for the explanation. I now think that DOS is useful today in illustrating the definition (in a negative way) as you just did. I actually plan to understand more about DOS just to be able to personally give an answer like that. It also seems very useful precisely to expose a programmer to the entire machine.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-10 13:50 +0000 |
| Message-ID | <vqmqn7$e4b$1@reader1.panix.com> |
| In reply to | #18758 |
In article <87ikoh13fx.fsf@example.com>, Salvador Mirzo <smirzo@example.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> [snip] >> >> So it's hard to see how DOS really qualifies as an OS, despite >> the OS-like abstractions it provides. > >Thanks for the explanation. Certainly; happy to do it. >I now think that DOS is useful today in >illustrating the definition (in a negative way) as you just did. I >actually plan to understand more about DOS just to be able to personally >give an answer like that. This, I think, is reasonable. >It also seems very useful precisely to expose a programmer to the entire >machine. But this I'd push back on, at least until I understood the goal a bit better. Is the intent to understand how systems work at a low level? To understand systems architectural more generally? Or as a, "how did we get here?" exercise in systems evolution? While understanding some bits of DOS, the BIOS, and the context around the late 70s/early 80s PC/home computer indistru is essential for the last, for first two, there are other, better ways to understand the machine than studying DOS and the BIOS. And in particular, modern systems, even those built around x86 CPUs, bear little resemblence to the original IBM PC. Personally, I think one is better off coming at things from a fresher, more modern perspective, unencumbered by the follies of the past, as opposed to looking at things through the lens of 1979 Boca Raton. To understand hardware at the most basic level, one would be better off looking at something like the Arduino platform, which is almost stupidly simple, but by design, very approachable. To understand architecture at a more rational level, look at something like RISC-V; x86, and x86_64, carries too much baggage from the past that obfuscates understanding. To understand OS design, or even firmware, there are better examples out there. I'd look at something like MIT's materials for their OS course, in particular xv6. The negative case study aside, or spelunking into the history of the PC platform, I can't think of a good reason to study DOS. Historically important, yes; but otherwise an exemplar of how over-compensating for technical constraints can lead to bad technology. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2025-03-10 14:10 -0300 |
| Message-ID | <874j00yfpr.fsf@example.com> |
| In reply to | #18761 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <87ikoh13fx.fsf@example.com>, > Salvador Mirzo <smirzo@example.com> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes: [...] >>It also seems very useful precisely to expose a programmer to the entire >>machine. > > But this I'd push back on, at least until I understood the goal > a bit better. Is the intent to understand how systems work at a > low level? To understand systems architectural more generally? > Or as a, "how did we get here?" exercise in systems evolution? Heads up---this is a long sharing of personal interests, which might be awfully uninteresting. I seem to have a certain interest in how things work. I never got into hardware, though, even though my first computer book was a book called Hardware---it helped me to put together my computer and made sense of some BIOS options, but I can't quite remember anything else from it, after all the years. Hardware (by Gabriel Torres, a Brazilian author) https://www.clubedohardware.com.br/livros/disponiveis/hardware-2%C2%AA-edi%C3%A7%C3%A3o-r33/ I was surprised to see the first edition being published in 2022. (I read the first edition most likely in 1994 or 1995, around those days.) Although I know the POSIX API superficially well enough to write network servers in C, say, I also did not get at all into the UNIX kernel---always thought of doing, but never quite managed to. So it seems to me that that my curiosity doesn't get too low level. The same thing seems to happen on the network. I've been fascinated by DNS, SMTP et cetera and also IP, but then when I read TCP/IP Illustrated, for example, I don't care too much about, say, Nagle's algorithm. In other words, there's a certain depth that my curiosity doesn't seem to care so much about. Nevertheless, I would certainly enjoy studying anything at all if there's a certain context to do it. It's too not clear what the context is for each subject. I've ignored hardware for most of my life and focused on understanding how to use a system like a UNIX system. Now I think I ignored hardware too much. Lately, I even started taking notes on hardware. (It's incredible how much acronyms you guys use, each one abstracting some concept or some mechanism.) > While understanding some bits of DOS, the BIOS, and the context > around the late 70s/early 80s PC/home computer indistru is > essential for the last, for first two, there are other, better > ways to understand the machine than studying DOS and the BIOS. > And in particular, modern systems, even those built around x86 > CPUs, bear little resemblence to the original IBM PC. > > Personally, I think one is better off coming at things from a > fresher, more modern perspective, unencumbered by the follies of > the past, as opposed to looking at things through the lens of > 1979 Boca Raton. To understand hardware at the most basic > level, one would be better off looking at something like the > Arduino platform, which is almost stupidly simple, but by > design, very approachable. To understand architecture at a more > rational level, look at something like RISC-V; x86, and x86_64, > carries too much baggage from the past that obfuscates > understanding. To understand OS design, or even firmware, there > are better examples out there. I'd look at something like MIT's > materials for their OS course, in particular xv6. > > The negative case study aside, or spelunking into the history of > the PC platform, I can't think of a good reason to study DOS. > Historically important, yes; but otherwise an exemplar of how > over-compensating for technical constraints can lead to bad > technology. Nice! I happen to agree. I did think at first that x86 should be the choice and even started reading Randall Hyde while I still used Windows daily---not anymore. But I did come to the conclusion that it's too complicated and something prettier should take its place. Recently I was reading about the 6502, but lately also concluded that a RISC-V system could be the most educational to me. Nevertheless, at least so far this is not my main focus. It's like I'm taking the topic like a university course that's not main my area of study. I'm interested in it, but I have other duties to care for as well. Some time ago, I gave the xv6 book first chapters a read and it turns out they now do it on RISC-V, which reinforces the choice of architecture. I liked what they were doing. I signed myself up to be reminded to buy https://arace.tech/products/milk-v-jupiter-spacemit-m1-k1-octa-core-rva22-rvv1-0-risc-v-soc-2tops-miniitx when it'd be available in stock again. It did and I got the mail. But then I asked myself why did I do it---I have no use for a new computer; I have no project. I am not really a hardware person. But there's no question I like to know what you guys are talking about, say. It's hard for me to ignore things that are quite relevant to my interests---whatever they might really be, they're definitely computer oriented. And let me stress that I think history is definitely important to me because it seems to be a big part of what I consider understanding. I seem unable to feel that I understand something unless I understand the historical evolution of how the thing came about. But I am not a historian for sure; after I get the overall description of the facts on the time line, I usually move on. For instance, now that I understand UNIX somewhat, I try to understand what came before it---say MULTICS, ITS, TOPS-20, TENEX are names that I believe were systems that started before UNIX. But surely I don't really want to write programs for MULTICS, say, even though it would be a lot of fun for me to somehow emulate it and write notes on how it all works, say. I would never feel I understand a system unless I put my hands on it. (That's why I made the DOS comment about helping me put my hands on a computer architecture [that it runs on].) Here's an example. Being very fond of UNIX, I became interested in Plan 9---at least to see what it's about. At some point I found a book on Plan 9 that's authored by Francisco Ballesteros. I believe it's never been published, but it's available as a PDF on his homepage. Oh, here it is: Introduction to Operating System Abstractions Using Plan 9 From Bell Labs Francisco J. Ballesteros https://doc.cat-v.org/plan_9/9.intro.pdf I read the book. I wrote programs. I did some exercises. It gave me a feeling that I have an introduction to Plan 9. Would I like to go back to it? I would love to, but then there's a lot of other fun stuff. Lately, I've been working on an idea in Common Lisp. I have a lot of fun writing Lisp. My first exposure to Lisp was Racket, which I now consider a big mistake. I am so much more compatible to Common Lisp than Racket. (Macro writing is so much simpler in Common Lisp than in Racket, for example. And although I've bought in to some of the Racket elegance, I decided to just simplify my life in the end.) It took me many years to realize that, but I finally did. On my first weekend with Common Lisp I noticed I never had more fun with a programming language---perhaps when I studied C while writing an IRC robot without using the standard io libraries. If I were to understand enough about RISC-V, say, to the point of being able to read and make small changes to a certain toy operating system or something like that, I would be very pleased to, say, give a lecture to a computer user's group on how things work---what a computer is, how it works, what the function of an operating system is. Of course I could do a presentation on the topic without knowing how these things really work, but that's not me. I like to say that 1 + 1 = 2 and then define the successor function, define addition, define some of the numerals and show Peano meant with ``1 + 1 = 2''. In fact, one the chief things I love about computers is that we can---without having access to a particle accelerator, if you know what I mean---show what everything in it is about. It's accessible. (As math is.) But I wouldn't major in electrical engineering (at first), you see? I wouldn't get as low as electricity---it's a complete change of subject. It turns out I majored in mathematics because back then I thought it was smarter to follow the ideas and not quite the hardware. The hardware was too fast-changing, so I thought it was a lose to study it seriously. Now I think that was a mistake. (It doesn't *significantly* change.) I still think it was right to spend the years on math, but the mistake was in ignoring hardware. I ended up falling in love with mathematics and went as deep into it as I could, but because computers had always been my passion, I ended up coming back to them later and I can't see much use for all the math I studied, even though it still seems pretty useful indirectly---so no great regrets. (Math has been my best training in reading. After I graduated, I thought I could read anything---clearly an exaggeration, but I'm sure you get what I mean.) I feel pretty happy and lucky that I enjoy with so many things. It doesn't help me to became an expert in anything, but I am not trying to win any prize anyway. I'm not competitive; rather, I'm cooperative.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-10 18:29 +0000 |
| Subject | Studying the system (was Re: z/PDOS-generic) |
| Message-ID | <vqnb1p$p75$1@reader1.panix.com> |
| In reply to | #18766 |
In article <874j00yfpr.fsf@example.com>, Salvador Mirzo <smirzo@example.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <87ikoh13fx.fsf@example.com>, >> Salvador Mirzo <smirzo@example.com> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: > >[...] > >>>It also seems very useful precisely to expose a programmer to the entire >>>machine. >> >> But this I'd push back on, at least until I understood the goal >> a bit better. Is the intent to understand how systems work at a >> low level? To understand systems architectural more generally? >> Or as a, "how did we get here?" exercise in systems evolution? > >Heads up---this is a long sharing of personal interests, which might be >awfully uninteresting. >[snip] I don't have much to say in response to your message other than that I think it's perfectly fine to dabble and see where your interests take you; have at it! You are under no obligation to become an expert in all areas. Enjoy yourself. :-) Plan 9 is a fun system to work with and wrap your head around. Nemo's notes are excellent (he wrote those for his students). - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-03-11 05:38 +1100 |
| Message-ID | <vqnbjg$1g5f7$1@dont-email.me> |
| In reply to | #18766 |
"Salvador Mirzo" <smirzo@example.com> wrote in message news:874j00yfpr.fsf@example.com... > cross@spitfire.i.gajendra.net (Dan Cross) writes: > > If I were to understand enough about RISC-V, say, to the point of being > able to read and make small changes to a certain toy operating system or > something like that, I would be very pleased to, say, give a lecture to > a computer user's group on how things work---what a computer is, how it > works, what the function of an operating system is. That looks like a semi-concrete/coherent goal to me. > I'm not competitive; rather, I'm cooperative. This too. First of all - you're going to hit time constraints. So while a fantastic multiprocessing OS and GUI would be nice, it's not something that Tim Paterson came up with in the first version of QDOS. Even if he had less resource constraints. And you have already answered why you don't just stick Linux on RISC-V and call it a day - it's not what others call a "toy" OS. Note that MSDOS was used for a very long time in business and I never heard anyone call it a toy at the time. And use what instead? The Amiga? Macintosh? You're after something simple. And ask yourself what the simplest OS that could theoretically be written is. And you're basically back to MSDOS or something similar. And that's exactly what I did - write something similar to MSDOS. I challenge you to find something in PDOS that is "excess baggage that could be removed to simplify things for new starters". However, I did indeed simplify PDOS by way of redesign - by creating PDOS-generic. So I go back to a previous question. Do you accept the concept of a BIOS - or perhaps a BIOS-like layer - or UEFI? If so, if you provide a BIOS for RISC-V (or use UEFI), then PDOS-generic (the OS) will run under that already. You just need to compile it. Other than you will need to implement setjmp/longjmp (assembler) too. And one thing that isn't in PDOS-generic that I intend to add, is to replace functions like syscall PosOpenFile with a syscall fopen. But even that is internal to the OS. Because apps don't need syscalls at all. Inspired by the Amiga, you can simply call into callback functions. DLLs on Windows are similar. Those things may or may not devolve into syscalls - it is hidden from the user (which I consider to be a good thing). And you don't specifically need to buy a RISC-V machine. You can write an emulator. The mainframe emulator I wrote is 3000 lines long - all that was needed to get gcc 3.2.3 to recompile itself. Alternatively you could focus on the BIOS (or pseudo-bios) portion of RISC-V support. Or use Linux as a glorified pseudo-bios. That's how PdAndro for Android phones works. Basically, for simplicity, separate out a BIOS (or similar) from the (simple) OS proper, and more options open up. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-10 19:07 +0000 |
| Message-ID | <CLGzP.935496$t84d.363634@fx11.iad> |
| In reply to | #18769 |
"Paul Edwards" <mutazilah@gmail.com> writes: >"Salvador Mirzo" <smirzo@example.com> wrote in message >news:874j00yfpr.fsf@example.com... > >Note that MSDOS was used for a very long time in business Not really. Most business software ran on mainframes and minicomputers in the MSDOS era. And once NT arrived, DOS was done. There was very little _real_ business software written for MSDOS. Spreadsheets and word processing are a very small portion of business computing. Material planning, resource planning, human resources, enterprise payroll applications, etc were not really available for MSDOS at any scale. >and I never heard anyone call it a toy at the time. Then you weren't listening.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-10 19:09 +0000 |
| Message-ID | <vqndd1$6tp$1@reader1.panix.com> |
| In reply to | #18771 |
In article <CLGzP.935496$t84d.363634@fx11.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >"Paul Edwards" <mutazilah@gmail.com> writes: >>"Salvador Mirzo" <smirzo@example.com> wrote in message >>news:874j00yfpr.fsf@example.com... >>Note that MSDOS was used for a very long time in business > >Not really. Most business software ran on mainframes >and minicomputers in the MSDOS era. And once NT arrived, DOS was done. > >There was very little _real_ business software written for >MSDOS. > >Spreadsheets and word processing are a very small portion of >business computing. Material planning, resource planning, >human resources, enterprise payroll applications, etc >were not really available for MSDOS at any scale. Hear, hear. >>and I never heard anyone call it a toy at the time. > >Then you weren't listening. He's still not. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-03-10 13:00 -0700 |
| Message-ID | <20250310130006.00000497@gmail.com> |
| In reply to | #18771 |
On Mon, 10 Mar 2025 19:07:14 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Not really. Most business software ran on mainframes > and minicomputers in the MSDOS era. And once NT arrived, DOS was > done. > > There was very little _real_ business software written for > MSDOS. > > Spreadsheets and word processing are a very small portion of > business computing. Material planning, resource planning, > human resources, enterprise payroll applications, etc > were not really available for MSDOS at any scale. This is a nicely self-illustrative post, in that you start out with an incendiary but extremely blinkered (if not flatly untrue) statement and then spend the remainder of it relocating the goalposts to align with where you kicked the ball. *Plenty* of business software ran on MS-DOS, same as other single-tasking, unprotected microcomputer OSes that card- carrying partisans of larger systems like to count as "not a *real* OS" Because Reasons, and it's only by redefining "real business" to mean "large (multi)national corporations" and "business software" to mean "end-to-end computerized management of the entire business enterprise" that you can even move your argument out of the realm of "demonstrably false" and into "arguable, sort of, if you can get people to accept your definitions exclusively." C-, see me after class.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-10 20:20 +0000 |
| Message-ID | <vqnhhi$atq$1@reader1.panix.com> |
| In reply to | #18773 |
In article <20250310130006.00000497@gmail.com>, John Ames <commodorejohn@gmail.com> wrote: >On Mon, 10 Mar 2025 19:07:14 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Not really. Most business software ran on mainframes >> and minicomputers in the MSDOS era. And once NT arrived, DOS was >> done. >> >> There was very little _real_ business software written for >> MSDOS. >> >> Spreadsheets and word processing are a very small portion of >> business computing. Material planning, resource planning, >> human resources, enterprise payroll applications, etc >> were not really available for MSDOS at any scale. > >This is a nicely self-illustrative post, in that you start out with an >incendiary but extremely blinkered (if not flatly untrue) statement and >then spend the remainder of it relocating the goalposts to align with >where you kicked the ball. *Plenty* of business software ran on MS-DOS, >same as other single-tasking, unprotected microcomputer OSes that card- >carrying partisans of larger systems like to count as "not a *real* OS" >Because Reasons, and it's only by redefining "real business" to mean >"large (multi)national corporations" and "business software" to mean >"end-to-end computerized management of the entire business enterprise" >that you can even move your argument out of the realm of "demonstrably >false" and into "arguable, sort of, if you can get people to accept >your definitions exclusively." > >C-, see me after class. I don't know much about "business software", so I can't really comment on that, except to say that I imagine a lot of small and perhaps even medium-sized businesses got a lot out of PCs and DOS programs or whatnot. Maybe individuals or small teams in bigger organizations, too. I can also imagine that they would hit a scaling limit pretty quickly, at which point they would want to step up to something more capable. But I do know a lot about operating systems, and the objections to categorizing things like MS-DOS as "a *real* OS" are not mere handwaving that boils down to "Because Reasons"; there are actual definitions in use across the field one can look to, and MS-DOS et al simply do not meet them. It's great that control software in the early PC era let people do useful work with those machines; that doesn't mean that software was good or fit reasonable definitions of what an "Operating System" is. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-03-11 07:59 +1100 |
| Message-ID | <vqnjr6$1i00t$1@dont-email.me> |
| In reply to | #18774 |
"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message news:vqnhhi$atq$1@reader1.panix.com... > In article <20250310130006.00000497@gmail.com>, > John Ames <commodorejohn@gmail.com> wrote: > >On Mon, 10 Mar 2025 19:07:14 GMT > >scott@slp53.sl.home (Scott Lurndal) wrote: > > > >> Not really. Most business software ran on mainframes > >> and minicomputers in the MSDOS era. And once NT arrived, DOS was > >> done. > >> > >> There was very little _real_ business software written for > >> MSDOS. > >> > >> Spreadsheets and word processing are a very small portion of > >> business computing. Material planning, resource planning, > >> human resources, enterprise payroll applications, etc > >> were not really available for MSDOS at any scale. > > > >This is a nicely self-illustrative post, in that you start out with an > >incendiary but extremely blinkered (if not flatly untrue) statement and > >then spend the remainder of it relocating the goalposts to align with > >where you kicked the ball. *Plenty* of business software ran on MS-DOS, > >same as other single-tasking, unprotected microcomputer OSes that card- > >carrying partisans of larger systems like to count as "not a *real* OS" > >Because Reasons, and it's only by redefining "real business" to mean > >"large (multi)national corporations" and "business software" to mean > >"end-to-end computerized management of the entire business enterprise" > >that you can even move your argument out of the realm of "demonstrably > >false" and into "arguable, sort of, if you can get people to accept > >your definitions exclusively." > > > >C-, see me after class. > > I don't know much about "business software", so I can't really > comment on that, except to say that I imagine a lot of small and > perhaps even medium-sized businesses got a lot out of PCs and > DOS programs or whatnot. Maybe individuals or small teams in > bigger organizations, too. I can also imagine that they would > hit a scaling limit pretty quickly, at which point they would > want to step up to something more capable. > > But I do know a lot about operating systems, and the objections > to categorizing things like MS-DOS as "a *real* OS" are not mere > handwaving that boils down to "Because Reasons"; there are > actual definitions in use across the field one can look to, and > MS-DOS et al simply do not meet them. It's great that control > software in the early PC era let people do useful work with > those machines; that doesn't mean that software was good or fit > reasonable definitions of what an "Operating System" is. > > - Dan C. > It is you that doesn't have a "reasonable definition" of "operating system". At the time of MSDOS, I never saw one columnist or any individual who ever said that MSDOS was a misnomer, since it isn't technically an OS. Nor Tim Patterson called out for putting "OS" in "QDOS" because "it ain't an OS". But either way, it isn't a very useful semantic debate. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-03-10 15:11 -0700 |
| Message-ID | <20250310151114.000023e9@gmail.com> |
| In reply to | #18774 |
On Mon, 10 Mar 2025 20:20:02 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > But I do know a lot about operating systems, and the objections > to categorizing things like MS-DOS as "a *real* OS" are not mere > handwaving that boils down to "Because Reasons"; there are > actual definitions in use across the field one can look to, and > MS-DOS et al simply do not meet them. It's great that control > software in the early PC era let people do useful work with > those machines; that doesn't mean that software was good or fit > reasonable definitions of what an "Operating System" is. So let's dig into that a bit. Merriam-Webster defines an "operating system" thusly: > software that controls the operation of a computer and directs the > processing of programs (as by assigning storage space in memory and > controlling input and output functions) Wikipedia, being edited by Wikipedians, is a little more weird and obtuse, but more or less in accord: > Software that is designed for controlling the allocation and the use > of various hardware resources to tasks and remote terminals. 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. In a single-tasking, single-user environment any operation the user invokes can be Considered Legitimate, and this loose approach to protection makes it possible for third-party or user-written software to hook into interrupts/API calls and extend the system easily (although DOS users generally made less use of this than classic MacOS users did.) It also manages memory allocation (enabling applications, drivers, and TSRs to co-exist safely, provided they behave themselves) and handles input and output to/from screen/keyboard, disk, and parallel and serial ports. Again, it does not *prevent* programs from taking control of these things themselves, but that's a trade-off - yes, you lose some security,* assuming you even care about that, but you gain flexibility. (Supporting new hardware is generally as simple as writing a program to frob the appropriate ports, unless the OS needs to be able to treat it as a standard storage/communications channel. Even then, hooking into the necessary interrupts is fairly straightforward.) * (And it's worth noting that, in the original PC architecture pre-286, it's functionally impossible to do protection anyway. There's not a damn thing *any* OS running on an 8086 can do to prevent an errant program from scribbling over the OS/another process or frobbing an I/O port something else is trying to manage.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-10 23:11 +0000 |
| Message-ID | <vqnrjl$4a9$1@reader1.panix.com> |
| In reply to | #18779 |
In article <20250310151114.000023e9@gmail.com>, John Ames <commodorejohn@gmail.com> wrote: >On Mon, 10 Mar 2025 20:20:02 -0000 (UTC) >cross@spitfire.i.gajendra.net (Dan Cross) wrote: > >> But I do know a lot about operating systems, and the objections >> to categorizing things like MS-DOS as "a *real* OS" are not mere >> handwaving that boils down to "Because Reasons"; there are >> actual definitions in use across the field one can look to, and >> MS-DOS et al simply do not meet them. It's great that control >> software in the early PC era let people do useful work with >> those machines; that doesn't mean that software was good or fit >> reasonable definitions of what an "Operating System" is. > >So let's dig into that a bit. Merriam-Webster defines an "operating >system" thusly: > >> software that controls the operation of a computer and directs the >> processing of programs (as by assigning storage space in memory and >> controlling input and output functions) Msrs. Merriam and Webster were not, to my knowledge, computer scientists. >Wikipedia, being edited by Wikipedians, is a little more weird and >obtuse, but more or less in accord: > >> Software that is designed for controlling the allocation and the use >> of various hardware resources to tasks and remote terminals. Indeed obtuse. What about a system that does not use "remote terminals"? 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) I further posted how I feel that MS-DOS dos not meet these criteria, and why. So arguing about a definiton from a mass-market English langauge dictionary and/or wikipedia is not, frankly, very compelling in comparison. >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? 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"? I don't think anyone working on it thought of it that way. >In a single-tasking, single-user environment any operation the >user invokes can be Considered Legitimate, and this loose approach to >protection makes it possible for third-party or user-written software to >hook into interrupts/API calls and extend the system easily (although >DOS users generally made less use of this than classic MacOS users did.) While an operation a *user* invokes, such as running a command or invoking a program, can be "Considered Legitimate" in that context, it does not follow every operation performed by a program is legitimate. Programs have bugs; those bugs can corrupt the state of the system; at best this may simply crash the system. At worst it can lead to data corruption or loss. DOS can't protect against that. So it fails criteria (3) of Roscoe's definition. >It also manages memory allocation (enabling applications, drivers, and >TSRs to co-exist safely, provided they behave themselves) and handles Actually, it did not allow TSRs to "co-exist" safely, because the set of things required to do so goes far beyond mere memory allocation. Since you brought up Wikipedia, the article on TSRs that Scott linked to earlier went into this in detail, and is well worth reading. >input and output to/from screen/keyboard, disk, and parallel and serial >ports. Again, it does not *prevent* programs from taking control of >these things themselves, but that's a trade-off - yes, you lose some >security,* assuming you even care about that, but you gain flexibility. >(Supporting new hardware is generally as simple as writing a program to >frob the appropriate ports, unless the OS needs to be able to treat it >as a standard storage/communications channel. Even then, hooking into >the necessary interrupts is fairly straightforward.) > >* (And it's worth noting that, in the original PC architecture pre-286, > it's functionally impossible to do protection anyway. There's not a > damn thing *any* OS running on an 8086 can do to prevent an errant > program from scribbling over the OS/another process or frobbing an > I/O port something else is trying to manage.) See above. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-03-11 10:51 +1100 |
| Message-ID | <vqntuf$1k2oj$1@dont-email.me> |
| In reply to | #18780 |
"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message news:vqnrjl$4a9$1@reader1.panix.com... > In article <20250310151114.000023e9@gmail.com>, > John Ames <commodorejohn@gmail.com> wrote: > >On Mon, 10 Mar 2025 20:20:02 -0000 (UTC) > >cross@spitfire.i.gajendra.net (Dan Cross) wrote: > > > >> But I do know a lot about operating systems, and the objections > >> to categorizing things like MS-DOS as "a *real* OS" are not mere > >> handwaving that boils down to "Because Reasons"; there are > >> actual definitions in use across the field one can look to, and > >> MS-DOS et al simply do not meet them. It's great that control > >> software in the early PC era let people do useful work with > >> those machines; that doesn't mean that software was good or fit > >> reasonable definitions of what an "Operating System" is. > > > >So let's dig into that a bit. Merriam-Webster defines an "operating > >system" thusly: > > > >> software that controls the operation of a computer and directs the > >> processing of programs (as by assigning storage space in memory and > >> controlling input and output functions) > > Msrs. Merriam and Webster were not, to my knowledge, computer > scientists. I am. And I assume Tim Patterson and Bill Gates are too. And I'm telling you that Merriam and Webster have the correct definition. Mothy - whoever he is - don't bother telling me - I don't give a shit who he is - doesn't get to unilaterally dictate the meaning of the term. > >Wikipedia, being edited by Wikipedians, is a little more weird and > >obtuse, but more or less in accord: > > > >> Software that is designed for controlling the allocation and the use > >> of various hardware resources to tasks and remote terminals. > > Indeed obtuse. What about a system that does not use "remote > terminals"? > > 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) > > I further posted how I feel that MS-DOS dos not meet these > criteria, and why. > > So arguing about a definiton from a mass-market English langauge > dictionary and/or wikipedia is not, frankly, very compelling in > comparison. Arguing Mothy the alleged computer scientiest god who dictates a very common English term - very very common - is not compelling at all. > >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. Do you think there is one single person in this OPERATING SYSTEM forum who doesn't know that MSDOS doesn't have protected memory? Drop a name. You don't have one. We don't need a peanut like you to tell us again and again that you have an operating system that has memory protection while some of us dweebs don't. Yeah - we get it. You're Dan the Man. In fact I'm thinking of writing to Merrian-Webster to put your name under the definition of "genius". > Also, a boot loader takes control of the computer, albeit > temporarily: is that also an operating system? That's a specious argument. No-one here is claiming that that is the sole definition of an operating system. We all know already. We wouldn't be in this obscure group if we didn't. What we don't agree with is that Dan the Man gets to define the English language, or who can post in this group etc etc. > DOS can't protect against that. So it fails criteria (3) of > Roscoe's definition. And you fail the first definition of "not being a moron". The first definition being "not saying moronic things". BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-03-11 08:37 -0700 |
| Message-ID | <20250311083745.000076a4@gmail.com> |
| In reply to | #18780 |
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. 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? 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? 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? > >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, 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. > 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.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-11 17:28 +0000 |
| Message-ID | <vqprsc$25q$1@reader1.panix.com> |
| In reply to | #18782 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| Date | 2025-03-12 05:40 +1100 |
| Message-ID | <vqq027$2468t$1@dont-email.me> |
| In reply to | #18784 |
"Dan Cross" <cross@spitfire.i.gajendra.net> wrote in message news:vqprsc$25q$1@reader1.panix.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? 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 > >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. No-one at all is disputing that SunOS is far more sophisticated than OpenBoot as an OS. The question is whether OpenBoot meets the definition of an OS at all. MSDOS certainly does. And the Wikipedia authors have it right. I didn't bother to check whether they consider OpenBoot to be an OS. > Now my question to you: why do you care what specific label > people apply to MS-DOS? It's more when you insist that MSDOS is not an OS, going against the common English term. Repeatedly. As if anyone in here doesn't already know that MSDOS is not as good as your favorite OS. You can come in here and use your freedom of speech to insist that a dog is a cat too. Trying to inspire an alt.os.development revolution to change the English language. Why would I care that you insist on being a jackass? Because it takes time to correct the misinformation that you are using the English language in a non-standard way, not benefitting anyone. Just the same as you lied about PDOS having other people's copyrighted code in it. Takes time to correct your lies. We get it already. You have access to what you consider to be a fantastic OS, and you want to belittle OSes that aren't as good as that, to boost your fragile ego somehow in reflective glory about being part of that bandwagon/movement. You may as well be posting "you suck - ha ha ha". In fact, that would be much better, because it doesn't require a technical correction as it is a self-evident ad hominem attack. You may have noticed that I never reply to your childish attempts to get adults to not talk to me with "don't feed the troll". If an adult is influenced by your puerile shit to not talk to me - sounds like a win/win situation. It's your lies that require effort to correct. BFN. Paul.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | alt.os.development
csiph-web