Mail Archives: opendos/1997/02/05/21:58:09
> There has been a lot of discussion lately on the list about
> improvements in OpenDOS, and software in general breaking on
> older machines.
I apologize if I have left the impression that my primary concern is older
systems; it is not. My primary concern is embedded systsms in which PC
compatible is not needed, not desired, and expensive; yet, the most
cost-effective development system is DOS, so many systems eat the costs of
PC compatibility because the tools are affordable.
> The post I just read about Turbo C 1.5 not running on the DEC
> Rainbow (a NON-PC compatible as stated) is irrelevant. If TC 1.0
> works, then use it!
The example was intended to illustrate software that requires compatible
hardware for no good reason. Why should the command line version of Turbo C
care if it's running on a PC? It's a _compiler_ for crying out loud. I
specifically omitted the IDE from my complaint, because it makes sense for
that to be tied to specific hardware.
For what good reason should a _compiler_ be tied to a specific piece of
hardware?
> From the software development side of things, a developer wants
> to write software that works on the MOST number of machines. To
> do that, it makes sense to stick to some sort of standard.
I have no problem with that. My gripe is about tying the _operating system_
to a particular bit of hardware for no good reason.
> By sticking to standards, we help maintain an even playing field
> when developing. When new technology or hardware comes into the
> picture, new standards are needed.
By sticking to standards at an unneccesarily low level, you are also
stifling creativity. At the risk of putting you back to sleep, let me use
CP/M as an example.
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.
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.
The Televideo 802 is a fairly straightforward machine; the Z80 is in
control and can access all of the I/O ports.
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.
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.
> MSDOS
> is an x86 OS, however TC1.5 is an "IBM-PC or 100% compatible PC
> running the DOS operating system" program.
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.
> If all programs were made without using any direct hardware
> access, then all programs would be written in ANSI C and run over
> VT100 terminals and be SLOW, NON-GRAPHICAL, and BORING.
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.
> (Besides, that is what VMS is for. :o)
I'll tell the half a dozen VAXen in my basement that you care.
> The whole point of this posting is to try and make people who are
> using older equipment understand WHY new programs may NOT work on
> their computer, and WHY a lot of people WANT new features that
> might not work on older computers.
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.
The embedded market is large and thriving. I realize embedded PCs arenot as
large a market as desktop machines, but they are still an important one.
Have you any idea how many processors are in the PC sitting on your desk?
Roger Ivie
ivie AT cc DOT usu DOT edu
- Raw text -