Eric Pouech <[EMAIL PROTECTED]> writes:
> this won't work if the file number you want to dup is one of the
> default files (stdin, stdout, stderr...), as
> Win32HandleToDosFileHandle won't let you set it. Unless
> Win32HandleToDosFileHandle is wrong about this test.
I think it's wrong yes, there
There are better ways of getting rid of FILE_Dup2 than moving a bunch
of kernel APIs into winedos. The obvious one is to allocate new
handles until we get the one we want and then free the others; not
exactly efficient, but I don't think many apps calls FILE_Dup2 in a
loop.
this won't work if the f
Eric Pouech <[EMAIL PROTECTED]> writes:
> but we do export FILE_Dup2 from kernel32, which doesn't correspond to
> anything either. My patch was also killing that one. Basically,
> replacing one krnl386 API, and a wine only API in kernel32, with a
> wine only API in winedos (which is our own, so po
Alexandre Julliard wrote:
Eric Pouech <[EMAIL PROTECTED]> writes:
I hope Alexandre will not got mad about the introduced circular dep
(kernel32 => (delay) winedos => kernel32). Since, we're now building
the DLLs through the .spec files, I assumed, since it no longer
impacts the make system, it wo
Eric Pouech <[EMAIL PROTECTED]> writes:
> I hope Alexandre will not got mad about the introduced circular dep
> (kernel32 => (delay) winedos => kernel32). Since, we're now building
> the DLLs through the .spec files, I assumed, since it no longer
> impacts the make system, it would be ok.
I don't
