This is a multi-part message in MIME format.
--------------F882908D00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael,
--------------F882908D00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="WUSHEL.001"
Subject:
Re: Flat memory models
Date:
Tue, 18 Mar 1997 11:06:44 +0100
From:
Organization:
T&K
Newsgroups:
comp.lang.pascal.borland
References:
1 , 2 , 3
Thank you for a balanced and reasonable response to my posting. I
have snipped most of your post due to the length of this
response.
Since I mentioned Flat Real Mode, I have received many email
requests for more information. The information contained here may
help others decide what they want to do.
I should immediately say I am not a programmer.
I am an Analog and Digital engineer (US Patents 3674930, 3810234,
4533881, 4603299, 4929894, 5050169.) I am also a businessman.
ADVANTAGES OF FLAT REAL MODE
Interrupts, Bios calls, access to I/O ports are exactly the same
as in DOS programming. Because it *IS* DOS programming.
In the x86 Assembly Language FAQ - General Part 2/3, available
at:
http://www.*-*-*.com/ ~raymoon/faq/gen2.txt
"The benefits of this (Flat Real Mode) technique are many. Most
importantly, you can access extended memory without resorting to
slow BIOS calls or having to implement a complete DOS extender.
If your program uses interrupts extensively (timer interrupts for
animation or sound, for example), real mode is a better choice
because protected mode handles interrupts slower. DOS itself uses
this technique in HIMEM.SYS as a fast, practical method of
providing access to extended memory."
In SWAG: MEMORY #0099.SWG, Herman Dullink writes:
"With the new VESA VBE Core Standard 2.0, the entire video memory
of a SVGA or other video adapter that supports linear/flat
addressing can be accessed as one large chunk of memory somewhere
in the 4GB(/16MB) address space of the 386(sx):"
"Accessing video memory without the need of bankswitching really
speeds up video performance. In terms of pixels per second,
drawing lines in the 1600x1200,256 colours graphics mode is now
faster than in the 320x200, 256 colours mode."
"The only limitation of FLAT is your imagination. And you'll need
that as no high-level language DOS compiler I've seen (yet)
supports 32-bit addressing without the need of some kind of DOS-
extender. However, FLAT will link smoothly with almost any 16-bit
DOS compiler. I use Turbo Pascal 5.5 and 6.0 myself for the body
of the programs I'm writing, and use some assembly at the places
I need the 32-bit addressing. See EX2 for a very nice example."
DISADVANTAGES OF PROTECTED MODE PROGRAMMING
From Robert Collins excellent site, at:
http://www.*-*-*.com/
"From an applications' point of view, protected mode and real
mode aren't that different. Both use memory segmentation,
interrupts, and device drivers to handle the hardware. But there
are subtle differences that make porting DOS applications to
protected mode non-trivial."
From the Borland BP7 installation files:
"WINDOWS AND PROTECTED-MODE APPLICATIONS - Starting Windows in
enhanced mode from a DOS shell created by a DOS protected-mode
program (such as RTMRES.EXE or BP.EXE) is unsafe. Normally
Windows refuses to load in enhanced mode under such conditions,
but in certain situations it can hang the system. Therefore, a
DOS protected-mode program that invokes Windows should always
start Windows in Standard mode."
"386^MAX DPMI SERVER - There are known problems with pre-6.02
versions of the 386^Max DPMI server. We recommend that you obtain
and use their latest version (or use the Borland DPMI server
instead)."
"CTRL-C UNDER 386^MAX - If you are using 386^MAX 6.01-6.02 with
DPMI support, the BP critical-error handlers and Control-C
handlers will not be effective. You can work around this problem
by putting the NODPMI switch into your 386MAX.PRO file."
"CTRL-C IN OS/2 DOS BOX - If you are running under an OS/2 DOS
box, you will not be able to use Control-C in your DOS
protected-mode applications. Control-C will cause the DOS session
to crash. This is a bug in OS/2's DOS protected-mode support that
will be fixed in a future release."
"There is a known problem in OS/2 which will cause the DOS
session to crash after the second application terminates if it
uses a different loader. This will be fixed in a future release
of OS/2's DOS protected-mode support."
"Note that it is not safe to start Paradox 4.0 from a DOS
protected-mode application written in Borland Pascal with
Objects."
From the Borland DPMIUSER documentation:
"To run a DOS protected-mode application from a Windows DOS
prompt, you must first modify the DOSPRMPT.PIF file found in your
Windows directory so that the protected-mode program will be able
to use extended memory."
Duncan Murdoch maintained an excellent bug list for TP6 and BP7.
His web site is:
http://www.*-*-*.com/
The following is quoted from his bug lists:
http://www.*-*-*.com/
http://www.*-*-*.com/ #tp6bugs
"39. Coprocessor exceptions aren't handled properly in protected
mode. BP and TDX are likely to be aborted by the error. Things
are worse within Desqview, but that may be a Desqview bug.
Partially fixed in 7.01 - things are fine in DOS, they don't work
in Windows or Desqview."
"47. Contrary to the online help, Release() does not work in
protected mode. (This is documented in the Language Guide.)"
"48. On certain machines, protected mode programs (including
BP.EXE) will not read characters correctly. (E.g. repeated
cursoring will insert digits into your text.) Sometimes running
"KEYB US" before BP fixes it; there are some rumours that
Quarterdeck's QDPMI or other bad DPMI servers may be at fault;
there are other rumours that it's a bad keyboard controller chip
causing the trouble."
"52. In protected mode when using BGI, using RestoreCRTMode and
SetGraphMode can leave BGI in an unstable state, and a GP fault
may follow."
Bottom line: It is clear that dos extenders and protected mode
software are much more complex and failure-prone. Perhaps some of
these bugs are fixed - perhaps new ones have arrived. How do you
tell which computers can run your code, and which ones will
crash? What if your user loads new software that turns out to be
incompatible?
Second bottom line: It is impossible to guarantee that a user
will have all the necessary compatibility problems solved for
you. If you write protected mode software, you run a real risk of
crashing your user's system.
SPEED
I need programs that load instantly, do their work fast, and exit
so I can get on with the next item of business.
Invariably, protected-mode programs have a slight but noticeable
delay before they start doing anything. I can always tell when I
am running a protected mode program because of this delay.
Also, protected mode programs seem to lack the "snap" of real
mode programs. Protected mode software always seems a bit more
sluggish and reluctant than real mode programs.
I have a perfect example.
I just upgraded to BP7, and use the DOS command-line compiler,
BPC.EXE, exclusively. It is a protected mode program, and is the
counterpart of TPC.EXE in TP6.
It doesn't do much more than TPC.EXE - there were only a couple of
new instructions added, like "Break" and "Continue".
The oop portions might be more complicated, but I don't use oop
so I don't know what has been added. Neither compiler handles EAX
instructions.
The first thing that struck me was BPC.EXE is almost twice as
large as TPC.EXE, and needs RTM.EXE, the Borland run-time module
for protected mode, plus DPMI16BI.OVL.
So, right off the bat I have 274,504 bytes of files to load off
the hard disk. TPC.EXE is only 69,214 bytes. You can check my
math below:
BPC.EXE 125,002 bytes
RTM.EXE 85,998 bytes
DPMI16BI.OVL 63,504 bytes
Total 274,504 bytes
TPC.EXE 69,214 bytes
This might explain part of the startup delay, but it does not
explain the difference in compile time.
BPC.EXE runs at about half the speed of TPC.EXE. It is very easy
to tell - both report the compile time when they are done.
BPC.EXE does the same thing as TPC.EXE, plus it has the benefit
of more years of refining the code. And this is from a company
that used to pride itself on the speed of it's compilers!
So, if protected mode is faster, why is BPC.EXE so slow?
SECOND EXAMPLE.
We use PCAD for schematic capture and pcb layout.
PCAD Version 4.5 ran fine on a 12 MHz 286.
PCAD Version 5.0 requires a 386. There is very little difference
between 4.5 and 5.0, except 5.0 uses a DOS extender and runs in
protected mode.
PCAD Version 4.5 on a 12 MHz 286 is as fast as PCAD Version 5.0
on a 25 MHz 386.
To put it another way, when you switch to PMODE programming, you
need a CPU with twice the throughput to achieve the same speed.
Bottom line: PMODE programs run at about half the speed of the
same program running in DOS Real Mode.
Second Bottom line: "The Power of 32-Bit" is a marketing myth.
CURIOUS ANOMALY
There is a real sleeper of a DOS de{*filter*} in BP7. Borland
...