From: "Nicholas R LeRoy" <nleroy AT norland DOT com>
Message-Id: <9705140745.ZM8286@dopey>
Date: Wed, 14 May 1997 07:45:36 -0500
In-Reply-To: dj-admin@delorie.com
        "~OD: Re: OpenDOS graphics drivers" (May 14,  1:06am)
References: <9705140606 DOT AA14584 AT norsun DOT norland DOT com>
To: opendos AT delorie DOT com
Subject: Re: OpenDOS graphics drivers
Cc: leathm AT solwarra DOT gbrmpa DOT gov DOT au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: bulk

On May 14,  1:06am, leathm AT solwarra DOT gbrmpa DOT gov DOT au (Leath Muller) wrote:

I'm *not* trying to flame or pick a fight here, but I feel compelled to
clear this up a bit...

> Even though a DOS 16bit program doesn't have scheduling to worry about,
> it still only runs at half the speed of a 32bit program; under NT and Win95
> you can also set the priority of a program to 'real-time' which pretty much
> takes over the operating system completely.

This isn't entirely true.  Technically, 386+ processors execute many
instructions *faster* in real mode than in protected mode.  They don't have
to worry about selectors and / or protections, paging, etc.  I don't have
the tech reference on the P5 or P6, but this was true at least through
the 486.

Also, 32 bit programs *do not* inherently run faster than 16 bit programs.
That is a misnomer.  If the program doesn't need to handle more than 16
bits of data at a time, then even a 64-bit (or 128 bit, etc) program won't
run a bit faster.  On the contrary, may run slightly slower because the CPU
now needs to grab 32 (or 64 or 128) bits of data when it technically only
needs 16, so you'll effectly increase the amount of memory that's required,
the size of the working set, and will have more cache misses, etc.

That being said, however...  In reality *most* software can take advantage
of the 32 bit CPU, at least in some places.  And, as Leathal mentioned,
a good scheduler will introduce very little overhead.  Bear in mind,
however, that we're talking about M$ products here.  IMHO the best thing
to ever come out of Redmon is an empty truck.  :-)

So, in summary, I'd say that reality lies somewhere between the two ideals.
In theory, one can create a strictly 16-bit program that's faster than a
32 bit.  In practice, however, the water is pretty muddy and there are a
lot of things to consider.

Personally, I think the idea of a 3D library for OD would be a huge score.
Make it an *open* standard.  Some people are trying to do something similar
for Linux, and there's debate as to what should / shouldn't be in the kernel.
Perhaps these could all work together.  :-)

-Nick

-- 
+--------------------------------------+-------------------------------------+
| /`-_     Nicholas R LeRoy            | Linux -- What *nix was meant to be. |
|{     }/  nick DOT leroy AT norland DOT com      | gcc   -- What C was meant to be.    |
| \ *  /   Norland Corp                +-------------------------------------+
| |___|    W6340 Hackbarth Rd          |  Escape the Gates of Hell with      |
|          Fort Atkinson, WI 53538     |   The choice of a GNU generation... |
+--------------------------------------+-------------------------------------+
| Hey -- These are my own ideas, not my employer's.  Don't blame them...     |
+--------------------------------------+-------------------------------------+