Rick Chauvin, on Dec 17 2006, 11:13 AM, said:
fwiw, the only non-ms patch I've ever installed so far was from this forum yesterday, which was the Shell98.exe (and later did the Copy2gb.exe which I thought maybe should go with it too?)
..My point is maybe you all already do when you tested this, but I do not have the unofficial service pack nor the killer replacements or any other files from here installed - if that was suppose to matter up front for this Explorer Lockups SHELL32.DLL fix to work?
Shell32.dll is flawed no matter which/how many service pack(s) and/or unofficial updates/patches/replacements/etc you installed.
All that matters is if you installed IE [Internet Explorer] 5.5 SP2, 6.0 or 6.0 SP1.
All these web browsers are flawed [because of M$ integration
], therefore you need to install SHELL98.EXE [fixed shell32.dll] in order to fix the flaw.
COPY2GB.EXE fixes an entirely different matter:
*but* this new SHELL32.DLL *also* fixes this bug [see forum topic above].
HTH [Hope This Helps]
Petr, on Dec 17 2006, 03:23 PM, said:
Max_04, on Dec 17 2006, 09:21 PM, said:
Practically shell32 of this fix is impossible to localize, when I translate strings in italian with restorator and click on "save" or "save_as" gives "corrupted resource, probably file encryped or compressed".
Result is a crash of restorator.
Yes, it seems the "Anonymous author" made some mistake.
I just tried to load this file by Heaventools PE Explorer (not free), saved it, the size has decreased and Restorator works fine.
The best would be if MDGx could ask "Anonymous author" to repair the shell32.dll file, I'm not sure that shell32.dll repaired by PE Explorer is 100% functional (I have not tested it)
Edit: I have tried to use shell32.dll patched by "Anonymous author", re-saved by PE Explorer and all resources replaced by Czech resources by Restorator and the system booted and did not crashed (yet). No deep testing.
Anonymous author's answer:
Please try the same with the original file 4.72.3812.600 from M$! PE
Explorer also shortens the original file on save. There seems to be
something unusual in how M$ arranged the sections of this DLL.
Rick Chauvin, on Dec 16 2006, 02:42 PM, said:
It was good to see others working on this Quantity File Delete Hang problem with Win9x & IE6, and in one way or another I have worked on testing this issue for many years too, and had even once wrote a quick webpage about it giving an easy dllswap method and offered 0byte files to try and be a help to the situation: Win98 w/IE6 Causes Freeze-ups While Doing Quantity File Deletes
Well when I saw this post write up on your forum that you and your anonymous source had been working on this issue too I was pleased and thankful, and so being more than happy to try it and so being very hopeful I installed your Shell98.exe to see if it would solve the problem - but unfortunately for me anyway I'm sorry to say it did not fix it; although it may have changed it somewhat and may have caused other anomalies, but the bottom line is that after my standard 2500 file delete it still will hang; it does come back after a minute or so; it may act a bit different in small ways - but at that point like it always did will not let you rename or delete files further without re-exhibiting the same hang flaws. And so for me it was to type 5 at the msdos prompt to instantly swap the 5.5 dll's back in place, and once again with regards to large quantity file deletes the 5.5 dlls still work very well.
I'm happy to say that the 2 GB file copy error was resolved with the shell98 fix though - and that is a welcome change - thank you for that.
Anonymous author's answer:
I am sorry to hear that the patch did not work for you. Please make sure
you downloaded the latest version of SHELL98.EXE and actually installed
SHELL32.DLL 4.72.3812.620 (and not 4.72.3812.610). If it is 4.72.3812.620,
please re-read the license agreement that comes with the installer MDGx
Unofficial Windows 98/98 SP1/98 SE Explorer Lockups SHELL32.DLL
... The patch I am providing is not a fix in the true sense ... The
problem may still occur if a large number of files is deleted, moved etc,
*while* USER resources are low, say below 30% ...