Eric Pouech pouech-eric@wanadoo.fr writes:
- this patch partially implements this scheme. It's partial because
console handles are still handled by wineserver. Their value is however obfuscated so that we can track their real usage.
IMO you shouldn't need to have any obfuscation code in the server at all. If you need that, something is wrong with the design.
- next step would mean implementing the console handle management
outside of wineserver (likely in wineconsole)
I'm not convinced we really need that; IMO it's OK to keep them in the server, as long as we can identify them as console handles from the client.
Alexandre Julliard wrote:
Eric Pouech pouech-eric@wanadoo.fr writes:
- this patch partially implements this scheme. It's partial because
console handles are still handled by wineserver. Their value is however obfuscated so that we can track their real usage.
IMO you shouldn't need to have any obfuscation code in the server at all. If you need that, something is wrong with the design.
I don't need the obfuscation at all (just setting the two lower bits of the handle to 1). I used obfuscation to make it easier to track bugs. I'll resubmit without the obfuscation macros.
- next step would mean implementing the console handle management
outside of wineserver (likely in wineconsole)
I'm not convinced we really need that; IMO it's OK to keep them in the server, as long as we can identify them as console handles from the client.
I was what I really wanted to move to wineconsole was the content of screen buffers (which are copied twice currently and which I find rather bad). Of course, we could split handle management and object management in two different locations (wineserver resp. wineconsole), but this will complicate things IMO and as any performance enhancement, it doesn't need to be done immediately (there are some other items to focus on)
A+
Eric Pouech pouech-eric@wanadoo.fr writes:
I don't need the obfuscation at all (just setting the two lower bits of the handle to 1). I used obfuscation to make it easier to track bugs. I'll resubmit without the obfuscation macros.
My objection is not so much the obfuscation itself (though I think it's safer to only touch the lower two bits), but the fact that the server knows about it. This handle manipulation must be purely client side, the server must not have to know about it at all; all handles passed to the server must be normal handles.
My objection is not so much the obfuscation itself (though I think it's safer to only touch the lower two bits), but the fact that the server knows about it. This handle manipulation must be purely client side, the server must not have to know about it at all; all handles passed to the server must be normal handles.
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
A+
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.
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+
Eric Pouech pouech-eric@wanadoo.fr writes:
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 second one IMO. The client cannot possibly treat console handles as opaque values, since it needs to know about the obfuscation/bit manipulation; it also needs to cope with the STD_*_HANDLE pseudo-handles. So it's much better to encapsulate all that stuff in the client than to have the client do half of it and the server do the other half.
-
Alexandre Julliard -
Eric Pouech