I downloaded and installed MS VC++ 8.0 Express beta. The advantage of Express over full Visual Studio 2005 is in a smaller disk footprint and you need 'only' MS Passport (not MSDN subscription) to download it. Note that Express does not come with Windows headers and libraries so you need to download Platform SDK or use existing, older installation. For example, before invoking bjam, you may say: set INCLUDE="C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include";%INCLUDE% set LIB="C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\lib";%LIB% Here are the problems encountered when building boost: 1) flags for DLL and single-threaded static library have changed. You would need the following flags in msvc-tools.jam: # VC8.0 flags msvc CFLAGS <runtime-build>release/<runtime-link>dynamic : /LD ; flags msvc CFLAGS <runtime-build>debug/<runtime-link>dynamic : /LDd ; flags msvc CFLAGS <runtime-build>release/<runtime-link>static/<threading>single : /MD ; flags msvc CFLAGS <runtime-build>debug/<runtime-link>static/<threading>single : /MDd 2) Og and Gs compiler flags will be deprecated and cause warning. 3) many string functions ( sprintf, strcat, wsccpy, etc. ) cause deprecated warning. 4) compilation errors, all involving wchar_t like: C:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(207) : error C2664: 'bool boost::spirit::utility::impl::range_char_compare<CharT>::operator ()(const boost::spirit::utility::impl::range<CharT> &,const CharT) const' : cannot convert parameter 1 from 'wchar_t' to 'const boost::spirit::utility::impl::range<CharT> &' with [ CharT=wchar_t ] Reason: cannot convert from 'wchar_t' to 'const boost::spirit::utility::impl::range<CharT>' with [ CharT=wchar_t ] No constructor could take the source type, or constructor overload resolution was ambiguous Problem #1 can be solved by commenting out older flags and substituting them with the new ones in msvc-tools.jam. I am sure this is not the most elegant solution, ignorant of bjam as I am. Re. problem #2, I could not find an explicit suggestion on what new options should be used. However, the sheer number of problems with /Og option listed in MS Knowledge Base make me believe that it would be best to remove it. Whidbey (but not Express) is to offer more advanced profile-based optimizations. As for /Gs I would assume that /GS (also /RTC1) should substitute it, following the article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechar... As for #3, even barring security concerns, I tend to agree that using string functions with source and destination buffer size parameters is desirable. However, I wouldn't know which portable changes would avoid these warnings; presumably MS-specific extensions would be required. Still unfamilar with boost++ modules that caused errors under #4, I haven't looked into it. While more detailed info about these issues may be possible to find on MSDN, searching for any phrase, unfortunately, results in a huge number of .NET related articles. Tony