Mail Archives: opendos/1997/02/10/07:23:41
On Wed, 5 Feb 1997, Roger Ivie wrote:
> > 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.
Ok, if PC compatible is not needed, then use a portable OS that
isn't tied to the x86 IBM-PC.
> > 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.
Ask Borland. I'm sure that they didn't say, "hey, lets make this
program not run on the DEC rainbow". On the contrary. Turbo C
is an IBM PC program. Borland claims that it will run on an
IBM-PC or 100% compatible computer. The claim doesn't read that
Turbo C will run on any circuit board with an 8088 on it. That
is WHY TC cares if it is running on an IBM PC, because it was
written FOR an IBM PC. Simple. As for your wishing that TC was
made for the x86 in general and not just the IBM PC, I'm afraid
you'll have to take that up with Borland. Besides, you should be
using Micro C for embedded systems work anyways. The code it
produces is much smaller. Anyone doing embedded systems work
should know about Micro C.
Also, feel free to use FreeDOS. The FreeDOS kernel is written
with Micro C as well. This would be a fantastic solution to all
of your embedded systems work as it is all FREE.
> For what good reason should a _compiler_ be tied to a specific piece of
> hardware?
To take advantages of that hardware? Everyone is free to choose
between portability and speed and/or other OS/hardware specific
features when designing a piece of software. This doesn't
exclude compiler vendors. Just out of curiousity, does Microsoft
C, or Watcom, or Symantec or Zortech or DJGPP work on the DEC
rainbow?
Also out of curiousity, can you use MSDOS on the systems that you
are working on? What I'm asking is were you using MSDOS
previously, but now you're upgrading to using OpenDOS for
development? Or is MSDOS incompatible with the embedded systems?
> > 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.
Blame Microsoft/IBM for that. They never said that DOS was a
portable OS. Whoever told you that it was needs to be set
straight.
> > 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.
... ZZZZZ.. ZZZZZZ.. .... ....
By sticking to a VT100 terminal, I'd say is stifling creativity.
> 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.
Then why do you keep talking about CP/M?
> 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.
Hmmm. Can we say "Linux" boys and girls?
> 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.
[SNIP]
Well if CP/M is so fantastic and portable, THEN USE IT!!!!!
> 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.
Well then USE CP/M!!! You keep complaining DOS doesn't do this
and it doesn't do that, but CP/M does this, AND it does that.
So, _USE_ CP/M. What is the problem? That is like me saying
that Windows doesn't run on my 8088, but DOS does, and
complaining till DOOMSDAY that Windows should be more portable.
> > > 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.
Sure there is. Borland said "Lets design a C compiler for the
IBM PC." Then they did it. End of story.
> Similarly, there's no good reason for DIR to do direct
> screen writes.
That is a perfectly valid *opinion*. However, there *IS* a
perfectly good reason for DIR to do direct screen writes, I want
it to, so do many others.
I will configure it to do so too. If you feel that you dislike
direct screen writes, then be sure to configure it to NOT do
them. Simple.
> Do you expect ls to do direct screen writes under Linux? Why
> not? It's also a PC operating system.
ls writes to the screen amazingly fast in Linux. Although I
don't have the sources handy, I'd bet that it does use direct
screen writes.. If it doesn't, then it must go through some
blazingly fast interface to video memory. An ls under Linux goes
about 4 times faster than a DIR under DOS *WITH* direct screen
writes!!!! Don't ask me why, but it does. Must be file access
speed or something.
Oh, BTW, Linux is *NOT* *JUST* a PC OS. It is also for 68k, DEC
Alpha, Sparc, PowerPC, MIPS, ... I'm sure an ls is just as fast
on those machines under Linux as well.
Also, even if ls doesn't do direct writes, it IS POSSIBLE to
write a version of LS for Linux that DOES do direct writes so
your argument is pointless. I've written a couple programs for
Linux that do direct screen writes in text mode and they work
great. I don't much care that they don't work over a serial line
as I've written them for me and anyone I'd be giving them to uses
the console anyways and would appreciate the effort I've put into
making the video code scream. (It would take me about 6 hours to
put conditional code in to make them work over serial lines as
well).
> > 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.
A command shell as NOT an operating system. A shell is a program
just like any other on the system. Your above statement doesn't
make much sense.
> > (Besides, that is what VMS is for. :o)
>
> I'll tell the half a dozen VAXen in my basement that you care.
I don't though.
> > 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.
Apples != oranges.
I said that my point was to make people understand that newer
programs wont work on their "computers", not their microwave
ovens.
> 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.
Yes, the embedded market is large. But I am talking about MSDOS
which is an IBM-PC OS, and programs written for that architecture
and operating system. My concerns towards IBM-PC/MSDOS software
working on ANY embedded systems are about on level with my
concerns of IBM-PC/MSDOS software running on a VAX, or a VIC-20
for that matter. We're dealing with 2 different worlds.
> Have you any idea how many processors are in the PC sitting on your desk?
No, please tell me. It's an ACER 486-DX2/66.
Besides, my PC isn't on my desk. :o)
Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris
Computer Consultant | My webpage has moved and my address has changed.
My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html
mailto:mharris AT blackwidow DOT saultc DOT on DOT ca
Close windows, and OpenDOS! http://www.caldera.com/dos/dos.htm
- Raw text -