这是一个困扰我们很久的问题。
一直以来我受到了蒙骗，以为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。
不过本人使用的方法没有经过严格的测试，不保证不会带来其他的问题。各位有兴趣可以自己试一试。