ntdll/kernel32: #27
Eric Pouech
pouech-eric at wanadoo.fr
Tue Jun 17 15:00:38 CDT 2003
Alexandre Julliard wrote:
> Eric Pouech <pouech-eric at 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+
--
Eric Pouech
More information about the wine-devel
mailing list