delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/02/10/08:06:31

From: mharris AT blackwidow DOT saultc DOT on DOT ca
Date: Mon, 10 Feb 1997 07:51:16 -0500 (EST)
Reply-To: mharris AT blackwidow DOT saultc DOT on DOT ca
To: Roger Ivie <IVIE AT cc DOT usu DOT edu>
cc: OPENDOS AT mail DOT tacoma DOT net
Subject: Re: [opendos] COMMAND.COM enhancement
In-Reply-To: <01IF34DWTGTE8ZOP0K@cc.usu.edu>
Message-ID: <Pine.LNX.3.95.970210074229.285i-100000@capslock.com>
Organization: Total disorganization.
MIME-Version: 1.0
Sender: owner-opendos AT mail DOT tacoma DOT net

On Thu, 6 Feb 1997, Roger Ivie wrote:

> OK, I've been thinking about it and I finally have my objections to modifying
> COMMAND.COM so that it does direct screen writes down to a few simple
> statements. Here goes:
> 
> Why is it that when we're speaking of Linux, it's A Good Thing to have
> device independence, yet when we're speaking of DOS it's suddenly A Good Thing
> for every program to lug around half a dozen video drivers?

In any OS, it is desirable to have device independance.  That
includes Linux AND DOS.  However, I have programs for DOS, AND
for Linux that do DIRECT screen writes, and also access other
hardware *directly*.

Who said it was a good thing to have a half a dozen video drivers
for programs in DOS?  I never heard anyone say that.
 
> If you want to improve the performance of OpenDOS screen writes, put the
> improvement where it belongs: in the console device driver.

I don't want to improve the performance of OpenDOS screen writes.
I want to improve the performance of COMMAND.COM screen writes.
Since programming COMMAND.COM with a few condition tests can
easily provide direct screen writes, it is the only choice.

I'm sure that the DOS console device driver is allready written
to be quite optimized.  Regardless of how much you optimize
the console driver, it's not going to compete with direct video
access at the application level.  A program calling DOS to do
I/O with the display goes through MANY layers of code before
arriving at video memory.  This includes many interrupt calls
which include a TONNE of stack push/pop work.

You are just not getting the picture.  You just want to continue
arguing just to see your name in print.

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

DJGPP: Current version 2.01

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019