Jump to content

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


MDGx

Recommended Posts

-I agree, Anonymous, we all get a little wound-up at times (especially Erpdude8 ;) , and, yes, myself :blushing: ), don't take it personally, just a little over-enthusiasm for our own viewpoints sometimes...

-You still of course know that we all (incl. Erp) worship your work and place you up on the highest pedestal along with MDGx & Co. :thumbup

UBER-appreciations, guys...

>;]

Link to comment
Share on other sites


I don't think that a dispute regarding file-dating and build-numbering logic with one MSFN member, regardless of the rights or wrongs, has to mean that you withdraw your support from the whole community, which in general has been extremely grateful to you for your work and interest.

I agree and I would personally be even more grateful if Anonymous could some day remember the extra setting, he talked about some time ago, which allows to set a custom size for 32bit resources.

Link to comment
Share on other sites

Since Anonymous is a volunteer and willing to share his ability on his own time and dime has to be given a great deal of credit and admiration to say the least - and endless appreciation. I know we all here must feel the same way. I don't know erpdude8 personally but I certainly don't think he meant a wrong to cause any discontent at all, and was just micro focusing on a particular point is all - but let's keep the right focus in sight and especially the appreciation going in the 'right direction' here where it belongs considering all things in perspective. I know we all have and give full support for Anonymous to continue and would foster that possibility in every way. Certainly I do support him continuing with his new findings he spoke of and to release them to help the 'Explorer Hang' anomaly even further.

Anonymous, I and we all give a great respect and admiration for what you do, and ask that you would please continue, please, since it is so well appreciated the effort that you give and your abilities and willingness to share them.

Thank you

Link to comment
Share on other sites

  • 1 month later...

I hope Anonymous still is considering releasing Shell32.dll v4.72.3812.640, very very please :thumbup

Quote from Anonymous:

[...]

When developing 4.72.3812.640, I also came across very simple methods that are bound to cause the EXPLORER hang even if v5.5 BROWSExx.DLL files are installed! So please stay tuned!

If you would please consider that if needed I would be very happy and qualified to be a beta tester before it's released even; fwiw a number of times so far in the last few months, even though rare, I have had it still uniquely hang with v4.72.3812.634 in place. I have been respectfully and even patiently excitingly awaiting to bring this to the next level with v4.72.3812.640

..Thank you very much for considering it..

Link to comment
Share on other sites

Rick Chauvin:

Anonymous author replies to your question:

I am sorry I got your hopes up, Rick. 4.72.3812.640 will not be released. 640 has no new functionality and 640 in its default state works as 634 does. 634 is already designed to prevent the Explorer hang (= Explorer's unresponsiveness even when just one file is renamed, deleted, moved, etc. after a "bulk delete") 100% and I verified with a debugger that it does so 100%. The code in 640 was rearranged and slightly modified so that certain sections, subfunctions, etc. of the patch could be modified, turned off, etc. more easily, but at the risk of bringing the Explorer hang back!!! That's all. AFAIK, there have been no reports of side effects, so there appears to be no need for 640 to pinpoint possible causes of side effects. Please post more information on the 'hangs' you are referring to in your post. They may be caused by something else. What is commonly referred to as the "Explorer hang" is technically impossible with 4.72.3812.634.
Link to comment
Share on other sites

I have removed this patch (on Windows ME) because 1) I still got explorer freezes in some circumstances and they seem to a bit be nastier than the normal ones (apparently it happens when using another aplication that works with the file system while doing file ops with explorer), 2) I did not like how the entire computer hangs for a few seconds in the other circumstances when the fix prevents the freeze.

All in all my personal workaround to the explorer freeze is better to my taste as I am back on my feet within two seconds only whenever it happens.

Any chance you remember the settings for increasing the size of the 32bit resources anonymous author of several patches ? :)

Link to comment
Share on other sites

Two points:

The problems I had (previously mentioned in this thread) with connecting to servers via webdav, which had seemingly been introduced by the Anonymous Author's shell32 update, have disappeared with the latest 634 build. I have no idea why this is - at least nothing to my knowledge has changed to affect things at the server I connect to. But the problems trouble me no more. So, thanks, Anonymous Author, if you brought about this positive result. :thumbup

Secondly though, I do find your response to erpdude here somewhat petty, if I may say so. I don't think that a dispute regarding file-dating and build-numbering logic with one MSFN member, regardless of the rights or wrongs, has to mean that you withdraw your support from the whole community, which in general has been extremely grateful to you for your work and interest.

Anonymous author replies:
'bristols' wrote on Feb 28, 08:05 AM:

> ... Secondly though, I do find your response to erpdude here somewhat

> petty, if I may say so ... extremely grateful ...

Many thanks for letting me know. I am really pleased to know the patch

works for you now. No, the dispute alone was clearly not the reason -

'erpdude8's' demand and the posting of 635 *plus* the dispute was. It then

becomes prohibitively time-consuming to look at things if some new issue

with the patch happens to surface - one version is really "bad enough."

I think I let this forum know before: "I have a life!" (= such disputes

are petty and I do not get involved).

HTH
Link to comment
Share on other sites

This particular post by itself has nothing to do with the Explorer Hang issue, but I want to clarify here at this point only because a few of my previous posts in this thread where I had mentioned about me getting excessive Send Error reports, and so now wanted to explain that I did finally resolve that issue last month but was by me simply restoring a partition image of C:\ from two months earlier where I knew it did not have that problem at all - and it still does not. I had then updated three of anonymous updates: Copy2gb.exe, Shell98.exe, and U891711.exe and of course it's still fine for that. I have not had the time/incentive to reinstall the few other updates besides those to isolate which of the other new updates were causing my Send Error problem in the first place.

Edited by Rick Chauvin
Link to comment
Share on other sites

Rick Chauvin:

Anonymous author replies to your question:

I am sorry I got your hopes up, Rick. 4.72.3812.640 will not be released. 640 has no new functionality and 640 in its default state works as 634 does. 634 is already designed to prevent the Explorer hang (= Explorer's unresponsiveness even when just one file is renamed, deleted, moved, etc. after a "bulk delete") 100% and I verified with a debugger that it does so 100%. The code in 640 was rearranged and slightly modified so that certain sections, subfunctions, etc. of the patch could be modified, turned off, etc. more easily, but at the risk of bringing the Explorer hang back!!! That's all. AFAIK, there have been no reports of side effects, so there appears to be no need for 640 to pinpoint possible causes of side effects. Please post more information on the 'hangs' you are referring to in your post. They may be caused by something else. What is commonly referred to as the "Explorer hang" is technically impossible with 4.72.3812.634.

*As far as the Explorer hang issue, when I say that it's still there although shows itself in a slightly different presentation for before/after - I am being straight since I see it still happening in different ways, and having had co-existed with it for too many years to know it's not another issue; however not having the tools to present the exact debug details, then I do certainly understand that anonymous want's the in-hand proof. It may have more meaning to you though if you see it first hand since seeing is believing and the fact you'll have your familiar tools in hand to debug it; realize though if you readily use your WXP partition all day long and don't exclusively use W98SE throughout the day for All various tasks - then you may not notice it show up/happen so easily like those that do since giving it the full opportunity to present.

The trigger in some ways is somewhat different now, and it doesn't necessarily trigger anymore by a specific quantity near 2500 file delete, although not as often but yes still does present by some of the other same varying ways (I see epidenk noted it too in his last post) that it did before although I say it's somewhat morphed in a few instances; for one of a few examples is that when it hangs - then just like I had outlined in the beginning when you go to rename a file it still hangs but now a morph is that after it hangs for the 10 seconds it will recover whereas before it wold not - so in some ways it's different yes, but yet the core cause is still there. Swapping out the browse*dlls just like before gets around the problem giving another indication it still exists. Remember as you said before the original IE6 problem is not in the shell32.dll itself but was just that you creatively found a unique way to 'work around' the explorer hang issue while also curtailing resource usage via the shell32.dll, which worked great thank you. I'm saying that the original Explorer Hang problem (not originated in shell32.dll or anything you did) still exists and can still somewhat show/manifest itself aprox 10% of the time (other than what you uniquely did to workaround it in the shell32) is all.

I'd be glad to do whatever in my time constraints to give you debug information if you supply the debug software and details of what to do; otherwise I have no problem with leaving it just as it is while booting to and staying with W2K/WXP going forward, since the reason I had been staying booted lately almost exclusively to my W98SE partition at home is because at the time when I joined the msfn group was to in some way try to be a help to you to put the Explorer Hang issue to bed once and for all, if possible. It's come a long way, thank you for that. I do wonder why epidenk is the only other one 'so far' who has brought it up that the problem still exist; maybe epidenk could help to give you the extra input you seek as well.

If I could see into the future and knew for sure there was never to be another update in any form to solve the rest of the Explorer Hang issue though, then without much ado I would press 5 at my dos prompt to put the v5.5 browse*dlls back in place since taking All aspects of the situation into consideration, to me it's still the best most convenient resolve around, and afaiac, does not have any 'less than' security issues, and the convenience of much faster bulk file deletes along with 99.9% freedom from any original Explorer Hang irritability's means the most to me. YMMV. I do honestly hope though that you will get the debug info you need to see the rest of the underlying story, because I believe you have the know how to fix it - we just need to put the root cause information in front of you, or have it happen on your own setup, so that you can see what we see - and then you will be able to figure out how to resolve it.

*Note though as compared to many others here at MSFN, I do not have any version of W98SE SP2 nor 98SE2ME installed either, which may or may not make a difference to this explorer hang problem. For me except for the 3 anonymous created updates my W98SE partition is pretty much a stock SE install using all original MS updates, fwiw.

Link to comment
Share on other sites

Rick Chauvin + eidenk:

Anonymous author replies:

On Apr 16 2007, 01:46 PM, Rick Chauvin wrote:

> ... then without much ado I would press 5 at my ...

Rick,

I am afraid you will have to go back to your v5.5 browsexx.dlls then: You remembered correctly that the original problem is not in SHELL32.DLL, the root cause of the problem is somewhere in USER.EXE. However, it is in SHELL32.DLL where the unresponsiveness comes from. 4.72.3812.620 was a "work-around" as it just minimized the risk. I created 4.72.3812.634 b/c I happened to come across what got "messed up" after a "bulk file delete." When Explorer became unresponsive even if just one file was moved, renamed, etc. I was able to go in with the right tools and stop it (of course w/o killing EXPLORER.EXE). Likewise, I was also able to create this situation of unresponsiveness even w/o any prior bulk file delete operation (that's why I am also sure the Explorer hang is possible with IE4, IE5, IE5.5, etc.). Even when I create a situation like this, 4.72.3812.634 "recovers 100%," that is, file rename, move, etc. operations are as before, as if nothing has ever happened. As I wrote before, the Explorer hang is therefore technically impossible with 634.

'eidenk' is using WinMe and 5.50.4134.120, the equivalent of 4.72.3812.620, the "work-around" as I called it. There is no WinMe equivalent of 4.72.3812.634. This fully explains what he is reporting in his latest post on this topic.

I hope this helps.

Link to comment
Share on other sites

Oh right, there has been two fixes on 98SE and only the first of those has been made for ME. I hadn't read properly and got confused by the fact that Rick Chauvin and myself seem to report the same behaviour.

I confirm that IE 5.5 is affected by the explorer freeze bug as I am using IE5.5. For that reason I always found weird reports of people saying that a transplant of IE5.5 files into a IE6 installation was fixing the problem.

I usually move lots of files around and that freeze is so annoying that I have would have probably moved to another platform if I hadn't devised a satisfactory workaround/fix to that problem several years ago.

Link to comment
Share on other sites

Rick Chauvin:

Anonymous author replies:

Rick,

I am afraid you will have to go back to your v5.5 browsexx.dlls then: You remembered correctly that the original problem is not in SHELL32.DLL, the root cause of the problem is somewhere in USER.EXE. However, it is in SHELL32.DLL where the unresponsiveness comes from. 4.72.3812.620 was a "work-around" as it just minimized the risk. I created 4.72.3812.634 b/c I happened to come across what got "messed up" after a "bulk file delete." When Explorer became unresponsive even if just one file was moved, renamed, etc. I was able to go in with the right tools and stop it (of course w/o killing EXPLORER.EXE). Likewise, I was also able to create this situation of unresponsiveness even w/o any prior bulk file delete operation (that's why I am also sure the Explorer hang is possible with IE4, IE5, IE5.5, etc.). Even when I create a situation like this, 4.72.3812.634 "recovers 100%," that is, file rename, move, etc. operations are as before, as if nothing has ever happened. As I wrote before, the Explorer hang is therefore technically impossible with 634.

I hope this helps.

Anonymous,

The v4.72.3812.634 shell32.dll workaround may have changed how it presents itself 'on your test bed setup with your debug tools installed' but the hang still does present itself on mine, and once it hangs yes it does recover after you wait 15 or more seconds that is correct which it did not do before, but still while on the same boot it still will hang again for another 15 or more seconds on the next awaiting trigger event, and so on and so on - and in that sense it's still somewhat the same nuisance of explorer hang.

I just had it hang again today on my setup simply by deleting selective stuff from my recycle bin, which prompted me to come back here to your post just now and reply again - but certainly not in a challenging way at all - but only in a positive fyi way to say what is true in my experience and to try and get clarification. This is how it is with a 'stock' W98SE setup, not just on mine, but on the 3 others that I have access to now - however if you are talking about an SP2 or 98SE2ME modified install setups then I don't know how it's on that...which I wanted to ask you do you have those options installed?

Now wait for a minute, I just sat here re-reading your posts words very, very, carefully, a few times, and when you say this.

"Even when I create a situation like this, 4.72.3812.634 "recovers 100%," that is, file rename, move, etc. operations are as before, as if nothing has ever happened"

I think you are saying once the hang happens the workaround will recover without having to reboot now and recovers by itself, if so - yes that is very true I do notice that whereas before you had to reboot to completely clear it. (log off/on sometimes worked but had occasional caveats)

What I've been saying is that the actual trigger still presents itself and hangs, and can hang repeatedly 15+ seconds each time it does - but yes it still will recover each time that it happens without a reboot. It's this 15 second 'explorer hang' that occasionally gets triggered and still keeps presenting itself that I'm speaking about - are you saying different?...are you saying that it does not trigger and hang for 'your' setup 'at all' anymore?

Link to comment
Share on other sites

however if you are talking about an SP2 or 98SE2ME modified install setups then I don't know how it's on that...which I wanted to ask you do you have those options installed?

There should not be any difference whether one is on 98SE, ME, 98SE2ME or whatever pack or version of IE.

but yes it still will recover each time that it happens without a reboot.

This explorer freeze bug is not one that forces you to reboot. It can be recovered from easily with the triple finger salute. When you freeze, do Ctrl-Alt-Delete. Choose to end the explorer task. This will pop the shutdown menu. Cancel it. Wait a few seconds or redo the operation a second time and soon a message box will appear, telling you that explorer is not responding. Choose to end the task. Explorer will then be terminated and will restart automatically. You should be back on a fully functional desktop and explorer.

There is a way of doing the equivalent of this with just one click on the middle mouse button if you are willing to run Cool Mouse 96 as a background task and configure it so that it launches, for example, Nirsoft's explorestart.

Whenever you get that freeze you can then move your mouse cursor to where your taskbar is and then click on your middle mouse button. In one second you'll be back on your feet.

Edited by eidenk
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...