Jump to content

98 SE SP 3.32


Gape

Recommended Posts

Ravage' timestamp='1361070125' post='1030204']

Thanks, glad to help :)

Some other bugs/ideas:

When installing TrueType Fonts, there's some file not found error messages (might be normal, see attached image)

This is not a BUG, you can ignore this.
Ravage' timestamp='1361070125' post='1030204']

Make esdi_506.pdr, vmm.vxd, and vcache.vxd optional for rloew patch users

There is no need, these files DoNOT conflict with rloew patches.
Ravage' timestamp='1361070125' post='1030204']Include the updated disk tools (http://www.mdgx.com/files/BHDD31.ZIP)
The only thing need from this pack is the updated defrag and scandisk. All other files are already included.
Link to comment
Share on other sites


I thought the font thing might just be clean up or something, good to know for sure.

There is no need, these files DoNOT conflict with rloew patches.

They overwrite them though. I have rloew's high capacity & sata patches applied to esdi_506.pdr. AFAIK, the one in the pack doesn't support sata drives. If I dont restore it before windows starts up, the system becomes unbootable.

As for the memory files, I have a gigabit lan and a 256mb video card, so I have to run some special switches (with rloews patchmem) in order to get everything stable. I don't know if the files in the pack have the same tweaks applied (i've always just restored them to be safe).

The only thing need from this pack is the updated defrag and scandisk. All other files are already included.

Yeah thats what I meant (scandisk, defrag, and the disk maintenance dll). Very useful for bigger hard drives.

Edited by [FMC]Ravage
Link to comment
Share on other sites

Ravage' timestamp='1361119694' post='1030269']
There is no need, these files DoNOT conflict with rloew patches.

They overwrite them though. I have rloew's high capacity & sata patches applied to esdi_506.pdr. AFAIK, the one in the pack doesn't support sata drives. If I dont restore it before windows starts up, the system becomes unbootable.

As for the memory files, I have a gigabit lan and a 256mb video card, so I have to run some special switches (with rloews patchmem) in order to get everything stable. I don't know if the files in the pack have the same tweaks applied (i've always just restored them to be safe).

The SP definitely does conflict with these Patches. The SP only installs the LLXX High Capacity Patch and the Memory Workaround. The SATA Patch and the /M Option of PATCHMEM is definitely not duplicated. Available RAM will be limited to ~1GiB.

The Patches can be integrated with the current SP by uninstalling them, installing the SP, and then reinstalling them without rebooting Windows.

The Memory Workaround must also be removed to regain access to the full RAM.

Link to comment
Share on other sites

I got that problem too when I leave in my USB memory card reader. Then I get 4x drives in the middle of existing, disrupting my drive layout. One day I'll look into my BIOS and add a hack to make mounting USB devices optional...

There may be a BIOS option to stop USB Devices from being mounted. I also have a Driver Letter Remapper that can stabilize the Letter assignments.

Link to comment
Share on other sites

The Memory Workaround must also be removed to regain access to the full RAM.

Is that in the system.ini file? Because I looked for MaxPhysPage/MaxFileCache entires in it after installing the pack and couldn't find any.

Right now I just use a floppy to restore those 3 files (vmm, vcache, and esdi_506) after installing the pack. Is that sufficient or am I not fully restoring it?

Edited by [FMC]Ravage
Link to comment
Share on other sites

Ravage' timestamp='1361140578' post='1030298']

The Memory Workaround must also be removed to regain access to the full RAM.

Is that in the system.ini file? Because I looked for MaxPhysPage/MaxFileCache entires in it after installing the pack and couldn't find any.

Right now I just use a floppy to restore those 3 files (vmm, vcache, and esdi_506) after installing the pack. Is that sufficient or am I not fully restoring it?

I'm fairly certain rloew is referring to the VCACHE.VXD v4.10.2223 that is installed by the uSP. It is an unofficial "workaround" version and would be incompatible with the RAM Limitation Patch.

I would recommend you follow rloew's instructions for removing and reinstalling the RAM patch after the uSP rather than trying to restore it manually. The uSP updates VMM.VXD, which is a good thing, and it would need to be patched rather than the older VMM.VXD extracted from VMM32.VXD.

Basically, if you plan to use the RAM Limitation Patch, you WANT the VMM.VXD installed by the uSP. You do NOT WANT the VCACHE.VXD installed by the uSP.

I believe PROBLEMCHYLD removed the other RAM tweaks from the uSP. :yes:

Edited by LoneCrusader
Link to comment
Share on other sites

Ravage' timestamp='1361140578' post='1030298']

The Memory Workaround must also be removed to regain access to the full RAM.

Is that in the system.ini file? Because I looked for MaxPhysPage/MaxFileCache entires in it after installing the pack and couldn't find any.

Right now I just use a floppy to restore those 3 files (vmm, vcache, and esdi_506) after installing the pack. Is that sufficient or am I not fully restoring it?

I tested an older version of the SP, so I had not verified that SYSTEM.INI changes were removed.

Replacing the three files is sufficient to restore the original Patched Files.

If you want the newer VMM.VXD and VCACHE.VXD, you can use the procedure I described previously to Patch them.

The SP Version of VCACHE.VXD is compatable but will interfere with Installation/Uninstallation unless you ignore it by using:

PATCHMEM <options> * * -

You may want to get an unmodified VCACHE.VXD 2223 and overwrite the one placed by the SP before Reinstalling my Patch.

Oh ok

1 more question. Will rloew's app patch the updated vmm.dll file if its just sitting in the vmm32 folder? (as it normally gets it from vmm32.vxd)

Definitely.

PATCHMEM checks if VMM.VXD and VCACHE.VXD already exist, and only extracts them if they don't.

VMM.VXD updates preexisted the development of PATCHMEM, so I provided for them.

The PATCHMEM Uninstaller will also not remove them if they existed before they were Patched.

Link to comment
Share on other sites

Thanks rloew and LoneCrusader. Since I don't have any of rloew patches ATM, there is no way I can come up with a workaround. Users that have his patches, will have to comeup with their own solution/workaround. Sorry guys. rloew is probably the best solution since he has the patches and able to test the SP. New update just released :thumbup

Link to comment
Share on other sites

Ravage' timestamp='1361164839' post='1030312']

That clears things up, thanks.

Edit: Do you know where I can find an unmodified vcache.vxd file? (didn't have much luck searching)

I found only the patched version on MDGX's website so I downloaded and analyzed it.

I determined the Patch author bumped the Version Number, so there is no original 2223 Version.

So you can stick with the original Version.

If integrating the SP, for the updated VMM, with my Patches, as described before, remove the VCACHE.VXD file installed by the SP before Reinstalling my Patches.

If not, just use the Version on your backup Disk.

Link to comment
Share on other sites

Ravage' timestamp='1361209754' post='1030367']

@PROBLEMCHYLD

My KVM is working great now, no hotplug issues. Nice work!

Its great that users has particular hardware and software to test the flaws in SP. The Service Pack can and will improve from this point with the help of you testers. Thanks and enjoy 3.17 :yes::w00t::lol::D
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...