strange that you only 470k free...
> 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)?
Oakcdrom sounds very outdated and might also use more RAM than UIDE...
Just for comparison, you could also try the old xcdrom and gcdrom, but
UIDE is almost always better. I also think that you only want to use
the CD-R or CD-RW from which you booted. The it is usually easier and
more reliable to use the ElTorito.sys driver, which works together with
your BIOS CD boot logics and is also a very small driver :-) How much
data do you have on the CD that you want to access, in megabytes?
Unless you really need EMS or UMB memory, HIMEMX or XMGR could be
a more stable and sufficiently small choice. With EMM drivers, you
have to be careful to not use UMB areas that conflict with other
drivers, hardware or BIOS functions, as modern systems are not so
good in always properly reporting such areas to DOS. I would not
recommend trying to use b000-b7ff as extra UMB area, by the way.
The NOEMS option of EMM drivers has a misleading name: It disables
the EMS 3 page frame, possibly freeing 64kB of UMB, but EMS itself
stays active for EMS 4 compatible apps which need no page frames.
My personal experience is that very few apps do need EMS at all...
> SHELL=A:\COMMAND.COM A:\ /E:512 /P
Without UMB driver, you would only use DOS=HIGH, but that already
saves a lot of low DOS RAM, because kernel and command.com can go
into HMA and XMS respectively with much of their data.
You might also try STACKS=0,0 although that could reduce
stability on some systems.
> DEVLOAD /H A:\UIDE.SYS /S511 /D:CDROM1 /H
Because UIDE is a device driver, you better load it in
config.sys already. Unless you are sure that your UMBs
are stable, better do not load it high into UMBs here.
You can use DEVICE there (or DEVICEHIGH for UMB, which
might be less stable depending on hard- and firmware).
> LH A:\RDISK.COM /S10 /:Y
You could also try SHSURDRV instead, of course.
> A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z
Of course /qq also makes debugging harder. I would
suggest to use the /C option to make SHSUCDX load in
the area that you select (low or, with LH, high) as
opposed to picking an area itself. You could try the
syntax /D:CDROM1,Z,,1 to say that only 1 unit is to
be used from the selected CDROM1 driver as you have
no drive letters left after Z: anyway. May save RAM.
Similarily, I would recommend a /D:0 option to not
reserve the default 8 extra drive tables in memory.
You can use option /V to see memory stats at init.
It is not really clear to me why you only have 470k
free with so few drivers loaded, can you do e.g.
MEM /C /D > somelog.txt and paste the output from
that log on this list?
Apart from findtdsk, there are also other tools to
find disks by volume label. For example I return a
drive letter by errorlevel in one of them, so you
do not need environment variables.
Which other variables does your app gather and put
into the environment or into a batch file that is
later used to update the environment? Can you give
more details about in which way this goes wrong in
FreeCOM 0.83 and 0.84 while okay in classic 0.82?
Thanks! Regards, Eric
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