Eric Pouech pouech-eric@wanadoo.fr 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 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.
Alexandre Julliard wrote:
Eric Pouech pouech-eric@wanadoo.fr 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 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.
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.
A+
Eric Pouech pouech-eric@wanadoo.fr 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.
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.
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 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. A+
Eric Pouech pouech-eric@wanadoo.fr 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's no reason that it couldn't return a std handle. If there are really places where we don't want that, we can do the check in the caller, but I suspect it was done only to allow lazy init of the stdio handles.
-
Alexandre Julliard -
Eric Pouech