[LoneCrusader]

Ok, I don't know how these things have gotten "derranged" from their original configuration, but it may explain why you had problems with XUSBSUPP.

From the dates of the files, it looks like the VMM32 and VMM files still on your system were the "patched" copies used by the Demo RAM patch. I don't know how these files remained there if you had it uninstalled it when you first ran XUSBSUPP, but nonetheless they remained.

The RAM patch must be removed from the system first, as XUSBSUPP will update files patched by the RAM patch, and break the RAM patch. (And apparently itself in the process.)


Copy VMM32.O20 and VMM.O20 from your backup to your Windows 95 machine. See if VMM.O20 has a "Version" Tab under Properties. (Note this only shows under 9x, .VXD files' Version Tab doesn't work under XP.) If it doesn't then you can simply delete it. If it does, then tell me the file version.


Now, under your other OS, rename the current VMM32.VXD dated 11/27/12 to VMM32.ERR and replace it with the VMM32.O20 dated 7/5/05 from your backup.

EDIT: Also delete any VCACHE.VXD, VCACHE.BAK, or VCACHE.xxx files and replace it with a copy of the one from the HotFix that we directed you to when we started work on this.

See if this stops the hangups and the MS-DOS mode issues.


Second EDIT:
If VMM.O20 from the backup, and VMM.VXD currently on your machine do NOT have Version Tabs under 95, then Delete BOTH of them. (Note VMM.VXD not VMM32.VXD, VMM32.VXD will NEVER have a Version Tab.)

This post has been edited by LoneCrusader: 05 January 2013 - 12:14 AM

[peter777]

LoneCrusader, on 04 January 2013 - 11:54 PM, said:

Copy VMM32.O20 and VMM.O20 from your backup to your Windows 95 machine. See if VMM.O20 has a "Version" Tab under Properties. (Note this only shows under 9x, .VXD files' Version Tab doesn't work under XP.) If it doesn't then you can simply delete it. If it does, then tell me the file version.

The files that were backed up are on a 'headless' box at present, so I skipped this step, to do later, as it only determines version numbers.

LoneCrusader, on 04 January 2013 - 11:54 PM, said:

Now, under your other OS, rename the current VMM32.VXD dated 11/27/12 to VMM32.ERR and replace it with the VMM32.O20 dated 7/5/05 from your backup.

There was one named VMM32.BAD with 7/5/05, so I used that one.

LoneCrusader, on 04 January 2013 - 11:54 PM, said:

EDIT: Also delete any VCACHE.VXD, VCACHE.BAK, or VCACHE.xxx files and replace it with a copy of the one from the HotFix that we directed you to when we started work on this.

There was only one found, and I replaced it with the file from the hotfix.

LoneCrusader, on 04 January 2013 - 11:54 PM, said:

See if this stops the hangups and the MS-DOS mode issues.

MS-DOS mode still exists.

It's been booted up for 15 mins now, and no hang though.

Oops, ..spoke too soon.

LoneCrusader, on 04 January 2013 - 11:54 PM, said:

Second EDIT:
If VMM.O20 from the backup, and VMM.VXD currently on your machine do NOT have Version Tabs under 95, then Delete BOTH of them. (Note VMM.VXD not VMM32.VXD, VMM32.VXD will NEVER have a Version Tab.)

Okay thanks,

Peter

This post has been edited by peter777: 05 January 2013 - 12:36 AM

[peter777]

I do have XP Pro on another computer. Maybe I should look at getting Works, Office, Money for XP, and then the W95B files can at least be converted.

[LoneCrusader]

Ok, is the hard drive currently in the "new" computer or the "old" computer? I'm so confused...

It needs to be back in the old computer in order to get everything straightened out. Once that's done, then you can make another good backup and we can try again if you want to.

Having the HDD in the new computer for this has been a disaster.



Right now we need to get all traces of XUSBSUPP and the Demo RAM patch removed.
(I'm going to assume that the VMM.VXD was from the RAM patch judging by its date. Delete it.)


Did the Uninstall of XUSBSUPP from Add/Remove programs work properly after you had done the manual part? (It should have asked you to restart?)


So now you should have:

C:\WINDOWS\SYSTEM\VMM32.VXD dated 2005,
VCACHE.VXD extracted from the HotFix,
and there should NOT be any VMM.VXD under C:\WINDOWS\SYSTEM\VMM32\

Does all that check out?

This post has been edited by LoneCrusader: 05 January 2013 - 12:45 AM

[LoneCrusader]

I do have some ideas about the other issues you're having, but we need to get "back to where we were" so to speak before they can be addressed.

If the things we're doing don't fix it, the MS-DOS mode may be caused by all of the devices being removed and/or drivers not being reloaded. Also, if the HDD is in the "new" computer, then BIOS settings with regard to the SATA ports on your motherboard might cause it.

Also, the loading of EMM386.EXE may be contributing to you not being able to access Normal Mode with the Demo RAM patch on the new machine. (I will leave that for others more knowledgeable to comment on, but I remember seeing others describe issues with it.)

Note all of this is conjectural at the moment.

This post has been edited by LoneCrusader: 05 January 2013 - 01:19 AM

[peter777]

LoneCrusader, on 05 January 2013 - 12:42 AM, said:

Ok, is the hard drive currently in the "new" computer or the "old" computer? I'm so confused...

The HDD is in the old computer.

LoneCrusader, on 05 January 2013 - 12:42 AM, said:

It needs to be back in the old computer in order to get everything straightened out. Once that's done, then you can make another good backup and we can try again if you want to.

I'm aware that this is taking up a lot of your time. Possibly one last try, and then I might look at the XP Pro solution I mentioned.

LoneCrusader, on 05 January 2013 - 12:42 AM, said:

Did the Uninstall of XUSBSUPP from Add/Remove programs work properly after you had done the manual part? (It should have asked you to restart?)

Yes, that worked fine, and I did a restart afterwards.

LoneCrusader, on 05 January 2013 - 12:42 AM, said:

So now you should have:

C:\WINDOWS\SYSTEM\VMM32.VXD dated 2005,
VCACHE.VXD extracted from the HotFix,
and there should NOT be any VMM.VXD under C:\WINDOWS\SYSTEM\VMM32\

Does all that check out?

Yes, that all checks out, the file from the hotfix is 41 KB and dated 10/31/97. The computer boots up okay, and is in MS-DOS mode.

Peter

[LoneCrusader]

peter777, on 05 January 2013 - 01:42 AM, said:

The HDD is in the old computer.

I'm aware that this is taking up a lot of your time. Possibly one last try, and then I might look at the XP Pro solution I mentioned.

Yes, that worked fine, and I did a restart afterwards.

Yes, that all checks out, the file from the hotfix is 41 KB and dated 10/31/97. The computer boots up okay, and is in MS-DOS mode.

Peter

Ok, things are looking up.

I believe we have successfully removed the Demo RAM patch and XUSBSUPP. There should not be any more files left with .O20 extensions, and you should remove any remaining files we have used/altered such as VMM32.ERR, and leave only a backup copy of the 2005 VMM32.VXD, named VMM32.ORI. (Be sure to use that name, as XUSBSUPP uses the .O20 extension, and the RAM patch uses .BAK, so .ORI leaves us with an extension that will not be altered, deleted, or overwritten by any update.)

Does the computer still hang now that we have reached this step, or have we stopped that?


Now, as you encountered errors while the HDD was still in the "new" machine, and had to transplant it again, it is probably a good idea to go into Safe Mode and remove all of the devices from the Device Manager again to ensure that no devices detected on the "new" machine are still present. Then Reboot, and allow the machine to install drivers for the older hardware.

If you get any prompts about missing files, try manually directing the installer to C:\WINDOWS\OPTIONS\CABS or C:\WINDOWS\SYSTEM, if the required files are still not found, try other "logical" locations under C:\WINDOWS. If any are still not found, make note of what files they are and what device was requesting them if possible.

Hopefully this will correct the MS-DOS Mode issue and get you back to where you were.

Let me know the results. I must go soon for tonight though, as I have to work in the morning.

[peter777]

LoneCrusader, on 05 January 2013 - 01:58 AM, said:

I believe we have successfully removed the Demo RAM patch and XUSBSUPP. There should not be any more files left with .O20 extensions, and you should remove any remaining files we have used/altered such as VMM32.ERR, and leave only a backup copy of the 2005 VMM32.VXD, named VMM32.ORI. (Be sure to use that name, as XUSBSUPP uses the .O20 extension, and the RAM patch uses .BAK, so .ORI leaves us with an extension that will not be altered, deleted, or overwritten by any update.)

Yes, that is all as you have described.

LoneCrusader, on 05 January 2013 - 01:58 AM, said:

Does the computer still hang now that we have reached this step, or have we stopped that?

Yes, it still hangs, and quite a few blue screens.

LoneCrusader, on 05 January 2013 - 01:58 AM, said:

Now, as you encountered errors while the HDD was still in the "new" machine, and had to transplant it again, it is probably a good idea to go into Safe Mode and remove all of the devices from the Device Manager again to ensure that no devices detected on the "new" machine are still present. Then Reboot, and allow the machine to install drivers for the older hardware.

Okay, I have done that, but it hung on installing new drivers. I could still use the mouse (move it), but the computer kinda 'froze', and many blue screens.

Thanks very much for all your help in this. I will have to try the XP Pro option.

Thanks,

Peter

[LoneCrusader]

peter777, on 05 January 2013 - 03:41 AM, said:

Yes, it still hangs, and quite a few blue screens.

Okay, I have done that, but it hung on installing new drivers. I could still use the mouse (move it), but the computer kinda 'froze', and many blue screens.

Thanks very much for all your help in this. I will have to try the XP Pro option.

Thanks,

Peter

I don't know why the system would suddenly start behaving like that. Something else must have been altered or corrupted somewhere along the line. I'm suspicious of that point you noted about how the "Boot Sector" had been modified... I think that the filesystem may have been adversely affected by having to move the drive around so much and/or having to mount it under different OS'es. Sometimes that can cause "glitches" due to different methods of handling; I've seen odd behavior on FAT32 partitions that I had shared between 98SE, XP, and Linux before.

At this point I don't know what else to try. If you ever want to take a crack at it again with a fresh Windows 95 install then I'll be glad to help you any way I can.

[peter777]

LoneCrusader, on 06 January 2013 - 03:56 AM, said:

I don't know why the system would suddenly start behaving like that. Something else must have been altered or corrupted somewhere along the line. I'm suspicious of that point you noted about how the "Boot Sector" had been modified... I think that the filesystem may have been adversely affected by having to move the drive around so much and/or having to mount it under different OS'es. Sometimes that can cause "glitches" due to different methods of handling; I've seen odd behavior on FAT32 partitions that I had shared between 98SE, XP, and Linux before.

Certainly something must have happened to the MBR, possibly that is why it continued to run in MS-DOS mode under Windows.

LoneCrusader, on 06 January 2013 - 03:56 AM, said:

At this point I don't know what else to try. If you ever want to take a crack at it again with a fresh Windows 95 install then I'll be glad to help you any way I can.

Thanks very much for all your help. As the Win95B is basically unstable, now I'll try converting the files under XP Pro. Hopefully they will convert okay.

Regards,

Peter

This post has been edited by peter777: 06 January 2013 - 06:02 PM

[submix8c]

peter777, on 06 January 2013 - 06:01 PM, said:

Certainly something must have happened to the MBR, possibly that is why it continued to run in MS-DOS mode under Windows.

You initially said AVG (not updated) found and "fixed" it. A version that works on Win95b? Maybe IT goobered the MBR. And I highly doubt that MBR has anything to do with MSDOS-mode. Some PC's need an INF/Registry entry to enable UDMA. I'm not sure if 95b can do more than UDMA33 (LoneCrusader can answer that?).

As far as the MBR

fdisk /mbr

from a 95b/c EBD or "F8->Command Prompt Only"

[peter777]

Thanks for your reply. Have now copied files to XP Pro computer, and wiped WIN95B.

[rloew]

@peter777: Are you using the /M Option in my Demo Patch?

[peter777]

@rloew - I have deleted all the WIN95B OS now, thanks for the use of your RAM patch though.

[LoneCrusader]

submix8c, on 07 January 2013 - 12:11 PM, said:

I'm not sure if 95b can do more than UDMA33 (LoneCrusader can answer that?).

Actually I had never really thought about it. I would think that this is more a "hardware" issue than a "software" one. Maybe rloew could give a definite answer... I know he has run 95 on SATA drives with his patch, and I have run 95 on P4/IDE ATA100 boards so I doubt there is actually a "software" limitation here, unless logically it would be the upper limits of IDE BUS speed.

[LoneCrusader]

EDIT 06-10-2013:
THIS LINK IS NOW TO THE OLD VERSION 2.0. SEE THE NEXT POST, OR THE FIRST POST OF THIS THREAD FOR THE NEW VERSION 3.0.

Due to reported problems with MDGx's website , Drugwash has kindly provided a new download link for FIX95CPU.

This will be in effect until we find out what is going on...

This post has been edited by LoneCrusader: 10 June 2013 - 10:00 PM

[LoneCrusader]

FIX95CPU has been updated to version 3.0.
Get the new version here.

See the first post of this topic for what's new in this version. If you have already successfully installed FIX95CPU on Windows 95 OSR2, there is no need to update. This new version mainly addresses issues specific to Windows 95 RTM.

Special thanks to TmEE for hosting the new version.

This post has been edited by LoneCrusader: 10 June 2013 - 10:04 PM