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

[Rick Chauvin]

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

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.

Edited January 13, 2007 by Rick Chauvin

[Rick Chauvin]

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!

Edited January 13, 2007 by Rick Chauvin

[erpdude8]

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

Edited March 11, 2007 by glocK_94

[MDGx]

Rick Chauvin:

Anonymous author replied to your comments:

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.

Edited January 15, 2007 by bristols

[MDGx]

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.

[MDGx]

Bristols:

This is the Anonymous author's answer to your question:

Thanks for letting me know and thanks to 'bristols' for testing and

reporting the issue. I am sorry that the patch seems to have unwanted side

effects.

Unfortunately, I do not have/use WebDAV to test this issue. It would be

good if 'bristols' could post two screenshots: one that shows when it

works with 620 and and one, when it does not work with 634. I need more

information to figure out what could be causing this. How long does it

take with 620 to connect to Web Folders? Is there a timeout when trying to

connect with 634? If yes, how long does it take for the timeout to occur?

Is there a very, very brief, but significant drop in User Resources when

connecting to Web Folders (with 620 or 600)?

HTH

[bristols]

Thanks guys.

I hope what follows will suffice in place of screenshots - I've reproduced the error messages I receive verbatim.

Novell Netdrive is the WebDAV client I tend to use. When connection is achieved (usually after a pause of between 5 to 10 seconds), Explorer.exe automatically opens with the mounted drive showing. My process explorer shows that Novell Netdrive uses its own WebDAV DLLs, not the Windows ones.

If I try to connect to a server via WebDAV (let's say I'm trying to connect to http://www.blahblahblahblah.com/webdav/), using version 634, these are the error messages I get (according to the client I use):

Error messages

From Novell Netdrive client (I get one or the other each time I try):

- Can't connect to http://www.blahblahblahblah.com/webdav/ = No HTTP Response Code found

- Can't resolve http://www.blahblahblahblah.com/webdav/, Error 11001

From Windows Native WebDAV client ('webfolders'):

- Can't connect to the Web server http://www.blahblahblahblah.com/webdav. The server could not be located, or may be too busy to respond. Please check your typing or check to make sure the Web server is available.

Pause before the display of error messages

- With the Novell Client, there is a pause of between 20 and 30 seconds (occasionally longer but never less than).

- With Windows webfolders, the delay is more like 3-5 seconds.

Using SHELL32.DLL 4.72.3812.620

Even when this version is installed, connecting to a server via WebDAV is somewhat flaky, sometimes giving this Novell Netdrive error (as above with SHELL32.DLL version 634):

- Can't resolve http://www.blahblahblahblah.com/webdav/, Error 11001

and this Windows webfolders error:

- Can't connect to the Web server http://www.blahblahblahblah.com/webdav. The server could not be located, or may be too busy to respond. Please check your typing or check to make sure the Web server is available.

but, with 620, I never get the other above 'No HTTP' error experienced with 634.

In any case, with SHELL32.DLL 4.72.3812.620 installed, a couple of tries is usually enough to connect. Connection always comes eventually - more than 3 tries is unheard of. However, using 634, connection is never achieved.

Hope this helps; please let me know if I can be of further help.

Edited January 16, 2007 by bristols

[Rick Chauvin]

Anonymous,

Anonymous author replied to your comments:

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

I was back then and am glad to be a part of the process in any way now. This explorer hang has been one of my pet projects to get fixed for a long time now.

I was very appreciative to have recently found that you all were working on it here too.

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

I understand your point about the other files, and certainly your point about being prohibitively time-consuming.

It's natural for us to ponder though, since the only change needed to IE6 is swapping it's browseui.dll to v5 which quiets not only the Explorer hang, but also puts normal times back to the processing of deleting files - then could that portion of the v5 dll be patterned back to v6 accordingly.. ..afterall v6 internals came from the v5 in the first place.

You don't have to answer that.. ..I was just pondering outloud.

Anyway, thank you for the time you put into this and sharing your ability..

..without question many thank you's to MDGx too..

..and thank you's to everyone here, leaving no one out.

[LLXX]

They changed the structure quite a bit between the 5.x and 6.x versions.

[MDGx]

bristols:

This is the anonymous author's answer:

I saw 'bristols's' reply. I am afraid I do

not know yet what is causing it.

I have a few more questions to help me pinpoint the problem.

Also, when I have a bit more time, I probably will make one or two patches

(626 & 628 or so, not for general release) where some of the code of 634

is disabled to see if it makes any difference in connectivity.

'bristols',

Thanks for your reply. The error messages instead of screenshots will do.

However, I still need more information to understand what changes are

responsible for the loss in connectivity.

When connecting to Web Folders, do you ever get the EXPLORER hang with

version 600? With version 610?

Do you need more than one try to connect with 600? With 610? Did you

observe any differences in connectivity between 600 & 610?

HTH