LoneCrusader

Windows 95 2.1GHz CPU Limit BROKEN!

272 posts in this topic

@ BeatZero

Any new developments with the slipstreamer? :)

hi!

integrated the Winsock2, I am doing testing ... put the results soon ;)

some other important update that we could add? or something that supports a lot of memory (1gb), I tried the same trick windows 98 but not lucky

Edited by BeatZero
0

Share this post


Link to post
Share on other sites

**EDIT 2-10-2010**

In RE: Slipstreaming this Fix

It appears that this issue cannot be fixed by slipstreaming. Slipstreaming does not allow the VMM32.VXD system file to be properly compressed during the first reboot. If the updated files are introduced to the system before the first reboot and the IOS error take place, WININIT will fail to combine various VXD's into VMM32.VXD.

Text of this post left for further reference.

some other important update that we could add? or something that supports a lot of memory (1gb), I tried the same trick windows 98 but not lucky

I thought about adding some other things, but I don't really want to go overboard. I prefer to keep things simple. Adding important Microsoft updates I agree with, but I don't want to get into the realm of a "Service Pack," there's already one of those listed on MDGx's website. Also if we did that, I would want to have a method to select which things are installed and which ones aren't, that has always been my complaint with "cumulative" update packages.

I do have some ideas though, and I will look over some of the other Microsoft updates for 95 to see what might be added. :thumbup

On the memory issue - there may be ways of tweaking it to work (per the methods given in dencorso's thread). However, I was never able to get any of those memory tweaks to work on my 98SE system. I purchased RLoew's patch, and I've never had another problem. I know some people out there have a problem with paying for a patch, but personally I only recommend this method. I have no problem whatsoever giving someone fair compensation for good work and the time they put into it.

I should also mention an experience that I had when I was first looking into the 98SE RAM issue. I set up my system with 1.5GB of RAM, and I tested both Gape's Service Pack and RLoew's demo patch in separate 98 installs on the same machine. Gape's Service Pack did not correctly display the amount of RAM installed, I think it showed 1224MB or something like that (it's been a while), and the system seemed to be unstable. RLoew's patch worked flawlessly however, so I decided that I would buy it. Later I also tried installing the demo patch to the same 98 system as Gape's Service Pack, and the two seem to be incompatible, the amount of RAM was still incorrectly reported and the system seemed unstable.

I do not mean to disparage Gape or his Service Pack in any way, Ive got a lot of respect for him because he spent his time making something like that to distribute freely. :thumbup

Edited by LoneCrusader
0

Share this post


Link to post
Share on other sites

the method I adopted was that the Win98LiveCd

Himemx.exe used in place of HIMEM.SYS

system.ini

[vcache]

ChunkSize=1024

MaxFileCache=65535

config.sys

DEVICE=A:\DOS\HIMEMX.EXE /testmem:off

this was how I used in my project, and this works perfectly, however the tab of System Properties, always displays this number: 1152,0MB RAM

I am very interested in this information, because I have plans to create a LiveCD for Win95 :)

thank's

0

Share this post


Link to post
Share on other sites
I am very interested in this information, because I have plans to create a LiveCD for Win95 :)

Woohoo :w00t::thumbup

I thought you might have that in mind ;)

0

Share this post


Link to post
Share on other sites

Well, in my experience, Gape's uSP works well with > 1 GiB RAM, but one must first reach the right configuration without it, then save MSDOS.SYS, AUTOEXEC.BAT, CONFIG.SYS, SYSTEM.INI and WIN.INI, then apply Gape's uSP,

reboot, restart in MS-DOS, restore those saved files and reboot again. At this point one should either apply RLoew's RAM Limitation Patch or use the method of HIMEMX.EXE (renamed to HIMEM.EXE), xRayeR patch, Xeno86's vcache and XMSDSK (and in the latter case, Win 9x will not see more than about 1160 MiB of RAM, but the rest can be used in a ramdisk). I personally prefer to use RLoew's RAM Limitation Patch patch, in combination with RLoew's non-XMS Ramdsk, which is much more stable, but not free. The main problem with Gape's uSP with machines having lots of RAM lies, AFAIK, in the way it tweaks SYSTEM.INI, not in the updates it contains (but Gape's tweaks are OK for less than 1GiB, of course).

0

Share this post


Link to post
Share on other sites
Well, in my experience, Gape's uSP works well with > 1 GiB RAM, but one must first reach the right configuration without it, then save MSDOS.SYS, AUTOEXEC.BAT, CONFIG.SYS, SYSTEM.INI and WIN.INI, then apply Gape's uSP,

reboot, restart in MS-DOS, restore those saved files and reboot again. At this point one should either apply RLoew's RAM Limitation Patch or use the method of HIMEMX.EXE (renamed to HIMEM.EXE), xRayeR patch, Xeno86's vcache and XMSDSK (and in the latter case, Win 9x will not see more than about 1160 MiB of RAM, but the rest can be used in a ramdisk). I personally prefer to use RLoew's RAM Limitation Patch patch, in combination with RLoew's non-XMS Ramdsk, which is much more stable, but not free. The main problem with Gape's uSP with machines having lots of RAM lies, AFAIK, in the way it tweaks SYSTEM.INI, not in the updates it contains (but Gape's tweaks are OK for less than 1GiB, of course).

If you use HIMEMX.EXE and XMSDSK you can create a RAM Disk of any size but you cannot use all of it if it is very large. Windows will manage all memory allocated by any XMS RAMDisk. When the total of the allocated RAMDisk memory and the designated File Cache exceed approximately 700MB problems will occur. If you have 2GB or more of RAM you will not be able to use all of it with this method.

0

Share this post


Link to post
Share on other sites
If you use HIMEMX.EXE and XMSDSK you can create a RAM Disk of any size but you cannot use all of it if it is very large. Windows will manage all memory allocated by any XMS RAMDisk. When the total of the allocated RAMDisk memory and the designated File Cache exceed approximately 700MB problems will occur. If you have 2GB or more of RAM you will not be able to use all of it with this method.

It is this method that I use here, but a LiveCD is designed to run on several computers, creating a larger ramdisk, I will execute them problems on computers with little RAM (128, 256). :unsure:

In this case, I'll edit the AUTOEXEC.BAT and CONFIG.SYS with boot screen options for computers with 1gb, 2gb or more, then starting the livecd with pre-defined RAmdisk size :thumbup

0

Share this post


Link to post
Share on other sites

***UPDATE 2-10-09***

The first post in this thread has been updated with new information/methodology pertaining to Windows 95 Setup.

A new version of FIX95CPU.ZIP is available.

Slipstreaming as discussed by BeatZero and myself above does not appear to be a viable option for applying this fix. I remain open to suggestions for improvement however. :thumbup

Edited by LoneCrusader
0

Share this post


Link to post
Share on other sites

Now if only RLoew's RAM patch worked in 95 :whistle:

Between your prodding and a considerable amount of help in testing on your part, it is done.

As far as slipsteaming the AMDK6CPU fix, only the updated VFBACKUP.VXD cannot be combined into VMM32.VXD.

Removing or commenting out the appropriate line from WININIT.INI will allow slipstreaming.

0

Share this post


Link to post
Share on other sites

Between your prodding and a considerable amount of help in testing on your part, it is done.

Woohoo! :w00t::thumbup

For those who may be interested, we successfully tested up to 4GB of RAM with Windows 95 using RLoew's new patch.

Here are a couple of screenshots from the testing.

CPUZ34EE.gif

3584MB-RAM.gif

Edited by LoneCrusader
0

Share this post


Link to post
Share on other sites

Now, that's great news!

You both rock! :thumbup

0

Share this post


Link to post
Share on other sites

Thanks so much for your batch file. In order to get Windows 95B to work in the latest version of Virtual PC 7 in an efficient manner, I modified your batch file so it could be installed on the C drive with minimum typing and no floppy access (VPC7 needs a VB script in order to connect floppies). I know this will be nothing new for most of this community, but I would love it if anyone has any suggestions about this method.

http://www.virtualuser.net/files/win95/Win95VPC7.doc

http://www.virtualuser.net/files/win95/w95vpcbt.exe (self extracting iso file)

Derek

**EDIT 2-10-2010**

I thought about adding some other things, but I don't really want to go overboard. I prefer to keep things simple. Adding important Microsoft updates I agree with, but I don't want to get into the realm of a "Service Pack," there's already one of those listed on MDGx's website. Also if we did that, I would want to have a method to select which things are installed and which ones aren't, that has always been my complaint with "cumulative" update packages.

I do have some ideas though, and I will look over some of the other Microsoft updates for 95 to see what might be added. :thumbup

Edited by dawong
0

Share this post


Link to post
Share on other sites

Thanks so much for your batch file. In order to get Windows 95B to work in the latest version of Virtual PC 7 in an efficient manner, I modified your batch file so it could be installed on the C drive with minimum typing and no floppy access (VPC7 needs a VB script in order to connect floppies). I know this will be nothing new for most of this community, but I would love it if anyone has any suggestions about this method.

http://www.virtualuser.net/files/Windows%2095B%20in%20VPC%207.doc

http://www.virtualuser.net/files/w95vpcbt.exe (self extracting iso file)

Derek

Wow.. I guess I should not be surprised, considering that it is Microsoft, but I can't believe that they would have removed the ability to use a floppy drive from a virtualization program. That is beyond ridiculous. :huh:

IMO, Just another step in their campaign to erase all memory of DOS or DOS based Windows systems.

Anyhow, welcome to MSFN and I'm glad my fix was of some help to you. :hello:

I am actually working on another update to FIX95CPU.ZIP, using some suggestions and info given to me by rloew during the RAM patch testing discussed above. The new update will further minimize the required typing, and should eliminate one of the restarts for 95B and 95C users.

And based on the information you have given me, I may include a bootable ISO that contains the patch. Thanks for the feedback!

Edited by LoneCrusader
0

Share this post


Link to post
Share on other sites

Wow.. I guess I should not be surprised, considering that it is Microsoft, but I can't believe that they would have removed the ability to use a floppy drive from a virtualization program...

I agree 100%, and I wonder if the corporate office decided to remove it so their Win 7 sales would bump up, but the VPC programmers left in some functionality because they knew how ridiculous it was. The good news is that a very short program should allow restoration of disk functionality with a GUI interface, if I ever get the time to figure out C#/Windows programming and Powershell scripting.

IMO, Just another step in their campaign to erase all memory of DOS or DOS based Windows systems.

Not as long as MDGx and the other forum members are around :-) Thanks so much, and I will be happy to test your bootable ISO in VPC.

Derek

Edited by dawong
0

Share this post


Link to post
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.