Rolf Kalbermatter wrote:
From: Paul Vriens [mailto:[email protected]]
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 ;)
--
Cheers,
Paul.
