On Tue, 2007-12-11 at 17:28 +0000, Mark Ellis wrote: > On Tue, 2007-12-11 at 11:16 +0100, Guido Diepen wrote: > > > > > > Me too. I'm going to, hopefully today, go through all the rapi1 registry > > > calls and see exactly what works. > > > > I was thinking, you could see if the problem lays only in the InfoKey, or > > also in the EnumValue. The only reason I call the InfoKey is that I want > > to know what sizes for the buffers I need to reserve. > > > > I'm getting there, InfoKey now works. There were a few problems, but the > killer was the implementation trying to GetLastError, which isn't > provided by this function, who knows why. This of course meant the > buffer position was 4 bytes too far in. > > Unfortunately, EnumValue still doesn't work.
I think that the correct solution is to not read the reserved value, i.e. removing this line from both functions: rapi_buffer_read_optional_uint32(context->recv_buffer, lpReserved); Otherwise, they should be implemented just fine. Here are my specs. "No data" means that the value should not be sent. "Data" means that the value should be sent. (Controls parameter to rapi_buffer_write_optional* functions.) RegQueryInfoKey: Request 4 bytes HKEY hKey *lpcbClass bytes optional LPWSTR lpClass 4 bytes optional data LPDWORD lpcbClass, 4 bytes optional no data LPDWORD lpReserved, 4 bytes optional no data LPDWORD lpcSubKeys, 4 bytes optional no data LPDWORD lpcbMaxSubKeyLen, 4 bytes optional no data LPDWORD lpcbMaxClassLen, 4 bytes optional no data LPDWORD lpcValues, 4 bytes optional no data LPDWORD lpcbMaxValueNameLen, 4 bytes optional no data LPDWORD lpcbMaxValueLen, 4 bytes optional no data LPDWORD lpcbSecurityDescriptor, 8 bytes optional no data PFILETIME lpftLastWriteTime Response *lpcbClass bytes optional LPWSTR lpClass 4 bytes optional data LPDWORD lpcbClass, ignoring LPDWORD lpReserved, 4 bytes optional LPDWORD lpcSubKeys, 4 bytes optional LPDWORD lpcbMaxSubKeyLen, 4 bytes optional LPDWORD lpcbMaxClassLen, 4 bytes optional LPDWORD lpcValues, 4 bytes optional LPDWORD lpcbMaxValueNameLen, 4 bytes optional LPDWORD lpcbMaxValueLen, 4 bytes optional LPDWORD lpcbSecurityDescriptor, 8 bytes optional PFILETIME lpftLastWriteTime RegEnumValue 4 bytes HKEY hKey, 4 bytes DWORD dwIndex, *lpcbValueName bytes optional no data LPWSTR lpszValueName, 4 bytes optional data LPDWORD lpcbValueName, 4 bytes optional no data LPDWORD lpReserved, 4 bytes optional no data LPDWORD lpType, *lpcbData bytes optional no data LPBYTE lpData, 4 bytes optional data LPDWORD lpcbData Response 4 bytes last error 4 bytes return value *lpcbValueName bytes optional LPWSTR lpszValueName, 4 bytes optional LPDWORD lpcbValueName, ignoring LPDWORD lpReserved, 4 bytes optional LPDWORD lpType, *lpcbData bytes optional LPBYTE lpData, 4 bytes optional LPDWORD lpcbData > > What you could try is apply my patches to the synce-registry program, but > > instead of calling the InfoKey function to determine these values, you can > > set them manually > > > > So I mean these: > > //First determine the size of the holding arrays for all > > //subvalues/keys > > DWORD lpcSubKeys ; > > DWORD lpcbMaxSubKeyLen ; > > DWORD lpcbMaxClassLen ; > > DWORD lpcValues ; > > DWORD lpcbMaxValueNameLen ; > > DWORD lpcbMaxValueLen ; > > > > lpcbMaxClassLen++ ; > > lpcbMaxValueNameLen++ ; > > lpcbMaxValueLen++ ; > > lpcbMaxSubKeyLen++ ; > > > > The MaxClassLen you can set to 256 (that is 255 chars + the \0 terminator) > > The MaxSubKeyLen you can set to the max path len: MAX_PATH > > > > the other two values can be quite high, I am not sure whether a limit is > > put on the value len or the valuenamelen, but the maximum value len I > > encountered is 4096 bytes. If you just put it for testing at something > > like 16384 it should be ok. > > > > Then we will at least know whether the problem is within QueryInfo or > > within EnumValue. > > > > The answer seems to be both. > > We can hardcode sizes if it comes to it, but now I've done InfoKey I > think I've got the hang of it. It'll need to be fixed sometime anyway, > might as well do it right. > > David, after my first experience of reverse engineering in rapi, I'm > humbled by the effort it must have taken to get librapi to the point > it's at, hats off to you. Hey, the reverse engineering is the fun part! :-) Cheers, David -- ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
