Eric Pouech pouech-eric@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.