defuser
Content Type
Profiles
Forums
Events
Posts posted by defuser
-
-
6 hours ago, SweetLow said:
Is something else on this AHCI controller? Especially BIOS controlled drives.
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).
0 -
12 hours ago, awkduck said:
ahciwrap.sys
Thanks, this is what I need. It works (and it's even EMM386 compatible). Amazing work!
I haven't looked at GCDROM.SYS yet.
0 -
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.
0 -
Ah, I see, so it's a purely local issue. I'll investigate the cause. Thank you.
0 -
On 7/14/2025 at 5:24 PM, schwups said:
NewMoon (sqlite 3.50.1) - moreover broken :
- direct input URL
- all Dev tools missing except "page source" in menu on second browser startA message appears below Tab bar in Newmoon Browser on start "The bookmarks and history system will not be functional, because one of New Moon's files is in use by another application. Some security software can cause this problem." - Of course, certainly not the reason here
The replace of the two files of release 20250531 seem to be harmless and doesn't cause new problems so far.
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.
0 -
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
0 -
This means that the functionality depends on the overall configuration of "KernelEx". I need to try to make some changes to it.
0 -
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.
1 hour ago, schwups said:After a further check, I realised that at least "Restore Previous Session, Recently Closed Tabs and Recently Closed Windows" still works with IceApe and Newmoon here.
So I see a different behaviour to Serpent.
How did you manage to do this? In IceApe, it only works after rolling back the two files mentioned earlier.
0 -
24 minutes ago, schwups said:
For me IceAPE-UXP is really not my first choice, because of the 0bit download problem. Or is there a fix out there?
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.
0 -
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).
0 -
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.
1 -
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.
0 -
On 30 Ìàðò 2025 ã. at 11:05 PM, SweetLow said:
Just call original WININIT.EXE from fake one.
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.htmCombined 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.
0 -
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.
0 -
Yes, the problem was related to MTRR and now everything is fine:
0 -
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.
0 -
2 hours ago, SweetLow said:
P.S. And try to check some USB Storage - will it work too?
Yes, all three are working now: keyboard, mouse and flash drive.
0 -
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 finehttp://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 workBut 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):
QuoteType:PCI Seg 00 Bus 00 Dev 1A Fun 00
Offset:0000 Width:01
86 80 2D 8C 06 00 90 02 04 20 03 0C 00 00 00 00
00 30 40 F7 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 34 17 EA 11
00 00 00 00 50 00 00 00 00 00 00 00 0A 01 00 00
00 00 00 00 0D 15 0F 1D 00 00 00 00 00 00 00 00
01 58 C2 C9 00 00 00 00 0A 98 A0 20 00 00 00 00
20 20 FF 07 00 00 00 00 01 00 01 00 05 20 0A C0
00 00 DD 3F 30 0F 00 00 4F 01 00 00 8C 40 00 00
00 00 80 00 11 88 0C 93 70 0D 00 24 01 04 02 00
00 00 00 00 00 00 00 00 13 00 06 03 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 AA FF 00 00 00 DD DF 27 00 00 00
00 00 00 00 FF FF FF FF FF FF FF FF 3C 5E 7F CB
00 00 00 00 88 85 80 00 B1 0F 06 08 08 17 1A 20
-NEXT-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":
QuoteType:PCI Seg 00 Bus 00 Dev 1A Fun 00
Offset:0000 Width:01
86 80 2D 8C 06 00 90 02 04 20 03 0C 00 00 00 00
00 30 40 F7 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 34 17 EA 11
00 00 00 00 50 00 00 00 00 00 00 00 0A 01 00 00
00 00 00 00 DB 05 D6 1F 00 00 00 00 00 00 00 00
01 58 C2 C9 00 00 00 00 0A 98 A0 20 00 00 00 00
20 20 FF 07 00 00 00 00 01 00 00 01 00 20 04 00
00 00 DF 3F 30 0F 00 00 4F 01 00 00 8C 40 00 00
00 00 80 00 11 88 0C 93 70 0D 00 24 01 04 02 00
00 00 00 00 00 00 00 00 13 00 06 03 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 AA FF 00 00 00 DD DF 27 00 00 00
00 00 00 00 FF FF FF FF FF FF FF FF 3C 5E 7F CB
00 00 00 00 88 85 80 00 B1 0F 06 08 08 17 1A 20
-NEXT-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!
0 -
Quote
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.
0 -
55 minutes ago, SweetLow said:
And why did you ask solution without having problem?
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.
0 -
15 minutes ago, SweetLow said:
It is only half of test. Do Windows load successfully after that?
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.
0 -
2 hours ago, SweetLow said:
Two solution exist - or make driver (.SYS version) and run it before EMM386 or make DPMI version of CREGFIX.
P.S. http://sweetlow.orgfree.com/download/cregfix.zip
.SYS version for test
Checked it out. If you run this CREGFIX.SYS after EMM386.EXE in CONFIG.SYS - the above error occurs. But if you put it BEFORE it, there is no such error.
0 -
CREGFIX.COM + EMM386.EXE = "Unrecoverable privileged operation error - press Enter to reboot." Is there any workaround? EMM386.EXE a very useful technology that helps you run some software under Windows 98 that requires UMB + EMS and, of course, I would not like to completely abandon it.
0 -
7 hours ago, SweetLow said:
(0) D0000008 = mem base=D0000000 len=128M prefetchable
Thank you, it helped to find the reason in the right place! I went to the device manager to see the addresses of devices that are located in this region and found there a safely forgotten previously reserved address left over from the previous configuration, where with the old BIOS design of the video card (Before the BIOS patch), it did not interfere with anything (Like other 128\256MB video cards). And now, at 512MB, apparently-this piece is also captured. And this actually prevented the driver from loading, no matter how hard I tried and what measures I did not take... I removed this entry and everything loaded immediately.
Well, the actual results:
It was:
Become:
And one more not big, but nice enough, bonus (Was=>Became):
Well, the most basic thing that was expected from the BIOS patch, for which all this was originally started - exiting DOS back to Windows 98 (Re-booting Windows) - now works again. The patched (Problematic in this regard) NVCORE.VxD was replaced with the original one.
And also the oddity (With the absence of WC working by default) on PCI-E hardware under 9x in NVIDIA drivers is also in all its glory:
Originally it was (By default):
QuoteUnder DOS:
Reported Processor Physical Address Size (bits): 39
Variable MTRRs - Base, Mask and Decription:
00000200 0000000000000006 0000007E00000800 8G @ 0 / WB
00000202 0000000200000006 0000007FE0000800 512M @ 8G / WB
00000204 0000000220000006 0000007FF0000800 256M @ 8G 512M / WB
00000206 0000000230000006 0000007FF8000800 128M @ 8G 768M / WB
00000208 0000000238000006 0000007FFC000800 64M @ 8G 896M / WB
0000020A 000000023C000006 0000007FFE000800 32M @ 8G 960M / WB
0000020C 00000000C0000000 0000007FC0000800 1G @ 3G / UC
0000020E 0000000000000000 0000000000000000 Not used
00000210 0000000000000000 0000000000000000 Not used
00000212 0000000000000000 0000000000000000 Not usedAfter starting WINDOWS (This is how "good" the NVIDIA driver worked):
Reported Processor Physical Address Size (bits): 39
Detected Processor Physical Address Size (bits): 36
!!! Warning - Detected/Default Address Size less than Reported
Variable MTRRs - Base, Mask and Decription:
00000200 0000000000000006 0000000F80000800 450G @ 0 / WB
00000202 0000000080000006 0000000FC0000800 449G @ 2G / WB
00000204 00000000E0000000 0000000FE0000800 448G 512M @ 3G 512M / UC
00000206 00000000E0000006 0000000FE0000800 448G 512M @ 3G 512M / WB
00000208 0000000100000006 0000000F00000800 452G @ 4G / WB
0000020A 0000000200000006 0000000FE0000800 448G 512M @ 8G / WB
0000020C 0000000220000006 0000000FF0000800 448G 256M @ 8G 512M / WB
0000020E 0000000230000006 0000000FF8000800 448G 128M @ 8G 768M / WB
00000210 0000000238000006 0000000FFC000800 448G 64M @ 8G 896M / WB
00000212 000000023C000006 0000000FFE000800 448G 32M @ 8G 960M / WBSpeed test for Windows:
DirectDrawCreateEx({00000000-0000-0000-0000-000000000000},IID_IDirectDraw7): OK
PrimarySurface: OK
Resolution: 1920 x 1080 x 32bpp
VideoSurface (1024 x 768, R5G6B5): OK
NonLocal VideoSurface (1024 x 768, R5G6B5): 88760276h An attempt was made to allocate non-local video memory from a device that does not support non-local video memory.
SysMemSurface (1024 x 768, R5G6B5): OK
SysMem Read (Secs, Bytes/s): 0.2009 7828072242 7828M 8G
! Warning: Time less than 0.5 second, try to increase Test Surface Size or/and TestCount
SysMem Write (Secs, Bytes/s): 0.0426 36908233706 36908M 37G
SysMem Copy (Secs, Bytes/s): 0.0667 23569650702 23570M 24G
SysMem To VideoMem Blt (Secs, Bytes/s): 1.2544 1253855763 1254M 1G
VideoMem To SysMem Blt (Secs, Bytes/s): 0.1156 1360970207 1361M 1G
Video.Lock: OK
Pitch: 2048
Virtual Address: A56FBE00
VideoMem Read (Secs, Bytes/s): 6.5443 6008483 6M 0G
VideoMem Write (Secs, Bytes/s): 18.9863 82841970 83M 0G
SysMem To VideoMem Copy (Secs, Bytes/s): 18.9299 83089032 83M 0G
VideoMem To SysMem Copy (Secs, Bytes/s): 6.4303 6115058 6M 0G
Video.UnLock: OKTom2D test (Under Windows):
BENCHMARK: DIRECT DRAWING TO VISIBLE DEVICE
Text: 227273 chars/sec
Line: 27273 lines/sec
Polygon: 14963 polygons/sec
Rectangle: 13514 rects/sec
Arc/Ellipse: 15723 ellipses/sec
Blitting: 337 operations/sec
Stretching: 119 operations/sec
Splines/Bйzier: 23981 splines/sec
Score: 4099After pre-configuring MTRR under DOS and then applying MTRR_LEN under WINDOWS:
QuoteReported Processor Physical Address Size (bits): 39
Variable MTRRs - Base, Mask and Decription:
00000200 0000000000000006 0000007F80000800 2G @ 0 / WB
00000202 0000000080000006 0000007FC0000800 1G @ 2G / WB
00000204 00000000C0000001 0000007FE0000800 512M @ 3G / WC
00000206 0000000200000006 0000007FE0000800 512M @ 8G / WB
00000208 0000000220000006 0000007FF0000800 256M @ 8G 512M / WB
0000020A 0000000230000006 0000007FF8000800 128M @ 8G 768M / WB
0000020C 0000000238000006 0000007FFC000800 64M @ 8G 896M / WB
0000020E 000000023C000006 0000007FFE000800 32M @ 8G 960M / WB
00000210 0000000000000000 0000000000000000 Not used
00000212 0000000000000000 0000000000000000 Not usedDirectDrawCreateEx({00000000-0000-0000-0000-000000000000},IID_IDirectDraw7): OK
PrimarySurface: OK
Resolution: 1920 x 1080 x 32bpp
VideoSurface (1024 x 768, R5G6B5): OK
NonLocal VideoSurface (1024 x 768, R5G6B5): 88760276h An attempt was made to allocate non-local video memory from a device that does not support non-local video memory.
SysMemSurface (1024 x 768, R5G6B5): OK
SysMem Read (Secs, Bytes/s): 0.2004 7848894282 7849M 8G
! Warning: Time less than 0.5 second, try to increase Test Surface Size or/and TestCount
SysMem Write (Secs, Bytes/s): 0.0427 36807615029 36808M 37G
SysMem Copy (Secs, Bytes/s): 0.0668 23547175251 23547M 24G
SysMem To VideoMem Blt (Secs, Bytes/s): 1.2529 1255418377 1255M 1G
VideoMem To SysMem Blt (Secs, Bytes/s): 0.1157 1359767179 1360M 1G
Video.Lock: OK
Pitch: 2048
Virtual Address: A546CE00
VideoMem Read (Secs, Bytes/s): 6.3954 6148462 6M 0G
VideoMem Write (Secs, Bytes/s): 1.0794 1457109079 1457M 1G
SysMem To VideoMem Copy (Secs, Bytes/s): 1.0555 1490168976 1490M 1G
VideoMem To SysMem Copy (Secs, Bytes/s): 3.4080 11538193 12M 0G
Video.UnLock: OKBENCHMARK: DIRECT DRAWING TO VISIBLE DEVICE
Text: 454545 chars/sec
Line: 78125 lines/sec
Polygon: 36364 polygons/sec
Rectangle: 15873 rects/sec
Arc/Ellipse: 31447 ellipses/sec
Blitting: 2474 operations/sec
Stretching: 1034 operations/sec
Splines/Bйzier: 52083 splines/sec
Score: 82690
[SOLVED] CD-ROM don`t work, after EXIT to DOS.
in Windows 9x/ME
Posted
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.