The code page on the server is not necessarily the code page on the client
It’s not enough to choose a code page. You have to choose the right code page.
We have a system that reformats and reinstalls a network client computer each time it boots up. The client connects to the server to obtain a loader program, and the loader program then connects to the server to download the actual operating system. If anything goes wrong, the server sends an error message to the client, which is displayed on the screen while it’s still in character mode. (No Unicode available here.)
Initially, we used
FormatMessageAto generate the error message, but somebody told us we should use
WideCharToMultiByte(CP_OEM). I’m not sure whether this is a valid suggestion, because the client hasn’t yet installed Unicode support so it only is capable of displaying 8-bit text, and using
CP_OEMwill use the OEM code page on the server, which doesn’t necessarily match the OEM code page on the client.
What is the correct way of generating the error message string?
Now, mind you, the argument against using
CP_OEM is the same argument against using
FormatMessageA! In neither case are you sure that the code page on the server matches the code page on the client. If
CP_OEM is wrong, then so too is
FormatMessageA (which uses
The correct solution is to use
FormatMessageW followed by
x is the OEM code page of the client. You need to get this information from the client to the server somehow so that the server knows what character set the client is going to use for displaying strings.
There’s really nothing deep going on here. If you’re going to display an 8-bit string, you need to use the same code page when generating the string as you will use when displaying it. Keep your eye on the code page.