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

[Rick Chauvin]

I have fixed the 2GB+ copy limitation at its root, by fixing the kernel itself (which contains the flawed API _llseek). I recommend the use of the fixed kernel and v5 browse* files.

See Copy2Gb link in my signature for more information.

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:

http://www.msfn.org/board/index.php?s=&amp...st&p=553933

"The bug that causes the 2 Gibyte file copy limit is *not* in _llseek. The

matter of fact is: _llseek simply calls SetFilePointer and Win9x's

SetFilePointer API does not comply with the official API definition."

2 GB Files Kernel patch now fixes correct API function [setFilePointer].

(...and another snipit from his other post)

http://www.msfn.org/board/index.php?s=&amp...st&p=556609

"Pre-enlargement is very useful: If there is not enough disk space to copy

a 2-to-4-GiByte file, it is detected sooner. It also prevents the scenario

of another process reducing the available free space to a point where the

really lengthy copy process of a 2-to-4-GiByte file fails before it

finishes."

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 January 6, 2007 by Rick Chauvin

[LLXX]

http://www.msfn.org/board/index.php?s=&amp...st&p=553933

"The bug that causes the 2 Gibyte file copy limit is *not* in _llseek. The

matter of fact is: _llseek simply calls SetFilePointer and Win9x's

SetFilePointer API does not comply with the official API definition."

2 GB Files Kernel patch now fixes correct API function [setFilePointer].

(...and another snipit from his other post)

http://www.msfn.org/board/index.php?s=&amp...st&p=556609

"Pre-enlargement is very useful: If there is not enough disk space to copy

a 2-to-4-GiByte file, it is detected sooner. It also prevents the scenario

of another process reducing the available free space to a point where the

really lengthy copy process of a 2-to-4-GiByte file fails before it

finishes."

First of all, there is nothing wrong with SetFilePointer as it uses 64-bit file pointers; the problem is in _llseek which interprets its 32-bit filepointer as signed irregardless of the desired seek (from the beginning, from the current position, or from the end), and thus attempts to move the file pointer past the beginning of the file even when the desired seek is from the beginning (in which case a negative offset 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 by forcing it to zero-extend the file pointer to 64 bits (thus keeping its sign positive) *only* when a seek from the beginning is specified. Otherwise the file pointer is signed and can be moved within the file as usual.

Anonymous seems to have fixed shell32.dll to use SetFilePointer instead, although this still leaves _llseek flawed. SetFilePointer doesn't need any changes.

That second paragraph regarding pre-enlargement was just a discussion of the benefits/disadvantages of implementing Copy2Gb by omitting pre-enlargement altogether (and thus avoiding the use of the flawed _llseek).

[erpdude8]

4807 works fine, don't fix it if it ain't broken. (I did the 64k files test with it, so I'm quite confident it works)

build 4807 is okay to use BUT it has security flaws and exposes Win98/ME systems to several security breaches. build 4948 fixes these security bugs.

better off updating to 5.50.4948.700 of BROWSEUI.DLL to secure Win98/ME

Edited January 8, 2007 by erpdude8

[LLXX]

4807 works fine, don't fix it if it ain't broken. (I did the 64k files test with it, so I'm quite confident it works)

build 4807 is okay to use BUT it has security flaws and exposes Win98/ME systems to several security breaches. build 4948 fixes these security bugs.

better off updating to 5.50.4948.700 of BROWSEUI.DLL to secure Win98/ME

Show me one proof-of-concept of any of these claimed "security flaws", and maybe I'll consider. Otherwise, remember I've been malware-free ever since I installed 98se half a decade ago.

[MDGx]

UPDATED · 1-9-2007

Please see the top of this topic for most recent update.

____________________________________

Updates:

- Win98/98 SP1/98 SE SHELL32.DLL installed by SHELL98.EXE = updated to version 4.72.3812.634 = this is the real thing = all EXPLORER crashes are now gone, independent of free USER resources percentage.

- WinME SHELL32.DLL installed by SHELLME.EXE = same version 5.50.4134.120 = "rearranged" for easier localization (translation into languages other than English).

Enjoy.

[bristols]

Thanks MDGx and anonymous author for this latest version.

I've just downloaded the fix and unpacked SHELL32.DLL and it still shows version 4.72.3812.620, not .634 (and is timestamped October 30 2006). Is this correct - did the author not actually update the build/date in this latest release?

Just trying to clear up any confusion.

[MDGx]

Thanks MDGx and anonymous author for this latest version.

I've just downloaded the fix and unpacked SHELL32.DLL and it still shows version 4.72.3812.620, not .634 (and is timestamped October 30 2006). Is this correct - did the author not actually update the build/date in this latest release?

Just trying to clear up any confusion.

Actually [as some1 else also noticed], the file was still the old one.

My web site provider had a maintenance downtime, so I couldn't access my ftp site for a while.

But please try again... all files should be up now.

SHELL98.EXE link:

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

SHELLME.EXE link:

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

Thanks for noticing.

Best wishes.

[bristols]

Cheers MDGx for the explanation. Got the updated file now. I'll download the rest of today's updates again too, just in case.

Thanks again, all the best.

[MDGx]

Cheers MDGx for the explanation. Got the updated file now. I'll download the rest of today's updates again too, just in case.

Thanks again, all the best.

No need to d/l the other files again.

SHELL98 + SHELLME were the only ones I couldn't upload for a while.

HTH

[Rick Chauvin]

[...]

Author's comments..

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.

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.

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?

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

Edited February 16, 2007 by Rick Chauvin

[noguru]

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.

W98xIE6xQuantityFileDeleteHangBug

Rick

MDGx has answered that question already. Page 3 of this topic.

http://www.msfn.org/board/index.php?showto...84451&st=40

The copy2gb kernell32.dll is not needed but doesn't hurt. I have them both installed and never had problems with it.

It's good to hear that shell v4.72.3812.634 is working for you. The 620 version was working for me too and I'll stick with it since I have a dutch version of it (kindly provided by Hp38user).

Anyone that has used both versions succesfully but has extra benefits (performance) from the last version? If this is the case than I will use the last version too.

[Rick Chauvin]

MDGx has answered that question already. Page 3 of this topic.

http://www.msfn.org/board/index.php?showto...84451&st=40

The copy2gb kernell32.dll is not needed but doesn't hurt. I have them both installed and never had problems with it.

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.

Edited January 11, 2007 by Rick Chauvin

[Acheron]

Many thanks to Anonymous author! This was the fix I was hoping for, to make an end to all workarounds used to prevent the hanging issue on explorer file deletion

[whatever420]

...and so naturally we wonder if that slow delete process problem in the IE6x BROWSEUI.DLL can at some point also be fixed too?

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

It's an amazing difference...

On the plus side, Anon's Patched Shell32.dll file DOES seem to work...

Kudos!

[LLXX]

That speed decrease may simple be due to more inefficient code in the main loop.