Fiddling with EnumServicesStatusExW

Paul Vriens paul.vriens.wine at gmail.com
Fri May 15 03:43:11 CDT 2009


Rolf Kalbermatter wrote:
>> From: Paul Vriens [mailto:paul.vriens.wine at 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 ;)

-- 
Cheers,

Paul.



More information about the wine-devel mailing list