defuser

I don't have Windows ME on bare metal right now to test this. However, on Windows ME running in Virtual PC, the behavior of "SCANDSKW" is similar, and the effect is quite good: This provides a clear demonstration of the change in write speed during disk surface scanning, where: "1" - when the SCANDSKW window is in the background; "2" - when the SCANDSKW window is active; "3" - when intensive mouse movements occur above the active SCANDSKW window.

As you know, the speed of ScanDisk under Windows 9x depends on the intensity of mouse movement. I made a short recording demonstrating this effect: As you can see in the recording, the speed of the scan increases significantly when you move the mouse. The question is, is it possible to fix this behavior so that the scan always runs at maximum speed and is not affected by mouse movement? Thank you.

I would also like to add that during further research, I discovered that "AHCICD" and "AHCIWRAP" (both of these drivers individually) support on-the-fly loading through "DEVLOAD.COM" at any convenient time when needed (they do not need to be loaded through CONFIG.SYS). However, I was unable to do anything with "GCDROM.SYS" (it seems that it requires a pure SATA connection without AHCI, or my controller is not yet compatible with it, or there may be something else entirely). But since "AHCIWRAP.SYS" has already fixed the issue mentioned in the topic title, I have added "[SOLVED]" there. Thank you all.

Yes, there is always at least 1 disk (the system disk) present in the BIOS (it's bootable). There might be something else besides it. I'll check it out. update: I checked the BIOS, and there's only the system SSD and this disk drive (NEC). Only 4 devices are physically connected (including the disk drive).

Thanks, this is what I need. It works (and it's even EMM386 compatible). Amazing work! I haven't looked at GCDROM.SYS yet.

Hello. I've encountered a problem where the CD-ROM works fine in early DOS (before WINDOWS starts), but stops working completely in late DOS (after exiting WINDOWS). Regardless of when MSCDEX is loaded, attempting to access the contents of the CD results in the following error: "CDR103: CDROM not High Sierra or ISO-9660 format reading drive J Abort, Retry, Fail?" I am using the AHCICD 1.1 driver (By Rudolph R. Loew) + MSCDEX 2.95 (By Microsoft Corp). In CONFIG.SYS: "DEVICEHIGH=AHCICD.SYS /D:OEMCD001", and to call MSCDEX the line is used "MSCDEX /D:OEMCD001 /L:J" (AUTOEXEC.BAT or other place). Have you already faced this problem, is it possible to fix it? Thank you.

Ah, I see, so it's a purely local issue. I'll investigate the cause. Thank you.

I confirm that this behavior has been observed in the latest NewMoon. By the way, does anyone have the "Speedometer 2.0" test fully completed in Roytam1 browsers (in any of them)? https://browserbench.org/Speedometer2.0/ I have this test fully passed in Mypal 29.3.0 from Feodor2, whereas in any browser from Roytam1 the test is not fully passed, for example, in IceApe (any version) somewhere at the very end the browser freezes and hangs in memory until you close it via Process Exlorer. Is it just me or is this the standard behavior? Sorry if this question has already been solved\discussed.

After searching on My Computer, I found three versions of this package: I don't remember where I downloaded it, and I haven't tested it on Win95 yet, but if you need it, I've uploaded all three in a single archive. You can download it from there (the link is valid for a certain period): http://www.upload.ee/files/18288081/CCCP.zip.html

This means that the functionality depends on the overall configuration of "KernelEx". I need to try to make some changes to it.

That's right, I've already checked it. In "palemoon-28" (From 2025.05.31) and "basilisk52" (From 2025.05.31), the files are downloading correctly. I've added them to my programs. Thank you. As you mentioned, this is the cause of the new problem: "- import from UXP: No issue - Update SQLite lib to 3.50.1 and require it as syslib. (5ae40cfe) (6c4f2fc44)" For some reason, this new "SQLite 3.50.1" can't work properly anymore. What is missing? I also tested it on a clean version of XP (SP2, from 2004), and there was no issue. Dependency Walker under Windows 98 doesn't show any new dependencies for "mozsqlite3.dll," and I didn't notice any new requirements for "xul.dll." Is there any internal fundamental change in "SQLite" itself that doesn't take into account the features of 9x? I don't understand, as I'm not very familiar with all of this. For now, I'll stick to the previous (stable) versions. How did you manage to do this? In IceApe, it only works after rolling back the two files mentioned earlier.

No. I use a temporary workaround - when I need to download something, I copy the download link to another program (for example, Mypal29 or OperaPresto 12.02). I assume that Serpent/Newmoon doesn't have this error? Well, that's quite interesting, and I'll try it out.

The same applies to IceAPE-UXP (current version, dated 2025.06.21). As a temporary workaround, I have rolled back the two files "xul.dll" and "mozsqlite3.dll" to previous versions (dated 2025.05.31).

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.

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.