[bristols]

Thanks MDGx and anonymous author for this latest version.

I've just downloaded the fix and unpacked SHELL32.DLL and it still shows version 4.72.3812.620, not .634 (and is timestamped October 30 2006). Is this correct - did the author not actually update the build/date in this latest release?

Just trying to clear up any confusion.

[MDGx]

bristols, on Jan 9 2007, 06:18 PM, said:

Thanks MDGx and anonymous author for this latest version.

I've just downloaded the fix and unpacked SHELL32.DLL and it still shows version 4.72.3812.620, not .634 (and is timestamped October 30 2006). Is this correct - did the author not actually update the build/date in this latest release?

Just trying to clear up any confusion.

Actually [as some1 else also noticed], the file was still the old one.

My web site provider had a maintenance downtime, so I couldn't access my ftp site for a while.
But please try again... all files should be up now.

SHELL98.EXE link:
http://www.mdgx.com/files/SHELL98.EXE

SHELLME.EXE link:
http://www.mdgx.com/files/SHELLME.EXE

Thanks for noticing.

Best wishes.

[bristols]

Cheers MDGx for the explanation. Got the updated file now. I'll download the rest of today's updates again too, just in case.

Thanks again, all the best.

[MDGx]

bristols, on Jan 9 2007, 06:37 PM, said:

Cheers MDGx for the explanation. Got the updated file now. I'll download the rest of today's updates again too, just in case.

Thanks again, all the best.

No need to d/l the other files again.
SHELL98 + SHELLME were the only ones I couldn't upload for a while.

HTH

[Rick Chauvin]

MDGx, on Oct 12 2006, 06:08 PM, said:

[...]

Author's comments..

Rick,

Many thanks for testing the patch and for your comments.
Is there a sure-fire method that you know and use which triggers the bug successfully in most cases?
It would be very helpful to know.
It may help pinpoint the location of the actual bug in USER.EXE and whatever code in KRNL386.EXE/KERNEL32.DLL USER.EXE calls.

It was never an exact science however causing the hang to happen was very predictable. Originally we observed that the threshold to trigger (for the majority) was about 1500 files and did nOt matter if there was any filesize to them, and so for logical convenience I offered the 2500.zip for testing purposes - which 'at that time' a 2500 delete would almost certainly trigger it. Deleting more in one action was unnecessary and as well undesirable. It was also observed the trigger was Cumulative, meaning if during one boot process you deleted 1000 files and it didn't hang yet, but then next or even later in the same boot when you delete more (or do any other affecting process) it will still cause it to hang once the threshold was passed. Because it's cumulative, if you wanted more than 2500 to test delete then after you Select All and delete 2500 to the Recycle Bin, then in reverse from the Recycle Bin Select All on the same deleted files and click Restore - therefore now giving you a cumulative total of 5000 files having been deleted, do again for 7500 total, again for 10,000 and so on and so on for any number of times as realistically needed to prove the point. Importantly this back/forth procedure also helps giving combined task processes to the mix which greatly enhances the trigger. There's no reason or benefit for the 'average' person testing to delete using 'single' large groups of 20,000, 30,000 or more files which just takes lots of extra time for explorer to even process/show that many files in the first place (especially on older spec'd setups) not to mention introducing other non-related errors to the mix because of unnecessarily causing low resources to further aggravating the issue - and so using a 2500 quantity for testing purposes was proven most appropriate to 'effectively trigger' while staying away from any type of extra related low resources issues.

Once the hang ever happens, the sure way to prove you are actually under the bugs spell or not, is to simply right click anywhere and try to create a new file or folder - if it hangs for aprox 30 seconds before it creates, then you know you have been bitten and a reboot (better than just a log off/on) is the only best way to recover.

The best method to trigger is a Select All and Delete to the Recycle Bin, and on the same files in the Recycle Bin Select All and right click to Restore, and do that back and forth as many times as realistically needed to prove the point. Further trigger enhancers 'along with' the former would also be alternating permanent deletes out of the RB and/or cut's from the RB and paste to other places back and forth.

Quote

Which versions of KERNEL32.DLL have you been using for these tests?
4.10.2225 (official version) from 320798usa8.exe or an earlier version?
The updated version from COPY2GB.EXE on your machine is 4.10.2226 (unofficial version), correct?

Originally I used what was right from the retail cd which was v4.10.2222 and I never had a reason to apply 320798, but recently yes I did switch to your latest 4.10.2226 for testing, however!, yesterday I now uninstalled that back to using the 4.10.2222 original again - to virgin test your new v4.72.3812.634 shell32.dll all by itself... ! ...and I have methodically tried every single trick in the book I know of, and as of this moment anyway, it's 100% *, and I cannot cause the IE6xQuantityFileDeleteHangBug to happen anymore.. The testing is too young yet to give a final determination; I will continue trying and observe it as the days go by, but if this proves out to be true, you have earned a well deserved honor! and Thank You for doing it!

*********************************
*EDIT.. a few weeks later coming back to this post to make just these two lines of edit info here for this post - and that info is that I did find some unwanted side effects though as explained later in this same thread)
*********************************

Also on topic to ask is why does on a W98x setup with straight IE6x installed as compared to straight IE5x, does it take Seven times as long to standardly delete files! (most noticeable on quantity deletes for sure) ..However, we know that if we take an IE6x install and swap just its BROWSEUI.DLL with the one from IE5x then the delete time will match a straight IE5 install which is fast and normal, just like it is with the same IE6x versions on W2000 or WXP its delete time is fast/normal too! What is it within the IE6x BROWSEUI.DLL 'when on W98x' that makes its delete process so measuredly drawn out slow?...which imho is a misdirected/mismatched process within it and was the final aggravator that caused the explorer hang bug to fully 'come out and show itself' in W98x IE6x.. ..and so naturally we wonder if that slow delete process problem in the IE6x BROWSEUI.DLL can at some point also be fixed too?

Also a question that begs to be answered please, since the new shell32.dll takes care of not only the 2-4 GB file usage on Win9x, and now the explorer hang bug - is there any reason or benefit whatsoever! to also use your new copy2b's Kernel32.dll ??? If you would elaborate, thank you.
The point of this being that since so Many processes run off of Kernel32, so naturally we want to cover All bases with any changes made to it.

W98xIE6xQuantityFileDeleteHangBug

Rick

This post has been edited by Rick Chauvin: 16 February 2007 - 09:55 AM

[noguru]

Rick Chauvin, on Jan 11 2007, 03:54 AM, said:

Also a question that begs to be answered please, since the new shell32.dll takes care of not only the 2-4 GB file usage on Win9x, and now the explorer hang bug - is there any reason or benefit whatsoever! to also use your new copy2b's Kernel32.dll ??? If you would elaborate, thank you.

W98xIE6xQuantityFileDeleteHangBug

Rick

MDGx has answered that question already. Page 3 of this topic.

http://www.msfn.org/board/index.php?showto...84451&st=40

The copy2gb kernell32.dll is not needed but doesn't hurt. I have them both installed and never had problems with it.

It's good to hear that shell v4.72.3812.634 is working for you. The 620 version was working for me too and I'll stick with it since I have a dutch version of it (kindly provided by Hp38user).
Anyone that has used both versions succesfully but has extra benefits (performance) from the last version? If this is the case than I will use the last version too.

[Rick Chauvin]

noguru, on Jan 11 2007, 12:48 PM, said:

MDGx has answered that question already. Page 3 of this topic.

http://www.msfn.org/board/index.php?showto...84451&st=40

The copy2gb kernell32.dll is not needed but doesn't hurt. I have them both installed and never had problems with it.

Yes I previously had read and was well aware of what that link said and appreciated it, but for gp and this timepoint, my post was specifically asking Author>Anonymous to also respond to this same question, as well as my other questions too. Thank you.

This post has been edited by Rick Chauvin: 11 January 2007 - 12:48 PM

[Acheron]

Many thanks to Anonymous author! This was the fix I was hoping for, to make an end to all workarounds used to prevent the hanging issue on explorer file deletion

[whatever420]

Rick Chauvin, on Jan 10 2007, 09:54 PM, said:

...and so naturally we wonder if that slow delete process problem in the IE6x BROWSEUI.DLL can at some point also be fixed too?

Yes please .

I did some testing on my computer...

With the patched Shell32.dll and the IE 6 Brows*.dll files, it takes anywhere from 70 to 90 seconds to delete the 2500 0 byte test files...

With the patched Shell32.dll and the IE 5.5 SP2 Brows*.dll files, it takes anywhere from 24 to 30 seconds to delete the 2500 0 byte test files...

It's an amazing difference...

On the plus side, Anon's Patched Shell32.dll file DOES seem to work...
Kudos!

[LLXX]

That speed decrease may simple be due to more inefficient code in the main loop.

[Rick Chauvin]

whatever420, on Jan 12 2007, 12:12 AM, said:

Rick Chauvin, on Jan 10 2007, 09:54 PM, said:

...and so naturally we wonder if that slow delete process problem in the IE6x BROWSEUI.DLL can at some point also be fixed too?

Yes please .

I did some testing on my computer...

With the patched Shell32.dll and the IE 6 Brows*.dll files, it takes anywhere from 70 to 90 seconds to delete the 2500 0 byte test files...

With the patched Shell32.dll and the IE 5.5 SP2 Brows*.dll files, it takes anywhere from 24 to 30 seconds to delete the 2500 0 byte test files...

A tidbit, fwiw, and going back a few years now but it's only the Browseui.dll that is the issue here, and the Browselc.dll is only offered for those who wanted the extra limited customization of buttons & toolbars of IE's feature where without it you don't em.. ..iow, it's only the Browseui.dll that's involved with this dragged out longer deleting issue.

Quote

It's an amazing difference...

..yes it is, and fwiw remember each persons TTD (time it takes to actually delete After the delete prompt appears, and clicking delete) will depend upon each systems processing power and ram & other pertinent specs; for instance my processor is a 3.4e GHz 800 FSB w/1 GB ram, etc.

The TTD on 2500 0byte txt files for me using the v5.5 Browseui.dll is 15 seconds.
The TTD on 2500 0byte txt files for me using the v6 Browseui.dll is 60 seconds.

You'll really notice the longer time differences on larger groups of files and it is exasperating to wait, but agree that normally many will not need to process that many - however hopefully there is a way that reworking the IE6x Browseui.dll to work better with W98x would make it the ultimate combination with the shell32.dll fix for this whole issue. (also keep in mind since we know that the v6 browseui.dll is somehow involved with this longer delete process delay, then what I really wonder is if there are any other windows/explorer processes that are delayed as well, but we just haven't realized it yet? ..I for one hope not, or I will be much more tempted to leave the v5 dlls in place.

..ps, swapping v5 & v6 browse*dlls back and forth can be as very easy as pressing the number 5 or 6 at the dos prompt.. ..the readme notes in my dllswap.zip talks about that, which is given on my webpage write-up about the subject.

This post has been edited by Rick Chauvin: 13 January 2007 - 09:29 AM

[Rick Chauvin]

LLXX, on Jan 12 2007, 05:19 AM, said:

That speed decrease may simple be due to more inefficient code in the main loop.

Besides that I wanted to bring up this point too, that since IE6 installed on W2000 or WXP for me takes the same 15 seconds on the same 2500 file delete process spoken of above on W98x, then one has to logically conclude that this issue is not an IE6 issue within itself, but only with how they modified it to work within W98x; and so since we know that just swapping to the v5 browseui.dll on IE6 W98x duplicates the exact same normal delete times as IE6x on 2K/XP, then it would be great if in some way it would possible to appropriately/safely rework the v6 Browseui.dll for W98x to do its function properly, while leaving the normal delete times on W98x alone. In combination this would make the ultimate shell32.dll fix!

This post has been edited by Rick Chauvin: 13 January 2007 - 09:26 AM

[erpdude8]

Rick Chauvin, on Jan 12 2007, 01:04 PM, said:

LLXX, on Jan 12 2007, 05:19 AM, said:

That speed decrease may simple be due to more inefficient code in the main loop.

Also I wanted to bring up this point, that since IE6 installed on W2000 or WXP for me takes the same 15 seconds on the same 2500 file delete process spoken of above, then one has to logically conclude that this issue is not an IE6 issue within itself, but only with how they modified it to work within Win9x; and so since we know that just swapping to the v5 browseui.dll on IE6 9x duplicates the exact same normal delete times as IE6x on 2K/XP, then it would be great if it was in some way possible to appropriately/safely rework the v6 Browseui.dll for Win9x to do its function properly, while leaving the normal delete times on Win9x alone. In combination this would make the ultimate shell32.dll fix!

let's remember Rick, that IE6 does not run under Win95. IE6 runs only under Win98 & ME. some people interpret "Win9x" as Win95/98/ME.

so Win95 users are exempt from this deletion of large number of files problem; highest version of IE used under W95 is IE 5.5

[Rick Chauvin]

Technically I used that term Win9x and 9x out of true context you're right, but naturally my mindset was always talking Win98x - and even at that technically leaves out ME which I don't mean to. I know you all knew what I meant though, but I do stand corrected thank you. If the abbreviation W98x can be more appropriate then I will go back and edit my posts.

[glocK_94]

Thanks a lot for the update! :

I translated the new version into french. It can be downloaded here : win9x4ever.online.fr

This post has been edited by glocK_94: 11 March 2007 - 05:43 PM

[MDGx]

Rick Chauvin:

Anonymous author replied to your comments:

Quote

Rick Chauvin wrote on Jan. 10, 2007 08:54 PM:

> It was never an exact science however ...

Thanks a lot for the detailed description of how to trigger the bug. As a
matter of fact, your 2500.ZIP file came in very handy when I started
looking into what was causing the EXPLORER hang. It was in part prompted
by the observation of a few years back that some software installation
programs also triggered the hang when they cleaned up a large number of
temporary files at the end of the installation process.

> Originally I used what was right from the retail cd which was v4.10.2222
> ...

This may explain why you noticed a difference in success rates going from
4.10.2222 to 4.10.2226. I would not expect to see a change in success
rate going from 4.10.2225 to 4.10.2226. The changes to SetFilePointer in
4.10.2226 cannot possibly affect the EXPLORER hang.

> ... and so naturally we wonder if that slow delete process problem in
> the IE6x BROWSEUI.DLL can at some point also be fixed too?

I don't know I am afraid. It is not just code in SHELL32.DLL &
BROWSEUI.DLL that is executed at that point. For example, SHLWAPI.DLL and
SHDOC401.DLL play a role as well. So pinpointing the real issue may be
prohibitively time-consuming. It is also possible that it is a fundamental
limitation of the Win9x architecture.

> Also a question that begs to be answered please, since the new
> shell32.dll takes care of not only the 2-4 GB file usage on Win9x, and
> now the explorer hang bug - is there any reason or benefit whatsoever!
> to also use your new copy2b's Kernel32.dll ??? If you would elaborate,
> thank you.

Unless you have applications that use _llseek and/or SetFilePointer *and*
do not work correctly with 2-4-GiByte-long files, there is no real benefit
from 4.10.2226. However, I would recommend against using 4.10.2222. There
are important bug fixes in 4.10.2225.

HTH

[bristols]

I've come across a potential problem with this latest update (build 4.72.3812.634).

Ever since installing the update, I've been unable to connect to servers via WebDAV; either via native Windows WebDAV, or through the Novell Netdrive client (version 4.1.873). Netdrive uses its own WebDAV DLLs, but both use SHELL32.DLL.

Could anyone else test this?

[bristols]

I've been testing the WebDAV problem I mentioned in the post above for 3 hours. I got other people, including the server administrators, to confirm that everything server-side was working as expected. None of these people used SHELL.DLL 4.72.3812.634, and none of them had problems using WebDAV. Similarly, I could retrieve other files on the server with no problem, so there were no network issues as such.

I reverted back to 4.72.3812.620 and WebDAV began working again. So the WebDAV problem was definitely introduced by SHELL32.DLL 4.72.3812.634.

MDGx, please inform the anonymous author.

This post has been edited by bristols: 15 January 2007 - 12:39 PM

[MDGx]

bristols, on Jan 15 2007, 11:34 AM, said:

I've been testing the WebDAV problem I mentioned in the post above for 3 hours. I got other people, including the server administrators, to confirm that everything server-side was working as expected. None of these people used SHELL.DLL 4.72.3812.634, and none of them had problems using WebDAV. Similarly, I could retrieve other files on the server with no problem, so there were no network issues as such.

I reverted back to 4.72.3812.620 and WebDAV began working again. So the WebDAV problem was definitely introduced by SHELL32.DLL 4.72.3812.634.

MDGx, please inform the anonymous author.

I have.
I'll post here a SHELL32.DLL update if/when I receive it from the Anonymous author.

Thanks for your feedback.

[bristols]

Thanks MDGx.