[jaclaz]

dencorso, on Jan 30 2010, 06:39 PM, said:

I use BeyondCompare to do it, but that's not a free software, so maybe you'll prefer to use some freeware alternative to it...

If I am not mistaken TinyHexer runs on Win9x/Me, only it does not have direct disk access under non-NT OS.

It has both a "normal" hex comparison feature and a script to find file differencies:
http://www.boot-land...?showtopic=8734

jaclaz

[herbalist]

HxD can access a disk under 9X and can compare files.
http://mh-nexus.de/en/hxd/

[LoneCrusader]

BeatZero, on Jan 29 2010, 09:43 PM, said:

Hi LoneCrusader, MDGx, Dencorso
I built a Slipstreamer to implement this project automatically installing Windows 95.

give me some feedback

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

This post has been edited by LoneCrusader: 10 February 2010 - 03:52 PM

[BeatZero]

@LoneCrusader

for some reason the 7za.exe failed to extract the files SETUPC.INF,LAYOUT.INF,NET.INF and NETCLI.INF of PRECOPY2.CAB
(perhaps one difference in the CAB version?)

edit CPUFIX.BAT:

Quote

replace:

7za.EXE X -y PRECOPY2.CAB SETUPC.INF
7za.EXE X -y PRECOPY2.CAB LAYOUT.INF
7za.EXE X -y PRECOPY2.CAB NET.INF
7za.EXE X -y PRECOPY2.CAB NETCLI.INF

to:

EXTRACt.EXE /Y /a PRECOPY2.CAB SETUPC.INF
EXTRACt.EXE /Y /a PRECOPY2.CAB LAYOUT.INF
EXTRACt.EXE /Y /a PRECOPY2.CAB NET.INF
EXTRACt.EXE /Y /a PRECOPY2.CAB NETCLI.INF

BeatZero

This post has been edited by BeatZero: 01 February 2010 - 02:16 AM

[LoneCrusader]

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

This post has been edited by LoneCrusader: 10 February 2010 - 03:53 PM

[BeatZero]

Thank you for reporting

Quote

Ok, these files are now properly extracted, however it is extremely slow.

This was the reason for choosing the 7za.exe, I will try unRAR.exe

Quote

"Warning - VMM32.TMP integrity check failed"

This appears on the first reboot, then no more

Quote

DUN14-95 was not automatically installed by Setup however.

I'm working on it, I see that should be written in a file cpufix.bat different for each version of win95 (A, B & C)
"there may be conflict with the msbatch, if you are using"

BeatZero

This post has been edited by BeatZero: 01 February 2010 - 07:19 AM

[LoneCrusader]

BeatZero, on Feb 1 2010, 04:25 AM, said:

Thank you for reporting

No problem. Thank you for spending time helping me with my pet project

[jaclaz]

BeatZero, on Feb 1 2010, 10:25 AM, said:

Quote

Ok, these files are now properly extracted, however it is extremely slow.

This was the reason for choosing the 7za.exe, I will try unRAR.exe

Why not EXTRACT.EXE?

jaclaz

[BeatZero]

jaclaz, on Feb 1 2010, 10:40 AM, said:

Why not EXTRACT.EXE?

jaclaz

extract.exe takes a long time to extract 4 small files
7za.exe presented error when extracting
The unRAR.exe satisfactorily perform well in both situations

This post has been edited by BeatZero: 01 February 2010 - 08:46 AM

[LoneCrusader]

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

This post has been edited by LoneCrusader: 10 February 2010 - 03:54 PM

[BeatZero]

LoneCrusader, on Feb 2 2010, 03:19 PM, said:

@ 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

This post has been edited by BeatZero: 02 February 2010 - 11:32 AM

[LoneCrusader]

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

BeatZero, on Feb 2 2010, 12:27 PM, said:

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.



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.

This post has been edited by LoneCrusader: 10 February 2010 - 03:56 PM

[BeatZero]

the method I adopted was that the Win98LiveCd

Himemx.exe used in place of HIMEM.SYS

system.ini

Quote

[vcache]
ChunkSize=1024
MaxFileCache=65535

config.sys

Quote

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

[LoneCrusader]

BeatZero, on Feb 2 2010, 02:44 PM, said:

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

Woohoo
I thought you might have that in mind

[dencorso]

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

[rloew]

dencorso, on Feb 2 2010, 09:45 PM, said:

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.

[BeatZero]

rloew, on Feb 3 2010, 04:35 AM, said:

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

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

[LoneCrusader]

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

This post has been edited by LoneCrusader: 24 February 2010 - 10:25 AM

[MDGx]

Updated package is here:
http://www.mdgx.com/web.htm#FX95

HTH

[rloew]

LoneCrusader, on 25 January 2010 - 11:15 AM, said:

Now if only RLoew's RAM patch worked in 95

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.