On Tuesday 11 December 2007 21:02:07 David Eriksson wrote: > I think that the correct solution is to not read the reserved value, > i.e. removing this line from both functions:
Within the rapi2 stuff I already removed that, figured that it would only be something to be used within the CeReg.. functions, not actually something with the device. > > 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.) I guess that this part changed then in the rapi2 stuff, because when using the rapi_buffer_read_optional_uint32, this went wrong. I don't know what exactly the optional means in these names, but it looks to me that the device sends a 0/1 bit denoting whether a certain value is sent. (If i understand the readd_optional_ code correctly). Within the rapi2 this did NOT work, because for example with the RegQueryInfo function it can be seen that all values are sent, no preceding 1 values. So if I would use the option_read_uint32 there, this would not work, it would try to read too much. Furthermore, regarding the strings and blocks of data, you just tell to the device how much you will expect in the response from the device. This value must always be >= 1, since you will always get at least 1 dword backup from the device denoting the size of the buffer that follows. If you did not want any info from the device, this value will be 0, but the value 0 (the length) you must read :) Finally, I guess that there was a small error in the read_string method, because the device does not send the terminating \0 character. The example that I found on the old-website (http://synce.sourceforge.net/synce/packet.php) shows a rapi1 call where we want to find out the Special folder path. It states the length is 0x0d. this corresponds exactly to the length of: "\My Documents" It shows a null terminator after this string, but in all the tests I have done with RegEnumValue, this 0 terminator does not exist and the next dword belongs to the next parameter. I am not sure whether this also holds for the rapi1 though, but for sure it holds for the rapi2 stuff. If i am correct, this already has been taken care of with the patch I supplied earlier to mark ellis. > > > 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 I don't understand what you mean with the optional here, since the device must always send this information because it does not have any knowledge of what the user requested (that is not sent by us in the request) > > Hey, the reverse engineering is the fun part! :-) I have to agree that it is the fun part. Unfortunately I don't have the possibility of booting into windows and get the data. It is really fun to see that without actually knowing anything, you start to make educated guesses about what would be useful and what not and it is soooo nice if your guesses turn out to be right :) As mentioned, I saw that there still some gaps to be filled in with the rapi2 API, I will see what I can do during the week for those. Unfortunately these are the more 'dangerous ones', like delete keys, delete values, etc :) Note to self: Make backup :) Regards, Guido Diepen -- Aviation is proof that given the will, we have the capacity to achieve the impossible. --Eddie Rickenbacker ------------------------------------------------------------------------- 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
