The problem

we have STLport as our C++ standard library. Whether this is suitable is to be seen
for the C++ runtime, we rely on libsupc++ for GCC builds. The equivalent functions for MSVC are inside msvcrt.lib (our solution to the C pendant is msvcrtex)
the C++ ABI differs between GCC and MSVC
Wine's C++ runtime is unable to support even the most basic programs
additionally, explorer relies on non-standard library features, yet explorer_new is nowhere near ready

The plan

in the new c++-bringup branch, create a new C++ runtime library that will support our goals
have a library in lib\sdk\cpprt or so (and corresponding headers somewhere in include\c++) that implements the runtime functions in native C++
export these functions to the appropriate DLLs (msvcp*, msvcirt, ...), using MSVC's ABI (that is, make wrappers if G++ is the compiler in use)
link our C++ apps to these DLLs
make a static library to link with all G++-built programs, which wraps the MSVC functions exported by these DLLs to be G++-compatible
this way, we provide a working runtime to MSVC-built programs, and ours depend only on MS's own runtime DLLs (or we have the option to link the C++ stuff completely statically)
a perfectly working operator new (with RTTI and exception) would be the first/most important step
back up everything by extensive tests

Here are some likely next steps:

check how much of the below list is included in STLport or easily available from somewhere else
create tests for RTTI basics
implement most of type_info (perhaps exceptions should be first?)
implement dynamic_cast, std::bad_cast, std::__non_rtti_object
create tests for try/catch/finally/throw
create tests for standard exceptions (std::exception, std::bad_alloc, ...)
implement std::exception and friends
create tests for new/delete
implement operator new, operator delete, `eh vector constructor iterator`, `eh vector destructor iterator` etc