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: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:LLXX wrote on Dec 16 2006, 07:33 PM: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.

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 SE
that 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 and
USER resources in Win9x/ME: The OS and all applications, whether they are
16-bit or 32-bit versions, share the same GDI and USER resources. These
resources are managed by GDI.EXE and USER.EXE, respectively. One of the
two data segments of GDI.EXE is for GDI resources and one of the two data
segments of USER.EXE (plus two extra heaps) is for USER resources. GDI and
USER objects (in these data segments) are accessed through *16-bit-wide*
handles. 32-bit applications (and DLLs) just use zero-extended 32-bit
versions of the same handles. The data segments I am referring to are
32-bit segments with an *initial* size of approx. 2.1 MiByte each. The
16-bit resources are just the lowest 65536 bytes each in these two 32-bit
data segments. 16-bit-wide handles and the 16-bit resource limit cause the
real bottle neck in resources of Win9x. Increasing the default size of the
two 32-bit data segments (which would be possible using hidden system
settings for them) makes very, very little, if any difference.

I have just done this test on my Win ME IE 5.5 SP2 system. It's quite interesting, read on :

Starting with system and user resources at 65% free, GDI at 75% free

I copied one folder containing 56,493 files and 619 folders totaling 1.55 GB (1,668,057,987 bytes) and occupying 2.07 GB (2,223,521,792 bytes) of disk space.

No freeze while copying. Resources didn't change of even 1%.

I then enabled explorer view. GDI fell to 70%.

I then copied over files and folders in several steps into the top folder obtaining 12383 objects (including 447 folders).

GDI resources fell at 64% when I selected all objects.

I dropped them into an empty folder but the window froze (but not the rest of explorer), instead of waiting a bit I killed and restarted the explorer from a batch on my middle mouse hook.

I was back then with resource level I had begun with.

I went again in the folder with the 12383 objects and did reenable explorer view. The resources did not change unlike above when I lost 5% of GDI doing almost the same thing.

I did reselect all 12383 objects and tried to drop again in an empty folder. The window froze again but this time I waited and the files finally copied over. The GDI resources did not change unlike above where they fell by another 4% trying to do that.

Only after everything was copied did explorer attempt to refresh the view. System and User resources fell briefly to O before jumping back to their normal value. GDI resources did not change but the entire explorer was frozen.

So that the "classic" explorer freeze we speak about in this thread appears to take place when explorer updates the view for a large number of files.

I killed and restarted it and was back to normal.

I did reselect the 12383 objects by click and drag and then did a right-click. It took several seconds to diplay the context menu. I then did choose delete.

When the deleting was finished, explorer did refresh the view of the folder and again System and User resources fell briefly to 0 after which the explorer was frozen again. The GDI resources did not visibly change at any point.

I did then empty the recycle bin but without having it opened. During the operation, System and User resources fluctuated by 6-7%.

Explorer did not freeze doing that but I am pretty sure it would have if I would have had the recycle bin opened.

Have you actually tried making a directory with several thousand files in it, and deleting/copying all of them?

(Hint: i386 of XP CD, or extracted contents of all 98SE CAB files )

Currently using: BROWSELC.DLL and BROWSEUI.DLL 5.50.4807.2300, no problems. Tested up to 16,384 files (used a splitter to split a 16Kb file into 1-byte files).

I think I found the fix for this large files manipulation bug in Win98 SE with MS IE 6.0 or 6.0 SP1 installed...

eidenk, you need to be using IE6 SP1, NOT IE 5.5 SP2, in order for the BROWSE98.EXE patch to work.

though you need to be using version 5.50.4948.700 of BROWSEUI.DLL instead of 5.50.4807.2300 to have the latest security benefits for the BROWSEUI.DLL file, LLXX. I no longer use 5.50.4807.2300 of BROWSEUI.DLL file because it has security flaws that are fixed in version 5.50.4948.700.

I'll see if I can test out the BROWSE98.EXE patch on my WinME + IE6 SP1 machine, MDGx.

eidenk, you need to be using IE6 SP1, NOT IE 5.5 SP2, in order for the BROWSE98.EXE patch to work.

Explorer hangs after deletion but it recovers without a crash.These files work better than
the orginal because the original files crashed explorer.
My theory is that deleting large files eat resources fix the resource problem and we might
have a solution.

Have you actually tried making a directory with several thousand files in it, and deleting/copying all of them?

(Hint: i386 of XP CD, or extracted contents of all 98SE CAB files )

Currently using: BROWSELC.DLL and BROWSEUI.DLL 5.50.4807.2300, no problems. Tested up to 16,384 files (used a splitter to split a 16Kb file into 1-byte files).

CD %windir%\System
regsvr32 /u /s %windir%\System\browseui.dll
regsvr32 /u /s %windir%\System\browselc.dll
regsvr32 /i /s %windir%\browseui.dll
regsvr32 /i /s %windir%\browselc.dll

Sorry but is it possible that some of you guys don't invest very much time in this problem
or are to lazy to read previous articles about this issue?

I think one can't use IE6 brows* files for Windows Explorer.

AFAIK I only know as solution to use the files LLXX mentioned