On Wed, 2007-12-12 at 08:20 +0000, Mark Ellis wrote: > On Tue, 2007-12-11 at 21:02 +0100, David Eriksson wrote: > > On Tue, 2007-12-11 at 17:28 +0000, Mark Ellis wrote: > > > 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: > > Seems to be working ok with this still in, but I have actually supplied > a non-NULL location in my testing, hope it doesn't break later. > > > 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 > > > > This was all fine. > > > 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 > > > > Had to take out the aforementioned read of last_error. Also had to swap > lpClass and lpcbClass, ie read the size first, perfectly logical but > breaks the parameter passing order, bizarre. Do you think when M$ > assigns these things for someone to spec, it explicitly states "make it > as awkward as possible". > > > > > 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 > > > > > > Had to remove the last_error read again, still testing. >
Time to contradict myself. I said that last error wasn't returned by these functions. Well it does seem to always be zero, but I need to read it because the return value is definitely second in the buffer. This becomes obvious when stuck in an infinite loop when you're certain you're checking for ERROR_NO_MORE_ITEMS :) I'm still a uint32 short in the buffer, so what seems most likely is that the device does not return, in the case of enumvalue, the size of the name string, we're left to figure that out. Same applies to infokey with regard to the class name. Anyone see any glaring errors in my reasoning ? Mark ------------------------------------------------------------------------- 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
