Revision as of 12:54, 7 March 2012 by ThFabba (Start a page describing our C++ problems and possible solutions)
- 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)
- thus, we have no C++ runtime library
- additionally, explorer relies on non-standard library features, yet explorer_new is nowhere near ready
- import msvcp90 (or msvcp60?) from Wine into
lib\sdk\cpprtakin to CRT (take HEAD, I'm already putting MSVC build fixes in there)
- link C++ applications statically with this new library (instead of -lsupc++)
- we can export the functions from msvcp90.dll at little extra cost, just like our msvcrt.dll
- import the tests along with it so we see if our runtime works like it should
Problems with the plan
- is it really msvcp90 we want? Do we want 90 or 100 depending on the compiler in use? Or do we want 60 for compatibility reasons of some sort? It should also work with GCC!
- msvcp* has problems similar to those in CRT, where we'll likely need adjusted inline assembly code, some assembly wrappers etc.
- STLPort's headers might be somewhat incompatible with that new runtime. We might need to override them (and Wine of course doesn't have C++ headers) or replace STLPort with something else