> Thanks, after using all the excellent advice so far, I am **ALMOST** back
> up and running, the environment variable problem has been worked around,
> and I have taken onboard the memory saving advice (have about 470k of
> conventional memory, which should be ample, how much did billyboy say we
> wouln't need anything more than?).
> Problem is, now the ghost process is crashing with a read error from the
> DVD, which I know don't contain any errors.   Could this be related to me
> using UIDE.SYS rather than our previous driver (oakcdrom.sys)?  Is there
> anything I should be aware of?  Or any way to help diagnose the error?
> My config and autoexec now look like:
> Config:
> FILES=20
> Autoexec:
> LH A:\RDISK.COM /S10 /:Y

I agree with Bernd Blaauw's comments today, that perhaps a "basic" UIDE
will help you resolve your "Ghost" problems.   In general, you may want
to go back to your "original" CONFIG/AUTOEXEC files, then put in all of
our "advice" one line at a time.   This may help to positively find the

I have never worked with "Ghost", but if it is an "old" DOS program, it
may be dependent on exactly WHICH areas of XMS memory are in-use and so
available for it.   There are two more UIDE switches you can "test", to
see if this is so:  /R15 and /R63.    They "reserve" 15-MB and 63-MB of
XMS memory.    This will make UIDE load itself after the first 16-MB or
64-MB of memory (the first 1+ MB is the DOS system plus its HMA space).
Certain "Sound Blaster" cards did only 24-bit DMA and so cannot use any
memory beyond 16-MB.   Certain other "game" programs were NEVER updated
to the V3.0 XMS Specification (up to 4-GB of memory) and still use only
V2.0 XMS logic (64-MB maximum).   So, UIDE's /R15 and /R63 switches are
intended to "accomodate" such ancient hardware/software!

If a line-by-line "re-update" of your CONFIG.SYS and AUTOEXEC.BAT fails
to determine the "Ghost" problem, do try UIDE with /R15 and /R63 as the
last resort.   Worth a try!

Also, I do not completely agree with Bernd about problems caused by the
use of "UMBs" (upper-memory blocks).   There are a few drivers not able
to "detect" various parts of upper-memory:  JEMM386/JEMMEX still do the
"old" Microsoft tests for compatibility (newer "odd peripherals" memory
sometimes confuses them), and a few of the newer chipsets might not-yet
be supported by UMBPCI.   But, once "detected" and put into use through
JEMM386/JEMMEX/UMBPCI, upper memory should NOT be your problem.

> I have a small update on my original email (I haven't had a chance to
> try the items below).  When I run Ghost, the CD drive is listed twice,
> once via it's drive letter and once via it's ATAPI direct access.
> Access via drive letter fails repeatably.   Access directly works.
> I don't know if that sheds any light on things.

This late E-Mail MAY be telling me there is a "driver CONFLICT" between
UIDE and whatever "Ghost" I-O logic may be present.   If so, you should
try UIDE with its /N2 switch, which asks UIDE not to run CD/DVD drives.
If this eliminates your "Ghost" problem, then (A) you need to disable
the "Ghost" I-O logic and run your CD/DVD drives only through UIDE, or
(B) vice-versa, i.e. you must load UIDE with /N2 to avoid your "Ghost"
errors.   NOT any "fun", either way, I know!   But, I have never used
"Ghost" and do not know what its writers do in running CD/DVD drives!

Best wishes,

Jack R. Ellis

Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
Freedos-user mailing list

Reply via email to