Date: Sun, 02 Feb 1997 16:00:43 -0600 (MDT)
From: Roger Ivie <IVIE AT cc DOT usu DOT edu>
Subject: [opendos] Apologies
To: OPENDOS AT MAIL DOT TACOMA DOT NET
Message-id: <01IEY1TXB3KI90TT9J@cc.usu.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

Sorry, guys, yes I've been a bit grumpy lately and looking to start a 
flameware.

However, I do believe putting direct screen writes into COMMAND.COM is not 
a good idea, primarily because of some things I have done with DOS or have 
been trying to do with DOS.

As I mentioned in my last message, I used to own a DEC Rainbow. The DEC 
Rainbow is a really nice little MS-DOS machine; it is built around the 8088 
but is _not_ PC compatible. Instead of the PC stuff, it has a fairly nice 
VT100 emulation for the console (a bit on the slow side; those of you 
complaining about how slow DOS writes are on a PC should try a Rainbow out 
for fun some time). The Rainbow also could support up to 896KB of RAM, 
something 8088 PCs could never do.

I used Turbo C 1.0 quite extensively on the DEC Rainbow. It worked well; I 
could not use the integrated development environment because that (quite 
reasonably, I suppose) depended on running on a PC (direct video writes, 
keyboard intercepts, and the whole shebang). The command line version of 
the compiler worked fine, and I was able to do some C development on the 
DEC Rainbow.

When I finally got around to purchasing Turbo C (instead of "borrowing" a 
friend's copy), Borland had moved on to version 1.5. Instant, utter 
failure.

The _command line_ version of Turbo C 1.5 was tied to the PC hardware. I 
see absolutely no valid reason for the command line version of a compiler 
to care about the hardware it is running on. To me, this was a gratuitous
violation of the rules for MS-DOS; MS-DOS is supposed to be an operating 
system for x86 computers, not an operating system for IBM clones. After 
that, more and more software was gratuitously tied to the IBM PC hardware 
until it became impossible to find anything at all that would run on the 
DEC Rainbow.

As I also mentioned earlier, I have been involved in several embedded 
systems built around some sort of embedded PC. We use the PCs because they 
are cheap and readily available, but the need for a video screen and a 
keyboard is a major annoyance; in many instances, it would really be much 
more convenient to have a serial console.

We have been purchasing off-the-shelf processors for applications, but 
sometimes the fit isn't good; embedded processors are kind of expensive and 
you quite often cannot get exactly the features you need. There are a 
number of x86 processors aimed at the embedded market; the Intel 386EX, for 
example, is a very nice processor, but I have been frustrated in most of my 
attempts to use one. The 386EX is _not_ PC compatible; nevertheless, it has 
features which would make it very useful in embedded applications. 

I really have no problems with you guys taking the sources to COMMAND.COM 
and making a replacement shell which does direct video writes. My 
difficulty is in bundling such a shell with OpenDOS in place of 
COMMAND.COM. 

Roger "kinda grumpy lately" Ivie
ivie AT cc DOT usu DOT edu

PS: You haven't seen a _really_ long boot time until you've turne on a 
VAX-11/730; imagine loading diagnostics from tape over a 19.2KBaud serial 
line...