Looking for help on RAMDRIVE.SYS (DOS 7/Win98)
Kenny McCormack
device=C:\windows\himem.sys
device=C:\windows\ramdrive.sys 20000 /E
in CONFIG.SYS
Yes, I need a 20 meg ram disk. It works, except that long filenames don't
work. It is related to size - if I make the RAM disk smaller (say, 2M),
then the long filenames work. Yes, I am aware that the LFNs don't work
until the GUI is up - I am booting the GUI and, as I say, if I make the RD
small, the LFNs work.
Some questions:
1) Is there any workaround? (I tried a lot of things, but no avail)
2) Documentation for RAMDRIVE is hard to find these days - what
I have documents 3 parameters: DiskSize SectorSize NumEntries
(as well as /E for Extended and /A for Expanded memory).
Are there any other params? One of the problems I am having is
that space is being wasted because of the clustersize; I would
like to reduce that. I'm not sure if SectorSize is exactly what
I want - to affect the number of "Allocation Units".
3) Are there any other ram disk programs out there that support
long filenames on very large ram disks?
P.S. Yes, I'm aware of the "You shouldn't use a RAM disk; Windows can
manage the memory better than you can, etc, etc" arguments. I'm not sure
I believe them, though...
Ted Davis
First, the size and nature of the ramdrive don't enter into long
filename handling: the OS does that on FAT drives by using extra
directory entries and marking them as also being volume labels. Since
there are a fixed number of root directory entries, it is best to
avoid long names in a drive root - use a directory.
RAMDRIVE, being a Microsoft offering is pretty near worst in class - I
have had good results with XMSDSK loaded in AUTOEXEC.BAT.
There are cases where a ramdrive is useful under Windows, but these
are pretty specialized. You definitely don't want to put the TEMP
directory there (unless you have a way to make sure neither Windows
nor any of its applications that can recover from a crash cannot
crash, and that no application that depends on temp files for
installation will ever be installed); you don't want a ramdrive if
Windows actually uses virtual memory - it would just make that
situation worse. Some disk intensive tasks can benefit.
--
T.E.D. (tda...@gearbox.maem.umr.edu)
Kenny McCormack
Thank you for your reply. However, the LFN issue is real as I've described
it. I am familiar with the implementation of LFNs via "unused" directory
entries and of the limitations of the number of root directory entries on
a RAM disk unless you take steps to increase them.
However, the fact remains, that if the RD size is large (I have not done
a lot of testing to determine exactly where, but I know it is between 2 and
15 megs), then the following commands immediately after booting (the RD is
empty at this time):
D:
cd \
md biglongname
creates (as the only file in the root of the RD) a directory named BIGLONGN
>RAMDRIVE, being a Microsoft offering is pretty near worst in class - I
Amen to that.
>have had good results with XMSDSK loaded in AUTOEXEC.BAT.
I used to use XMSDISK back in pre-LFN days. Does it still work with
Windows and LFNs?
>There are cases where a ramdrive is useful under Windows, but these
>are pretty specialized. You definitely don't want to put the TEMP
>directory there (unless you have a way to make sure neither Windows
>nor any of its applications that can recover from a crash cannot
>crash, and that no application that depends on temp files for
>installation will ever be installed); you don't want a ramdrive if
>Windows actually uses virtual memory - it would just make that
>situation worse. Some disk intensive tasks can benefit.
Right. I am using it for a disk intensive (zillions of little files)
application.
Charles Dye
McCormack) wrote:
>I am setting up a RAMDRIVE, using:
> device=C:\windows\himem.sys
> device=C:\windows\ramdrive.sys 20000 /E
>in CONFIG.SYS
>
>Yes, I need a 20 meg ram disk. It works, except that long filenames don't
>work. It is related to size - if I make the RAM disk smaller (say, 2M),
>then the long filenames work. Yes, I am aware that the LFNs don't work
>until the GUI is up - I am booting the GUI and, as I say, if I make the RD
>small, the LFNs work.
This is a known bug in Windows 98. It was discussed some time last year
in, IIRC, comp.os.msdos.4dos. It affects other RAMdrive programs like
Franck Uberto's XMSDSK too. One workaround is to reduce the size of the
RAMdrive until the problem goes away. Another is to allocate memory
from the top. XMSDSK has a /T option to do this; RAMDRIVE.SYS has no
corresponding capability. Microsoft is aware of the issue, and
apparently not interested in fixing it.
Using XMSDSK:
xmsdsk 20000 r: /t /y
>P.S. Yes, I'm aware of the "You shouldn't use a RAM disk; Windows can
>manage the memory better than you can, etc, etc" arguments. I'm not sure
>I believe them, though...
This is probably true for the majority of Windows users. Different
people have different systems and use them in different ways, though;
you may very well get a benefit from a RAMdrive. Be aware that many
Windows-based installers expect the %TEMP% directory to survive a
reboot, so you may need to point it at a hard drive before installing
applications.
--
Charles Dye ras...@highfiber.com
Kenny McCormack
Charles Dye <ras...@highfiber.com> wrote:
>On Fri, 21 Jan 2005 23:40:16 GMT, gaz...@yin.interaccess.com (Kenny
>McCormack) wrote:
>
>>I am setting up a RAMDRIVE, using:
>> device=C:\windows\himem.sys
>> device=C:\windows\ramdrive.sys 20000 /E
>>in CONFIG.SYS
>>
>>Yes, I need a 20 meg ram disk. It works, except that long filenames don't
>>work. It is related to size - if I make the RAM disk smaller (say, 2M),
>>then the long filenames work. Yes, I am aware that the LFNs don't work
>>until the GUI is up - I am booting the GUI and, as I say, if I make the RD
>>small, the LFNs work.
>
>This is a known bug in Windows 98. It was discussed some time last year
>in, IIRC, comp.os.msdos.4dos. It affects other RAMdrive programs like
>Franck Uberto's XMSDSK too. One workaround is to reduce the size of the
>RAMdrive until the problem goes away. Another is to allocate memory
>from the top. XMSDSK has a /T option to do this; RAMDRIVE.SYS has no
>corresponding capability. Microsoft is aware of the issue, and
>apparently not interested in fixing it.
Considering that they keep saying they are dropping support of 98 (have
they actually done so, yet - I don't know - I don't keep on the latest MS
poop), this is not that surprising.
>Using XMSDSK:
>
> xmsdsk 20000 r: /t /y
Can you say a bit about why "allocating from the top" fixes the problem?
Also, where do you get XMSDSK?
>>P.S. Yes, I'm aware of the "You shouldn't use a RAM disk; Windows can
>>manage the memory better than you can, etc, etc" arguments. I'm not sure
>>I believe them, though...
>
>This is probably true for the majority of Windows users. Different
>people have different systems and use them in different ways, though;
>you may very well get a benefit from a RAMdrive. Be aware that many
>Windows-based installers expect the %TEMP% directory to survive a
>reboot, so you may need to point it at a hard drive before installing
>applications.
I'm using it to try to speed up an application that uses zillions of small
files.
Charles Dye
McCormack) wrote:
>Can you say a bit about why "allocating from the top" fixes the problem?
I really don't know; all I can say is that it appears to be a memory-
management issue. Possibly it's related to the problem where UMBs
vanish when you exit from Windows 98 back to DOS.
>Also, where do you get XMSDSK?
ftp://garbo.uwasa.fi/pc/memutil/fu_rd19i.zip
ftp://ftp.sac.sk/public/sac/utildisk/fu_rd19i.zip
--
Charles Dye ras...@highfiber.com
Kenny McCormack
Charles Dye <ras...@highfiber.com> wrote:
>On Sat, 22 Jan 2005 15:54:43 GMT, gaz...@yin.interaccess.com (Kenny
>McCormack) wrote:
>
>>Can you say a bit about why "allocating from the top" fixes the problem?
>
>I really don't know; all I can say is that it appears to be a memory-
>management issue. Possibly it's related to the problem where UMBs
>vanish when you exit from Windows 98 back to DOS.
Just out of curiosity, does "allocate from the top" mean "use the INT 15
method"? If so, that might explain it. In that case, you would not need
to run HIMEM.SYS, right?
>>Also, where do you get XMSDSK?
>
>ftp://garbo.uwasa.fi/pc/memutil/fu_rd19i.zip
>ftp://ftp.sac.sk/public/sac/utildisk/fu_rd19i.zip
Interestingly, neither of these worked for me. Garbo seemed to hang
(perhaps I needed to be more patient?), and the the second one gave an
error about the directory not existing (I used "wget" to try to snarf the
whole URL - I would imagine that if I tried with an interactive FTP client,
I could figure out what the correct directory structure is)
Anyway, got it from Simtel, so all is well.
Ted Davis
McCormack) wrote:
<snip>
>
>Thank you for your reply. However, the LFN issue is real as I've described
>it. I am familiar with the implementation of LFNs via "unused" directory
>entries and of the limitations of the number of root directory entries on
>a RAM disk unless you take steps to increase them.
>
>However, the fact remains, that if the RD size is large (I have not done
>a lot of testing to determine exactly where, but I know it is between 2 and
>15 megs), then the following commands immediately after booting (the RD is
>empty at this time):
>
> D:
> cd \
> md biglongname
>
>creates (as the only file in the root of the RD) a directory named BIGLONGN
>
>>RAMDRIVE, being a Microsoft offering is pretty near worst in class - I
>
>Amen to that.
>
>>have had good results with XMSDSK loaded in AUTOEXEC.BAT.
>
>I used to use XMSDISK back in pre-LFN days. Does it still work with
>Windows and LFNs?
I use it with Win98 boot disks - no GUI, but it does allow specifying
the sector size, and that influences many things.
>
>>There are cases where a ramdrive is useful under Windows, but these
>>are pretty specialized. You definitely don't want to put the TEMP
>>directory there (unless you have a way to make sure neither Windows
>>nor any of its applications that can recover from a crash cannot
>>crash, and that no application that depends on temp files for
>>installation will ever be installed); you don't want a ramdrive if
>>Windows actually uses virtual memory - it would just make that
>>situation worse. Some disk intensive tasks can benefit.
>
>Right. I am using it for a disk intensive (zillions of little files)
>application.
You may be running out of sectors - try XMSDSK with a small sector
size and see what happens.
If you were using one of the NT series OSs, I'd suggest AR RAM Disk,
but it doesn't work with Win9x.
--
T.E.D. (tda...@gearbox.maem.umr.edu)
Ted Davis
The Simtel page is
<http://www.simtel.net/product.php?url_fb_product_page=4825>
A Google search on
xmsdsk download
turns up this quote from the author's home page
(<http://www.geocities.com/politalk/rmdrv/fu_rd19i.htm>)
"An Internet search for fu_rd19i should result in many sources for
downloading this utility." There is a download link on that page.
(Firefox, of course, suppresses the Geocities popups.)
--
T.E.D. (tda...@gearbox.maem.umr.edu)
J. Yazel
McCormack) wrote:
>I am setting up a RAMDRIVE, using:
> device=C:\windows\himem.sys
> device=C:\windows\ramdrive.sys 20000 /E
>in CONFIG.SYS
>
>Yes, I need a 20 meg ram disk. It works, except that long filenames don't
>work. It is related to size - if I make the RAM disk smaller (say, 2M),
>then the long filenames work. Yes, I am aware that the LFNs don't work
>until the GUI is up - I am booting the GUI and, as I say, if I make the RD
>small, the LFNs work.
> -------- SNIP --------
===================================
I run a 90MB ram disk on my machine, using Win98.
I use xmsdsk and have no problems with LFN on either Win98 or when I
boot to the command line.
I suggest you use the following command line in your autoexec.bat file.
Of course, you should change the e:\util path to your path and the j:
drive designation to whatever you want.
lh e:\util\xmsdsk 90000 j: /y /t /c1
Put your system PATH command someplace after the above command line.
Jack
Kenny McCormack
Yes, the concensus here is that using XMSDSK (*) and the /t option should
do the trick. I haven't had a chance to test it yet.
Thanks to all.
(*) On the motto of: Anything but Microsoft.
Kenny McCormack
Ted Davis <tda...@gearbox.maem.umr.edu> wrote:
...
>If you were using one of the NT series OSs, I'd suggest AR RAM Disk,
>but it doesn't work with Win9x.
Just out of curiosity, what would say are the strong (i.e., selling) points
of AR RAM Disk? I looked at the web site, and it looks fine (actually
might be worth downloading/testing at some point), so I'm certainly not
saying anything negative, but I'm curious what you would say are the big
tickets here.
Ted Davis
Few surprises, and those are Windows problems that are easily worked
around, it is resizable and reassignable, and it's free. It does not
appear to be an adware/spyware installer, it appears free of trojans,
viruses, and worms, and it just has a feeling of competence and
honesty about it.
The biggest wart is that Explorer doesn't see it (XP) until reboot,
though it's there, usable, and can be accessed in Explorer by typing
the drive letter + colon into the "Address" field - CMD has no trouble
finding it (nor does PsInfo -d).
--
T.E.D. (tda...@gearbox.maem.umr.edu)