Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.Login to AccountCreate an Account

Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

LoneCrusader

Posted 04 January 2013 - 09:17 PM

Thanks, the only files that end in "O20" are shown in the attached file.

Peter

Ok, that's fine. The ones that I referred to in \VMM32 "IF any ... are there" would only be there in the event that they had been updated since the original installation was done. Otherwise they are already packed into VMM32.VXD.

What's the version number of the VMM.O20 that was present? It's the only one that falls into this category it seems. Interesting, had you updated this file before?

peter777

Posted 04 January 2013 - 10:40 PM

peter777

Junior

Member

59 posts

Joined 15-November 12

OS:XP Pro x86

Country:

The manual uninstall went okay, but Windows is running in MS-DOS mode now. It also said the MBR was modified - possible virus. I used to run AVG on this W95 box, but it's no longer updated. Also, can't uninstall AVG for some reason.

There are intermitant hangs, but could be the display driver, it doesn't have the correct drivers yet. Great that the W95B is back again though, thanks very much for your help.

[What's the version number of the VMM.O20 that was present? It's the only one that falls into this category it seems. Interesting, had you updated this file before?

I don't think I would have updated that file, but the 'patch' for using extra ram does I think. The files are

LoneCrusader

Posted 04 January 2013 - 11:54 PM

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

peter777

Posted 05 January 2013 - 12:32 AM

peter777

Junior

Member

59 posts

Joined 15-November 12

OS:XP Pro x86

Country:

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.

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.

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.

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.

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

LoneCrusader

Posted 05 January 2013 - 01:17 AM

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

LoneCrusader

Posted 05 January 2013 - 01:58 AM

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

Posted 05 January 2013 - 03:41 AM

peter777

Junior

Member

59 posts

Joined 15-November 12

OS:XP Pro x86

Country:

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.

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.

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.

LoneCrusader

Posted 06 January 2013 - 03:56 AM

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

Posted 06 January 2013 - 06:01 PM

peter777

Junior

Member

59 posts

Joined 15-November 12

OS:XP Pro x86

Country:

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.

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.

submix8c

Posted 07 January 2013 - 12:11 PM

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

LoneCrusader

Posted 07 January 2013 - 11:30 PM

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

Posted 10 June 2013 - 10:04 PM

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.

xTMODx

Posted 12 April 2014 - 06:24 AM

xTMODx

Member

3 posts

Joined 10-April 14

OS:Windows 8.1 x64

Country:

Hi i have still a problem installing win95 on my machine

after the first reboot during installation, i put the disc with fix95cpu and do the process. Then i reboot put the win95 cd in the drive and let it boot, then there is "Windows wird gestartet..." (Windows is starting) for a second or two, after that the windows 95 logo appear and after that i get "Windows-Schutzfehler. Starten Sie den Computer neu." (Windows protection error. You need to restart your computer).

LoneCrusader

Posted 14 April 2014 - 04:19 PM

after the first reboot during installation, i put the disc with fix95cpu and do the process. Then i reboot put the win95 cd in the drive and let it boot, then there is "Windows wird gestartet..." (Windows is starting) for a second or two, after that the windows 95 logo appear and after that i get "Windows-Schutzfehler. Starten Sie den Computer neu." (Windows protection error. You need to restart your computer).

My mainboard is the Asus P4V533-MX with Pentium 4 3,06GHz (SL6PG).

Would be greast if someone could help me.

xTMODx

Could you please provide more detailed specs for your machine? How much RAM are you using?

xTMODx

Posted 14 April 2014 - 06:33 PM

xTMODx

Member

3 posts

Joined 10-April 14

OS:Windows 8.1 x64

Country:

Hi i have still a problem installing win95 on my machine

after the first reboot during installation, i put the disc with fix95cpu and do the process. Then i reboot put the win95 cd in the drive and let it boot, then there is "Windows wird gestartet..." (Windows is starting) for a second or two, after that the windows 95 logo appear and after that i get "Windows-Schutzfehler. Starten Sie den Computer neu." (Windows protection error. You need to restart your computer).

My mainboard is the Asus P4V533-MX with Pentium 4 3,06GHz (SL6PG).

Would be greast if someone could help me.

xTMODx

Could you please provide more detailed specs for your machine? How much RAM are you using?