ramdrv4m - Universal RAM Drive for Windows 9x

[SweetLow]

1 hour ago, defuser said:

You tried it and it worked (By the way, this applies to any disk under 98\98SE, but it doesn't work at all in WinME. Just in case I'm doing something wrong)?

Ok, MS-RAMDRIVE is bad case. But there are two other names treated as RAM Drives - RDV and VDISK. And as they are shorter than 11 characters - any name RDV* or VDISK* are treated as RAM Drives too...

1 hour ago, defuser said:

is it possible to get access to the ramdisk ALREADY placed in memory under WinXP?

Yes in general, but IDK such software for XP.

[defuser]

8 hours ago, SweetLow said:

Ok, MS-RAMDRIVE is bad case. But there are two other names treated as RAM Drives - RDV and VDISK. And as they are shorter than 11 characters - any name RDV* or VDISK* are treated as RAM Drives too...

Thank you. It is stored in the same place (in Kernel32.dll)? (Yes, these parameters follow right behind...). You can already make an "RDVDRIVE" and it works! It remains to find and replace "DV" with "AM" in the code, which already looks easy to solve (Although it is no longer critical or significant, because the main goals have been achieved). At the same time, I checked it in WinME and no, alas, both do not work. It seems that since WinME, they have removed this from the code altogether. Although the same "MS-RAMDRIVE" in the body Kernel32.dll for some reason, it is still present. Although I haven't tried with installed service packs.

8 hours ago, SweetLow said:

Yes in general, but IDK such software for XP.

Well, only PSE36 ramdisk for NT4 comes to mind here. I tried to find it in order to test it under XP, but it turned out to be a difficult task. This SDK seems to have been completely lost to history. There is only some information left that such a principle once existed, but the sources themselves can no longer be downloaded:

http://web.archive.org/web/19990421095003/http://developer.intel.com/vtune/vtcd/index.htm
http://web.archive.org/web/19991007020425/http://developer.intel.com/vtune/pse36/
http://web.archive.org/web/19991008040955/http://support.intel.com/support/performancetools/pse36/sysreq2.HTM

If you find this ramdisk and it will work in XP, then you can do something else. Create a disk in XP and then initialize it in 98 using RAMDRV4M, which already provides this feature. You don't need anything extra to do this. Or, which is more correct, but will require some improvements - to upgrade the ramdisk for NT already, giving it similar functionality (This driver was distributed with the source texts, so by combining it with the RAMDRV4M code, this might have been possible).

 

Yes, everything worked out - icons and types changed everywhere:

At the same time, after RAM\RDV, you can add any valid characters, in any language, but only so that their total number does not exceed 11. Thus, if you change " RDV " to "PAM", you even get a certain localized construction - "PAMДИСК" => "".

Edited August 22, 2024 by defuser

[SweetLow]

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

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."

Version for testing:
http://sweetlow.orgfree.com/download/ramdrv4m.zip

RAMDRV4M->README:
>Unresolved problems at this time:
>1. Due how the IOS works, there is two consecutive
>blue screens with warning on exit to DOS when a swap file is located
>on RAM Drive. This behavior is non-specific to RAMDRV4M.
>2. RLOEW disks do not work after exiting to DOS.

I managed to write a workaround for these problems (under Windows 95 & 98, not ME) and it turned out that both problems are actually the same problem - unplanned (and too early) deletion of the drive by the OS.
However, the source of such impolite behavior is unknown still.

[SweetLow]

Release:

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

>Unresolved problems at this time:
>1. Due how the IOS works, there is two consecutive
>blue screens with warning on exit to DOS when a swap file is located
>on RAM Drive. This behavior is non-specific to RAMDRV4M.
>2. RLOEW disks do not work after exiting to DOS

Fixed too early destruction of controller object on Windows exit.

[defuser]

Greetings. I noticed a feature that is observed when checking the RAMDRIVE surface:

Checking up to 1000 (approximately) clusters is very fast, from ~1000 to ~2100 very slow, and then after ~2100 to ~3200 again very fast! RAMDISK is now at 12.5 GB and in this test the ramdisk is completely empty.

[SweetLow]

12 minutes ago, defuser said:

Checking up to 1000 (approximately) clusters is very fast, from ~1000 to ~2100 very slow, and then after ~2100 to ~3200 again very fast!

Check Variable MTRRs (and use something like Disk Test from AIDA64 for tests, it is much more clearer).

[defuser]

Yes, the problem was related to MTRR and now everything is fine:

[defuser]

On 16 Ôåâðàëü 2025 ã. at 10:07 PM, SweetLow said:

>1. Due how the IOS works, there is two consecutive
>blue screens with warning on exit to DOS when a swap file is located
>on RAM Drive. This behavior is non-specific to RAMDRV4M.

Yes, it is stable and reproduces for me, if you move the paging file (WIN386.SWP) to "RAMDISK64". Only I don't have a blue screen, but a black one and only the white wand flashes. And in order to continue, you need to double-click any button on the keyboard, after which the exit/restart procedure continues as usual. At the same time, the keyboard must be connected to the PS/2, or to a USB port managed by the CSM. Since reinitialization of the USB controller after the WINDOWS driver occurs at the DOSSTART.BAT processing stage (But not before), and this is one of the subsequent stages. The need to press a key occurs precisely at the most inconvenient moment when the WINDOWS driver has been successfully unloaded and no LONGER works, and the CSM BIOS driver has STILL not turned on and re-activated the USB. Therefore, I had to refrain from the beautiful idea of "Paging file in x64 RAM" at the moment (This role is not so bad performed by SSD). Although the idea itself is quite attractive (In everything else), I tested it and, in addition to the obvious speed advantage, it can also save the SSD from unnecessary procedures for overwriting the drive cells (Which is also quite useful for SSDs and other solid-state media). In general, you need some kind of workaround that automates the keystroke procedure (especially for new systems without PS/2 support), both when you exit Windows and during a hot reboot (SHIFT+Restart). Or a fundamental bug fix (this doesn't happen with regular disks). Well, or the third possible solution is to find a way to initialize the "Legacy USB" at a slightly earlier stage, so that the USB keyboard would ALREADY work at the time of this error (Unloading the WINDOWS driver and IMMEDIATELY after this initialization of the CSM USB). But how to do this, so far there are no ideas. And yes, the problem is clearly beyond the scope of "RAMDRV4M", but it is also impossible not to mention this separately here.

[SweetLow]

5 hours ago, defuser said:

but a black one

This is broken video driver. I got such picture on VBEMP.

 

5 hours ago, defuser said:

Therefore, I had to refrain from the beautiful idea of "Paging file in x64 RAM" at the momen

I assume you have to CAREFULLY reread description of the last updates of RAMDRV4M. They located right on this page.

[jumper]

The last updates don't solve his problem.

 

[SweetLow]

2 hours ago, jumper said:

The last updates don't solve his problem.

How did you apply them?

[defuser]

The problem is completely solved. Everything turned out to be banally simple: to correctly update the  product to a more recent version, it is not enough to replace "RAMDRV4M.PDR" in the "IOSUBSYS" folder.  In order for the update to pass correctly, you first had to delete the controller in the device manager,  as well as "RAMDRV4M.PDR", perform a reboot. Install the new version "cleanly". Only after doing all  this together did the problem finally fully go away. Currently, performing a "hot reboot"  (shift+restart) and the "exit Windows" procedure works correctly, without the need for user  intervention. Thank you all.

[SweetLow]

4 minutes ago, defuser said:

it is not enough to replace "RAMDRV4M.PDR" in the "IOSUBSYS" folder

Usually it is enough if only RAMDRV4M.PDR is changed. But fix of problem with early unload was unusual as it required the change of Registry parameter for controller object...