Introduction
This routine shows how to use UpdateResource
to change a single string resource in an executable file.
This all started because I was writing an internationalized screen saver that had to work on all Windows platforms, and I needed to be able to change the screen saver's name to the correct language at install time.
With Win9x, this is easy, because the .scr file name is the name shown in the Display settings (to verify, on a 9x system, search for *.scr files), so all I had to do was rename the file. With NT4/2000/XP, it was another story. On those OSs, the screen saver's name is in string resource ID=1 of the .scr file; the filename is completely different.
So, I had to somehow figure out how to change a string resource on the fly.
I knew UpdateResource
was the solution, but it wasn't well documented, and I had found a number of questions in newsgroups by people who had been having lots of problems with it when trying to use it on string resources. It's one of those fun API routines that seems to never return an error code even though it doesn't work!
Well, I poked and prodded and with the help of a hex editor and a resource viewer for debugging, I figured it all out.
The keys to getting things to work were:
- Converting the replacement string to Unicode first (that one was clearly documented).
- Unless you are writing string ID=0, the buffer passed to
UpdateResource
must start with one or more leading zeroed WCHAR
s; each one you add increments the string resource ID by one (so in the code below, to get string ID=1, I start the buffer with a single zeroed WCHAR
).
- After the leading zero
WCHAR
s, include a WCHAR
containing the number of characters in the string, then fill out the buffer with the actual converted Unicode characters.
- The buffer must be
WCHAR
-aligned, and its size must be an even number of WCHAR
s (to guarantee this, I use GlobalAlloc
).
I am sure my code could be cleaner, and some of the assumptions above may not be exactly correct, though they work in the limited scope in which I have tried the code.
The PADDINGXX mystery solved?
I discovered that UpdateResource
has an innocuous but curious side effect... if it needs to insert padding to correctly align sections, it inserts the repeating pattern PADDINGXX as needed. So, if you ever see those bytes in a file, it's probably because the file was processed by UpdateResource
. If you are debugging UpdateResource
, the presence of fragments of PADDINGXX bytes in the output file can also be a tip-off that you have an alignment or padding problem (but they may also be there innocuously, for example, if the preceding section needed to be padded out by a few bytes).
Caveats
- This code has been tested only on executables that have a string resource ID=1 in a string table separate from other string tables (e.g., a screen saver).
- This will only work on Windows NT4/2000/XP only (Win9x doesn't support
UpdateResource
and related APIs).
Sample Code
BOOL SetScreenSaverName(LPCTSTR szSSPath, LPCTSTR szSSName)
{
HANDLE h = ::BeginUpdateResource(szSSPath,FALSE);
if(!h)
{
return FALSE;
}
CString sNewString = szSSName;
int iCharCount = sNewString.GetLength() + 1;
LPWSTR pUnicodeString = new WCHAR[iCharCount];
if(!pUnicodeString)
{
return FALSE;
}
DWORD dwUnicodeCharCount =
MultiByteToWideChar(CP_ACP, NULL, sNewString.GetBuffer(0),
-1, pUnicodeString, iCharCount);
HGLOBAL hGlob =
GlobalAlloc(GHND, (dwUnicodeCharCount + 4) * sizeof(WCHAR) );
if(!hGlob)
{
delete pUnicodeString;
return FALSE;
}
LPWSTR pBufStart = (LPWSTR)GlobalLock(hGlob);
if(!pBufStart)
{
GlobalFree(hGlob);
delete pUnicodeString;
return FALSE;
}
LPWSTR pBuf = pBufStart;
pBuf++;
*(pBuf++) = (WCHAR)dwUnicodeCharCount-1;
for(int i=0; i<(int)dwUnicodeCharCount-1; i++)
*(pBuf++) = pUnicodeString[i];
delete pUnicodeString;
if(++dwUnicodeCharCount % 1)
dwUnicodeCharCount++;
BOOL bSuccess = TRUE;
if(!::UpdateResource(h, RT_STRING, MAKEINTRESOURCE(1),
MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US),
pBufStart, dwUnicodeCharCount * sizeof(WCHAR) ) )
{
bSuccess = FALSE;
}
GlobalUnlock(hGlob);
GlobalFree(hGlob);
::EndUpdateResource(h, FALSE);
return bSuccess;
}