[PROBLEMCHYLD]

RFMaster

We need your patch to do the following, I was in a rush yesterday

Patch Original VMM.VXD 4.10.2222 - if not present extract from VMM32.VXD or patch VMM.VXD file inside the VMM32.VXD

Patch Hotfix VMM.VXD 4.10.2226 if exist

Patch Original VCACHE.VXD 4.10.2222 if exist if not present extract from VMM32.VXD or patch VCACHE.VXD file inside the VMM32.VXD

Skip patching for VCACHE.VXD 4.10.2223 if detected - its already patched

Patch Original VMM32.VXD and any system VMM32.VXD

Add newer version after file has been patched.

With all of this you should NOT need a new patch. This covers the different version and different methods.
Some people with have the needed files inside their VMM32 folder and some will have rebuild their VMM32.VXD file with no files in the VMM32 folder. I will also remove VCACHE.VXD 4.10.2223. Your patch should cover everything and everything combination.

[RFMaster]

VCACHE.VXD 4.10.2223 if detected - its already patched

My patcher do not care about vcache, it works without vcache.

[PROBLEMCHYLD]

My patcher do not care about vcache, it works without vcache.

This was part of the misunderstanding earlier on in this thread. Its good to know, your patcher will be superior and cover every combination.
Another reason I'm removing VCACHE.VXD, there is no reason to have a patched VMM.VXD and VCACHE.VXD when they both do the same thing. Now its time to go to the liquor store and get fucked up. Thanks again friend.

[danikayser84]

I'd be curious as to whether a similar patch could be created or adapted for Windows 95 OSR2 or Windows Me as well? Always wanted to try Windows 95 with 4GB ;) Needless to say, nice work with the patch :D Might give it a try on my Dell Inspiron 8200 (doing a dual boot of 98SE and XP on it perhaps)

[Jimmyjam]

I just tried RFMaster's patcher on a machine containing a Gigabyte board and got a VFAT error on bootup in Win98SE. iirc this usually means it couldn't find enough free space in the first 16MB of RAM to load the filesystem driver. This isn't too surprising, considering how large the memory table must be if it's now looking after multiple GB of RAM.

Is there some way to relocate the VXDs somewhere else in memory, since they're being patched anyway? The VMM files themselves are quite large and normally get loaded into the first 16MB.

[Steven W]

Jimmyjam, I haven't tried RFMaster's latest patches, but for the sake of thoroughness, would you give us details on your hardware and what all you've done to patch the files? If my understanding is correct, his latest patch works on VMM32.vxd while it's on the system, meaning it could potentially affect the other VXDs that are packed into it. I can't help but wonder if there could have some issue created with VFAT.vxd inadvertently created by patch.

I'm sure RFMaster might have a better clue and may tell me that I'm full of shit. Perhaps those testing the patch now should back up the original files first, RFMaster considers it "Beta" after all.

Backing up could be good for testing and resolving issues too.

[Jimmyjam]

I definitely keep backups of files that'll be altered by unofficial fixes or patches. I also have the HDD imaged to a network drive in case the install completely buys the farm. I strongly recommend backing up to anyone who intends to mess with their system files.

Let's see... The machine has:
Gigabyte GA-P35-DS3L mainboard
3x1GB DDR2 memory modules
Nvidia Geforce 7600GT PCIe
Agere 56k faxmodem PCI
Sound Blaster Live! PCI (sadly no DDMA on the ICH9 southbridge for SB16 emu)
IDE DVD-RW (LG) & 80GB HDD, and a 3.5" floppy.
SATA controller and on-board sound both disabled in BIOS to avoid any possible conflicts since they're unused anyway.

I know AGP memory can cause issues by being in the wrong place at the wrong time as well, but the 7600 is a PCI device as far as Win98 is concerned and I don't have an AGP board on hand to test to see if it manages things differently.

I expect the error would have been a lot more bizarre if the patch actually corrupted VFAT.VXD in any way. As it stands Windows just can't load the thing into memory and halts.

[Steven W]

I know AGP memory can cause issues by being in the wrong place at the wrong time as well...

That's a possible issue some may have to deal with.

I realize it's a long shot, but since you have the originals can you use VXDLib to extract VFAT.vxd from your original vmm32.vxd put it in the VMM32 folder and see if that works. Probably won't, but worth a shot.

Links to VXDLib and other tools at MDGx's wonderful site:

REMOVED BY MODERATOR: Hyperlink. DUTCH LAW DOES NOT ALLOW HYPERLINKING TO WAREZ MATERIAL.

and we have a bit of discussion here:

http://www.techtalk.cc/viewtopic.php?f=30&t=519

[Steven W]

Another question that seems reasonable to ask, is how did you boot in the first place? Did you limit RAM somehow? With software? Remove RAM?

You know what I mean. If you did it with software, did you remove that software after running the patch?

[Jimmyjam]

Just XMS ramdisk and system.ini kludges.

Initial installation was done with a single 512MB memory module installed, then changed to 3x1GB later.
HIMEMX and XMS ramdisk run before Win98 boots, creating a 2GB ramdisk at the end of physical memory.
Modified MaxPhysPage and Vcache settings in system.ini to prevent Windows from using too much of the remaining 1GB, or the cache going haywire.

The resulting system ran well, except I can't put the swap file on the ramdisk as I'd prefer without causing it to switch over to MS-DOS compatibility mode. RFMaster's patch seems like a more elegant solution.

In preparation for the VMM patch I REM'ed out HIMEMX/ramdisk and removed the MaxPhysPage line from system.ini. I left the Vcache limits in because they shouldn't have any impact on what the patch does and I'm not aware that the patch fixes the vcache bug.