> 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:
> SHELL=A:\COMMAND.COM A:\ /E:512 /P
> DEVLOAD /H A:\UIDE.SYS /S511 /D:CDROM1 /H
> LH A:\RDISK.COM /S10 /:Y
> A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z
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!
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