Comments: Authenticated sender is <david AT diablo DOT eimages DOT co DOT uk>
From: "David Cantrell" <david AT diablo DOT eimages DOT co DOT uk>
To: opendos AT mail DOT tacoma DOT net
Date: Mon, 3 Feb 1997 14:22:42 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [opendos] speeding up command.com
Reply-to: david AT diablo DOT eimages DOT co DOT uk
Message-ID: <1357142637-14672907@diablo.eimages.co.uk>
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

bartosz AT bielbit DOT bielsko DOT pl wrote:

> chambersb AT juno DOT com
>
> > Question:
> >
> > OpenDOS is for x86 processors, right?
> > You're not going to break things by inserting a little ASM code - >
>
>   Maybe we can use some 386, 486, 586 or MMX specyfic opcodes inside
> Open DOS. Executables will be smaller and faster but all machines
> with less than (386...MMX) could be dropped into trash.

There would be no benefit in using 386 (or higher) instructions.  All 
existing DOS apps expect to use a 16-bit operating system, so even if 
the app is 32-bit internally (such as those compiled with DJGPP), it 
still has to go 16-bit for talking to device drivers - such as sound 
cards, CDs, hard disks, and for allocating memory.  If you rewrote 
these as 32-bit code, you would still have to provide 16-bit 
emulations of them, just like Win95 does.  And you would get the same 
code-bloat and horrendous number of bugs as Win95.

Anyway, the performance advantage would not be noticeable.  You spend 
very little productive time at the command prompt, so to gain a 
performance increase from going 32-bit, you would either have to 
rewrite all your APPS to be 32-bit, or be the demon-batch-coder-
from-hell and do all your work in COMMAND.COM.

-- David Cantrell, http://www.eimages.co.uk/users/davidc/

Power is both corrupting and dangerous when unchallenged and
concentrated in the hands of the majority.  Voices of tolerance
and compassion are easily drowned.
      -- Akbar S. Ahmed