fhub

Well, I've just downloaded both versions again from MajorGeek to be sure we're talking about the same executables. Now when I do a binary file compare, there's NO DIFFERENCE at all in the code (not a single byte) - the only differences are in the (UniCode) text sections, and these differences are: 1) changing every occurence of "1.0" to "2.0" (6 times) 2) changing "Rain for Windows 95/98" to "Ony for Windows 98" So do you really believe these text changes could have any influence on how the program runs/works??? I always thought this would be a experts forum, but it seems to be rather a newbie forum ... ;-)

It seems you guys aren't even able to use a filecompare utility!? But ok - be happy with your 'different' Rain 2.0 ...

This Rain '2.0' is just a fake - exactly the same code as 1.0 with only the version number patched to 2.0 at a few places!

Well, then you're one of the lucky ones with a modern CPU. ;-) This new CPU-Z tries to access special CPU registers, and if they are not available then the program crashes with a BSOD in Win98. So you seem to have a CPU with these special registers. :-)

Well, both programs don't work in Win98! :-( CPU-Z 1.55 gives a crash (BSOD). I've been in contact with the author in the last 2 days and he has fixed the problem already, but the new Win98 version is still not on his website. And HW-Monitor 1.16 gives an error message because he used a WinAPI function call which doesn't exist in Win98. I've just written him another e-mail, so it will take some time until also this problem will be fixed.

Well, I would say that Win98 is even more safe than a Swiss bank account nowadays!

No problem, Ken! My patch does exactly the same, but without changing the version number (I don't see what this should be good for!?), so only one byte is modified. And the included 'Patcher.exe' has the advantage, that a second usage restores the original file again. But otherwise there's almost no difference ... Regards, Franz

Here's a more comfortable solution: Unzip the files from my attachment to the Acrobat folder and run 'Patch.bat' - that's all. No need to rename anything, and no need to keep a backup copy, because running 'Patch.bat' again will restore the original file. AR606Patch.zip

Of course the registry removal doesn't work, but the utility 'exeversion' (from steelbytes) mentioned above does in fact work with the latest version 11.33 of ProcessExplorer - it runs without problems in Win98! (unfortunately this trick does not work for ProcessMonitor)

I can recommend either XFDisk or WWBMU: http://www.mecronome.de/xfdisk/index.php http://toolsandmore.de/Central/Produkte/So...em-Tools/WWBMU/ Both are very simple and small, work completely with code in the MBR (i.e. need no extra files on the harddisk), and survive restoring the OS from a disk image. Both programs allow to remove the bootmanager again (e.g. if you want to re-format the HD), but of course this could also be done with a simple "fdisk /mbr". The 2nd one (WWBMU) has only a German GUI (but this will only be needed during installation), so you may probably prefer XFDisk. I've also used XFDisk without any problems for many years - well, until I've installed a maths program from Texas Instruments (TI-Nspire CAS) a few months ago: this TI-Nspire writes some (licence?) data to the MBR (usually I would call such a program a virus), and XFDisk doesn't like such MBR modifications (it has a built-in MBR integrity check exactly for preventing against MBR viruses) and simply stopped booting. Thus I've switched to WWBMU (which still works after this TI-Nspire 'virus' ;-) ), but I'm sure you don't have such a crazy program which stores any data in such critical HD areas, so you could certainly use XFDisk without any problems on your system.

... and quite often produces the most terrible crashes (BSODs) I´ve ever had on my Win98 computers!

Hi xrayer, I think there might be a little problem with your IO.SYS patch!? Look at the bytes in the following 2 lines: (o=0x0, d=0xd) \HIMEM.SYSo/TESTMEM:ONdoo \HIMEMX.EXEo/MAX=999999do Since HIMEMX.EXE is one byte longer than HIMEM.SYS, the termination zero-byte 0x0 is moved one byte to the right by your patch. But this is exactly the byte where the HIMEM parameter /TESTMEM starts. So if IO.SYS is using the usual method of addressing strings (with a fixed address table), and I´m quite sure it indeed does it this way, then this address pointer for the parameter now points to this zero-byte (instead of the starting ´/´ of /MAX=...). So this parameter /MAX=999999 isn´t used at all by IO.SYS, I´m afraid! A simple solution would be to just rename HIMEMX.EXE to HIMEM.EXE, so the length would be the same as HIMEM.SYS and the terminating zero-byte doesn´t need to be moved. Furthermore you could now even use 1 full GB (1048576) instead of 999999, because after the /TESTMEM string there are 2 zero-bytes (but only 1 is needed of course), so you could increase the string length by 1 byte.