這是一個困擾我們很久的問題。
一直以來我受到了矇騙，以爲stl作爲一個模版庫，所有的類和函數都是inline的，使用stl編寫的程序不需要額外的依賴。並由此更偏愛用string而不喜歡CString，很明顯，僅僅使用了一個字符串功能，就要給我的程序搭上一個近1M的mfc42.dll(使用靜態鏈接MFC也鬱悶：明明沒寫幾行代碼，編譯出來的程序咋就那麼大呢？)
後來慢慢的發現，用string還不如用CString。因爲至少98以上的系統就自帶有MFC42.dll。可是string需要的兩個庫(msvcrt.dll和msvcp60.dll)之一—msvcp60.dll在某些系統上卻沒有。這一點從網上搜搜有多少帖子在找MSVCP60.DLL就知道了。
不僅僅是string，在使用map和set的時候，居然也要用到msvcp60.dll。
爲了解決這個問題，我搜遍了google上中文網頁，沒見有討論這個問題的，大家的解決方案就是去下載一個MSVCP60.DLL。
後來在一個國外網站上發現了一條線索，(網址http://www.dinkumware.com/vc_fixes.html)
原文就不摘錄了，大意是VC的stl實現存在一點問題，其中特別提到了<xtree>的實現由於自作主張的用到了線程互斥，從而要依賴DLL。我把本機的xtree用網站上的版本替換過之後，set和map終於擺脫了msvcp60.dll了。還剩下string的問題沒有解決。
再後來看到微軟網站上一篇關於string在多處理器的機器上會導致崩潰的文章(http://support.microsoft.com/default.aspx?scid=kb;en-us;813810)，上面提到了如何在動態鏈接運行庫的時候，使得string的實現不依賴msvcp60的方法，很簡單，就是到<sting>和<xstring>中分別找到#ifdef _DLL … #endif這塊內容，註釋掉即可。
照着此法做了以後，string是不依賴msvcp60了，不過編譯出的exe文件還是依賴於msvcp60。
看來要想徹底解決，還得自己操刀。通過Dependency工具查看，發現我的exe導入了msvcp60的std::_Xlen這樣一個函數，於是搜索了VC98目錄下的所有文件，在VC98\CRT\SRC\STRING.CPP中找到了函數的實現：
_STD_BEGIN
// report a length_error
_CRTIMP2 void __cdecl _Xlen()
{_THROW(length_error, "string too long"); }
// report an out_of_range error
_CRTIMP2 void __cdecl _Xran()
{_THROW(out_of_range, "invalid string position"); }
_STD_END
於是我在自己的工程中隨便找了一個地方寫下如下代碼：
namespace std {
void _Xlen()
{
}
void _Xran()
{
}
};
然後編譯，OK了，終於擺脫了MSVCP60.DLL。
不過本人使用的方法沒有經過嚴格的測試，不保證不會帶來其他的問題。各位有興趣可以自己試一試。