Question about ATL component Chinese path Registration

The ATL component registration is a bad bug that needs to be solved by modifying the ATL source code. This record is recorded here to facilitate the next time you reinstall the machine.

I used ATL to write a COM component (compiled under MBCS). If it is installed in a Chinese path, registration will fail.
Why does it fail?
Open the source file statreg. h of ATL and find the function bool addstring (lpcolestr lpsz ).
The updateregistry of the component calls bool addchar (const tchar * PCH ).
These two functions are used. See:
Bool addstring (lpcolestr lpsz)
{
Uses_conversion;
Lpctstr lpszt = ole2ct (lpsz );
While (* lpszt)
{
Addchar (lpszt );
Lpszt ++; // note! @ 1
}
Return true;
}
Bool addchar (const tchar * PCH)
{
If (NPOs = nsize) // realloc @ 3
{
Nsize * = 2;
P = (lptstr) cotaskmemrealloc (p, nsize * sizeof (tchar ));
}
P [NPOs ++] = * PCH;
# Ifndef _ Unicode
If (isdbcsleadbyte (* PCH ))
P [NPOs ++] = * (PCH + 1); file: // note! @ 2
# Endif
Return true;
}
If we do not use Unicode, If we encounter a Chinese character, Mark @ 2 lines to identify the entire Chinese Character and store it in the buffer zone. However, the PCH variable still points
When the first byte of the Chinese character is returned to the @ 1 line, lpszt ++ points to the second byte of the Chinese character! Later, the second byte of the Chinese character will be considered as an independent word.
Again. So garbled characters are generated. (some of the information registered by the component is incorrect)
How can this problem be solved?
From the above analysis, we can easily find a solution:
Bool addstring (lpcolestr lpsz)
{
Uses_conversion;
Lpctstr lpszt = ole2ct (lpsz );
While (* lpszt)
{
Addchar (lpszt );
Lpszt ++;
}
Return true;
}
/*************************************** ****************************
* This function cause some error in Hanzi.
* Modified by L. C., Nov 12th, 2001
**************************************** ***************************/
/*************************************** *****************************
Bool addchar (const tchar * PCH)
**************************************** ****************************/
Bool addchar (const tchar * & PCH) file: // We'll modify the PCH Value
{
If (NPOs = nsize) // realloc
{
Nsize * = 2;
P = (lptstr) cotaskmemrealloc (p, nsize * sizeof (tchar ));
}
P [NPOs ++] = * PCH;
# Ifndef _ Unicode
If (isdbcsleadbyte (* PCH ))
/*************************************** ****************************
P [NPOs ++] = * (PCH + 1 );
**************************************** ****************************/
P [NPOs ++] = * (++ PCH );
# Endif
Return true;
}
What are the other errors?
Observe the @ 3 line. If you want to read Source code (Starting from line 1), it is obvious that there is a risk of buffer overflow:
In the case of non-Unicode, NPOs must be added twice to enter this section Code There could be NPOs = nSize-1. If so, I'm afraid Program Of
There will be some unpredictable behavior (although the probability is very small: there is not much possibility of a large Chinese section in the RGS file ). Modification comparison
Easy, change if (NPOs = nsize) to If (NPOs = nSize-1. (Of course there are many other methods)
Conclusion
If your component may appear in the Chinese path (using MBCS), we recommend that you use _ atl_static_registry during compilation.
Compile, and modify the relevant code in ATL (or write and register the function by yourself) before compiling ). Otherwise, the existing ATL. dll will break down your good news.
Modifying existing class libraries is dangerous. Because their call relationship is too complicated. However, if there is a bug in it, this is also
Good method.