New old 2G file size bug

[submix8c]

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

[rloew]

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.

[rloew]

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.

[dencorso]

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

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.

[jds]

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.

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

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 April 8, 2011 by jds

[Mijzelf]

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 April 7, 2011 by Mijzelf

[dencorso]

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

[jds]

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.

[jds]

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.

[dencorso]

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

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.

[egrabrych]

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 September 19, 2012 by egrabrych

[PROBLEMCHYLD]

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 Solution

[jds]

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 September 20, 2012 by jds