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

[Rick Chauvin]

erpdude8, after going back and reading previous threads again (you're in most of them I see) I noticed anonymous mentions it to be 4.72.3812.610 and so that is the one I am after please - Does anyone have Shell32.dll v4.72.3812.610 please I would like to get for reference/testing and save - would you please link it here or PM if preferred. Thank you much.

whatever420, thank you for the 4.72.3812.620 version, and yes I certainly did understand your explanation on your aftermarket edits, and the screenshot was a good visual explanation as well)

[MDGx]

Rick Chauvin:

Anonymous author replies to your comments:

I have reason to believe there is a problem with the certificates in ROOTSUPD.EXE under Win9x. I also have some answers to Rick's questions re 4.72.3812.634

Rick Chauvin wrote on Feb 16, 01:22 PM:

> Shell32.dll bug report ):

> latest v4.72.3812.634

> ...

I really doubt the problems have anything to do with SHELL32.DLL 4.72.3812.634.

There appears to be a common misconception about the EXPLORER hang (and the patch): Neither the original code nor the patch touch any file at all. They deal with how the changes resulting from a file operation, such as delete, move, etc., are *displayed*. So the patch cannot possibly cause the permanent deletion of what is in the 'History' subdirectory. (There is a "Paranoia" registry setting in TweakUI that clears the IE history at user logon and maybe that is causing the history to be cleared.) IEXPLORE.EXE obviously uses SHELL32.DLL, but AFAICT IEXPLORE.EXE does not use the patched code, for example, when one clicks on an item in the History pane. In addition, when I developed the patch I swapped original and patched SHELL32.DLL versions far more than once, but did not notice any effect on IE6's history.

I rarely use Win98SE (and IE6SP1) these days, but I did surf the web with IE6SP1 while testing the patch and found no ill side effects from any version including 4.72.3812.640 (= modification to facilitate customization with a HexEditor), which I have not released (and may never release). I checked my FAULTLOG.TXT file (Error reporting is disabled on my PCs) and it appears that crashes in IE6SP1 are very rare.

However, I found a problem that is worth noting: After I installed the latest ROOTSUPD.EXE (January 18, 2007) I noticed that I get a very annoying "race" ("competing") condition in IE6SP1 with some SSL connections. There is *no* difference whether the original 600 or the patched 634 or 640 are installed. Ctrl-Alt-Del is the only way to kill the particular instance of IEXPLORE.EXE and try the connection again.

If the crashes in IE6SP1 should be investigated further, I would need far more information. The DW.LOG file has very little information on the actual crash, so only the full report (that would be sent to M$) or a DrWatson crash file (xxxxxxxx.WLG) would provide useful information.

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!

I hope this helps.

I am sending you a "revised" 4.72.3812.634 (same date!). I hope this one does not trigger the bug/crash in Restorator and makes it easier to create versions for languages other than English [475 KB, English]:

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

Extract this new SHELL32.DLL 4.72.3812.634 using WinZip 9.0/newer, PowerArchiver 6.xx/newer or WinRAR, or by simply installing it on Win98 SE [and found in %windir%\system ].

Best wishes.

P.S.:

SHELL98 has been updated again today [2-19-2007]:

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

HTH

[MDGx]

MDGx, is shell32.dll v4.72.3812.620 the last version change anonymous made for the 2-4gb fix before he started adding explorer hang fixes?

Actually 4.72.3812.610 was the last version that fixed only 2-4 GB files bug.

Beginning with 4.72.3812.620 onward the anonymous author added code to fix explorer/OS lockups.

HTH

[MDGx]

Anonymous author replies:

Tihiy wrote on Feb 10, 04:04 AM:

No, that's wrong. User/Organization/Serial was in USER.EXE only in Windows 95.

And patching latest USER.EXE for win98 and winme will be enough.

However, after patching i haven't noticed any stability improvements, all my resource-draining tests still usually hang system.

So i don't think those patches will be useful. I wish i had an debug win9x version...

Plainly wrong! The information is still there, even under WinME (whether it is used for anything is a different matter). Please take a closer look at USER.EXE *before* you write such nonsense!

Hotfixes such as KB291362 actullay personalize USER.EXE and fill those fields when they install the new version of USER.EXE - I verified that a long, long time ago when KB260067 was released.

I would not expect to see *major* stability improvements (from 'or cx,ax' --> 'or ax,ax'), for three reasons:

(1) A previous call to KERNEL.LOCALALLOC may have failed already, was handled correctly, and the buggy code is no longer executed.

(2) I picked this bug as an *example* (please see that post!) b/c it is easy to understand and is one of the very, very few I still remember where to find. There are other, much less obvious bugs in USER.EXE, where things can go wrong when KERNEL.LOCALALLOC (or KERNEL.LOCALREALLOC) fails (same for GDI.EXE!).

(3) The hang may not be a bug at all, but "perfectly" normal b/c WM processing stops.

If Win9x were designed to work when Resources are low, that is, below 10%, one would not get the well-known warning "Ninety percent or more of your system resources are in use. To free up system resources, quit any programs that you are not using. If you do not, your computer may stop responding." from M$'s ResourceMeter!!!

In my experience, that type of bug is more likely to cause heap corruption (with a subsequent GPF or BSOD) than a system freeze.

As a matter of fact, sometimes I am *truly* amazed how well, really well actually, Win98SE works despite all those bugs (and there are zillions of them)!!! One example is a totally different bug in USER.EXE and there is no fix for it: The splash screen of some programs such as Office XP programs causes a small, but permanent Resource leak in USER.EXE. It also causes a larger Resource leak in GDI.EXE, but that one is concealed very, very cunningly!

AFAIK, Win9x debug versions were available for download from M$ - I do not know if they still are. I am also not sure if they are very useful now as they lack *all* hotfixes.

I hope this helps.

Best wishes.

P.S.: I think I now know what is causing the problems with Restorator ('Max_04'). I will send you a rearranged 4.72.3812.634 when I have a chance to test it out:

download the updated SHELL98 [475 KB, English]:

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

[Max_04]

Anonymous author replies:

Tihiy wrote on Feb 10, 04:04 AM:

No, that's wrong. User/Organization/Serial was in USER.EXE only in Windows 95.

And patching latest USER.EXE for win98 and winme will be enough.

However, after patching i haven't noticed any stability improvements, all my resource-draining tests still usually hang system.

So i don't think those patches will be useful. I wish i had an debug win9x version...

Plainly wrong! The information is still there, even under WinME (whether it is used for anything is a different matter). Please take a closer look at USER.EXE *before* you write such nonsense!

Hotfixes such as KB291362 actullay personalize USER.EXE and fill those fields when they install the new version of USER.EXE - I verified that a long, long time ago when KB260067 was released.

I would not expect to see *major* stability improvements (from 'or cx,ax' --> 'or ax,ax'), for three reasons:

(1) A previous call to KERNEL.LOCALALLOC may have failed already, was handled correctly, and the buggy code is no longer executed.

(2) I picked this bug as an *example* (please see that post!) b/c it is easy to understand and is one of the very, very few I still remember where to find. There are other, much less obvious bugs in USER.EXE, where things can go wrong when KERNEL.LOCALALLOC (or KERNEL.LOCALREALLOC) fails (same for GDI.EXE!).

(3) The hang may not be a bug at all, but "perfectly" normal b/c WM processing stops.

If Win9x were designed to work when Resources are low, that is, below 10%, one would not get the well-known warning "Ninety percent or more of your system resources are in use. To free up system resources, quit any programs that you are not using. If you do not, your computer may stop responding." from M$'s ResourceMeter!!!

In my experience, that type of bug is more likely to cause heap corruption (with a subsequent GPF or BSOD) than a system freeze.

As a matter of fact, sometimes I am *truly* amazed how well, really well actually, Win98SE works despite all those bugs (and there are zillions of them)!!! One example is a totally different bug in USER.EXE and there is no fix for it: The splash screen of some programs such as Office XP programs causes a small, but permanent Resource leak in USER.EXE. It also causes a larger Resource leak in GDI.EXE, but that one is concealed very, very cunningly!

AFAIK, Win9x debug versions were available for download from M$ - I do not know if they still are. I am also not sure if they are very useful now as they lack *all* hotfixes.

I hope this helps.

Best wishes.

P.S.: I think I now know what is causing the problems with Restorator ('Max_04'). I will send you a rearranged 4.72.3812.634 when I have a chance to test it out:

download the updated SHELL98 [475 KB, English]:

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

Now restorator is ok, what it is necessary to edit in shell32.dll italian?

[Rick Chauvin]

Anonymous author replies:

I really doubt the problems have anything to do with SHELL32.DLL 4.72.3812.634.

I agree with you, but for whatever reason SendErrorReports for me anyway, appears to happen much less with shell32.dll 4.72.3812.600 than with 472.3812.634 giving various iexplore.exe application failure errors; however...*

It is true last week I did loose the History Listings contents when I swapped dlls back and forth, but.., having tried it a number of times since then I cannot reproduce it again so just let it go if it's not relative.

What I can say is that I've noticed a sharp increase in the amount of SendErrorReports that are prompted lately which before I 'seldom' saw any therefore had no reason to even think about dw being on. No doubt there was a change that has happened for me to cause this and is what I've tried to pin down - the thing is as of yet I cannot tell you exactly what is causing it since when I did the last number of updates - naturally it was not on my mind to go right out and surf websites to see if I could get SendError prompts; and so that's the reason for the Unknown of When it started with this, and so at this point I can only go backwards and reverse what I'd done in the meantime - which are a few things, for instance to possibly complicate the issue is that I had also installed MSFN's latest W2K IE and OE Cumulatives reworked to install on W98SE:

~ ie925454.exe = W98SE - MS06-072, 925454, Cumulative for IE, 12/2006

~ oe911567.exe = W98SE - MS06-076, 923694, Cumulative for OE, 12/2006

However, I found a problem that is worth noting: After I installed the latest ROOTSUPD.EXE (January 18, 2007) I noticed that I get a very annoying "race" ("competing") condition in IE6SP1 with some SSL connections. There is *no* difference whether the original 600 or the patched 634 or 640 are installed. Ctrl-Alt-Del is the only way to kill the particular instance of IEXPLORE.EXE and try the connection again.

*Ahhh, then maybe that roots update could be it then since yes I did install that 10,0,2195,0 Root Certificate mentioned to do from msfn... ...okay I've just now reversed the install of 10,0,2195,0 back to v9,0,2195,0 easily - hopefully this is the issue causing it since you noticed the things you did; alternately hopefully it's not the ie925454.exe update I previously did - but if it was I could easily reverse that too.

If the crashes in IE6SP1 should be investigated further, I would need far more information. The DW.LOG file has very little information on the actual crash, so only the full report (that would be sent to M$) or a DrWatson crash file (xxxxxxxx.WLG) would provide useful information.

I wish that "error report contents" box with its mini dump info would let a copy work within the box, or a way to easily save it..

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!

That's great, and fwiw I've absolutely seen the specific explorer hang with v5.5 as you've previously mentioned, although it was rare but I did see it; I've also absolutely seen the specific explorer hang even when the v5.5 dll's are used in v6 but here too it's not very often at all... Also fwiw, I have three times so far seen the specific explorer hang even using the new shell32.dll v4.72.3812.634 but here too comparatively it's not very often and so I'd call it 97% effective over the original.

If you are contemplating a v4.72.3812.640 in the works with the few issues mentioned you've found and fixed, even if beta, please do let me test it!

Hopefully with the roots reverted back to v9,0,2195,0 I will not see any more SendErrorReports - I may even disable the dw which produces it.

Edited March 16, 2007 by Rick Chauvin

[Rick Chauvin]

MDGx, is shell32.dll v4.72.3812.620 the last version change anonymous made for the 2-4gb fix before he started adding explorer hang fixes?

Actually 4.72.3812.610 was the last version that fixed only 2-4 GB files bug.

Beginning with 4.72.3812.620 onward the anonymous author added code to fix explorer/OS lockups.

Yes but after that post you are quoting and as you can see by the very first post (#121) on this webpage, I did realize it was v4.72.3812.610 that I wanted to get for reference/archive/testing. Do you or anyone still have v4.72.3812.610? Thank you.

[MDGx]

Do you or anyone still have v4.72.3812.610? Thank you.

Please email me:

http://www.mdgx.com/form.htm

and I'll send it to you.

HTH

[MDGx]

Max_04:

Anonymous author replies:

I am attaching the Italian SHELL32.DLL (as a *one-time* exception!).

Repacked with iexpress installer:

SHELL32.DLL Fix [475 KB, Italian]:

http://www.mdgx.com/files/SHELL98I.EXE

Max_04 wrote on Feb 19, 2007 02:27 PM:

> Now restorator is ok, what it is necessary to edit in shell32.dll

> italian?

Check sum!

BTW, I guess it is a bug in Restorator. Restorator apparently does not take into account that there are fewer restrictions on the PE format if the file alignment is in page sizes (0x1000 for x86 CPUs).

HTH

[Max_04]

Max_04:

Anonymous author replies:

I am attaching the Italian SHELL32.DLL (as a *one-time* exception!).

Repacked with iexpress installer:

SHELL32.DLL Fix [475 KB, Italian]:

http://www.mdgx.com/files/SHELL98I.EXE

Max_04 wrote on Feb 19, 2007 02:27 PM:

> Now restorator is ok, what it is necessary to edit in shell32.dll

> italian?

Check sum!

BTW, I guess it is a bug in Restorator. Restorator apparently does not take into account that there are fewer restrictions on the PE format if the file alignment is in page sizes (0x1000 for x86 CPUs).

HTH

Thank you for your help.

Edited February 22, 2007 by Max_04

[Rick Chauvin]

Just some notes fwiw, is that within a few hour time period within the past two days while just using the internet for normal interaction of different websites, I've received 3 Send Error Reports prompts already. I cannot accurately tell if having had reverted back to the previous Roots version helped or not - although it seems it's less.

FWIW even if a little help, here's each of the error prompts info I could copy just from the front header box only.

AppName: iexplore.exe AppVer: 6.0.2800.1106 ModName: browseui.dll

ModVer: 6.0.2800.1896 Offset: 00031a6a

AppName: iexplore.exe AppVer: 6.0.2800.1106 ModName: ole32.dll

ModVer: 4.71.2900.0 Offset: 000a6f0d

AppName: iexplore.exe AppVer: 6.0.2800.1106 ModName: kernel32.dll

ModVer: 4.10.0.2224 Offset: 0000b9a6

Before these particular entries above though, there have been other files that are listed as the trigger, even shell32 was listed as well.

The Faultlog.txt didn't manage to get written to for these last three times, however other times previously it did.

~~~~~~~

Too see if it makes a difference I've decided to next reverse the msfn modified ie925454.exe IE Cumulative I mentioned.

...or...

if instead it's more appropriate I can instead just shut this SendTo reporting OFF

HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main

"IEWatsonEnabled"=dword:00000000

Realize I don't give a hoot about DW and it's error reporting if it's not important or has valuable meaning.

I never even realized the blessed thing was on, but lately it's been quite busy and so has been in my face to notice it and is the only reason why I brought it up.

Anonymous, I didn't mean any harm insinuating it was because of any specific modified shell32 or kernel32 and I apologize for that since I'm not sure anymore, and it just appeared that way at the moments; actually I've found after I had rotated in/out all versions of shell32 and even kernel32 that all of the different versions whether more or less for each, but still can be listed as a cause in the prompts - but as well at other times many other files can be the only ones listed as the cause too..

Edited March 16, 2007 by Rick Chauvin

[erpdude8]

I am sending you a "revised" 4.72.3812.634 (same date!). I hope this one does not trigger the bug/crash in Restorator and makes it easier to create versions for languages other than English [475 KB, English]:

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

this should NOT be released as version 4.72.3812.634! GIVE IT A DIFFERENT BUILD NUMBER!!

Why not release the "revised" shell32.dll file is 4.72.3812.635? That way, you avoid confusion and users will be able to tell the difference between the changes. When a DLL or any system file is revised, it SHOULD be given a different version or build number.

[MDGx]

Why not release the "revised" shell32.dll file is 4.72.3812.635? That way, you avoid confusion and users will be able to tell the difference between the changes. When a DLL or any system file is revised, it SHOULD be given a different version or build number.

Done.

Please see:

http://www.mdgx.com/web.htm#9SU

and:

http://www.msfn.org/board/?showtopic=46581

and:

http://www.msfn.org/board/?showtopic=84451

HTH

[MDGx]

UPDATED 2-28-2007

SHELL32.DLL English restored to proper build 4.72.3812.634 :

http://www.msfn.org/board/?showtopic=84451

Anonymous author replies...

QUOTE (erpdude8 @ Feb 23 2007, 12:06 PM)

> Why not release the "revised" shell32.dll file is 4.72.3812.635? That

> way, you avoid confusion and users will be able to tell the difference

> between the changes. When a DLL or any system file is revised, it SHOULD

> be given a different version or build number.

QUOTE (MDGX @ Feb 24, 04:08 PM)

> Done. Please see: ...

A new version # is *not* appropriate. The binary image that is loaded and

executed by Windows did not change nor were the English resources modified

in any way. The DWORD values that changed are always different for each

language build of the same version #.

In addition, the new file in SHELL98.EXE you created and posted is *not*

correct. I did not look at the files for other languages, but I suspect

they are wrong as well.

As a consequence, I have ended any support, etc. for the 'Explorer Hang'

project. More specifically, the release of SHELL32.DLL 5.50.4134.134/140

for WinMe, ported from 4.72.3812.634/640 and already near completion, is

on hold now indefinitely until I have convinced myself that this build #,

file dating, etc. nonsense 'erpdude8' has brought up more than once has

stopped for good.

Best wishes.

HTH

[bristols]

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.

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.