ramdrv4m - Universal RAM Drive for Windows 9x

[SweetLow]

ramdrv4m - Universal RAM Drive for Windows 9x

https://github.com/LordOfMice/Tools/blob/master/ramdrv4m.zip

Features description:
1. Memory support above 4GiB (default mode).
Primary purpose of creating this software.
2. A full-fledged 32-bit protected mode driver.
3. High speed of operation.
4. Can utilize RAM Drives created in memory
by other software. In particular, it is compatible with
RAMDSK32/64 from RLoew.
5. It consumes only 4MiB of virtual address space.
In addition to the real memory used for RAM Drive itself, of course.
6. Works on Pentium and higher class processors 
(i.e. it does not work on 80486).

As usual - readme is your best friend...

[defuser]

A very interesting decision. It seems that this is the first full-fledged PSE ramdisk in history that
installs and works directly under WINDOWS! No more downloading of HIMEMEX (by Rudolph R. Loew). HIMEMEX
itself, by the way, is not full-fledged: the PREALLOCATION function stated in the Readme does not work
in it, as a result of which you have to use them together with BURNMEM (the first, in fact, for the
RamDisk; the second for limiting memory). And, as it turned out during operation, the order in which
they are launched (Together with HIMEM) in CONFIG.SYS is crucial. The most stable sequence turned out to
be HIMEMEX > BURNMEM > HIMEM. This solved most of the problems associated with it. Now, thanks to
RAMDRV4M, in the future it will be possible to completely exclude HIMEMEX from this scheme. But first
you need to make sure that RAMDRV4M works as well, does not cause problems and is compatible with all
the programs you use, and this will take time. Also, knowing a little history of the development of
RAMDSK64 and its performance, depending on the newness of the hardware and, apparently, the BIOS
version, the question also arises of the compatibility of RAMDRV4M with more promising hardware (In
particular, based on LGA1700, in combination with the CREGFIX necessary there to fix VCACHE). It would
be nice if someone (who already uses such hardware) checked this right away. I'm starting testing on
HASWELL. And I’ll check the speed first:

initial results with RAMDSK64:

result with RAMDRV4M installed on top of RAMDSK64:

clean result with RAMDRV4M:

Amazing! Which, by the way, is quite remarkable, when I deleted the HIMEMEX boot line from CONFIG.SYS,
rebooted and saw the drive letter "G:", instead of "M:", I expected to see it, of course, empty. As
usually happens with RAMDSK64 after a reboot (If you don’t copy anything to it at the DOS stage or
immediately after starting WINDOWS). But when I opened it, I was quite surprised: all the files and
folders that were on the "M:" RamDisk before the reboot remained (On "G:")! Even the folder
"CrystalDiskMark22_9x" was already there! It turns out that this data was stored somewhere during the
reboot? But where? Is it really in RAM? I definitely didn’t have enough free space on the "C:" drive to
store a backup of the appropriate size there.

Simply fantastic. Well, okay, I will now test the pure version (Without RAMDSK64) under real conditions
of use with regular programs. This may take a long time. Thank you.

PS: How can I change the drive letter? I want to change it back to "M:", my software is copied when
loading to "M:" and the shortcuts also lead to "M:" and all sorts of "TEMP", "Temporary Internet Files"
are also registered there. I looked in the Readme and didn't see it. I opened the disk properties -
there is a gray "G:" there. I understand that you need to install LetterAssigner?

PSS: There was also a funny incident. When I installed it (Directly on top of RAMDSK64, without
disconnecting the existing disk) - at first it seemed that the system was frozen (Everything froze and
nothing could be done) and, after waiting a little, I was already reaching for the reboot button, when
suddenly everything came to life and a message appeared on a blue background "Windows The volume that
was removed had open files on it. Next time please check first to see if the volume can really be
removed. Press any key to continue." Nevertheless, even in this situation, everything went well and the
system continued to work normally after that, and the installed RAMDRV4M appeared in the device manager.

Edited April 13, 2024 by defuser

[schwups]

Impressive benchmarks, very interesting, I haven't dealt with RamDisk or RamDriver so far and unfortunately I don't have a suitable test system yet. My systems have 2 or 4 GB Ram (RLoews Ram Patches), but not more. If I buy two 4 GB bars or four 2 GB bars, I could expand the memory to 8 GB on two boards. Does it affect dual channel operation, especially with only two 4 GB bars?

[SweetLow]

On 4/13/2024 at 7:59 AM, defuser said:

How can I change the drive letter?

As with any PM only drive - in Device Manager made it Removable, set letter, made it non Removable. And as drive can stopped and started in Device Manager - no reboot needed (if no swap file on this drive, of course).

>It seems that this is the first full-fledged PSE ramdisk in history that
installs and works directly under WINDOWS!

The first PSE drive for Windows was made by Intel for Windows NT 4.0 ~ 25 years ago

>It would be nice if someone (who already uses such hardware) checked this right away.

You have to know already that I'am running one of my Windows 98 SE on Core i7 10700...

>the question also arises of the compatibility of RAMDRV4M with more promising hardware

There is no problem for compatibility for pure protected mode software. The problem of RLoew's solution is transition from real mode code that drives something to protected mode code that access memory and back.

>and a message appeared on a blue background "Windows The volume that
was removed had open files on it. Next time please check first to see if the volume can really be
removed. Press any key to continue."

Read readme...

> Is it really in RAM?

Read readme...

Edited April 16, 2024 by SweetLow

[SweetLow]

On 4/13/2024 at 7:59 AM, defuser said:

the PREALLOCATION function stated in the Readme does not work in it

There is minor error in himemex, i described it on ru-board. I recommend you read there too.

Edited April 16, 2024 by SweetLow

[defuser]

Quote from Readme:

Quote

"UseGoodDriveAfterReboot"=hex:00
use of the drive after a "hot" reboot. It is disabled by default.
It is not safe to turn it on even for drivers with memory higher than 4GiB - on modern 
BIOSes, the drive header at the beginning of the 4GiB+ address space may be preserved,
but the memory is changed somewhere in the middle of the address space.
(It's not clear why, but that's the way it is). So it is necessary to first proof
(copy something on the drive to the whole drive size, reboot and then compare
it with the original data). To give you an example: on my laptop rebooting works
neatly, but on the new working machine - not anymore, memory changes around
5 gigabyte.

I checked and noticed the following. The contents of the RamDisk are preserved even after rebooting to XP and back. But if the PC is turned off (Even for a short time), the information is permanently deleted. That is, within the framework of a working session, you can safely make reboots, including rebooting in XP and returning back, and the information on the RamDisk remains. However, this does not work if RAMDRV4M is used on top of RAMDSK64 (which may be necessary if you need to copy something to RamDisk already at the DOS stage). It only works when using the pure RAMDRV4M variant. But it still works well. My checks showed complete data safety (based on the results of checking checksums) even after returning from WinXP. In XP itself, of course, PAE\PSE is disabled (Not used).

[awkduck]

@SweetLow Excellent work!

I've been intending to write something like this, myself. I may still take a whack at it, for the educational result of the challenge. But, who knows how long it would have taken me to start? I'm spread too thin, lately.

Looking forward to taking your work for a test drive. You've done some neat things. But this one is an attention grabber. Would have tried it sooner, but my main browser is terrible, on github. Seems that a lot of the things you work on, have been things I've see people discus a desire for (at the usual Win9x places).

[SweetLow]

38 minutes ago, awkduck said:

But this one is an attention grabber.

Attention grabber?  My friend, if you want to see what is attention grabber look at hidusbf...

 

42 minutes ago, awkduck said:

a lot of the things you work on

Yes, subject is not the last thing in my TODO list.

[defuser]

Hello. Is there a standard way to assign a different default name? I changed the name several times in the disk properties, but it is not saved and each time from a cold start it is assigned the original one. Is it hardwired somewhere deep in the driver code? I tried changing everything I found in the registry, but also to no avail.

Another question concerns access from DOS to a previously created disk under WINDOWS. Do you need a separate 16-bit client?

[SweetLow]

1 hour ago, defuser said:

Is it hardwired somewhere deep in the driver code?

Yes. But I assume "label" command does its work still...

If you will point me why do you need variable label when driver create volume I  do option for this.

> Do you need a separate 16-bit client?

No. Drive can or can not be mounted before.

readme related options: 

- checking for third-party drives in memory at start address:
"CheckExternalVolume"=hex:FF
enabled by default. If a drive is detected, there are two options
(by configuration) - it is either used or left under the control of the
of the old software, with use option enabled by default:
"GrabRMVolume"=hex:FF
"GrabExternalVolume"=hex:FF.
The first parameter defines the use of known DOS drives
(e.g. RAMDSK32/64), the second - all other drives (no examples yet)

i.e.  GrabRMVolume - use DOS mounted drive,  GrabExternalVolume - use unmounted volume, no matter how it was loaded into memory

Edited May 6, 2024 by SweetLow

[defuser]

14 minutes ago, SweetLow said:

If you will point me why do you need variable label when driver create volume I  do option for this.

Nothing is necessary, I already understood how to do it. Thanks for the tip.
The reason is quite obvious - the name is long and the last letters of the name are still not visible:

I just wanted to make the name a little shorter. RamDrive for example fits:

I have only one RamDisk on the system, so it's hard to confuse anything.

 

[schwups]

I've tried it and it works. My RAMDisk is a bit small with a size of 1.99GB FAT. I used a stored board P5B (up to 8 GB RAM) from the basement and put a 450 Conroe-L single core on it. (6 GB RAM DDR2 - 800 => 3008MB RAM + 1.99GB RAMDisk)

--------------------------------------------------
CrystalDiskMark 2.2 (C) 2007-2008 hiyohiyo
Crystal Dew World : http://crystalmark.info/
--------------------------------------------------

Sequential Read : 1527.052 MB/s
Sequential Write : 1505.381 MB/s
Random Read 512KB : 1476.697 MB/s
Random Write 512KB : 1439.799 MB/s
Random Read 4KB :  669.878 MB/s
Random Write 4KB :  587.463 MB/s

Test Size : 100 MB
Date : 2024/08/16 23:08:53

 

HD Tach version 2.70
Drive: SweetLowRAM Drive PSE   0000
Access time: 0.0ms
CPU utilization: 100.0%
63 zones to be tested (32768kb zones).

Burst speed: 2481.8MB/s
Average read speed: 3412

[SweetLow]

1 hour ago, schwups said:

I've tried it and it works.

On Windows ME? Glad to hear.

P.S. Do you get Blue Screen message when try to shutdown your system when swap file locates on RAM drive?

Edited August 17, 2024 by SweetLow
p.s. addded

[schwups]

First test was OK - without blue screen. Swap file set to max 1000 on RamDrive.

[schwups]

No problems so far, also with swap file set to max size.