ntdll/kernel32: #27

[Eric Pouech]

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