[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
XyWrite and upper memory
- Subject: XyWrite and upper memory
- From: Patricia M Godfrey pmgodfrey@xxxxxxxx
- Date: Sun, 28 Jul 2002 17:59:24 -0400
Mike said, "Evidently, at least in earlier versions, XyWrite was making
use of little nooks and crannies of memory in which one would not
normally expect to find a running application..." and I think he's right
on target. Jordan asked, "Does Xy make such direct calls [sc., to memory
apart from the OS]?" What follows is a rather detailed attempt to address
this question. The short form is that in the last days of DOS after the
release of the 386, everyone was trying to find ways to use the physical
memory above 640 K that DOS couldn't. I have circumstantial evidence that
XyWrite was among the apps that did that by "sneaking up" and using RAM
supposedly reserved for hardware or by invoking protected mode, or both.
Here follows the whole megillah (Carl, if you think this will be of
limited interest and want to cut it, go ahead; just tell anyone who's
interested to drop me a line and I'll send it off list):
1. The DOS 640 K limitation: DOS was designed to use no more than 640 K
of RAM. At the time, that seemed a huge allowance. Later versions allowed
the RAM between 640 K and 1 Mb to be used for hardware, esp. display
adaptor RAM.
2. Beginning with the 386 CPU, PC architecture allowed the use of all the
memory physically available, if the PC was running in Protected Mode.
(Strictly speaking, the 286 also had protected-mode capabilities, but it
had to reboot to get in--or possibly out, or both, I forget which--of
protected mode, and hence was called brain-damaged by the techies.) DOS,
however, was not a protected mode OS. A specification brought forth by
Lotus (makers of 1-2-3, remember them?), Intel, and Microsoft, and hence
called LIM, allowed some of that RAM to be swapped into a 64K "Window" of
DOS-accesible RAM; this kludge was called Expanded Memory. The real
Extended memory could only be used as a RAM disk or the like at first.
Eventually, Microsoft came up with utilities to load some of the OS and
device drivers in parts of the RAM between 640K and 1 Mb, called the High
Memory Area and Upper Memory Blocks (I don't quite recall the
distinction, but it isn't important here).
Meanwhile, other software developers were trying various other
workarounds. Quarterdeck had a nice memory manager that contrived to use
the beyond-640K RAM. A Canadian company called Sub Rosa had a dBase III
clone that definitely used some of the "reserved for display RAM": it
would not work with Quarterdeck's environment, and completely went
haywire when the 486 came in. Borland devised a DOS protected mode
extender model and used it for dBase 5 for DOS, which requires 8 Mb of
RAM to run, but is a DOS app. Novell bought out Digital Research's
DR-DOS, and rewrote it as Novell DOS 7; it had protected mode routines
and was the preferred OS for XyWrite 4 for DOS (TTG ran all their
machines under it). The Novell and Borland implementations of protected
mode, I should note, were incompatible with each other. When I run dBase
5 under Novell DOS, I have to run a batch file to turn off Novell's
protected mode, launch dBase, and then turn Novell protected mode back on
after dBase is finished running. Otherwise, the PC reboots continuously.
3. Evidence for XyWrite's using protected mode calls to video memory:
First, the date: XyWrite 4 was produced right at the time that all this
finagling with upper RAM was going on.
Second, VGA card problems: Three PCs ago (a 486 running Novell DOS 7),
XyWrite (DOS 4.017) kept crashing if I had more than two or three files
open. I upgraded my VGA card to take advantage of the PCI slot, and the
crashes stopped. This would seem to indicate that Xy was using some of
that unused protected mode RAM by making direct hardware calls and not
telling the OS about it. (A similar problem occurs with the 32-bit
Windows app I have to use to print the mailing labels of our local
weekly: it's a database application, therefore requires a great deal of
memory, and dates back to DOS days. Though it's supposedly been
rewritten, I suspect some old DOS direct hardware calls, because the
wretched thing runs fine on a P100 with 32 Mb of RAM that has no
problematic drivers, but crashes repeatedly on a PIII with 128 Mb, but a
couple of DOS virtual machines loaded to let us run PageMaker 5 (16-bit
Win)--or on a Pentium Pro, also with 128 Mb, for which I cannot get
better than generic chipset drivers, because Compaq intended it for a
server and never wrote Win8.x drivers for some of its components. Plug
and Play, Hah!)
Third, Microsoft compatibility issues: Has anyone ever tried installing
XyWrite 4.017 for DOS on Microsoft DOS 6.22? It aborts and crashes with a
memory error message. This again sounds like differing and incompatible
attempts to run in protected mode.
Fourth, other issues: The display problems with files with lots of
footnotes that have recently been discussed seem like further evidence
that XyW is using High RAM, protected mode, or both. I also recall that
when I ran XyW under Novell DOS, I experimented with allocating my 4 Mb
or RAM to Expanded or Extended memory, and Xy ran better with it all
Extended.
I suppose only the people who actually coded XyWrite really know the
answer to this, but the evidence, if not as convincing as the trout in
the milk, seems pretty strong to me.
Patricia