This is still introduced when learning character encoding.
The original intention is to feel that since character encoding is so common, how does the operating system do it? So I want to debug the textouta function to see how it handles character encoding when outputting text. The final result is:
Textouta actually encapsulates another function call. The process of textouta is like this:
Bool textouta (
HDCHdc, // Handle to DC
IntNXStart, // X-coordinate of starting position
IntNYStart, // Y-coordinate of starting position
LpctstrLpString, // Character string
IntCbString// Number of characters
){
If (cbstring <= 0 ){
JMP 77f0fd46h
}
If (lpString = NULL ){
Jmp 77F0FD46h
}
PROC lpFunc = (PROC) 0x77EF8E4E;
LpFunc (hdc, nXStart, nYStart, 0, 0, lpString, cbString, 0, 1 );
}
In the above pseudo code, lpFunc calls the GdiGetCodePage function and the MultiByteToWideChar function in turn, and then calls the code at an address (77EF664F on my computer, the next step is other work, while TextOutW directly calls the code at the 77EF664F address.
The above is the conclusion of debugging for several hours. In fact, all these things can be seen through static analysis, which is simpler. This conclusion is meaningless later. However, for a few hours of debugging, I will keep it down for the time being.