Alexandre Julliard wrote:
Eric Pouech pouech-eric@wanadoo.fr writes:
as I wanted console handles to be managed by wineconsole, it was cleaner IMO to let them be transparently handled on the client side If you really prefer in the long run to keep the handles managed by wineserver, then the server should manage them transparently
I'm not sure I follow you. They can't be handled transparently on the client side, the client has to check for console handles in functions like ReadFile, and convert them to whatever is appropriate, whether that means a server handle or a wineconsole handle. So it seems much cleaner to always intercept console handles in the client, rather than intercepting some of them and passing others straight through to the server. Whether or not they turn out to be implemented in wineconsole ultimately is a different issue IMO.
In the patch I sent you, the interception is made on the client side. By transparently, I meant the obfuscation/deobfuscation mechanisms.
The full discussion we have is around passing console handles to the server. The client already intercepts any handle and checks whether it's a console handle or a regular ntdll handle. If it's a console handle, then implementation is passed to console functions (ReadConsole for ReadFile and so on).
The discussion we have (at least as I understand it ;-), is whether we should manage, on the client side, console handles: - as obscure values passed by the server (except for the two low bits set to 1) (this is the current patch implementation) - or as regular winserver handles with the two low bits set to 1, which means cleaning up those bits before sending the handles to the server
the transparency I was talking about referred to how the client should manage the handles if we had to move console handle creation out of wineserver
A+