Rick Chauvin

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!

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

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.

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

..repeating again, this problem ONLY !!! showed up if you have MSFN entered into your Trusted Zone (irregardless if you even have all boxes checkedoff enabled or not) and it only showed up on some of the MSFN webpages where shown the RSS placed in my screenshots; yes it showed up on all three W98x/W2K/WXP OS's w/IE6x installed. I already explained it was not in the RSS.png itself but in the ditty that operated its drop down function. If you do not have MSFN entered into the Trusted Zone or use that feature and you're using the standard Internet Zone - then yes it worked fine for you - and this post was never for or about you. ~ As I see today that the previous webpages that the problems existed - the RSS ditty has now been removed and it works fine for the instances I was specifically addressing... ************************* EDIT A week or so after this last post, msfn started using the RSS ditty again, and when they did once again we have the same siutation as explained in my above posts on some of msfn's webpages, and only in the situation I had described. Also today I started noticing that when posting a message onto this board and when I see the rss not fully loaded in my bottom left tray while I'm in the process of creating a message to post it, is when it seems that my browser will crash also - if it's related or not I don't know, but now I see someone else having this problem too http://www.msfn.org/board/index.php?s=&amp...st&p=619502. *************************

xper I understand what the png image is but my point was only that on some of your webpages it's not finishing and hangs at the point specified. The first time post test I was booted to W98SE and so today I booted to W2Kpro and WXPro and it does the same exact thing on each different OS's with different IE versions even.. but important clues to the problem are in the next paragraphs, but first here's two more screenshots this time taken while on WXP (last time was W98SE, not that it matters) (these are only quick 'low quality' gif screenshots N1K so don't get nervous since they're meant for quick visual reference and not for visual acuity) Screenshot Screenshot2 Since the rest of you said you didn't notice the issue yet and I knew I wasn't just talkin' idly - so I looked into it a bit more today. One thing is that it shows up on some, but not all webpages; another interesting point is that MSFN has to be in the Trusted Zone to do it (even if everything is all checkmarked Enabled in there - it will still do it) ..but if I 'Remove' MSFN from the Trusted Zone and it's just in the Internet Zone - then it wont do it - interesting sure, but moreso that it's also proven on each W98SE/W2K/WXP.... Here's a few other tidbits that will clue you into the problem, and yes naturally it's not the RSS png itself, besides since as you can see by my screenshots that it's already loaded but still hangs for it.. ..and so mostlikely the problem is in the ditty of the RSS png action, meaning that if I go down and hover my mouse on that bottom left RSS.png to drop down its ditty, then it will all the sudden finish loading itself.. ..the issue is in the dropdown ditty and only under the situations described. This is not a big deal to me at all - I was just playing solving a clue is all which is fun to do. It's of no consequence to me if you fix it or not other than it's the unresolved little details that get my attention... Rick

just a fyi, is I noticed whenever I'm surfing most pages on this forum, the browser will not completely load leaving just one png item to be finished, and that png item is as shown in these low quality gif screeshots for reference. Screenshot1 Screenshot2 It has something to do with the RSS feeds I guess, or needs a better script to run them? This problem for me ONLY! shows up if you have MSFN entered into your Trusted Zone (irregardless if you even have all boxes checkedoff enabled or not) and it only shows up on some of the MSFN webpages where the RSS is placed as shown in my screenshots later in this thread; yes it shows up on all three W98x/W2K/WXP OS's w/IE6x installed - it is not in the RSS.png itself but in the ditty that operates its drop down function. If I go down and hover my mouse on that bottom left RSS.png to drop down its ditty, then it will all the sudden finish loading itself.. ..the issue is in the dropdown ditty and only under the situations described. If you do not have MSFN entered into the IE6 Trusted Zone or use that feature and you're using the standard Internet Zone - then yes it works fine for you - and this post is not meant for you. Looking at the webpage script I can see they even talk of the issue at the end of this particular script ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ </script><!--TASK--><img src='http://www.msfn.org/board/index.php?act=task' border='0' height='1' width='1' alt='' /><!--ETASK--> <table cellspacing="0" id="gfooter"> <tr> <td width="45%"><img id="rsssyndication" src='style_images/msfnskin/rss.png' border='0' alt='-' class='ipd' /> <script type="text/javascript"> //<![CDATA[ menu_build_menu( "rsssyndication", new Array( "<a href='http://www.msfn.org/board/index.php?act=rssout&id=13' style='color:black'>MSFN Programming Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=14' style='color:black'>MSFN Application Installs Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=15' style='color:black'>MSFN Windows Vista Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=16' style='color:black'>MSFN Windows XP Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=17' style='color:black'>MSFN Windows NT4/2000/2003 Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=18' style='color:black'>MSFN Windows 95/98/98SE/ME Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=19' style='color:black'>MSFN Windows XP 64 Bit Edition Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=20' style='color:black'>MSFN Windows XP Media Center Edition Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=21' style='color:black'>MSFN Microsoft Office 2000/2002/2003/XP/2007 Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=22' style='color:black'>MSFN Unattended Windows 2000/XP/2003 Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=23' style='color:black'>MSFN Unattended Vista Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=24' style='color:black'>MSFN Device Drivers Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=25' style='color:black'>MSFN Windows PE Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=26' style='color:black'>MSFN Multi-Boot CD/DVDs Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=27' style='color:black'>MSFN Customizing Windows Forums</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=28' style='color:black'>MSFN Software Hangout Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=29' style='color:black'>MSFN Hardware Hangout Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=30' style='color:black'>MSFN Networks and Internet Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=31' style='color:black'>MSFN Malware Prevention and Security Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=32' style='color:black'>MSFN nLite Forums</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=33' style='color:black'>MSFN vLite Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=34' style='color:black'>MSFN Windows Post-Install Wizard Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=35' style='color:black'>MSFN XPize Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=36' style='color:black'>MSFN Other Member Contributed Projects Forums</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=37' style='color:black'>MSFN Graphics and Designing Art Forums</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=38' style='color:black'>MSFN Webdevelopment Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=39' style='color:black'>MSFN Server-Side Help Forum</a>", "<a href='http://www.msfn.org/board/index.php?act=rssout&id=40' style='color:black'>MSFN Technology News Forum</a>" ) ); //]]> </script> </td> <td width="10%" align="center" nowrap="nowrap"><a href="lofiversion/index.php/f8.html"><b>Lo-Fi Version</b></a></td> <td width="45%" align="right" nowrap="nowrap">Time is now: 16th February 2007 - 10:39 AM</td> </tr> </table> <script type='text/javascript'> //<![CDATA[ menu_do_global_init(); show_inline_messages(); // Uncomment this to fix IE png images // causes page slowdown, and some missing images occasionally // if ( is_ie ) // { // ie_fix_png(); // } //]]> </script> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rick

Yes, whichever browse*dll I use at any particular moment, I will have in place the new kernel32.dll; however, speaking of which, I was trying to decipher some previous posts between you and anonymous about where he says: I assume you both are on the same page with this now and each of your kernel32.dll's are set the same way? iow, it's really hard for members to go back and decipher all the previous posts now to know which file one should use - his or yours, and understand the differences why? Thank you LLXX for what you do here at MSFN. ~~~~~~~~~ OT; I've once again edited my last Post just previous to this one to better reflect current testing accuracy, to what I was saying before. thanks, Rick

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

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

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. 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. ..again well understood Okay thank you for the tip. 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. 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) 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!

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

"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

As you can see by my following screenshot from my software file/registry trackers GUI with only the System Folder tab changes open, shows me that each of the files you have listed in your above list have been replaced with the 925454 MSFN Cumulative for IE6 on W98SE installer anyway, so there was no need to do it manually. Naturally no regsvr is needed since this is Win98 and the files are just being replaced. The problem with just manually replacing files like you did, is as shown by this next screenshot of just the HKLM tab changes made by the install, that any of these ActiveX Compatibility registry entries that are also installed/needed for 925454, you are not getting them unless you had applied your own reg fix, otherwise if anything there points to any of the dlls then your new dll's references go nowhere. I would think without question for ease and simplicity that instead of fussing with doing it manually (which though can be many time the fun of it) ..but by using the MSFN's 925454 the whole job gets done at once and qualified, but for your comfort if/when you track the install then as I've shown in my screenshots, many of your answers will be known as you interpret the information going though the relevant tabs that show changes to whatever File or Registry tabs that the install made. As far as your comptability question, that's a good question.... it seems to be working normally here and I have a good feeling about it, and I have also a good feeling about MSFN only including in their IE re-works what's appropriate. I was under the assumption that the IE6 platform for W2K in regards to many of the IE6 files are compatible to the IE6 W98 platform. As for you 2nd posts question where you ask about: "The MS patch for Win-2K contains these files which are not mentioned in the patches being made available on this forum" ..and I would say whether or not they were mentioned in the forum, as you can see by my screenshot they are included in the MFSN 925454 cumulative, that is, the first 3 that you mentioned under that question. Rick

..another update to my previous posts. I'm a happy and willing tester of your fix - and btw thank you for working on it! Here's some more info: I've found that with this quantity file delete hang problem that replacing with your new version of shell32.dll is 'much much better' than using the original of course, and it is effective, but occasionally it does still fail as stated in the 'geek speak' notes of the installer, and other less occasional instances it fails too. 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' as compared to the v6 browse*dlls is a much faster moving delete process, and as we know it rarely freezes up with them like the current v6 browse*dlls do with or without the new shell32.dll (again though the new shell32.dll file is much!!! better than without it while using the IE6 browse*dlls) ...having said that though I do want to express a very big vote of Thank You's and encouragement to all the people who have taken the time to work on the shell32.dll fix for this quantity file delete hang problem, and that it is Greatly Appreciated for all of what you are doing with it, along with all the other neat stuff on this website. Thank You! Rick W98xIE6xQuantityFileDeleteHangBug

An update on my previous post is that since I first installed the Shell98.exe fix which did not work for me at first, but then later after I had read more of the threads and noticed it also suggested in conjunction with the Shell98.exe to also install the Copy2gb.exe just in case, and so I did - well that appeared to solve the problem for me. I've deleted the 2500 files and restored them back from the recycle bin over and over with no abnormal hang problems. I need to test it a few more times but at the moment it looks like it may be a good alternative instead of using the IE v5.5 Browselc.dll & Browseui.dll's to solve the large file quantity delete problem. If you wanted to know of any small differences between the two methods, the only minor difference I noticed is that with the 5.5 browse dlls in place, and after doing a 'select all' on 2500 files and pressing delete, and then when the delete prompt comes up and you press delete - then from there it only takes 10 seconds to delete the 2500 files. But with the v6 browse dlls in place from that same point it takes longer at 70 seconds to delete the same 2500 files. However to note doing a 'select all' and a restore on those files from the recycle bin, then in both cases it only takes 10 seconds to put them back and so the recycle bin restore function in each case seems to be fine, but I assume it's just the v6 dlls somehow effects a delay on the actual delete process as you watch the numbers from 1 to 2500 count up as it deletes.. I don't know if any more functions are belabored because of the v6 dll's though, it'll take more time to notice that of which I'm curious. Nice work to everyone involved, and thank you. You have my full attention Rick

Petr, with what you and Max_04 found, is that problem just a testing issue with Restorator, or would that also effect the files opertion itself - and would it have to be redone?

MDGx, erpdude8, etc ps to my yesterdays post... 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? Rick

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. As for the shortcut arrows, I actually so very much prefer the shortcut arrows to be visible - and so no changes needed for me there. Thanks very much for what you do.. ..and hopefully the file delete hang bug fix can be further refined someday while it's still up front to do so.. Rick