Rolf Kalbermatter wrote:
From: Paul Vriens [mailto:paul.vriens.wine@gmail.com]
How can I make sure the pointers to the strings are correctly passed back as well? Should the RPC stuff take care of these pointers and 'translate' them?
Those pointers are not really pointers but byte offsets from the start of the buffer. It's been a long time that I have looked into this but I believe that this is even the case on the client side (e.g. the caller). So there should be no problem with this, as RPC simply would need to copy the entire buffer including the strings section.
Sure, RPC does return the structs and the strings but the pointers (byte offsets) are wrong. How can I teach RPC to respect (change) those pointers?
We could of course teach EnumServicesStatusExW to change the pointers to the appropriate ones. We know exactly where there strings are so it should be fairly trivial to change those pointers. This however seems like a hack.
Well the original MS service control API has separate RPC calls for the A and W calls and the offsets are therefore calculated by the service control service itself correctly. If you want to implement the A call on top of the W call as is currently done for the other servicecontrol APIs too, you will probably have to adjust those offsets accordingly in the W to A translation of the strings.
Yeah, I know. I have the thing working with this (and that mentioned hack) but I'm obviously looking for the best (read correct) solution.
In the interest of a really compatible RPC interface to the MS service control service however, it would be better to implement the separate RPC calls for the A and W version.
Currently an MS Window client trying to call the Wine service control service over RPC will fail for the A calls (but there are also other RPC problems that make Windows-Wine RPC not work well).
More things to fix then ;)