[PROBLEMCHYLD]

[FMC]Ravage, on 16 February 2013 - 09:02 PM, said:

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.

[FMC]Ravage, on 16 February 2013 - 09:02 PM, said:

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.

[FMC]Ravage, on 16 February 2013 - 09:02 PM, said:

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.

[[FMC]Ravage]

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

Quote

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).

Quote

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.

This post has been edited by [FMC]Ravage: 17 February 2013 - 11:09 AM

[rloew]

[FMC]Ravage, on 17 February 2013 - 10:48 AM, said:

Quote

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.

[rloew]

TmEE, on 17 February 2013 - 07:44 AM, said:

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.

[TmEE]

That BIOS has no options on that regard, if there were I'd not be having any problems.

[[FMC]Ravage]

rloew, on 17 February 2013 - 12:33 PM, said:

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?

This post has been edited by [FMC]Ravage: 17 February 2013 - 04:39 PM

[LoneCrusader]

[FMC]Ravage, on 17 February 2013 - 04:36 PM, said:

rloew, on 17 February 2013 - 12:33 PM, said:

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.

This post has been edited by LoneCrusader: 17 February 2013 - 04:50 PM

[[FMC]Ravage]

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)

This post has been edited by [FMC]Ravage: 17 February 2013 - 06:56 PM

[rloew]

[FMC]Ravage, on 17 February 2013 - 04:36 PM, said:

rloew, on 17 February 2013 - 12:33 PM, said:

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.

Quote

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.

[[FMC]Ravage]

That clears things up, thanks.

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

This post has been edited by [FMC]Ravage: 18 February 2013 - 12:00 AM

[PROBLEMCHYLD]

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

[[FMC]Ravage]

Awesome, I'll test 'er out in the morning

[rloew]

[FMC]Ravage, on 17 February 2013 - 11:20 PM, said:

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.

[[FMC]Ravage]

@ rloew
So that's why I couldn't find it I'll have to adjust my install a little bit for the newer vmm file. I just assumed it was a custom mod too.

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

[PROBLEMCHYLD]

[FMC]Ravage, on 18 February 2013 - 11:49 AM, said:

@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

[PROBLEMCHYLD]

You guys will be happy to know I have UHCD.SYS 5.0.2195.6882 from Windows 2000 SP4 hotfix working

[bphlpt]

Cheers and Regards

[bphlpt]

As requested, here are some sample of the "START" with "Second Edition" added. Please specify font and color preference. I can probably use any font or color you like, but it would be most helpful if you can provide a sample with exact name of font and/or color or color code number, (since I'm a little color blind).

I've used Black (Almost impossible to see against the dark Blue), Red and White, with font choices of Ariel, Corbel, and Sans, just to get us started.

I can manipulate both character spacing and the slide the text around as necessary, but I think the font size of 16 is about right to my eyes.

Please let me know what you think.

Cheers and Regards

Attached File(s)

•  START-Arial16Black.JPG (2.53K)
  Number of downloads: 6
•  START-Arial16Red.JPG (3.38K)
  Number of downloads: 2
•  START-Arial16White.JPG (3.18K)
  Number of downloads: 2
•  START-Corbel16Black.JPG (2.45K)
  Number of downloads: 3
•  START-Corbel16Red.JPG (3.06K)
  Number of downloads: 4
•  START-Corbel16White.JPG (2.89K)
  Number of downloads: 6
•  START-Sans16Black.JPG (2.59K)
  Number of downloads: 4
•  START-Sans16Red.JPG (3.55K)
  Number of downloads: 2
•  START-Sans16White.JPG (3.34K)
  Number of downloads: 4

[Drugwash]

The JPG format is of no use for this particular purpose, especially being lossy - the format must be BMP, since it has to be hacked into explorer.exe as the BITMAP resource with ID 157.

Another thing is that the gradient should be calculated so that the bitmap viewed in 4bpp (in situations where video driver is missing or inappropriate) would not "split" the first word or otherwise look unaesthetical.

One other detail, albeit minor, would be resource 161, which is loaded in Safe Mode instead of resource 157. That's a grey-shaded image, much shorter than 157, but nevertheless it could be hacked into showing Second Edition somehow.

I've played with res 157 a few days ago but never got to post the results. Banner3.bmp would be the best bet, since it's the only one that takes into account the 4bpp aspect.
Here you are: download.

[bphlpt]

I like your versions much better than mine. LOL

I was just editing a jpg that PROBLEMCHYLD posted. But you look like you have a much more appropriate solution.

Cheers and Regards