[LLXX]

Does it even make any sense to seek beyond the beginning of a file? Any program that does that is either coded wrong (in which case original, _llseek would return with an error anyway), or is working with a file >2Gb (and can't because of the problem with _llseek).

Now that I think about it, older programs e.g. file managers will now have the capability to work with files >2Gb after fixed kernel is used, since _llseek was a carry-over from the days of Windows 3.11.

[eidenk]

I never use it usually for anything but I have just tried to use winfile.exe to copy a 2GB + file with unpatched WinME kernel32.dll and it does indeed fail.

[MDGx]

Anonymous author of several 98/ME patches responds to some comments:

Quote

On August 22, 10:39 AM, 'MDGx' wrote:

> Does it make sense to patch WinME kernel32.dll ?

As a matter of fact, it does! Although LLXX's patch is great, it does not
fix the real bug!!! I will write more shortly when I am less busy. WinME's
shell32.dll does use SetFilePointer.

On Aug. 21 2006, 03:43 PM, 'LLXX' wrote:

> At first, I was wondering about the NOPs as well, thinking that they'd
> presumably be for I/O delay purposes, but as the original code does not
> have any other instances of I/O instructions separated by so many NOPs,
> I decided to ignore them, and the code of the patched version ended up
> having delays between the OUTs in any case. The driver works fine
> without them anyway.

On how many PCs did she actually verify that for sure???

> My driver does send an extra zero to the sector count register, and this
> is not needed for LBA28 commands, but is for the LBA48, and at the time
> I couldn't think of a better place to put it. Yes, this does decrease
> performance for non-48bitLBA commands, but the additional ~30ns delay is
> unlikely to be noticeable as the actual command execution time is much
> greater.

I am afraid, LLXX completely misunderstood my comments re NOPs. It is
*not* about a truly negligible performance penalty. I was referring to the
fact that *older* IDE controllers *may* need it since M$soft put it there
in the first place (for Win95?). I agree, they also looked superfluous to
me as there are other instances where a suite of the same registers is
written to and where no NOPs are used, but only M$soft would know if they
are. As far as I can tell, it is the only instance where these two
registers are used in such a form. So I would not expect to see the same
8 NOPs somewhere else in the driver.

Best wishes.

Hope this helps.

[winxpi]

For shell32.dll :

shell32.dll 4.72.3812.600 got this line only:

76 30 53 8B 1D 44 16 80 66

Do I have to replace it like that:

eb 30 53 8B 1D 44 16 80 66

[LLXX]

Yes, looks like it...

[LLXX]

Update: Added 4.10.1998 for those that wanted it..

Regarding the NOPs in the HDD driver (discuss this further in the Enable48BitLBA thread, not this one which has absolutely nothing to do with it...), I think they were originally a call to a logging routine for debug purposes, but was NOP'd out in the release version.

This post has been edited by LLXX: 25 August 2006 - 12:07 AM

[erpdude8]

eidenk, on Aug 24 2006, 03:30 AM, said:

I never use it usually for anything but I have just tried to use winfile.exe to copy a 2GB + file with unpatched WinME kernel32.dll and it does indeed fail.

I was talking about Windows Explorer, not File Manager, eidenk. If you copy a 2Gb file from within Explorer (not File Manager or any other app) in WinME, it will copy ok without WinME kernel patch.

LLXX, I wonder if you can take a look at the _llseek kernel32.dll codes for Windows 2000, XP & Server 2003. do those versions need to be patched or not? also can you comment on what CLASYS said about "RAM slowing down with age" here:
http://www.msfn.org/...showtopic=34960

I have kernel32.dll files versions 5.0.2195.6688, 5.1.2600.2180 and 5.2.3790.1830. Let me know if you need them.

BTW - thanks for the kernel patches for win98fe/se/winme

This post has been edited by erpdude8: 25 August 2006 - 09:09 AM

[eidenk]

erpdude8, on Aug 25 2006, 08:56 AM, said:

eidenk, on Aug 24 2006, 03:30 AM, said:

I never use it usually for anything but I have just tried to use winfile.exe to copy a 2GB + file with unpatched WinME kernel32.dll and it does indeed fail.

I was talking about Windows Explorer, not File Manager, eidenk. If you copy a 2Gb file from within Explorer (not File Manager or any other app) in WinME, it will copy ok without WinME kernel patch.

Excuse me please, but you said it didn't make sense to patch the WinME kernel32.dll at all :

erpdude8, on Aug 23 2006, 08:54 PM, said:

a WinME kernel patch is really unnecessary since the WinME shell32.dll SetFilePointer API function "sidesteps" the problem. So I will AVOID using the ME kernel patch since the Copy2GB problem is already fixed in WinME. Why try to fix the Copy2GB problem with the ME kernel patch when it is already fixed in ME? doesnt make sense.

Additionally I was not answering to you specifically and what you now explain to me I know it well enough already if you want to read the few posts I made in this thread.

This post has been edited by eidenk: 25 August 2006 - 10:43 AM

[erpdude8]

eidenk, on Aug 25 2006, 11:40 AM, said:

erpdude8, on Aug 25 2006, 08:56 AM, said:

eidenk, on Aug 24 2006, 03:30 AM, said:

I never use it usually for anything but I have just tried to use winfile.exe to copy a 2GB + file with unpatched WinME kernel32.dll and it does indeed fail.

I was talking about Windows Explorer, not File Manager, eidenk. If you copy a 2Gb file from within Explorer (not File Manager or any other app) in WinME, it will copy ok without WinME kernel patch.

Excuse me please, but you said it didn't make sense to patch the WinME kernel32.dll at all :

because the Copy2Gb+ "explorer" problem was ALREADY fixed in WinME [no duh!]
if you use something else (and NOT windows explorer) to copy 2GB+ files and it fails, then you may need the ME kernel patch. maybe I wasnt quite clear on that. now it should be.

eidenk, do u use windows explorer to copy files? or do u use another program to do that?

BTW - you are free to use the WinME kernel 2Gb patch if you want. I'm not going to stop you or any other ME user out there. feel free to test it out if it works okay on your ME computer.

eidenk, on Aug 23 2006, 04:51 AM, said:

I have tested your tool in WinME and I get an error dialog with the following message : Issuing_llseek call.

As you've read above, I am able to create and copy files bigger than 2GB on that platform.

So what is the meaning of failing this test ?

I also get the "Issuing_llseek call" message when running the tool under Win2000, XP and Server 2003.

I happen to find newer kernel32.dll files for Win2000, XP & 2003 listed in MS security bulletin MS06-051:
http://www.microsoft.com/technet/security/...n/ms06-051.mspx

maybe these can also be candidates for patching the 2GBcopy problem under Win2000/XP.

LLXX, on Aug 22 2006, 01:37 AM, said:

Quote

This problem was corrected in Windows Millennium Edition, Windows 2000, and Windows XP.

If Windows 2000 uses_llseek and is able to copy files > 2Gb correctly, then the problem must reside in _llseek function in kernel32.dll.

Also, would increasing the buffer size beyond the default 64k make for faster copying?

I'm not so sure if Win2000/XP kernel files use "_llseek" to copy 2gb+ files correctly. As I stated above, I ran your MAKE2GB.EXE tool under Win2k/XP and the tool fails.

I have started a new topic about the Copy2Gb problem but for Win2000 here:
http://www.msfn.org/...showtopic=81450

This post has been edited by erpdude8: 25 August 2006 - 11:58 AM

[eidenk]

Right, I have installed the patch and it does not change anything to the winfile copy problem with 2GB + files on my machine.

Everything is exactly the same. Size of 2GB + files is reported wrongly within winfile and trying to copy will throw an error message.

Should the patch have fixed that ? I was expecting it would.

Is that a problem with winfile do you think ?

And how could I test the benefit of this patch on Win ME ?

@erpdude : Yes I use Explorer usually for copying but sometimes I use Total Copy which is is a drag and drop shell extension I have installed.

[LLXX]

WinFile has a lot of other internal limits...

All I fixed was _llseek and nothing more, it may enable older programs to read/write 2Gb+ files correctly.

Problem with _llseek still exists in 2000 and above, I believe M$ didn't look too much into fixing legacy API. The problem probably still exists in Vista.

However I doubt anyone using 2000+ OSs is going to be using older application that use _llseek, so it is not much of a problem.

[Acheron]

LLXX, on Aug 25 2006, 11:42 PM, said:

WinFile has a lot of other internal limits...

All I fixed was _llseek and nothing more, it may enable older programs to read/write 2Gb+ files correctly.

Problem with _llseek still exists in 2000 and above, I believe M$ didn't look too much into fixing legacy API. The problem probably still exists in Vista.

However I doubt anyone using 2000+ OSs is going to be using older application that use _llseek, so it is not much of a problem.

Yes, don't fix anything if it ain't broken

If you searched across Windows you would find more broken stuff. However if it isn't used it's not necessary to patch.

This post has been edited by hp38guser: 25 August 2006 - 04:04 PM

[erpdude8]

LLXX, on Aug 25 2006, 04:42 PM, said:

WinFile has a lot of other internal limits...

All I fixed was _llseek and nothing more, it may enable older programs to read/write 2Gb+ files correctly.

Problem with _llseek still exists in 2000 and above, I believe M$ didn't look too much into fixing legacy API. The problem probably still exists in Vista.

However I doubt anyone using 2000+ OSs is going to be using older application that use _llseek, so it is not much of a problem.

hp38guser, on Aug 25 2006, 05:03 PM, said:

Yes, don't fix anything if it ain't broken

If you searched across Windows you would find more broken stuff. However if it isn't used it's not necessary to patch.

my sentiments exactly, LLXX and hp38guser.

eidenk, on Aug 25 2006, 02:11 PM, said:

Right, I have installed the patch and it does not change anything to the winfile copy problem with 2GB + files on my machine.

Everything is exactly the same. Size of 2GB + files is reported wrongly within winfile and trying to copy will throw an error message.

File Manager [Winfile.exe] is a lousy tool for copying files, especially when copying files with long filenames which will truncate them. once you copy files with long filenames with winfile, you'll lose the long names for good and you will have to rename them in Explorer to get back your long filenames.

the NT4 version of Winfile.exe which I use under my WinXP computer can use long filenames and dont have the 2GB copy problem.

This post has been edited by erpdude8: 26 August 2006 - 07:56 AM

[eidenk]

erpdude8, on Aug 26 2006, 07:53 AM, said:

File Manager [Winfile.exe] is a lousy tool for copying files, especially when copying files with long filenames which will truncate them. once you copy files with long filenames with winfile, you'll lose the long names for good and you will have to rename them in Explorer to get back your long filenames.

There are some utils for enhancing Winfile, LFN support, etc..

http://www.wincorner.com/
http://www.winability.com/fmutils/

It would be nice if someone could come up with a mean of proving the _llseek kernel patch useful for Win ME.

[Tijay]

I´ve a small question :
It´s possible to patch the german version of the kernel32.dll ? I tried the versions posted here and they work very well - so far. But sometimes i get an error message about "mmtask". I can close the message window and everything goes at normal. No bluescreeen, no freezes. And the command windows are in an english/german mix
Tijay

[winxpi]

You could use e.g. Resource Hacker to translate kernel32.dll or wait for new 98SE SP in german think it should include this patch too.

This post has been edited by winxpi: 28 August 2006 - 02:34 PM

[winxpi]

LLXX, on Aug 21 2006, 08:15 PM, said:

1. Patch shell32.dll to use newer SetFilePointer function which uses 64-bit signed integers - difficult, but possibly the most "correct" solution.
2. Patch kernel32.dll _llseek to interpret seeking from the beginning with a negative offset as a positive offset - moderate, might break some other apps, but what program would want to move the file pointer past the start of the file?
3. Change conditional jump at 7FCEB354 to a permanent jump - easiest, but no more pre-enlargement - is pre-enlargement really needed?

Option 4 would have been the most difficult solution:
4. Patch shell32.dll and kernel32.dll *g*

What does this mean "but no more pre-enlargement" ,sorry my english isn't so well.
So how does this affect my system if there is no "pre-enlargement" ?

This post has been edited by winxpi: 28 August 2006 - 03:01 PM

[LLXX]

For files over 192Kb, the default behavior is for Windows to create the destination file and then set its size to whatever the size of the source is, then copy the data. That's what I mean by pre-enlargement.

I'm not too sure of the consequences of omitting pre-enlargement... a possible theory is that it might result in more fragmentation with multiple copies executing at once as the clusters are allocated as the file is being copied, while with pre-enlargement the clusters are already allocated before the copying begins.

...and no, I'm not going to patch any other language versions, simply because there are too many languages already, I'm surprised English hasn't become universal yet.

This post has been edited by LLXX: 28 August 2006 - 04:26 PM

[erpdude8]

LLXX, on Aug 28 2006, 05:26 PM, said:

...and no, I'm not going to patch any other language versions, simply because there are too many languages already, I'm surprised English hasn't become universal yet.

well not everybody living on this planet can't use Win98se in english but it would be nice if other people helped out in patching the kernel _llseek 2gb problem for other language editions of Win98se. I like winxpi's suggestion of translating the patched kernel file into a different language for those who use Win98se in other languages.

eidenk, on Aug 26 2006, 09:38 AM, said:

There are some utils for enhancing Winfile, LFN support, etc..

http://www.wincorner.com/
http://www.winability.com/fmutils/

It would be nice if someone could come up with a mean of proving the _llseek kernel patch useful for Win ME.

Wincorner's FMView & FMLFNs tools are NOT freeware, they're shareware. at least they're "no nag" shareware as MDGx mentioned FMLFNs on his 98SE2ME readme.txt file.

some advantages of using Winfile than Windows Explorer, eidenk, are that Winfile loads a lot faster than Explorer and that Winfile does NOT suffer from the "deleting large number of files" bug that hangs Explorer for a while. when deleting a very large number of files & folders in Explorer and IE6 SP1 is installed under Win98/ME, Explorer hangs but when deleting a very large number of files/folders in File Manager, Winfile does not hang. also, you are allowed to change the "System" attribute of files & folders in Winfile.

btw - LLXX and eidenk, can you comment on what CLASYS said about "RAM slowing down with age" here:
http://www.msfn.org/...showtopic=34960

This post has been edited by erpdude8: 29 August 2006 - 03:33 PM

[MDGx]

Guys,

The author of these [and other] 9x patches:
http://www.mdgx.com/files/918547.TXT
http://www.msfn.org/...showtopic=77218
http://www.msfn.org/...showtopic=58780
created a new KERNEL32.DLL patch for Win98SE [raised version build (as it should be) to 4.10.2226] + WinME [raised version build (as it should be) to 4.90.3001] which fixes the correct API function, in order to be able to create/copy/rename/move/delete files [no matter which File Manager/Explorer/similar 16-bit or 32-bit tool is used] of 2 GB and larger in size and up to 4 GB.

I have tested this new Kernel patch on my Win98 SE PC, and MAKE2GB testing tool works properly now.
MAKE2GB tool did not work with previous KERNEL32.DLL 4.10.2225 patch by LLXX.

More info from the author:

Quote

KERNEL32.DLL 4.10.2226 &
4.90.3001 allow file sizes up to 4 Gibyte in Win98SE & WinME,
respectively.

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.

----------
Value Meaning
FILE_BEGIN The starting point is zero or the beginning of the file.
If FILE_BEGIN is specified, DistanceToMove is interpreted
as an *unsigned* location for the new file pointer.
----------

The buggy Win9x code always interprets DistanceToMove as a signed
location.

I have posted here the iexpress installers for 98SE + ME:

WinME fix below here:
http://www.mdgx.com/web.htm#MEU

New > 2 GB Files Kernel patch now fixes correct API function [SetFilePointer]:
* Unofficial Windows ME 2-4 GB Files Errors KERNEL32.DLL 4.90.3001 Fix:
http://support.micro....com/?id=318293
Direct download [329 KB, English]:
http://www.mdgx.com/files/C2GBME.EXE
More info:
http://www.msfn.org/...showtopic=81200

Win98SE fix below here:
http://www.mdgx.com/web.htm#9SU

New > 2 GB Files Kernel patch now fixes correct API function [SetFilePointer]:
* Unofficial Windows 98 SE 2-4 GB Files Errors KERNEL32.DLL 4.10.2226 Fix:
http://support.micro....com/?id=318293
Direct download [261 KB, English]:
http://www.mdgx.com/files/COPY2GB.EXE
More info:
http://www.msfn.org/...showtopic=81200

These 2 patches also linked here:
http://www.msfn.org/...showtopic=46581

Hope this helps.