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 portability of APIs is less an issue), which I still consider worthwhile.
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 think that's a good idea, especially since winedos is not a standard dll. And IMO it's preferable to have kernel export _lclose16 which is a standard API, than replacing it by a new DisposeFileHandle function that doesn't correspond to anything on Windows.
A+
-- Eric Pouech
