Jump to content

98 (FE), 98 SP1, 98 SE + ME SHELL32.DLL fix


MDGx

Recommended Posts


Can someone apply the fix to Italian Win ME shell32.dll please?

Original Italian file is here: http://rapidshare.com/files/8458645/SHELL32.rar.html

not sure. MDGx will have to ask the "Anonymous" author of the unofficial English Shell32.dll fix if he can translate the Italian version.

well said, Rick Chauvin. These shell32.dll fixes for Win98 and WinME have mostly (though not completely) resolved the file deletion problem with the IE6 browseui DLL files.

Link to comment
Share on other sites

Also it's worth noting as has been mentioned a few times now we know that using the 5.5 browse*dlls 'in all instances' ... rarely freezes up with them
"rarely"? Make that 'never'.

I'll go for the 6,5535 files test if you really want proof of that.

@above: If it's the same version but in a different language, use a hex editor and fix the affected bytes in the code section. I'll try that right now ~

Edit: Can't find a fixed WinME shell32.dll to template from. I can't do anything :}

Edited by LLXX
Link to comment
Share on other sites

Also it's worth noting as has been mentioned a few times now we know that using the 5.5 browse*dlls 'in all instances' ... rarely freezes up with them
"rarely"? Make that 'never'.

I'll go for the 6,5535 files test if you really want proof of that.

@above: If it's the same version but in a different language, use a hex editor and fix the affected bytes in the code section. I'll try that right now ~

Edit: Can't find a fixed WinME shell32.dll to template from. I can't do anything :}

Technically (never) is not ultimately accurate - maybe it's 99% of the time, but I've had people report that it's happened to them on a straight SP5.5SP2 setups or even with IE6x w/5.5x brows'dlls (although rarely) and as well, I've had it happen to me once or twice, out of thousands though.

~~~~~~

You don't have your comma in the right place but I assume it's just a typo.

Anyway, if you want to try that many thousands files though then go ahead - I'll even supply the 65,534 (not 65,535) files since iirc 9x in theory can only create up to 65,534 directory entries, which in usable reality is more like 65,531 entries before it balks at letting you create another and gets squirly is you push it to 65,534 limit which can only be done with a automatic script to force the extra few which is how I made mine. Seriously though most peoples 9x boxes don't have the GHz or RAM to even try that many files without wasting an inordinate amount of time to even move them around let alone do anything else with them - even with my modern screaming machine takes a bit of time to process that many entries, so save my bandwidth and don't download the 65,534.zip - but stick with the 2500.zip! ..link below sig.

It is much better to suggest for the test just to use the 2500 0byte files like offered on my webpage (link below at sig) for a number of reasons - the most important being it's more than an adequate size beyond the extreme usage for Win9x, and so why bother with more than that if it's unrealistic in usage; furthermore, this delete hang happens not just because of file deletions, but any number of cumulative effects of deleting, renaming, moving, creating, etc, etc.. and so to cover most of them at once I like to SelectAll and delete the 2500, then from the RecycleBin do the same thing in reverse and select to Restore the files, and then if necessary back and forth any number of times as realistically needed to prove the point.

Rick

W98xIE6xQuantityFileDeleteHangBug

Link to comment
Share on other sites

Technically (never) is not ultimately accurate - maybe it's 99% of the time, but I've had people report that it's happened to them on a straight SP5.5SP2 setups or even with IE6x w/5.5x brows'dlls (although rarely) and as well, I've had it happen to me once or twice, out of thousands though.
It must be said that intermittent hardware glitches will also hang the OS, and should be disregarded for the purposes of this test since it has nothing to do with the software. What I'm saying is that the 5.5 files are correct while the 6.x ones contain a bug.
You don't have your comma in the right place but I assume it's just a typo.
I just prefer 4-digit groupings. Just ignore the commas if it seems odd.
Anyway, if you want to try that many thousands files though then go ahead - I'll even supply the 65,534 (not 65,535) files since iirc 9x in theory can only create up to 65,534 directory entries, which in usable reality is more like 65,531 entries before it balks at letting you create another and gets squirly is you push it to 65,534 limit which can only be done with a automatic script to force the extra few which is how I made mine. Seriously though most peoples 9x boxes don't have the GHz or RAM to even try that many files without wasting an inordinate amount of time to even move them around let alone do anything else with them - even with my modern screaming machine takes a bit of time to process that many entries, so save my bandwidth and don't download the 65,534.zip - but stick with the 2500.zip! ..link below sig.

It is much better to suggest for the test just to use the 2500 0byte files like offered on my webpage (link below at sig) for a number of reasons - the most important being it's more than an adequate size beyond the extreme usage for Win9x, and so why bother with more than that if it's unrealistic in usage; furthermore, this delete hang happens not just because of file deletions, but any number of cumulative effects of deleting, renaming, moving, creating, etc, etc.. and so to cover most of them at once I like to SelectAll and delete the 2500, then from the RecycleBin do the same thing in reverse and select to Restore the files, and then if necessary back and forth any number of times as realistically needed to prove the point.

Why I suggest such a high number of files, and also files with content in them (1 byte, but nonetheless content) is because testing in more extreme situations guarantees correct operation in normal usage. I find 2500 to be a bit low, since I have several directories containing 4000+ image files (total number of files on one of my HDDs approximately 25,0000). A more realistic limit would be 1,0000.

This post will be edited to display the results of 65535 files test.

Edit:

The limit is actually 65533, since entry 65535 is the highest and two are taken by . and .. already (unless working in the root directory, although I didn't want to add 64 thousand files to the root of any of my existing drives).

This limit is further lowered by long filenames, which take up their own directory entry.

"So, what's the result of the test?"

Explorer handled up to ~32K files with no noticeable delay, but beyond that point refreshes became gradually slower and slower - the final refresh, to show the full 65533 files, took almost a full minute. However, the OS remained fully functional throughout.

I copied the files to another directory, which took approximately 20 minutes. Once again the refresh at the end took nearly a minute to complete. I then deleted the files in the original directory - here is where the first bug occurred - selecting all the files and pressing the Delete button caused explorer to IPF somewhere in the kernel32. Gradually lowering the number of files confirmed that this may have to do with the file count being considered as negative, as it worked fine with deleting ~32000 files at once. Thus I deleted in two chunks, and proceeded to copy the other set of files back - once again, no problems. Deleting again this set in two chunks also free of any problems.

So, it seems to work.

Edited by LLXX
Link to comment
Share on other sites

Yes the IE6 files certainly has the bug brought out and we all agree on that along with most other things.

Yes I came up with 65,531 since it was calculated for the root of course.

I didn't actually mean you had to do the test with that many files, but it's fine that you did - I just showed up at your doorstep with them as a phun. I'm going to nip that link since that many is a little overkill and most people will find it more trouble than not with that many files.

Yes in that sense the fix seems to work with the delete hang for me too, but I'm curious why the actuall delete process seems to be methodically throttled slower as compared to the 5.5 files. I noticed you had mentioned that somewhere too; other than that it works, but certainly still keeping it in the testing thought mode status..

During the last week for one reason or another I had come with a shell32.dll error with the test, but with different usage not related to this test came up with a few Kernel32.dll errors as well; of course they showed up in the log file but as well I screenshot'd them for gp. I have not had time to track them down and just considered them as me pushing the limit with this OS as I usually do - time will tell. Yes both Copy2gb.exe & Shell98.exe had been applied earlier in the week

I've gotta do a few days of travel for the holidays, and so on that note.. Happy Holidays..!!!

Link to comment
Share on other sites

Rick Chauvin:

1. Please note that by installing 98MP10.EXE:

http://www.mdgx.com/wmp.htm#98MP10

[which among other files] installs the WinXP SP1 version of BROWSELC.DLL 6.00.2800.1106 , the OS may recover *only* in certain situations [?] from such lockups, but this is uncertain, because I haven't done enough testing.

2. Please note that by using the 2 older DLLs from IE 5.5 SP1 [bROWSELC.DLL 5.50.4807.2300 + BROWSEUI.DLL 5.50.4807.2300] with IE 6.0 SP1, as you state at your page [among many other people who offer the same workaround]:

http://www.rdchauvin.com/W98xIE6xBug.htm

IE 6.0 SP1 loses certain functionality, which is otherwise built into the newer IE 6.0 SP1 DLLs.

But what is more important, by using the older BROWSEUI.DLL 5.50.4807.2300 with IE 6.0 SP1, all security vulnerabilies that were fixed by M$ in all newer versions are *lost* , thus exposing the OS to all those security risks.

Please note that the OS is still exposed to most IE security risks even if using any other web browser [Firefox, Mozilla/Gecko, Netscape, Seamonkey, Opera, IE "skins" like Maxthon/Avant etc] to surf the internet, because of implementation of M$ "browser integration", which forces the OS to use IE DLLs for internet/network access, no matter which browser engine is used.

IMO:

If using IE 6.0 SP1, you have 2 solutions:

1. Uninstall IE 6.0 SP1 and then (re)install IE 5.5 SP1 [which as I mentioned above at #2] exposes the OS to security risks.

But please note that M$ does not issue any fixes/patches for any IE build other than 6.0 SP1, thus leaving IE 5.5 SP1 and all other older builds unpatched, and therefore exposed to security risks.

2. Or:

- if using Windows 98/98 SP1/98 SE:

install SHELL98.EXE = installs SHELL32.DLL 4.72.3812.620 fix

- if using Windows ME:

install SHELLME.EXE = installs SHELL32.DLL 5.50.4134.120 fix

and *never* move/copy/delete/rename large amounts of files/folders when USER resources drop at ~ 30% or below [not recommended anyway].

First reboot to recover USER resources back to normal values, if you need to perform such "en masse" file/folder manipulation chores.

This way all IE 6.0 SP1 security patches are up to date:

http://www.mdgx.com/ietoy.htm#BRO

and the OS is far less exposed to known security risks.

HTH

Link to comment
Share on other sites

Rick Chauvin:

1. Please note that by installing 98MP10.EXE:

http://www.mdgx.com/wmp.htm#98MP10

[which among other files] installs the WinXP SP1 version of BROWSELC.DLL 6.00.2800.1106 , the OS may recover *only* in certain situations [?] from such lockups, but this is uncertain, because I haven't done enough testing.

Okay duely noted, thanks.

I have not installed v10 and have been at v9 for a while.

OT, but also thanks for the info to revert the dxmasf.dll tip from last weeks 923689 installs.

2. Please note that by using the 2 older DLLs from IE 5.5 SP1 [bROWSELC.DLL 5.50.4807.2300 + BROWSEUI.DLL 5.50.4807.2300]with IE 6.0 SP1, as you state at your page [among many other people who offer the same workaround]:

http://www.rdchauvin.com/W98xIE6xBug.htm

IE 6.0 SP1 loses certain functionality, which is otherwise built into the newer IE 6.0 SP1 DLLs.

That was always well understood and is fully explained in the 2500.zip package offered on my page from back in 2003.

Also to LLXX, the reason why 2500 was chosen was because back then after much laborious testing by many, it was proven out that it took aprox just 1500 files deleted to consistently cause the hang anomaly to surface on any given fresh boot, and so another 1000 to make 2500 was added for good measure. There was no reason to use more than that, and 2500 was much more user friendly for others to test since it was easier/faster for the browser to manipulate, while still consistently causing the anomaly to happen.

Note to anyone that has the 65000 test file folder, be sure to zip it, since if you use registry/file tracking software, every snapshot taken you'll see it will waste time pausing on that folder as it tries to assesses the compare, even if nothing was changed within it.

But what is more important, by using the older BROWSEUI.DLL 5.50.4807.2300 with IE 6.0 SP1, all security vulnerabilies that were fixed by M$ in all newer versions are *lost* , thus exposing the OS to all those security risks.
..again well understood
Please note that the OS is still exposed to most IE security risks even if using any other web browser [Firefox, Mozilla/Gecko, Netscape, Seamonkey, Opera, IE "skins" like Maxthon/Avant etc] to surf the internet, because of implementation of M$ "browser integration", which forces the OS to use IE DLLs for internet/network access, no matter which browser engine is used.

Okay thank you for the tip.

IMO:

If using IE 6.0 SP1, you have 2 solutions:

1. Uninstall IE 6.0 SP1 and then (re)install IE 5.5 SP1 [which as I mentioned above at #2]exposes the OS to security risks.

But please note that M$ does not issue any fixes/patches for any IE build other than 6.0 SP1, thus leaving IE 5.5 SP1 and all other older builds unpatched, and therefore exposed to security risks.

Understood.

My preference is to use IE6SP1 with your latest ie925454.exe, along with either your shell32.dll fix, or with the swapped 5.5 browse*dlls. I haven't yet decided which one I will most often use yet and still testing your shell32 fix - it's not perfect but it's much better than without it of course; however the 5.5 browse*dlls work very well but with whatever as noted and unknown operational or security risks may arise when placing them in an IE6x environment of course.

2. Or:

- if using Windows 98/98 SP1/98 SE:

install SHELL98.EXE = installs SHELL32.DLL 4.72.3812.620 fix

- if using Windows ME:

install SHELLME.EXE = installs SHELL32.DLL 5.50.4134.120 fix

and *never* move/copy/delete/rename large amounts of files/folders when USER resources drop at ~ 30% or below [not recommended anyway].

First reboot to recover USER resources back to normal values, if you need to perform such "en masse" file/folder manipulation chores.

That's well understood. In some ways it's nice to be able to run with the ie925454.exe security benifits, and so being careful then the shell32 fix will be just fine. Going back for a minute, it's curious though, the only wondering I have is that with the 5.5 dll's in place it takes just 10 seconds to delete 2500 files, and 10 seconds to Restore from the RecycleBin, but with the v6 dll's in place with your shell32 fix, it takes 65 seconds to delete, but then just 10 seconds to restore them back - I guess the 65 seconds part is an unfortunate side effect pita, but other than that may not? be a big deal just so long as the fix causes No similar slowdowns in any other explorer instances (which I have not noticed yet)

This way all IE 6.0 SP1 security patches are up to date:

http://www.mdgx.com/ietoy.htm#BRO

and the OS is far less exposed to known security risks.

HTH

Yes I do agree it's nice to have the latest IE updates installed, that's why it's wonderful you all are working on shell32 or whatever way is the best way to solve the W98xIE6xQuantityFileDeleteHangBug. I for one much appreciate the work that you and others are doing with this and other 9x projects.

Thanks, and Happy New Year!

Link to comment
Share on other sites

I advised earlier in this forum NOT to use BROWSEUI.DLL version 5.50.4807.2300. PLEASE use BROWSEUI.DLL version 5.50.4948.700 dated 12/7/2004 from IE 5.5 SP2 KB905915 patch.

Does Rick Chauvin even know about version 5.50.4948.700 of BROWSEUI.DLL file?

Link to comment
Share on other sites

I advised earlier in this forum NOT to use BROWSEUI.DLL version 5.50.4807.2300. PLEASE use BROWSEUI.DLL version 5.50.4948.700 dated 12/7/2004 from IE 5.5 SP2 KB905915 patch.

Does Rick Chauvin even know about version 5.50.4948.700 of BROWSEUI.DLL file?

Erpdude8 I hate it ... telling this all the time.

But it must have been said that BROWSEUI.DLL from KB905915 makes the file deleting bad again!!!!

Like all of you know the answer for the IE6 problem was from here:

http://www.frankprovo.com/win98ie6filesproblem.htm

Frank Provo says:

Obtain the IE 5.5 versions of those files. The full version # is v5.50.4807.2300

browseui.dll

browselc.dll

This is a post from the topic "Windows Explorer Freezes" that brings nice information why browseui.dll version 5.50.4948.700 SHOULDN'T be used:
But I don't recommend you to take the browseui.dll(5.50.4948.700) from KB905915 for IE 5.5 SP2 Windows ME because

I once tested it and found out that you can also get the problem of a slowly reacting of Windows on deleting files.

So and I hope now not to read such stupid comments again,like why is my Windows freezing after I replaced BROWSEUI.DLL v5.50.4807.2300

with 5.50.4948.700 of BROWSEUI.DLL.

Edited by winxpi
Link to comment
Share on other sites

I advised earlier in this forum NOT to use BROWSEUI.DLL version 5.50.4807.2300. PLEASE use BROWSEUI.DLL version 5.50.4948.700 dated 12/7/2004 from IE 5.5 SP2 KB905915 patch.

Does Rick Chauvin even know about version 5.50.4948.700 of BROWSEUI.DLL file?

Yes erpdude8 I do have v5.50.4948.700 for testing on my box and I did get it when I read the posts here where you were talking about it weeks ago, which I then downloaded the ie905915.exe from msfn and extracted that particular browseui.dll out of it. Yes naturally I fully realize it's not in my dllswap.zip offered on my site and I just didn't take the time to update it - in reality it's not a big deal really; besides, since I've posted that webpage write-up on this issue for years on the official ms 9x forums, I don't want to have to explain to anyone 'there' who has a quirk for 'officialness' ..why I'm using unofficial dlls ..and so I'll just leave the dllswap.zip as it - if anyone wants to change the version of that one v5 dll then go for it. Yes I have tested v5.50.4948.700 and I did not see the problem that winxpi mentions, aamof, as mentioned in my previous post it only takes me 5 seconds to delete 2500 files to the RB and 5 seconds again to Restore the files back, and yes for that test I was using v5.50.4948.700.

In context though if you're concerned about using that v5 version dll compare to the previous v5 one because of any perceived security issues, then it might be well to consider the real disparity between using the current v6.00.2800.1896 dlls (from msfn ie925454.exe) as compared to either of those older v5 dlls.

But to your point, yes, if we're splitting hairs about it then yes I see your meaning and so if using the v5 dllswap method then we might as well use the v5.50.4948.700 dll - at the moment though I'm still testing the shell32 fix and have msfn's own ie925454.exe installed to go with it.

W98xIE6xQuantityFileDeleteHangBug

Rick

Edited by Rick Chauvin
Link to comment
Share on other sites

I advised earlier in this forum NOT to use BROWSEUI.DLL version 5.50.4807.2300. PLEASE use BROWSEUI.DLL version 5.50.4948.700 dated 12/7/2004 from IE 5.5 SP2 KB905915 patch.

Does Rick Chauvin even know about version 5.50.4948.700 of BROWSEUI.DLL file?

4807 works fine, don't fix it if it ain't broken. (I did the 64k files test with it, so I'm quite confident it works)
Link to comment
Share on other sites

[..edited..]

I've found interestingly that for whatever reason? the Shell32.dll fix (Shell98.exe) fix for Explorer lockups appears? to be more effective if the Kernel32.dll fix (Copy2gb.exe) is also installed. To explain more of what I've noticed is that if only the Shell32.dll is updated the hang problem is yes much improved (70% successful) over just having the original one in place - but I still can make it hang although not nearly as readily as without it that's for sure; however if I have both the shell32 and Kernel32 dlls updated then in my observances as of yet anyway, it appears to be even more improved (85% successful) and more difficult to trigger the hang problem. (In any of my tests when it hangs the User, System, and GDI resources still show high %)

Even though not a perfect fix, the Shell32.dll workaround is a good one and well worth it, and many thanks again to anonymous for taking the time to look at this problem.

Alternately, I think the best fix (97% successful) for this particular Explorer hang problem, may be to still swap the v6 out with the v5 browse*dlls; although, it's needs to be understood that there are the 'Unknowns' security and/or operations wise of using the v5 instead of v6 browse*dlls. ymmv

Irregardless though, because of the 2-4 GB file copy fix that's also contained in the new shell32.dll and/or kernel32.dll, I will leave them both in place.

One thing that always bugged me about IE6 as compared to IE5 on Win9x though (and doesn't seem quite right somehow I'll explain* later) is that the amount of time it takes to delete let's say 2500 0byte files with IE5 installed (or IE6 installed with IE5 browse*dlls) is 8 seconds, but with straight IE6 installed the same files deleted takes Seven times as long aprox 60 seconds (my times are for my particular machines specs) ..but to better magnify my point here, increasing the file delete amount to let's say 10,000 files with IE5 installed (or IE6 with IE5 browse*dlls) takes just 28 Seconds as compared to straight IE6 which is 4 Minutes! ..which is an unwanted considerable difference that imho should not be. As we know something was never right with IE6 on Win9x, but we know that IE6x is fine on the OS's they were intended for, iow, *if I boot to W2000 or WXP using the same IE6 version and do the same file delete test.. it works just fine and equal to the same fastest times in each Win9x test, and there is none of this what I call a methodically throttled back slower delete process like there is on Win9x with a straight IE6x installed. (The extra benefit of using the v5 browse*dlls on IE6 is faster deletes, while almost eliminating the Explorer hang problem.)

Edited by Rick Chauvin
Link to comment
Share on other sites

I have fixed the 2GB+ copy limitation at its root, by fixing the kernel itself (which contains the flawed API _llseek). I recommend the use of the fixed kernel and v5 browse* files.

See Copy2Gb link in my signature for more information.

Link to comment
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.
×
×
  • Create New...