submix8c Posted January 16, 2011 Share Posted January 16, 2011 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"...) Link to comment Share on other sites More sharing options...
rloew Posted January 16, 2011 Share Posted January 16, 2011 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. Link to comment Share on other sites More sharing options...
rloew Posted April 7, 2011 Share Posted April 7, 2011 first step would be making unofficial IO.SYS that could handle >4GB filesActually ... 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. Link to comment Share on other sites More sharing options...
dencorso Posted April 7, 2011 Share Posted April 7, 2011 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. Link to comment Share on other sites More sharing options...
jds Posted April 7, 2011 Author Share Posted April 7, 2011 (edited) first step would be making unofficial IO.SYS that could handle >4GB filesActually ... 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 nameSo 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 Link to comment Share on other sites More sharing options...
Mijzelf Posted April 7, 2011 Share Posted April 7, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
dencorso Posted April 7, 2011 Share Posted April 7, 2011 DOS Function 4302 might be the best way to quickly ascertain the true file size, I think... Link to comment Share on other sites More sharing options...
jds Posted March 17, 2012 Author Share Posted March 17, 2012 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. Link to comment Share on other sites More sharing options...
jds Posted June 25, 2012 Author Share Posted June 25, 2012 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. Link to comment Share on other sites More sharing options...
dencorso Posted June 26, 2012 Share Posted June 26, 2012 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. Link to comment Share on other sites More sharing options...
egrabrych Posted September 19, 2012 Share Posted September 19, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
PROBLEMCHYLD Posted September 19, 2012 Share Posted September 19, 2012 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 Link to comment Share on other sites More sharing options...
jds Posted September 20, 2012 Author Share Posted September 20, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now