msdos/int21 CREAT special cases

[Eric Pouech]

Ferenc Wagner wrote:
> 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.
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