28 May
2003
28 May
'03
11:11 a.m.
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.
28 May
28 May
2:43 p.m.
New subject: msdos/int21 CREAT special cases
Pouech Eric DMI AEI CAEN <pouech-eric(a)wanadoo.fr> 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.
2 Jun
2 Jun
7:31 p.m.
New subject: msdos/int21 CREAT special cases
Ferenc Wagner wrote:
Pouech Eric DMI AEI CAEN
<pouech-eric(a)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).
HTH
A+
--
Eric Pouech
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
3 Jun
3 Jun
10:06 a.m.
New subject: msdos/int21 CREAT special cases
Eric Pouech <pouech-eric(a)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.
6:55 p.m.
New subject: msdos/int21 CREAT special cases
Ferenc Wagner wrote:
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
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
_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.
7640
days inactive
7646
days old
4 comments
3 participants
participants (3)
-
Eric Pouech -
Ferenc Wagner -
Pouech Eric DMI AEI CAEN