msdos/int21 CREAT special cases

[Ferenc Wagner]

Eric Pouech <pouech-eric at wanadoo.fr> 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.

Well, the above has not much to do with my original patch,
but given some pointers I am willing to investigate this
anyway.
                                                Feri.