Re: msdos/int21 CREAT special cases

[Eric Pouech]

Ferenc Wagner wrote:
Eric Pouech <[EMAIL PROTECTED]> writes:


_lcreat16 (and al.) is in fact a 16 bit function, implemented in
krnl386. so, normally it wouldn't be accessible from 32 bit DLLs (we
can do it in some cases, but the least we do, the better it is).
So, if the same behavior (as _lcreat16) can be obtained with other 32
bit APIs (like _lcreat or CreateFile), that'd be better. Beware, that
_lcreat16 is different from _lcreat (search path order for example is
not the same).


Thanks for the clarification!  Given the definitions

HFILE16 WINAPI _lcreat16( LPCSTR path, INT16 attr )
{
    return Win32HandleToDosFileHandle( (HANDLE)_lcreat( path, attr ) );
}
HFILE WINAPI _lcreat( LPCSTR path, INT attr )
{
    /* Mask off all flags not explicitly allowed by the doc */
    attr &= FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM;
    TRACE("%s %02x\n", path, attr );
    return (HFILE)CreateFileA( path, GENERIC_READ | GENERIC_WRITE,
                               FILE_SHARE_READ | FILE_SHARE_WRITE, NULL,
                               CREATE_ALWAYS, attr, 0 );
}
I could easily change my patch to call _lcreat() or
CreateFileA() instead of _lcreat16(), but I am not sure if
that would be right, since the differences you mention do
not seem to be implemented, and I could not find any
documentation on them.  In sight of this, what do you
recommend?  The conformance tests do not show any anomaly in
the behaviour of _lcreat(), but it may be only that these
aspects simply are not tested.
you're right, I was in fact referring to the differences for
OpenFile between 16 and 32 bits. Replacing _lcreat16 by 
Win32HandleToDosFileHandle( (HANDLE)_lcreat( should be just fine
A+
--
Eric Pouech