Why does DosWrite not write beyond 2GB?
Andreas Buchinger
additional data to a nearly 2GB file, DosWrite fails. Number of actual data
written *pcbActual is 0. rc = 0. This usually indicates 'no space left'. But
there are 70GB left on this volume. File is opened with sopen, file position is
set with _lseeki64 to SEEK_END (below 2GB) and the following DosWrite can not
write additional 0x40000 bytes of data. Compiler OpenWatcom1.8.
Do I have to open the file with DosOpenL instead of sopen? This would be a huge
change so I ask before trying.
Andi
Paul Ratcliffe
Yes.
Gregg Young
Andi
Mike Greene has put together a lib for openwatcom that does this. You
might want to see if it will work for your needs. I was considering
adding this to 4OS2.
http://svn.assembla.com/svn/os2utils/ow64os2/
If you need backward compatibility (pre large file support systems) some
of the functions in wappers.c/h in FM/2 on netlabs check if the large
files are supported.
Gregg
tho...@antispam.ham
> Andreas Buchinger wrote:
>> I try to fix the copy issue with 4os2 and files >2GB. When trying to
>> append additional data to a nearly 2GB file, DosWrite fails. Number of
>> actual data written *pcbActual is 0. rc = 0. This usually indicates 'no
>> space left'. But there are 70GB left on this volume. File is opened with
>> sopen, file position is set with _lseeki64 to SEEK_END (below 2GB) and
>> the following DosWrite can not write additional 0x40000 bytes of data.
>> Compiler OpenWatcom1.8.
>>
>> Do I have to open the file with DosOpenL instead of sopen? This would be
>> a huge change so I ask before trying.
> Mike Greene has put together a lib for openwatcom that does this. You
> might want to see if it will work for your needs. I was considering
> adding this to 4OS2.
With each new release of OpenWatcom, I've been asking whether large file
support has been added. I use mostly the Fortran compiler, but I suspect
that if such support got added to the C compiler, the Fortran compiler
would get it due to the shared libraries.
Andi B.
Thx found it. Had a short look at it and it seems to do what I need.
Actually I've already added a slightly modified version of the FM/2
wrappers.x to 4os2 as suggested by Steven. Have to extend with sopen.
Question arises about OW licese - I have to login at sybase and read
the license before copying anything :-(
Andi
Gregg Young
>
> Thx found it. Had a short look at it and it seems to do what I need.
> Actually I've already added a slightly modified version of the FM/2
> wrappers.x to 4os2 as suggested by Steven. Have to extend with sopen.
>
> Question arises about OW licese - I have to login at sybase and read
> the license before copying anything :-(
>
> Andi
Andi
While I am not sure that Mike's code can be made a part of 4os2. My
quick read of the license would indicate that you can add the headers
and the lib to openwatcom and then use it to compile 4os2 giving the
same result.
Gregg
Gregg Young
Andi
I think it makes more sense to add this functionality to openwatcom then
to fix programs one at a time. All that is needed as far as I can see is
some fallback code in Mike's library to try the non"L" (ie DosOpenL
verses DosOpen) functions if the "L" function fails. This should be
backward compatible and transparently add some large file support to any
program that get recompiled.
Gregg
Paul Ratcliffe
> I think it makes more sense to add this functionality to openwatcom then
> to fix programs one at a time. All that is needed as far as I can see is
> some fallback code in Mike's library to try the non"L" (ie DosOpenL
> verses DosOpen) functions if the "L" function fails. This should be
> backward compatible and transparently add some large file support to any
> program that get recompiled.
This isn't going to work. You will still have a DLL dependency on the "L"
functions which mean any programs used on pre-FP13 systems won't load.
You need to resolve the function load addresses dynamically rather than
just shoving in calls to DosOpen and DosOpenL.
On systems which support the "L" function calls, I believe there is no
situation where "L" will fail and the non"L" will not.
ML
> which mean any programs used on pre-FP13 systems won't load.
FTR: which means Warp 4 shouldn't be called a supported OS, because
FP13+ isn't GA for several languages. Random example:
ftp://service.software.ibm.com/ps/products/os2/fixes/v4warp/russian
I actually expected at least a FP9 there, but appearantly it even never
reached that level for the Russian edition of OS/2 Warp 4.
---
Gregg Young
Hi
If you are referring to openwatcom support OS/2 warp 4 is still
supported. The change proposed here has not (and may never) been
implemented.
Gregg
Gregg Young
Paul
Thanks for your input. What is the best approach for loading the
functions dynamically across a wide range of OS2 versions.
Gregg
Andreas Buchinger
a pointer to the real DosOpenL. DosOpenL is never used in my code but _DosOpenL
instead.
static APIRET (* APIENTRY _DosOpenL)(PCSZ pszFileName,
PHFILE phf,
PULONG pulAction,
LONGLONG cbFile,
ULONG ulAttribute,
ULONG fsOpenFlags,
ULONG fsOpenMode,
PEAOP2 peaop2);
int WrapperInit()
{
HMODULE hDoscalls; /* Module handle */
APIRET rc = NO_ERROR; /* Return code */
if (DosQueryModuleHandle("DOSCALLS", &hDoscalls) != NO_ERROR)
TRACE("no DOSCALLS !!!!!!!");
rc = DosQueryProcAddr(hDoscalls, // Handle to module
567, // ProcName specified
NULL, // ProcName (not specified)
(PFN *)&_DosOpenL); // Address returned
// clear pointer cause at this time it helds not the valid address
_DosOpenL = NULL;
TRACE2("567 rc=0x%04X (%d)", rc, rc);
// rc on 567 is 65079 (ERROR_ENTRY_IS_CALLGATE) on Warp Server, and 182
(ERROR_INVALID_ORDINAL) on Warp 3
if ( rc == ERROR_ENTRY_IS_CALLGATE)
{
rc = DosQueryProcAddr(hDoscalls, // Handle to module
981, // ProcName specified
NULL, // ProcName (not specified)
(PFN *)&_DosOpenL); // Address returned
TRACE2("981 rc=0x%04X (%d)", rc, rc);
}
if (rc == NO_ERROR)
{ // large file support detected
iLargeFileSupport = TRUE;
TRACE("Congratulation, your system has large file support (Warp Server
for e-business or better)");
}
else
{ // no LFS
iLargeFileSupport = FALSE;
TRACE("Sorry, your system has no large file support (pre Warp Server
for e-business)");
}
return rc;
}
Regards,
Andi
Ruediger Ihle
Just out of curiosity: Why is the check for DOSCALLS.567 neccessary ?
I'm not aware of any OS/2 version that will allow to query DOSCALLS.981
successfully when it doesn't support large files. Also the comment about
Warp Server for e-business is a bit misleading, since there are systems
that support large files and that are not Warp Servers.
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address
Andreas Buchinger
> On Fri, 4 Sep 2009 07:07:37 UTC, Andreas Buchinger <and...@gmx.net> wrote:
>
> Just out of curiosity: Why is the check for DOSCALLS.567 neccessary ?
>
> I'm not aware of any OS/2 version that will allow to query DOSCALLS.981
> successfully when it doesn't support large files. Also the comment about
> Warp Server for e-business is a bit misleading, since there are systems
> that support large files and that are not Warp Servers.
>
>
I found a code snippet somewhere which uses 567 and 981. AFAIR I had problems
doing it without the 567 check on my Warp3 test system. But I'm not sure anymore
if it is really necessary. Maybe I'll try it again if I find some time.
In a redbook which describes Large File support, non LSF capable systems are
called 'pre Warp Server for e-business' so I kept this name.
Paul Ratcliffe
>>> I think it makes more sense to add this functionality to openwatcom then
>>> to fix programs one at a time. All that is needed as far as I can see is
>>> some fallback code in Mike's library to try the non"L" (ie DosOpenL
>>> verses DosOpen) functions if the "L" function fails. This should be
>>> backward compatible and transparently add some large file support to any
>>> program that get recompiled.
>>
>> This isn't going to work. You will still have a DLL dependency on the "L"
>> functions which mean any programs used on pre-FP13 systems won't load.
>> You need to resolve the function load addresses dynamically rather than
>> just shoving in calls to DosOpen and DosOpenL.
>>
>> On systems which support the "L" function calls, I believe there is no
>> situation where "L" will fail and the non"L" will not.
>
> Thanks for your input. What is the best approach for loading the
> functions dynamically across a wide range of OS2 versions.
Use DosQueryProcAddr on PMMERGE.981 to get a function pointer (to DosOpenL).
If that works without error then call the function pointer, else
call DosOpen().
Paul Ratcliffe
> The following works well for dataseeker. After this init routine _DosOpenL holds
> a pointer to the real DosOpenL. DosOpenL is never used in my code but _DosOpenL
> instead.
>
> int WrapperInit()
> {
> HMODULE hDoscalls; /* Module handle */
> APIRET rc = NO_ERROR; /* Return code */
>
> if (DosQueryModuleHandle("DOSCALLS", &hDoscalls) != NO_ERROR)
> TRACE("no DOSCALLS !!!!!!!");
>
> rc = DosQueryProcAddr(hDoscalls, // Handle to module
> 567, // ProcName specified
> NULL, // ProcName (not specified)
> (PFN *)&_DosOpenL); // Address returned
What if DosQueryModuleHandle returns an error? You go on to call the next
function with an invalid parameter. Not good practice.
IAC, I believe 567 is the 16 bit entrypoint, so this is not what you want.
> // clear pointer cause at this time it helds not the valid address
> _DosOpenL = NULL;
Huh? What's the point of all the above then?
> if ( rc == ERROR_ENTRY_IS_CALLGATE)
> {
> rc = DosQueryProcAddr(hDoscalls, // Handle to module
> 981, // ProcName specified
> NULL, // ProcName (not specified)
> (PFN *)&_DosOpenL); // Address returned
> TRACE2("981 rc=0x%04X (%d)", rc, rc);
> }
Why don't you just call this in the first place?
Ilya Zakharevich
>>> On systems which support the "L" function calls, I believe there is no
>>> situation where "L" will fail and the non"L" will not.
>> Thanks for your input. What is the best approach for loading the
>> functions dynamically across a wide range of OS2 versions.
> Use DosQueryProcAddr on PMMERGE.981 to get a function pointer (to DosOpenL).
> If that works without error then call the function pointer, else
> call DosOpen().
A duplicate in PMMERGE? Did not hear about it, but PMMERGE may be not
loaded...
Probably a misprint?
Ilya
Paul Ratcliffe
<nospam...@ilyaz.org> wrote:
>> Use DosQueryProcAddr on PMMERGE.981 to get a function pointer (to DosOpenL).
>> If that works without error then call the function pointer, else
>> call DosOpen().
>
> A duplicate in PMMERGE? Did not hear about it, but PMMERGE may be not
> loaded...
I meant to write DOSCALLS not PMMERGE.
Andreas Buchinger
> On Fri, 04 Sep 2009 09:07:37 +0200, Andreas Buchinger <and...@gmx.net> wrote:
>
>> The following works well for dataseeker. After this init routine _DosOpenL holds
>> a pointer to the real DosOpenL. DosOpenL is never used in my code but _DosOpenL
>> instead.
>>
>> int WrapperInit()
>> {
>> HMODULE hDoscalls; /* Module handle */
>> APIRET rc = NO_ERROR; /* Return code */
>>
>> if (DosQueryModuleHandle("DOSCALLS", &hDoscalls) != NO_ERROR)
>> TRACE("no DOSCALLS !!!!!!!");
>>
>> rc = DosQueryProcAddr(hDoscalls, // Handle to module
>> 567, // ProcName specified
>> NULL, // ProcName (not specified)
>> (PFN *)&_DosOpenL); // Address returned
>
> What if DosQueryModuleHandle returns an error? You go on to call the next
> function with an invalid parameter. Not good practice.
Absolutly correct. I've changed that. Thx.
> IAC, I believe 567 is the 16 bit entrypoint, so this is not what you want.
>
>> // clear pointer cause at this time it helds not the valid address
>> _DosOpenL = NULL;
>
> Huh? What's the point of all the above then?
>
>> if ( rc == ERROR_ENTRY_IS_CALLGATE)
>> {
>> rc = DosQueryProcAddr(hDoscalls, // Handle to module
>> 981, // ProcName specified
>> NULL, // ProcName (not specified)
>> (PFN *)&_DosOpenL); // Address returned
>> TRACE2("981 rc=0x%04X (%d)", rc, rc);
>> }
>
> Why don't you just call this in the first place?
At some stage during development I thought it was necessary as noted above. But
tried again and as you already wrote, query 567 is not necessary. I've changed
that too.
Regards,
Keith
support this (pre Warp 4 WEB and eCS versions) gives an error when loading
the executatable. To get around this I moved the DosOPenL (etc) calls to a
DLL that is only loaded if the system supports these calls.
I use the following code to check the OS version
rc = DosQuerySysInfo(11L , /* Get
version to see if large file support is possible */
QSV_MAX ,(PVOID)aulSysInfo,
sizeof(ULONG)*QSV_MAX);
if(aulSysInfo[1] == 45) /*
Large File support only possible with Warp4 WEB and eCS */
lfsupport = 1;
/* set large file suport active */
Keith Merrington
"Paul Ratcliffe" <ab...@orac12.clara34.co56.uk78> wrote in message
news:slrnhage6a...@news.pr.network...