MDGx Posted October 12, 2006 Share Posted October 12, 2006 UPDATE 2-28-2007This is *the* fix we have all been waiting for, folks. These 2 fixes were created by Anonymous author, who also developed unofficial U891711, Q918547, GDI*.*, KERNEL32.DLL + older SHELL98 fixes.SHELL98:http://www.mdgx.com/web.htm#9SURestored proper SHELL32.DLL 4.72.3812.634 English.This SHELL32.DLL version corrects *almost all* EXPLORER.EXE lockups independent of free USER resources percentage:* Unofficial Windows 98/98 SP1/98 SE Explorer Lockups With Internet Explorer 5.xx/6.xx SHELL32.DLL 4.72.3812.634 Fix:- SHELL32.DLL Fix [475 KB, English]:http://www.mdgx.com/files/SHELL98.EXE- SHELL32.DLL Fix [475 KB, French]:http://www.mdgx.com/files/SHELL98F.EXE- SHELL32.DLL Fix [475 KB, Italian]:http://www.mdgx.com/files/SHELL98I.EXEThis SHELL32.DLL Fix corrects Windows Explorer (and similar tools that use SHELL32.DLL APIs) lockups while trying to copy/create/move/delete/rename large number of files/folders with Internet Explorer 5.xx/6.xx already installed.BUG: This SHELL32.DLL fix breaks the ability of removing annoying arrows from Desktop shortcut icons!FIX: See "PATCHED SHELL32.DLL BUG + FIX" for complete details:http://www.mdgx.com/98-5.htm#PSBFSHELLME:http://www.mdgx.com/web.htm#MEUSame SHELL32.DLL version "rearranged" for easier localization (translation into languages other than English):* Unofficial Windows ME Explorer Lockups With Internet Explorer 5.xx/6.xx SHELL32.DLL 5.50.4134.120 Fix:Direct download [843 KB, English]:http://www.mdgx.com/files/SHELLME.EXEDirect download [847 KB, Italian]:http://www.mdgx.com/files/ITSHELME.EXEThis SHELL32.DLL Fix corrects Windows Explorer (and similar tools that use SHELL32.DLL APIs) lockups while trying to copy/create/move/delete/rename large number of files/folders with Internet Explorer 5.xx/6.xx already installed.How to uninstall this fix [valid for all versions]:Start button -> Settings -> Control Panel -> Add/Remove Programs -> select "Remove Unofficial Explorer Lockups SHELL32.DLL Fix" -> click Add/Remove button -> reboot.Author's comments...I am sending SHELL32.DLL [for Win98/98 SE], which is far more than a mere workaround.It does not fix the underlying bug in USER.EXE and its WM processing, but is designed to prevent the series of EXPLORER.EXE hangs 100% even if User Resources are low etc.Although some MSFN members seem to think otherwise, it is not a bug in SHELL32.DLL - it just happens to be the best place to take care of the problem.As always, this patch comes with the notice "Use at your own risk!"I am very sorry but I have no time to localize SHELL32.DLL and I also have no plans at this point to port the code from Win98/98 SE SHELL32.DLL 4.72.3812.634 or 635 to WinME 5.50.4134.120 ( --> .134) - the patch is more difficult to implement under WinME.However, I am sending a "rearranged" SHELL32.DLL 5.50.4134.120 [for WinME], the same "workaround", which should be much easier to localize = translate localizable strings into languages other than English.Rick Chauvin wrote on Jan 3 2007, 05:46 PM:I've found interestingly that for whatever reason? the Shell32.dll fix(SHELL98.EXE) fix for Explorer lockups appears? to be more effective ifthe Kernel32.dll fix (Copy2gb.exe) is also installed. To explain more ofwhat I've noticed is that if only the Shell32.dll is updated the hangproblem is yes much improved (70% successful) over just having theoriginal one in place - but I still can make it hang although not nearlyas readily as without it that's for sure; however if I have both theshell32 and Kernel32 dlls updated then in my observances as of yetanyway, it appears to be even more improved (85% successful) and moredifficult to trigger the hang problem. (In any of my tests when it hangsthe User, System, and GDI resources still show high %) Even though not aperfect 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 thisproblem.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.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?LLXX wrote on Jan 6 2007, 07:39 PM:First of all, there is nothing wrong with SetFilePointer as it uses64-bit file pointers; the problem is in _llseek which interprets its32-bit file pointer as signed irregardless of the desired seek (from thebeginning, from the current position, or from the end), and thusattempts to move the file pointer past the beginning of the file evenwhen the desired seek is from the beginning (in which case a negativeoffset would be nonsensical). In the unfixed version of _llseek,SetFilePointer gets passed the sign-extended file pointer, causing *it*to attempt to seek past the beginning of the file. I have fixed this byforcing it to zero-extend the file pointer to 64 bits (thus keeping itssign positive) *only* when a seek from the beginning is specified.Otherwise the file pointer is signed and can be moved within the file asusual.Anonymous seems to have fixed shell32.dll to use SetFilePointer instead,although this still leaves _llseek flawed. SetFilePointer doesn't needany changes.LLXX wrote on Dec 16 2006, 07:33 PM:Don't know what's with that one. The _llseek doesn't even look like itwas fixed. Edit: This problem doesn't affect explorer.exe in WinME somaybe that file is just a dummy.What is her problem??? It is beyond me why she writes such nonsense. Has she not read the official definition on msdn2.microsoft.com and in the 'Win32 SDK Reference Help' (WIN32.HLP)???KERNEL32.SetFilePointer has two modes: If called with a 32-bit pointer to the high-order DWORD of a 64-bit file pointer, it uses a 64-bit distance to move and uses it correctly.However, if the pointer to the high-order DWORD is NULL, KERNEL32.SetFilePointer uses a 32-bit distance to move.This is how KERNEL32._llseek calls KERNEL32.SetFilePointer (if unpatched) - KERNEL32._llseek itself is just a stub to call KERNEL32.SetFilePointer!This is very different from a (real = non-zero) pointer pointing to a high-order DWORD that is zero.AFAIK, _llseek and SetFilePointer are flawed in all versions of Windows (Win9x, WinNT, Win2k and WinXP) and probably in Vista, too.Interestingly, the official description on msdn2.microsoft.com of the SetFilePointer API (and its 32-bit call mechanism!) has changed several times over the years. One may speculate if this was done to disguise the flaw.P.S.:The code below is an example of a bug in USER.EXE.Unfortunately, it is *not* the bug that causes the EXPLORER.EXE hang, but the type of bug I was alluding to in an earlier message.This bug can cause mayhem when Resources are too low and KERNEL.LOCALALLOC fails.This type of bug occurs more than once in USER.EXE, but also exists in GDI.EXE, which highlights that coding practices apparently were not at their best when Windows 95 was developed.push 0x40push 0x14call KERNEL.LOCALALLOCmov cx, ds <-- ds<>0mov [bp-4], axmov [bp-2], dsor cx, ax <-- always <>0jnz ...xor ax, axjmp ...Author's comments...This is a patched version of:- SHELL32.DLL 5.50.4134.120 for Windows ME- SHELL32.DLL 4.72.3812.648 for Windows 98/98 SP1/98 SEthat prevents the EXPLORER hang from occuring when a large number of files is deleted, moved etc.As I wrote earlier, the problem arises because USER.EXE runs completely out of resources (=0%) right after such a file operation is completed.However, this is not a bug in USER.EXE. The patch I am providing is not a fix in the true sense, it is more of a workaround and, as always, is provided 'as is' without warranties expressed or implied and with the note 'Use it at your own risk.'The problem may still occur if a large number of files is deleted, moved etc, while USER resources are low, say below 30%.I also believe this problem has nothing to do with what versions of SHLWAPI.DLL and/or BROWSEUI.DLL are installed.It may occur much more frequently with the IE6 SP1 versions because they have much more code, which also takes longer to execute (and may no longer be "optimized" for a Win9x environment).May I use this opportunity to address a common misconception about GDI andUSER resources in Win9x/ME: The OS and all applications, whether they are16-bit or 32-bit versions, share the same GDI and USER resources. Theseresources are managed by GDI.EXE and USER.EXE, respectively. One of thetwo data segments of GDI.EXE is for GDI resources and one of the two datasegments of USER.EXE (plus two extra heaps) is for USER resources. GDI andUSER objects (in these data segments) are accessed through *16-bit-wide*handles. 32-bit applications (and DLLs) just use zero-extended 32-bitversions of the same handles. The data segments I am referring to are32-bit segments with an *initial* size of approx. 2.1 MiByte each. The16-bit resources are just the lowest 65536 bytes each in these two 32-bitdata segments. 16-bit-wide handles and the 16-bit resource limit cause thereal bottle neck in resources of Win9x. Increasing the default size of thetwo 32-bit data segments (which would be possible using hidden systemsettings for them) makes very, very little, if any difference.Please post here your test results.Thanks.Enjoy. Link to comment Share on other sites More sharing options...
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
Already have an account? Sign in here.Sign In Now