Mail Archives: opendos/1997/02/06/04:46:10
Roger Ivie writes:
> Now, I am not saying that we should all be running CP/M or that CP/M
> is the end-all be-all of operating systems. However, CP/M-land shows
> us the diversity that is possible by placing hardware independence
> where it belongs. I WOULD USE A MORE MODERN EXAMPLE, BUT THERE ISN'T
> ONE.
Are you totally sure about that? No other operating systems runs on
differing hardware?
> There is an incredible variety of CP/M machines. They range from really
> simple to complex. Yet all of them can run CP/M software. For example, I
> run THE SAME BINARY of KERMIT on my DECmate II and on my Televideo 802;
> these machines are about as far apart as you can get.
Same binary? Then, either all CP/M programs run in a virtual machine
provided by the operating system or both machines use the same
processor at a guess (god, it's *years* since I used CP/M, on an old
RML380Z).
> The Televideo 802 is a fairly straightforward machine; the Z80 is in
> control and can access all of the I/O ports.
Ahh, ok, Z80.
> The DECmate II is run by a PDP-8. The Z80 can't even get to I/O. Yet, the
> same program can use CP/M to do file transfers on both machines.
Ahh, Z80 again?
You have a good point, but the "same binary" thing isn't part of it IMHO.
> In x86-land, if I'm going to use a DOS program to do file transfers,
> I'd dang well better have a 16450 or compatible UART. Suppose I need
> to occasionally do HDLC? Fine, but you also have to carry around the
> 16450 if you want to speak to modems. In CP/M-land, it's possible to
> use, say, an SIO as a UART most of the time and HDLC occasionally.
I'm sure that few people would disagree that the PC and DOS are a
pretty broken combination, but when put together do a good job of
doing what we expect them to do.
> But there's no good reason for TC1.5's command line compiler to be
> tied to the PC architecture. Similarly, there's no good reason for
> DIR to do direct screen writes. Do you expect ls to do direct screen
> writes under Linux? Why not? It's also a PC operating system.
You are totally missing the point here. When Ian suggest getting
COMMAND.COM to use direct screen writes, he ment it as an option, not
as a move, period. Where is the harm in that?
> I'm not complaining about "all programs". I'm complaining about the
> operating systems. If you want fast DIRs, by all means write an
> alternate shell that does fast DIRs. Just don't put it in the
> operating systems.
I seem to remember the discussion was about getting the shell to do
optional screen writes, not about the OS doing direct screen writes.
> > (Besides, that is what VMS is for. :o)
>
> I'll tell the half a dozen VAXen in my basement that you care.
<envy> I never much liked VMS, but I love collecting old machines. :-)
At the moment I've only got a small number of micro's (even got an
as-new, boxed, hardly used ZX80 <g>), one day I want to get some sort
of VAXen.
> Again, my primary concern is not old machines, but embedded ones. If
> I'm building a special-purpose widget, I shouldn't need to make it
> 100% PC compatible just because the widget happens to need an
> operating system.
Why should you need to? All of what has been spoken about here works
on the idea that OD will work as it does now, but with optional
enhancements.
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard | ng2html - The NG to HTML converter.
Also available in the UK: | eg - Norton Guide reader for OS/2.
http://www.hagbard.demon.co.uk | dgscan - DGROUP scanner for Clipper.
- Raw text -