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.
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
WCHARs; 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
- After the leading zero
WCHARs, 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
WCHARs (to guarantee this, I use
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).
- 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).
BOOL SetScreenSaverName(LPCTSTR szSSPath, LPCTSTR szSSName)
HANDLE h = ::BeginUpdateResource(szSSPath,FALSE);
CString sNewString = szSSName;
int iCharCount = sNewString.GetLength() + 1;
LPWSTR pUnicodeString = new WCHAR[iCharCount];
DWORD dwUnicodeCharCount =
MultiByteToWideChar(CP_ACP, NULL, sNewString.GetBuffer(0),
-1, pUnicodeString, iCharCount);
HGLOBAL hGlob =
GlobalAlloc(GHND, (dwUnicodeCharCount + 4) * sizeof(WCHAR) );
LPWSTR pBufStart = (LPWSTR)GlobalLock(hGlob);
LPWSTR pBuf = pBufStart;
*(pBuf++) = (WCHAR)dwUnicodeCharCount-1;
for(int i=0; i<(int)dwUnicodeCharCount-1; i++)
*(pBuf++) = pUnicodeString[i];
if(++dwUnicodeCharCount % 1)
BOOL bSuccess = TRUE;
if(!::UpdateResource(h, RT_STRING, MAKEINTRESOURCE(1),
pBufStart, dwUnicodeCharCount * sizeof(WCHAR) ) )
bSuccess = FALSE;