Best Answer MSIYER , 09 May 2013 - 11:22
Yes Stefan, this Installscript function is a wrapper over Win32 API.
But the issue was more complicated than originally thought. I am going to share what I found in the hope that this solves someone else's problem too:
The value fetched from the registry by Installshield installer was written by a Win32 application. It has the following line of code:
RegSetValueEx(hKey, LEICA_PATH, 0, REG_SZ, (const unsigned char*)m_reqLeicaPath.GetBuffer(m_reqLeicaPath.GetLength()), m_reqLeicaPath.GetLength());
The RegSetValueEx function has the following signature:
LONG WINAPI RegSetValueEx(
_In_ HKEY hKey,
_In_opt_ LPCTSTR lpValueName,
_Reserved_ DWORD Reserved,
_In_ DWORD dwType,
_In_ const BYTE *lpData,
_In_ DWORD cbData
);
The MSDN reference for RegSetValueEx says the following about DWORD cbData:
cbData [in]
The size of the information pointed to by the lpData parameter, in bytes. If the data is of type REG_SZ, REG_EXPAND_SZ, or REG_MULTI_SZ, cbData must include the size of the terminating null character or characters.
The actual cbData value that the application was passing was :
m_reqLeicaPath.GetLength()
The m_reqLeicaPath variable is a CString and the CString::GetLength() returns the byte count of the string without taking into account the terminating null of a string.
The correct cbData should have been:
(m_reqLeicaPath.GetLength() + 1)
RegSetValueEx specifically requires the byte count to include one/two bytes for null character depending on ANSI/UNICODE settings.
Thus the value being stored in the registry was not proper. The way it would be retrieved will also be not proper.
I am killing the application's bugs. I have also decided to clean up the string based on the backslash guarantee.
Go to the full post