Using UpdateResource to change a string resource

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 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 WCHAR).
• 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 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

// szSSPath = path to .exe file// szSSName = replacement text BOOL SetScreenSaverName(LPCTSTR szSSPath, LPCTSTR szSSName) { HANDLE h = ::BeginUpdateResource(szSSPath,FALSE); if(!h) { // BeginUpdateResource failedreturn FALSE; } CString sNewString = szSSName; int iCharCount = sNewString.GetLength() + 1; LPWSTR pUnicodeString = new WCHAR[iCharCount]; if(!pUnicodeString) { // new failedreturn FALSE; } DWORD dwUnicodeCharCount = MultiByteToWideChar(CP_ACP, NULL, sNewString.GetBuffer(0), -1, pUnicodeString, iCharCount); HGLOBAL hGlob = GlobalAlloc(GHND, (dwUnicodeCharCount + 4) * sizeof(WCHAR) ); if(!hGlob) { // GlobalAlloc faileddelete pUnicodeString; return FALSE; } LPWSTR pBufStart = (LPWSTR)GlobalLock(hGlob); if(!pBufStart) { // GlobalLock failed GlobalFree(hGlob); delete pUnicodeString; return FALSE; } LPWSTR pBuf = pBufStart; pBuf++; // offset to make it string ID=1. Increment by more// to change to a different string ID// next 2 bytes is string length *(pBuf++) = (WCHAR)dwUnicodeCharCount-1; for(int i=0; i<(int)dwUnicodeCharCount-1; i++) // remaining bytes are string in wide chars (2 bytes each) *(pBuf++) = pUnicodeString[i]; delete pUnicodeString; if(++dwUnicodeCharCount % 1) // make sure we write an even number dwUnicodeCharCount++; BOOL bSuccess = TRUE; if(!::UpdateResource(h, RT_STRING, MAKEINTRESOURCE(1), MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), pBufStart, dwUnicodeCharCount * sizeof(WCHAR) ) ) { // UpdateResource failed bSuccess = FALSE; } GlobalUnlock(hGlob); GlobalFree(hGlob); ::EndUpdateResource(h, FALSE); // write changes return bSuccess; }