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

New old 2G file size bug

- - - - -

  • Please log in to reply
42 replies to this topic

#26
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,861 posts
  • OS:98SE
  • Country: Country Flag

Donator

Great! :thumbup


How to remove advertisement from MSFN

#27
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,093 posts
  • OS:98SE
  • Country: Country Flag

Try Downloading it and testing it again. I have updated it.
If it still doesn't work please post some more details on the errors.

Sorry rloew... I'm still experiencing the same crash :(.

See the attached file for a basic picture of the crash message and a Dr. Watson crash log...

Posted Image

While testing the DIAMOND.EXE that Submix8c found for LoneCrusader, I discovered that Microsoft routinely does a relative Seek to -1 when creating Temporaries. As I said before, Negative Seeks cannot be distinguished from Seeks below 4GiB without compromising 4GiB Support. But in this case, 4GiB-1 is the only position that is prohibited regardless, so I added a check to fail this particular Seek. This unbroke DIAMOND and probably a number of other Programs that use this method to Check Temporaries and other Files. Anyone using my KERNEL32 Patch should redownload it and replace the file.

@whatever420 Please redownload and try VIDEOREDO again.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#28
whatever420

whatever420

    MSFN Expert

  • Member
  • PipPip
  • 114 posts
  • OS:98SE
  • Country: Country Flag
Thanks rloew :)

I'll download your patch and give it another try...
Will report back later with results...
OS: WINDOWS 98SE MB: P3V4X (1006 004) CPU: P3 850 @ 1055 MHZ RAM: 768 MB of CL2 PC133 HDD: 2 WD1600AAJB-00J3A0 (160 GIG) VIDEO: GEFORCE FX 5500 (77.72) MONITOR: SONY CPD-100ES AUDIO: SBLIVE! (SB0228) DVD: BENQ 1655 (BCDB) / ASUS 1814BL (1.14)

#29
whatever420

whatever420

    MSFN Expert

  • Member
  • PipPip
  • 114 posts
  • OS:98SE
  • Country: Country Flag
rloew...

You'll be happy to know that the newly patched version seems to work for me... ie. no crash when using VideoReDo. :)

Great work!

Are there any caveats related to your patch?

Edited by whatever420, 08 January 2011 - 12:33 AM.

OS: WINDOWS 98SE MB: P3V4X (1006 004) CPU: P3 850 @ 1055 MHZ RAM: 768 MB of CL2 PC133 HDD: 2 WD1600AAJB-00J3A0 (160 GIG) VIDEO: GEFORCE FX 5500 (77.72) MONITOR: SONY CPD-100ES AUDIO: SBLIVE! (SB0228) DVD: BENQ 1655 (BCDB) / ASUS 1814BL (1.14)

#30
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,093 posts
  • OS:98SE
  • Country: Country Flag

rloew...

You'll be happy to know that the newly patched version seems to work for me... ie. no crash when using VideoReDo. :)

Great work!

Are there any caveats related to your patch?

Only the same caveat I added before. But now there are no known problem Programs.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#31
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,278 posts
  • OS:none specified
  • Country: Country Flag

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

Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#32
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,093 posts
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#33
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,093 posts
  • OS:98SE
  • Country: Country Flag


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! :
http://www.msfn.org/...-file-size-bug/

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#34
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,861 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

#35
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag



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! :
http://www.msfn.org/...-file-size-bug/

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, 07 April 2011 - 08:30 PM.


#36
Mijzelf

Mijzelf

    Advanced Member

  • Member
  • PipPipPip
  • 462 posts

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, 07 April 2011 - 02:58 AM.


#37
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,861 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

#38
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag
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.

#39
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag
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 : http://www.msfn.org/...889#entry961889
(Also note that due to editing, not all material in those postings is in chronological order.)

Joe.

#40
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Supervisor
  • 5,861 posts
  • OS:98SE
  • Country: Country Flag

Donator

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 : http://www.msfn.org/...889#entry961889
(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.

#41
egrabrych

egrabrych

    Junior

  • Member
  • Pip
  • 84 posts
  • OS:98SE
  • Country: Country Flag

Donator

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, 19 September 2012 - 01:49 AM.


#42
PROBLEMCHYLD

PROBLEMCHYLD

    The Resurrector for old Windows OS

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,528 posts
  • OS:98SE
  • Country: Country Flag


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

Believe God is the Alpha and Omega.
Believe Jesus Christ died for our sins.
Repent for your sins now or there will be
BLOOD

The Path to God


U98SESP3 03-11-2013


#43
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag


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 : http://www.msfn.org/...post__p__992772

Joe.

Edited by jds, 19 September 2012 - 10:58 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN