defuser

That's a good idea. I'll give it a try, but if I can't find a complete solution to this problem (and I still haven't given up hope), there's not much else I can do. I already have the "RECORDER" tool from Windows 3x, which allows me to record and play back any actions with a high level of accuracy (including mouse movements) and reproduce them in the same sequence. It works well in Windows 98 (although I'm not sure why Microsoft didn't include this useful tool in Windows 9x and later versions). About once every few days, I check RAMDRV64, which is used by several programs that are writing to it at the same time, causing occasional cross-writes that are successfully corrected by ScanDisk (restoring lost free space). Over time, these "mouse movements" become somewhat tedious. Therefore, it is important to me. Thank you!

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.