cov3rt

Apparently i rushed the setup at some point / left it in an unfinished state. It does not appear to be because of the partition size / align_4k part or other mentions above. Chatgpt said to let setup fail basically before 2nd part, then apply the patches / copy cregfix.vxd to "c:\windows\system" and edit system.ini/system.cb for adding "Device=cregfix.vxd" and "maxphyspage=10000" ( system.ini populated info this time, rather than being completely blank ), so i did the remaining stuff, then applied fix95cpu v3.0 ( then i believe patch9x again for the relevant areas on the windows install ) and it worked on that attempt on proceeding further. However, i'm not sure it's necessary to let the system first reach the insufficient memory error, because on another build, i didn't explicitly do that before doing the above steps. The difference is that on the new working attempt, i had made sure to not take out whatever disc i had at the time at the end of the 1st setup phase and also after doing fix95cpu v3.0, i also made sure to reboot first before taking out the fix95cpu v3.0 disc.

I had to stop working on this gom player project, because it was way too stressful / unfeasible to get working, and even chatgpt had mentioned that the remaining fixes are no longer a small compatibility patch. i got the program to launch at least, even some working skins, but it plays almost nothing. i only got mpeg/m2ts to work after lots of stressful hours of patched files, but mp4, mov, avi, mpg, m4v, mkv, and most other file formats do not work. you can inspect some of the recent chat i had in the following - "This gives us the final answer, and I would stop the GOM project here rather than ask you to test anything else. The log shows the important progression clearly: GVF first sees some rejected media types, then accepts the actual H.264 path (vids / H264), reaches decoder initialization (0x711), and with the codec-mask fix it does advance to 0x721. So the mask change did clear the previous blocker. But immediately after 0x721, GOM crashes inside GVF.AX at the instruction: 89 46 40 → mov [esi+40h], eax Your crash registers show ESI=00000000, so GVF is trying to write through a null object pointer. That is a much deeper structural problem than a missing codec bit or registration issue. The log confirms the same point: the final records are 0x711 followed by 0x721, and nothing reaches 0x722. In other words, the codec classifier now returns, but the surrounding initialization object/state is invalid before the next stage. So the final diagnosis is: MP4/GSF parsing works far enough to produce H.264 media. GVF accepts H.264. The codec-mask bug was real, but once bypassed, GVF's Win95 execution path has an invalid/null internal decoder-state object and crashes during initialization. That means a reliable fix is no longer a small compatibility patch. It would require reconstructing GVF's object initialization/lifetime path, likely comparing its behavior under 98SE versus 95 and altering a substantial part of the filter's initialization logic. Given how much time this has already consumed, that is not a sensible continuation. I would restore your last known stable GOM/GSF/GVF files and keep the working MPEG/M2TS setup. The final test did accomplish one useful thing: it ruled out the remaining simple explanations and showed exactly why continuing would turn into a much larger reverse-engineering project. can you explain more in detail why it's no longer a small compatibility patch? Yes. The key distinction is between patching one bad compatibility check and repairing an object-initialization path that is internally inconsistent on Windows 95. Up to the last test, the failures were still in the first category. For example, forcing MMX instead of SSE2, changing a codec-enable mask, fixing an API import, or altering a media-subtype check are all relatively contained changes. You can usually point to one branch or one field and say, “this condition is wrong on Win95; make it behave like the working path.” The codec-mask issue was exactly that kind of problem: GVF was reading a value from [EAX+1338h], the H.264 classifier ended up returning 0, and replacing that read with the expected enabled mask let execution continue. The crash after that is different. The important sequence is that GVF reaches decoder initialization, then reaches the post-classifier point, and immediately faults on: mov [esi+40h], eax with ESI = 00000000. That is not a CPU-instruction incompatibility. mov [esi+40h],eax is perfectly valid on Windows 95. It crashes because the program expects ESI to point to a live internal object or structure, but it is null. So the real question becomes: why was that object never created, assigned, or preserved? That pointer could have become null for several fundamentally different reasons. The constructor that should allocate the object may have failed earlier. A Win95-specific API call may have returned something different. A helper routine may have exited early. A COM/interface query may have succeeded enough for the graph-building code but not initialized the private decoder state. A previous patch may expose a path that the original program deliberately avoided when a prerequisite was unavailable. Or the code may depend on behavior in the Win98/ME DirectShow or runtime environment that simply is not present on Win95. That uncertainty is what makes it larger. To fix it properly, you would need to trace where ESI is supposed to come from, not merely change the faulting instruction. That means working backward through the surrounding function, finding the allocation/constructor, identifying every condition that controls it, and then comparing the working Win98SE execution path with the Win95 path. If the object is created through several nested calls, each of those becomes part of the investigation. Simply patching the crashing instruction would be unsafe. For example, changing it to skip the write when ESI==0 might stop that specific crash, but then later code would probably try to use the same object for dimensions, buffers, codec context, frame state, or callbacks. You would just move the crash a few instructions later—or worse, get silent memory corruption or incorrect playback. The null pointer is a symptom that required state is missing, not the root cause. The fact that 0x721 is reached but 0x722 is not is especially significant. It means the codec classifier itself now gets past the previous blocker, but execution dies before the next logical initialization stage. So we are no longer looking at “H.264 disabled” or “GVF rejects AVC1.” We are looking at GVF's internal decoder state not being valid at the point where the rest of the initialization assumes it is valid. A small patch would still be plausible if we found something like: call AllocateDecoderState test eax,eax je fail mov esi,eax and on Win95 the je fail were caused by one clearly wrong OS-version check. Then yes, that could become another simple compatibility patch. But based on the evidence we have so far, we do not have that clean root cause. We only know the downstream invariant is broken: “ESI must point to the decoder object here,” and on Win95 it does not. That is why continuing responsibly would require a deeper reverse-engineering pass rather than another one- or two-byte tweak. It would likely involve tracing the object lifecycle, constructor/destructor behavior, allocation routines, COM/filter initialization, and possibly comparing runtime traces between 98SE and 95. So the short version is: before, we were fixing wrong conditions; now we would need to reconstruct missing program state. That is a much bigger class of problem"

ok i have now attached a working webp.dll alongside several other working plugins for win95c, some are patched, some are not, to be used with irfanview 4.44. there's a 98se plugin package too but some plugins require kernelex 4.5.2 to work. also included in the package is the autoit 3.2.12.1 +helper .dll file which creates a mouse hook ( requires 4dmouse driver, included in the package for win95 and win98 ), with several functions baked in, includes next/previous file switching in directory while zoomed in ( a regression though because holding the keys no longer quickly scrolls when held. i had to do this to fix another issue with files getting skipped, but i think this is ok, because the default behavior in my opinion was erratic ), the mouse hook allows for zoom in / out to work with scroll wheel alone and prevents the directory from switching images in the process, lastly, the left mouse click allows panning, although it will not work if you do it aggressively / or in quick strides, you have to do it slowly / carefully, otherwise it will draw a rectangular box / not work. DOWNLOAD LINK only available for up to 3 days... https://limewire.com/d/4P87k#qF7SWNakaW

ok back to the topic on patch9x and related stuff. for some odd reason, im getting the insufficient memory to initialize windows message on re-installing win95c. the difference is that this time im installing it on the same dell latitude d820 system but with the a10 bios, instead of the a07 bios i was using earlier, and also with freedos fdisk.exe ( roughly 35 GB partition ) with the "align_4k" option enabled via fdisk.ini file ( start sector apparently 64 ). other than that, not really any other significant differences i can think of. the most odd part is that the system.ini section after 1st setup phase was completely blank, now the system.cb was blank in all tested situations, which is apparently normal, but not the system.ini, so i thought ok, that shouldn't be a problem, i'll just add the necessary stuff which is the [386Enh] section and cregfix/maxphyspage stuff, and the same for system.cb. so i do that, then install fix95cpu v3.0, then re-apply patch9x ( since it's required to do so when using fix95cpu ) then when i reboot, it goes to the insufficient memory message. so im like, ok, this is strange, i go back and try to set even a lower maxphyspage of 5000, and even put a minfilecache=65556 ( same for maxfilecache ), no difference. also deleting cregfix.vxd and even deleting system.ini / system.cb still shows up as blank on the newly created ones on reboot, and cregfix message part in same screen as insufficient memory still shows. so i dont really know what to do. the only other thing i can think of is use a partition at 32 GB max or slightly less than it, but i dont see how this is related?

Turns out we don't need to do the major hacking, because the older webp.dll version from 4.32 plugins works on windows 98SE without kernelex and should only need "IsDebuggerPresent" patched for windows 95 (the newer 4.44 plugin is the one with more missing APIs and only works on 98SE with kernelex 4.5.2). I had chatgpt do the patching directly via uploading the 4.32 version. Since i have only 98SE installed currently, i cannot test the patched version, but i'll upload it here, in case anyone can test. Will be available to download for a few days. https://limewire.com/d/jgPVH#535Yo0hpaq

Some info on missing exports for gom player 2.1.43.5119 on a windows 95 osr 2.5 fully updated system: . gom.exe - user32.dll - - AnimateWindow, GetMonitorInfoA, MonitorFromRect . gomx.dll - d3d9.dll - Direct3DCreate9 . libavcodec.dll - kernel32.dll - InterlockedCompareExchange, InterlockedExchangeAdd . Mpeg2DecFilter.ax - kernel32.dll - IsDebuggerPresent. USER32.dll - ChangeDisplaySettingsExA, ChangeDisplaySettingsExW

I decided now to try to make Irfanview 4.44 work as an alternative, but faced many unexpected results, like no fully working autohotkey 1.0.48.5 / autoit 3.1.12.1 scripts, and almost half of the plugins in the package do not work. I did mention in my other thread on patch9x that i was able to work around the SSE2 instructions problem so it will at least open regular jpeg/jpg files, but there are still many things unresolved for my purpose of using the program. I do not plan on trying to make most of the non working ones work, i did several attempts with ghidra with chatgpt but was not able to get anything to work yet. My main focus is webp.dll which currently does not work. You can use some older versions for some of the plugins and they'll work, like jpeg2000.dll version 4.3.3.0, but a good remainder of plugins still do not work. Here is what's missing for unpacked webp.dll checked on a fully updated windows 95 osr 2.5 system: kernel32.dll missing exports ( implicitly dependent modules ): EncodePointer DecodePointer GetModuleHandleExW IsDebuggerPresent IsProcessorFeaturePresent SetFilePointerEx InitializeCriticalSectionAndSpinCount

For the ethernet, If you can, try to find a package that uses B57W9X for the inf with driver version 7.80. I had that working for "VEN_14E4&DEV_165D&SUBSYS_865D1028&REV_01" on 98SE.

Thanks for the referencing to SSE2, i got some help from chatgpt to make a patched i_view32.exe which now loads jpeg/jpg files without error ( redirects to MMX i believe instead of SSE2 for the problematic path, though i've only done limited testing. ), also working that previously didnt is .crw file. i removed vtf.dll from the plugins as it was the one causing the "isdebuggerpresent" problem when trying to check installed plugins. i may not patch that file because it's not really that important, more of a niche plugin anyways. will update more later on other stuff. Also im gonna attach the patched i_view32.exe for use on irfanview 4.44 on windows 9x ( windows 95 osr 2.5 or newer ), should be up for at least a few days to download. https://limewire.com/d/Rfwr7#NECTyRfjXh

Some other info below for config.sys profiles, also mem /c /p showed 10.8 KB of UMB and 600 KB of conventional memory free when using specifically the emm386.exe ram auto option below, the no good indicator means windows could not boot, it gave the insufficient memory message during boot. this is for testing with patch9x 0.9.91 + fix95cpu v3.0 and rloew's "patchmem /m" all installed from beforehand using maxphyspage=44796 and minfilecache/maxfilecache=52224. the NOEMS option doesn't work with patch9x apparently.: full config.sys sample "DEVICE=C:\WINDOWS\HIMEM.SYS /NUMHANDLES=62 /TESTMEM:OFF DOS=HIGH,UMB DEVICE=C:\WINDOWS\EMM386.EXE RAM AUTO ", last line substitutes below: DEVICE=C:\WINDOWS\EMM386.EXE NOEMS FRAME=NONE - NO GOOD DEVICE=C:\WINDOWS\EMM386.EXE NOEMS NOVCPI - NO GOOD DEVICE=C:\WINDOWS\EMM386.EXE RAM HIGHSCAN - GOOD DEVICE=C:\WINDOWS\EMM386.EXE RAM - GOOD DEVICE=C:\WINDOWS\EMM386.EXE RAM 1024 - GOOD DEVICE=C:\WINDOWS\EMM386.EXE RAM 2048 - GOOD DEVICE=C:\WINDOWS\EMM386.EXE RAM AUTO - GOOD

Thanks jumper, but im already past that point, your method could be a potential workaround for specific cases. I'm at a point where the system.ini settings probably aren't as relevant as so much trying to figure out what could be the culprit to the misc. problems i was having, like ms dos prompt in windows not being able to launch with vbemp driver, etc. It could be that patch9x + fix95cpu v.3.0 + patchmem just dont do well together. i think i can uninstall patchmem to see if that might help with specific problems, but honestly, at this point, im really just trying to get specific programs to work, for example, irfanview 4.38 / 4.44 both have major problems and i cant get keyman6-2-183-0 to launch it's keyman application, mentioning kernel32.dll missing export to isdebuggerpresent, ( keyman32.dll and keyman.exe were culprits as viewed by dependency walker ). also the same missing export kernel32.dll isdebuggerpresent was mentioned by irfanview 4.44 when trying to select the installed plugins menu, and it happens when using the full plugins for 4.38 as well. both irfanview versions fail for loading any jpg file / about page, giving precisely the same error. i really wanted to get at least 4.32 or newer to work of irfanview, because of the webp plugin for example. bmp files work without problem, i tested both without any plugins, but they still fail with jpg files, even using the thumbnail mode to browse a directory with jpg files crashes the system. here is the error specifically from irfanview 4.38: I_VIEW32 executed an invalid instruction in module I_VIEW32.EXE at 0157:004dceb0. Registers: EAX=00010001 CS=0157 EIP=004dceb0 EFLGS=00210202 EBX=007fd538 SS=015f ESP=007dbd78 EBP=007dbe40 ECX=00800930 DS=015f ESI=00800930 FS=3017 EDX=007fd190 ES=015f EDI=00000000 GS=2b7e Bytes at CS:EIP: 66 0f 6f 06 66 0f 6f 4e 20 66 0f d5 02 66 0f d5 Stack dump: 00000000 007fc990 007f4320 007dc0f0 007f4962 000013f6 00000000 0000000e 00000011 007f4320 bff713ee 00000157 bff78913 00000801 007dbdf0 000ee524

ok so i was able to get patchmem /m to work in a late update phase, because the vmm.vxd file became present. it mentioned something about skipping vmm32.vxd due to no backup?, but i was able to patch vmm.vxd at least. while i was able to now set maxphyspage higher to as much as 44796, i could not get vbemp driver to load unless using like 30000 ( with 44796, it just went to a black screen ), and even then, when i did reboot, upon reaching desktop, windows complained on not having enough memory, and to quit one or more programs, which i found very odd, because i dont remember if i ever encountered this problem in perhaps a decade of testing win9x stuff. i tried vbemp as low as 10000, min/maxfilecache to 52224, no change for the ms dos problem, but was fixed by changing back to the standard vga display adapter driver. also for example using the following in my config.sys ( tested at least with maxphyspage=30000 ) prevented booting to windows, mentioning that initializing error relating to memory, needing to quit one or more programs. "DEVICE=C:\WINDOWS\HIMEM.SYS /NUMHANDLES=62 /TESTMEM:OFF DOS=HIGH,UMB DEVICE=C:\WINDOWS\EMM386.EXE NOEMS", though the config.sys stuff i just referenced are more optional, i dont absolutely need them, it's more of a tweak. all in all, it seems to point to patch9x as the problem, and i haven't even tested patch9x on windows 98SE yet with or without patchmem, which i'd be doing soon. outside these things, other programs / functions were mostly ok, i was able to run for example hwinfo32 6.42, TaskInfo2002 v. 4.0.0.51, process explorer 8.52.

I am testing patch9x (jhrobotics) on a windows 95 osr 2.5 system with intel ich7-m chipset (dell latitude d820) with 4 GB ram. i was under the impression the patch9x would be roughly equivalent or better than patchmem from rloew, but unfortunately, it seems to be regressing in some areas. i specifically downloaded "patcher9x-0.9.91-boot.ima", used winimage to extract the contents, and only integrated the "patch9x.exe" + "CWSDPMI.exe" files in my custom 98SE boot disk iso burned to a cd, (patch9x needs to run from "a:" directory). The author of patch9x mentioned that fixes from patchmem were largely integrated with patch9x ( not fully ) but most stuff implemented and to work on w95 as well, at least in the most recent release 0.9.91, which is the one i am using, however, i cannot set maxphyspage at 40000 or higher, where as in the past with patchmem, i was able to get up to at least 48000 without problem. "maxphyspage=39999" or lower does work ( roughly 922 MB ram ). minfilecache and maxfilecache were set to 52224 throughout testing with "maxphyspage=30000" to at least up to "maxphyspage=48000". Additionally, i cannot run patchmem if patch9x already gets installed from beforehand which i do for install media ("c:\win95") in this case before running setup. i was thinking that maybe i could get the best of both worlds for combining the patches, but this doesn't appear to be possible. running "patchmem /m" says something about vmm32.vxd already being patched and vmm.vxd not found. i searched vmm.vxd in both my install media and c: drive and could not locate such file, only vmm32.vxd is present.

I was able to figure out the main issue after chatgpt referenced boot image related stuff. essentially it was not using the actual modified stuff, because i wasn't providing the .img/.ima base file from beforehand when creating the boot media via the software i was using. i know you did mention about this earlier, but i didn't understand what that meant exactly in my context. for those starting with just the 98SE boot disk iso, you'll need winimage + ultraiso and / or anyburn, but if you already have a stock 98SE boot image in .img form, then all you need is ultraiso i believe. i had chatgpt write a short guide on this, but i'm also providing the boot disk in .ima form already + my modified 98SE boot disk iso already made as attachments for some time so people can download and use / test, though i haven't been able to test the iso one's actual functionality, because i only have unsupported systems at the moment that are incompatible, like "hp 14-dq0054dx" using an external usb optical drive, shows as no fixed drive present, AHCI not loaded, etc. the boot disk doesn't support NTFS. It is essentially stock 98SE boot disk + CTMOUSE, AHCICDA.SYS, HimemX2, JEMM386.EXE, UIDE.SYS, modified autoexec.bat/config.sys/setramd.bat. https://limewire.com/d/Dq2t6#JQjSz1GzN9 SHORT VERSION for creating bootable el torito cd iso using extracted modified files injected into ultraiso + stock 98SE boot disk .ima file: CLEAN SHORT METHOD (what you want) You already have: - Stock Win98SE boot .IMG (good boot sector) - Modified boot files (CONFIG.SYS / AUTOEXEC.BAT / drivers) - ISO content (WIN98 folder / CAB files etc.) STEP 1: Open the .IMG in WinImage and make sure your modified CONFIG.SYS and AUTOEXEC.BAT are inside it. Save the .IMG. STEP 2: Open UltraISO. STEP 3: File -> New -> Data CD/DVD Image STEP 4: Drag and drop the Windows 98 CD files into the ISO project: - WIN98 folder - CAB files - SETUP.EXE (if present) STEP 5: Bootable -> Load Boot File Select your modified Win98SE boot .IMG STEP 6: File -> Save As Choose: Standard ISO (*.iso)

I burned the 98SE boot disk iso onto a cd and booted it via internal optical drive ( sata in ide mode ) on the Hp probook 6460b. I have used this method on other computers without problem, of course, almost all of them were much older ( usually no newer than ich6 ) and usually the connection was pure ide, not sata in ide mode.