jds

New old 2G file size bug

43 posts in this topic

While testing the DIAMOND.EXE that Submix8c found for LoneCrusader...
Well I'll be flippered! I did something right for a change! Glad ya found your bug! Congrats on the fix!

(this post allows reminder of your "fix" module as well, so not a "wasted post"...)

0

Share this post


Link to post
Share on other sites
While testing the DIAMOND.EXE that Submix8c found for LoneCrusader...
Well I'll be flippered! I did something right for a change! Glad ya found your bug! Congrats on the fix!

(this post allows reminder of your "fix" module as well, so not a "wasted post"...)

Thank you very much for the DIAMOND.EXE Link. I was able to rework my Slipstream Scripts to use it to support Windows 95 for LoneCrusader. I had my 2GB Patch installed when I was testing DIAMOND Batch Scripts, and even the Example Scripts failed. Although it seemed unlikely, the 2GB Patch was the only one that affected File functions, so I removed it and DIAMOND worked. A FILEMON log nailed it.

0

Share this post


Link to post
Share on other sites

first step would be making unofficial IO.SYS that could handle >4GB files

Actually ... there's a 2G bug in there to deal with, before worrying about 4G! :

Joe.

Technically it is not a bug. It is "By Design". To work with files larger than 2GB, you need to set a flag on an "Extended Open" Call.

A small TSR probably could be used to force the flag.

0

Share this post


Link to post
Share on other sites

:blink: Function 6C00, bit 4 of BH! If not for you, RLoew, I'd never find out about it! You do rock! :thumbup

Well, the little TSR could trap the Acces Denied return and try to find out whether the file in question is bigger than 2 GiB and, if so, set the flag and retry, returning the result of the read as if it had succeeded, else let the error alone... :) Of course, this might result in having to take steps for safely rentering DOS to find out the file size, but it is sure possible to implement cleanly, I think.

0

Share this post


Link to post
Share on other sites

first step would be making unofficial IO.SYS that could handle >4GB files

Actually ... there's a 2G bug in there to deal with, before worrying about 4G! :

Joe.

Technically it is not a bug. It is "By Design". To work with files larger than 2GB, you need to set a flag on an "Extended Open" Call.

A small TSR probably could be used to force the flag.

:blink: Function 6C00, bit 4 of BH! If not for you, RLoew, I'd never find out about it! You do rock! :thumbup

Well, the little TSR could trap the Acces Denied return and try to find out whether the file in question is bigger than 2 GiB and, if so, set the flag and retry, returning the result of the read as if it had succeeded, else let the error alone... :) Of course, this might result in having to take steps for safely rentering DOS to find out the file size, but it is sure possible to implement cleanly, I think.

Great catch Mr Loew!

From Ralph Brown's Interrupt List :

--------D-216C00-----------------------------

INT 21 - DOS 4.0+ - EXTENDED OPEN/CREATE

AX = 6C00h

BL = open mode as in AL for normal open (see also AH=3Dh)

bit 7: inheritance

bits 4-6: sharing mode

bit 3 reserved

bits 0-2: access mode

100 read-only, do not modify file's last-access time (DOS 7.0)

BH = flags

bit 6 = auto commit on every write (see also AH=68h)

bit 5 = return error rather than doing INT 24h

bit 4 = (FAT32) extended size (allow 4GB files instead of 2GB)

CX = create attribute (see #01769)

DL = action if file exists/does not exist (see #01770)

DH = 00h (reserved)

DS:SI -> ASCIZ file name

So Int 21/6C00 does provide a clue. However, since I also use DR-DOS 6.0, which does not support Int 21/6C00 (BTW, DR-DOS 7.XX does), I know most 16 bit applications/utilities I have don't actually use this particular function call, but the older Int 21/3C or Int 21/3D (I haven't verified 'chksum.com' yet). So it would be necessary to intercept these older function calls too and redirect them to Int 21/6C00 with a suitable tweak to BH.

I dunno, this seems like a bug that became "by design", so as not to admit it was a bug in the first place. Why on Earth would you deliberately constrain file sizes to 2G?

Joe.

Update: I've now tested Charles Dye's 'chksum.com' utility (which was where I initially discovered the 2G file size limitation) on DR-DOS 6.0 (which doesn't support Int 21/6C00), and since it works there, can confirm this utility uses only the older Int 21/3C or Int 21/3D function calls.

Edited by jds
0

Share this post


Link to post
Share on other sites
Why on Earth would you deliberately constrain file sizes to 2G?
For compatibility reasons. When a program uses a signed int to store the filepointer, it could get mad when the pointer runs negative. With this construction a program has to explicitly tell the OS that is can handle large files. Edited by Mijzelf
0

Share this post


Link to post
Share on other sites

DOS Function 4302 might be the best way to quickly ascertain the true file size, I think...

0

Share this post


Link to post
Share on other sites

Well, this thread sort of got sidetracked over another 2G issue and the support for different seek modes in patched versions of 'kernel32.dll', which is progress nonetheless, however, the original issue (2G limitations for 16 bit app's and MS-DOS 7.10 itself) is yet unresolved. Is this an "IO.SYS" problem and would it be possible to fix?

Joe.

0

Share this post


Link to post
Share on other sites

For completeness (up to this date), note that there was a bit more discussion on this issue in postings 34-39 of the following thread :

(Also note that due to editing, not all material in those postings is in chronological order.)

Joe.

0

Share this post


Link to post
Share on other sites

For completeness (up to this date), note that there was a bit more discussion on this issue in postings 34-39 of the following thread :

(Also note that due to editing, not all material in those postings is in chronological order.)

Well, not anymore... :D

While I left post #34 there, I moved #35-39 here, which is where they really belong, and now they've become posts #33-37 on this thread. i decided to leave post #34 there because it has a pointer to this thread, and it's quoted in toto in RLoew's reply to it, which is posts #33 on this thread, so nothing was lost.

0

Share this post


Link to post
Share on other sites

Use my Patch and have unlimited Seek capability over the range 0 to 4GiB-2, and break some programs. Or use COPY2GB which is more limited but has less impact on compatability.

"98 SE SP 3.7" includes Kernel32.dll (version 4.10.0.2226, build RRL). Binary analysis shows that this is not the original file patched by Mr. Loew (version 4.10.0.2225, build RRL), not there is also a file of the COPY2GB patch (version 4.10.0.2226, build QFE).

Does anyone know anything specific about the origins and characteristics included in the Kernel32.dll of the "98 SE SP 3.7"?

Edited by egrabrych
0

Share this post


Link to post
Share on other sites

Use my Patch and have unlimited Seek capability over the range 0 to 4GiB-2, and break some programs. Or use COPY2GB which is more limited but has less impact on compatability.

"98 SE SP 3.7" includes Kernel32.dll (version 4.10.0.2226, build RRL). Binary analysis shows that this is not the original file patched by Mr. Loew (version 4.10.0.2225, build RRL), not there is also a file of the COPY2GB patch (version 4.10.0.2226, build QFE).

Does anyone know anything specific about the origins and characteristics included in the Kernel32.dll of the "98 SE SP 3.7"?

Searching and reading goes a long way on the forum :huh:Solution
0

Share this post


Link to post
Share on other sites

Use my Patch and have unlimited Seek capability over the range 0 to 4GiB-2, and break some programs. Or use COPY2GB which is more limited but has less impact on compatability.

"98 SE SP 3.7" includes Kernel32.dll (version 4.10.0.2226, build RRL). Binary analysis shows that this is not the original file patched by Mr. Loew (version 4.10.0.2225, build RRL), not there is also a file of the COPY2GB patch (version 4.10.0.2226, build QFE).

Does anyone know anything specific about the origins and characteristics included in the Kernel32.dll of the "98 SE SP 3.7"?

Please read post #38 :

Joe.

Edited by jds
0

Share this post


Link to post
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.