defuser

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.

Yes. It worked! Thanks for the tip. I used a tiny program "BAT2EXEC", from here: http://web.archive.org/web/20060512120615/http://ftp.sunet.se/pub/simtelnet/msdos/batchutl/bat2ex15.zip Mention of this wonderful program was found there: https://www.mdgx.com/newtip14.htm Combined in one BAT file a call to the original "WININIT.EXE" + "UserProg.EXE" (following it) and converted using "BAT2EXEC" to a single file, giving it the name "WININI1.EXE". Corrected and "WIN.COM" (What would be the new one "WININI1.EXE" called instead of the original one "WININIT.EXE"). As a result of all these actions, during a hot reboot, if "WININIT.INI" is found in the folder "C:\WINDOWS" - then run first "WININI1.EXE", which first calls the genuine original "WININIT.EXE" and he works out as usual, and after him immediately enters the game already and "UserProg.EXE", producing useful action. Not exactly a perfect design, but at least that's how it works. So now, as they say, both hares are whole and wolves are full I will generally observe. I hope that everything will work correctly from now on. PS: Yes, you're probably right. But for some reason, Google sent me here with my question (And I thought that maybe we should not duplicate discussions that were previously created by other participants, but instead supplement existing ones?). But if this is somehow not good - then okay, it's not difficult for me to create a new topic next time.

Is it possible to execute a user script or EXE file during a hot reboot? This is when the usual "Restart" is selected in the menu, while holding down the "SHIFT" key (Sometimes the OS itself also chooses this simplified method of rebooting). I always assumed that "DOSSTART.BAT" is also processed there (just like when exiting in DOS), but it turned out that it is not. Called only "WININIT.EXE", and then only if "WININIT.INI" exists next to it (you need to create it again each time). However, I didn't find any convenient way to call the EXE file from "WININIT.INI". The rough approach is to replace "WININIT.EXE" to any other EXE that needs to be executed by giving it this name and placing "WININIT.INI" next to it. And this method works. However, this also loses useful functionality (necessary for the system to work properly, as well as for installed programs and drivers). Maybe there is some more elegant way to execute the necessary code (BAT or EXE) during a hot reboot (But only necessarily at an early stage, before starting the WINDOWS kernel and GUI)? Thank you.

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

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.

Yes, all three are working now: keyboard, mouse and flash drive.

Result: http://sweetlow.orgfree.com/download/usb20_win9x.zip - from cold start - it works fine - after exiting to DOS - it doesn't work - after returning to WINDOWS (with the EXIT command) - it works fine http://sweetlow.orgfree.com/download/usbehci.zip - from cold start - it works fine - after exiting to DOS - it doesn't work - after returning to WINDOWS (with the EXIT command) - does not work But there is good news. I found a workaround to enable the mouse (The keyboard is connected to the second port managed by CSM and it works correctly everywhere and always). And so, after the first cold boot in DOS, I saved PCI registers for the USB controller on which the mouse is installed (USB1_GOOD.TXT): And then, booted into WINDOWS. Exit to DOS. The mouse immediately went out (Stopped working). Then I ran RU.EXE and I applied all these data (Which are given above) and the mouse immediately lit up (Earned). This means that the mouse and keyboard just need to be initialized automatically after exiting to DOS via DOSSTART.BAT. And the problem will be completely solved. Content "USB1_BAD.TXT": By the way, when the controller is running, these digits "0D 15 0F 1D" are constantly changing. And when the controller does not work, they freeze and stand still (DB 05 D6 1F). After applying data from "USB1_GOOD.TXT" these numbers come to life again and start moving. Mouse working!

This is a very good, stable EHCI driver. I use it for a long time, there are no complaints (serious). Moreover, it turned out to be useful not only for Windows 98, but also helped to solve the problem of "jumping" or halving the frequency of USB port polling in Windows XP (USBEHCI.SYS) on one of the problematic configurations. My only wish is to improve support for real DOS mode as much as possible. Now, after exit to DOS, the keyboard and mouse connected to the EHCI controller that this driver is installed on in Windows 98 do not work. And in order to continue working (type something on the keyboard), you now need to switch the keyboard to the second USB controller, which is controlled by CSM (only a dummy driver is installed on it). And after exiting DOS (Returning to WINDOWS with the "EXIT" command), the driver works as if nothing had happened. That is, it is not correctly unloaded (It does not transfer control back to the CSM BIOS). And this is the only small (Since there is a working workaround), but still very desirable improvement at the moment. Otherwise, everything works very smoothly (Other options I tried either did not work at all, or worked very crookedly, or required pulling the system floor from Windows ME). And this is the most compact and versatile option that does not require making deep changes to the original Windows 98.

I'm focusing on choosing the right hardware for the new configuration, and I came to ask if there is a solution to this problem. The choice depends on it. If there is a solution, then it will be one piece of hardware (later). And if there is no solution, then it will be a completely different hardware (earlier). Such things you want to know in advance, so as not to make a mistake and make the right choice.

On the current hardware (Without VCACHE error) - loaded successfully. For reliability, it would be necessary to check this on the problem hardware (Which is subject to this error), but I don't have it at hand at the moment.