Jump to content

Copy2Gb


LLXX

Recommended Posts

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 ?

Link to comment
Share on other sites


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 ?

It means _llseek is flawed, but WinME SHELL32.DLL sidesteps the problem by using SetFilePointer API instead.

I have obtained ME kernel and it is in the queue for patching.

Also, KERNEL32.DLL 4.10.2225 and 4.10.2001 are now available for download.

Edited by LLXX
Link to comment
Share on other sites

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 ?

It means _llseek is flawed, but WinME SHELL32.DLL sidesteps the problem by using SetFilePointer API instead.

I have obtained ME kernel and it is in the queue for patching.

Also, KERNEL32.DLL 4.10.2225 and 4.10.2001 are now available for download.

a WinME kernel patch is really unnecessary since the WinME shell32.dll SetFilePointer API function "sidesteps" the problem. plus the ME patch may cause a few old programs (like the ones that seek beyond the beginning of a file) to crash as I read somewhere in the readme.txt file. 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.

Edited by erpdude8
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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.
Link to comment
Share on other sites

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.

Edited by LLXX
Link to comment
Share on other sites

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/board/index.php?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

Edited by erpdude8
Link to comment
Share on other sites

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 :

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.

Edited by eidenk
Link to comment
Share on other sites

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.

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.

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/board/index.php?showtopic=81450

Edited by erpdude8
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...