Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

Copy2Gb

- - - - -

  • Please log in to reply
116 replies to this topic

#1
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05
Version 1.1 available for download

As mentioned in http://support.micro....com/?id=318293 Windows 98SE shell fails at trying to copy files over 2Gb. According to M$...

This problem can occur because of a problem in the versions of the Shell32.dll file that are included with Windows 98 and Windows 98 Second Edition. The root cause is a generic file operation which is used by the shell in Windows 95/98 and Microsoft Windows NT 4.0 which interprets values that are greater than 2 GB as negative numbers.

...the problem is with shell32.dll.

Unfortunately, M$ is only partially right. I've inspected and traced through the copying code in shell32.dll, and the actual problem seems to lie within the kernel itself, at the _llseek API.
7FCEB349	 mov	 [ebp+nNumberOfBytesToWrite], eax
7FCEB34C	 mov	 eax, [edi+20h]
7FCEB34F	 cmp	 eax, 30000h; over 192Kb in size?
7FCEB354	 jbe	 short 7FCEB386; no pre-enlargement if not
7FCEB356	 push	ebx; iOrigin
7FCEB357	 mov	 ebx, ds:_llseek
7FCEB35D	 push	eax; lOffset
7FCEB35E	 push	[ebp+hDestFile]; hFile
7FCEB361	 call	ebx; _llseek apparently has problems seeking over 2Gb
7FCEB363	 cmp	 eax, 0FFFFFFFFh
7FCEB366	 jz	  loc_0_7FCEB55D; fails here
7FCEB36C	 push	[ebp+hDestFile]; hFile
7FCEB36F	 call	ds:SetEndOfFile
7FCEB375	 test	eax, eax
7FCEB377	 jz	  loc_0_7FCEB55D
7FCEB37D	 push	0; iOrigin
7FCEB37F	 push	0; lOffset
7FCEB381	 push	[ebp+hDestFile]; hFile
7FCEB384	 call	ebx; _llseek
For those that don't understand the above code, what it does is attempt to enlarge the destination file to the correct size by seeking to the source filesize and then setting the file's end there. Unfortunately, if the file is >2Gb, _llseek fails with "invalid parameter" error. Also note that unless the file is over 192Kb in size, no attempt to pre-enlarge is made - the file just enlarges automatically as data is written to it.

Either the bug is with the _llseek function in the kernel and the code in shell32 is fine, or _llseek was designed to do that (i.e. interprets >2Gb as moving the file pointer backwards, but the pointer is already at the start of the file so it complains) and shell32 is flawed. I can see several possible fixes:

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?

-------------------------------------------------------------------------------------------------
Update:

Fixed kernels:
4.10.1998
4.10.2001
4.10.2222
4.10.2225
4.90.3000

(kernels are too big to attach)

Verification Tool:

Attached Files


Edited by dencorso, 08 December 2010 - 08:22 PM.
Made the MAKE2GB test app available again!



How to remove advertisement from MSFN

#2
wizardofwindows

wizardofwindows

    Wizard of Windows

  • Member
  • PipPipPip
  • 443 posts
  • Joined 17-June 05
:thumbup conquering the 2gb barrier would be a plus with dvd use today.noting many new games etc. are well over 2gig.u da man.

#3
Petr

Petr

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 981 posts
  • Joined 15-April 05
  • OS:98SE
  • Country: Country Flag
In Windows 2000 (beta), it seems to be this part of the source code:
// initialzie the file to the full size
	// this takes 3 dos calls, so only do it if the file is big
	if (pfd->nFileSizeLow > (COPYMAXBUFFERSIZE * 3))
	{
		// if there's a problem, bail
		if ((_llseek(hDest, pfd->nFileSizeLow, 0L) == HFILE_ERROR) ||
			(!SetEndOfFile((HANDLE)hDest)))
		{
			iLastError = GetLastError();
			goto ErrorOnWrite;
		}
		else
		{
			_llseek(hDest, 0, 0L);
		}
	}

Petr

#4
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05

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?

#5
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05
I've fixed _llseek, and it seems to work fine :D

Posted Image

Maybe I'll experiment with different buffer sizes next...

As usual, if you want a newer version or already modified kernel to be patched, just post.

Once Kernel Update Project stabilises I'll probably fix the modified kernel from it.

#6
the_guy

the_guy

    Creator of the Windows ME Service Pack

  • Member
  • PipPipPipPipPip
  • 914 posts
  • Joined 15-July 05
  • OS:ME
  • Country: Country Flag
Hey LLXX,

If you get it working from the 313829 version, can you try patching the NT4 version from MS04-037 (with Active Desktop) as well?

the_guy
Creator of the Windows ME Service Pack.

#7
Tihiy

Tihiy

    the creator

  • Member
  • PipPipPipPipPipPipPip
  • 1,932 posts
  • Joined 19-November 04
  • OS:Windows 7 x64
  • Country: Country Flag

Donator

I haven't checked code, but project seems excellent.
It is not needed to patch Kernel Update because it is patch itself and does not provide kernel32.dll

But patch 4.10.2225!

#8
wizardofwindows

wizardofwindows

    Wizard of Windows

  • Member
  • PipPipPip
  • 443 posts
  • Joined 17-June 05
thx u this is great u rock!!

Edited by wizardofwindows, 22 August 2006 - 10:14 AM.


#9
erpdude8

erpdude8

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,141 posts
  • Joined 24-November 04

As mentioned in http://support.micro....com/?id=318293 Windows 98SE shell fails at trying to copy files over 2Gb. According to M$...

This problem can occur because of a problem in the versions of the Shell32.dll file that are included with Windows 98 and Windows 98 Second Edition. The root cause is a generic file operation which is used by the shell in Windows 95/98 and Microsoft Windows NT 4.0 which interprets values that are greater than 2 GB as negative numbers.

...the problem is with shell32.dll.


You also need to patch kernel32.dll version 4.10.1998 (and version 4.10.2001 from Q320798) for Win98 FE, LLXX. Let's not forget, the 2GB+ copy problem also occurs under Win98 FE as noted in MS article 318293.

patching kernel32.dll files from Win95? I believe Win95 also has the 2GB+ copy problem but the Win95 kernel32.dll files are missing a bunch of functions that were included in the Win98 FE/SE versions of kernel32.dll files.

Edited by erpdude8, 22 August 2006 - 10:25 AM.


#10
MDGx

MDGx

    98SE2ME + 98MP10

  • Super Moderator
  • 2,678 posts
  • Joined 22-November 04
  • OS:none specified
  • Country: Country Flag
Great work.
Keep it up. ;)
Added link here [scroll under "Windows 98/98 SE/ME Updates + Patches"]:
http://www.mdgx.com/

Does it make sense to patch WinME kernel32.dll ?

And I think it's a good idea to patch kernel32.dll 4.10.2225 .

IMHO:
When patching a system file that has already been patched previously, it's best to patch the newest build, which contains all previous patches.
Patching the oldest file only takes care of the newest issue, but not any previous ones.

Thanks for your time.

#11
eidenk

eidenk

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,527 posts
  • Joined 28-March 05

Does it make sense to patch WinME kernel32.dll ?


I don't think so as it does not appear there is a problem with WinME. I have just created a 3.8GB archive and copied it over without problems.

I have been using Windows ME since a few years in the erroneous belief that it wouldn't handle files over 2GB.
Asus A8V Deluxe - Athlon 64 FX-55 2.6Ghz - 1GB DDRAM 400 - Windows ME (IE 5.5 SP2 Shell) + KernelEx 4.0 and Revolutions Pack 10

#12
winxpi

winxpi

    Member

  • Member
  • PipPip
  • 192 posts
  • Joined 22-September 05
  • OS:none specified
  • Country: Country Flag

[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?

Super another barrier fell.
I have some questions :
Not so important but did you try the most "correct" solution modifing shell32.dll ?

A better question :
How can I "Change conditional jump at 7FCEB354 to a permanent jump" and witch file would I have to change to do this?

thx again
Windows 98 has not got older, it just matured after 12 years!

#13
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05
The following patch requests have been listed:

- NT4 kernel - I don't have NT4, if you have the file PM me and deposit it somewhere.
- 4.10.2225 - Will do, http://www.mdgx.com/files/Q320798.EXE
- 4.10.1998 - I don't have this file, nor 98FE.
- 4.10.2001 - Will do, http://www.mdgx.com/files/Q320798.EXE
- Win95 kernels - probably pointless, as 95's explorer.exe doesn't work correctly with large files anyway.
- WinME - SHELL32.DLL probably changed to use SetFilePointer instead of flawed _llseek, may patch.

I have created a simple test to see if _llseek API in your kernel is flawed:

http://z11.zupload.c...?filepath=40201

All it does is attempt to create a file and then enlarge it to 2147483648 bytes via _llseek. It will report success or error depending on behavior of _llseek. (Delete the file after testing, it contains no useful data. Also ensure there is more than 2Gb of free space).

A better question :
How can I "Change conditional jump at 7FCEB354 to a permanent jump" and witch file would I have to change to do this?

Open shell32.dll in a hex editor and go to .7FCEB354 (or 3B354, depending on the editor). The following bytes should be there:
76 30 53 8b 1d 44 16 cb 7f
Change it to
eb 30 53 8b 1d 44 16 cb 7f
(This is version 4.72.3612.1700, I don't know the exact location in other versions).

Edit: fixed link

Edited by LLXX, 23 August 2006 - 03:47 PM.


#14
Philco

Philco

    Member

  • Member
  • PipPip
  • 273 posts
  • Joined 24-June 06
  • OS:98SE
  • Country: Country Flag

....

I have created a simple test to see if _llseek API in your kernel is flawed:

http://www.upload2.n...AKE2GB.ZIP.html

...


Please, file corrupted, hosting other server?
Posted Image
czech localization NUSB, BigHDD & UberSkin - homepage czech project: Winpack.org and windows98.ic.cz

#15
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05
It seems so. I found another filehost... seems to be working

http://z11.zupload.c...?filepath=40201

#16
eidenk

eidenk

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,527 posts
  • Joined 28-March 05
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 ?
Asus A8V Deluxe - Athlon 64 FX-55 2.6Ghz - 1GB DDRAM 400 - Windows ME (IE 5.5 SP2 Shell) + KernelEx 4.0 and Revolutions Pack 10

#17
the_guy

the_guy

    Creator of the Windows ME Service Pack

  • Member
  • PipPipPipPipPip
  • 914 posts
  • Joined 15-July 05
  • OS:ME
  • Country: Country Flag
According to 318293, the issue is resolved on ME, 2000, XP, and 2003.

the_guy
Creator of the Windows ME Service Pack.

#18
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05

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, 23 August 2006 - 05:25 AM.


#19
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05
Fixed ME kernel (4.90.3000) is Now available for download

#20
erpdude8

erpdude8

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,141 posts
  • Joined 24-November 04


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, 23 August 2006 - 08:59 PM.


#21
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05
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.

#22
eidenk

eidenk

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,527 posts
  • Joined 28-March 05
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.
Asus A8V Deluxe - Athlon 64 FX-55 2.6Ghz - 1GB DDRAM 400 - Windows ME (IE 5.5 SP2 Shell) + KernelEx 4.0 and Revolutions Pack 10

#23
MDGx

MDGx

    98SE2ME + 98MP10

  • Super Moderator
  • 2,678 posts
  • Joined 22-November 04
  • OS:none specified
  • Country: Country Flag
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.

#24
winxpi

winxpi

    Member

  • Member
  • PipPip
  • 192 posts
  • Joined 22-September 05
  • OS:none specified
  • Country: Country Flag
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

Windows 98 has not got older, it just matured after 12 years!

#25
LLXX

LLXX

    MSFN Junkie

  • Banned
  • PipPipPipPipPipPipPipPipPip
  • 3,399 posts
  • Joined 04-December 05
Yes, looks like it...




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users