Re: Re: msdos/int21 CREAT special cases

[Pouech Eric DMI AEI CAEN]

please stop using krnl386.exe export when possible (especially for dos emulation which is going out of kernel32/krnl386.exe combo). So, if CreateFile can do, please use it (ditto for any other krnl386 file related functions)
this is needed for proper DLL separation
> Hmm, and is there a reason to not do it in _lcreat16() instead?
> Or is _lcreat16() really "clever" enough to handle volume labels
> "properly" if called directly?
> Somehow I doubt it... ;)
> Or in fact you could walk further up the chain and maybe find that even
> _lcreat() should be the function to have that check instead...
> (or, for that matter, even CreateFileA and thus CreateFileW...)
>
> So my rough guess is that this should probably be prevented in CreateFileW
> instead even.

msdos/int21 CREAT special cases

[Ferenc Wagner]

Pouech Eric DMI AEI CAEN  writes:
> please stop using krnl386.exe export when possible
> (especially for dos emulation which is going out of
> kernel32/krnl386.exe combo). So, if CreateFile can do,
> please use it (ditto for any other krnl386 file related
> functions) this is needed for proper DLL separation

Sorry, I do not understand this.  What is krnl386.exe
export?  Should the DOS emulation code (being moved into
dlls/winedos) directly call CreateFileA and avoid the
_lcreat family?  Could you elaborate?
                                          Feri.

msdos/int21 CREAT special cases

[Eric Pouech]

Ferenc Wagner wrote:
> Pouech Eric DMI AEI CAEN  writes:
> > please stop using krnl386.exe export when possible
> > (especially for dos emulation which is going out of
> > kernel32/krnl386.exe combo). So, if CreateFile can do,
> > please use it (ditto for any other krnl386 file related
> > functions) this is needed for proper DLL separation

_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).

HTH

A+

msdos/int21 CREAT special cases

[Ferenc Wagner]

Eric Pouech  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.

msdos/int21 CREAT special cases

[Eric Pouech]

Ferenc Wagner wrote:
> Eric Pouech  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+