6 ms·
71, 80, 90, 100, 110, 120 - Did I miss any of these? - 6 different "C" runtime versions (apart from side-by-side sub-versions) for compiler that was released in
by malkia 13y ago
71, 80, 90, 100, 110, 120 - Did I miss any of these? - 6 different "C" runtime versions (apart from side-by-side sub-versions) for compiler that was released in span of 10 years.
It's not that I like the MSVCRT runtime. It's just that I have to target it. Any popular commercial product that has some form of plugin architecture (Autodesk for example) through DLLs would require more or less for one to compile it's own plugins with the exact version the main application was compiled.
It's a bit of strange moment - when one developer cries that OpenSSL should've not used it's own malloc implementation, and then another cries - don't expose malloc/free interface (but do say your_api_malloc, your_api_free) and this way you can target any "C" runtime.
Now these are completely two different things, but not so much. What if say OpenSSL used the "malloc" runtime - what version of MSVCRT.DLL would've they target? Does anyone really expect to target all these different versions and all these different compilers that you can't even find the free versions now through MSDN?
(Now I'm ignoring the fact that you can't easily hook malloc and replace it with "clear-zero" after alloc function, but that's just a detail).
What I'm getting is that there are too many C runtimes, hell DirectX was better!
I only wished MS actually somehow made MSVCRT.DLL the one and only DLL for "C" (C++ would be much harder, but it's doable).
- anon4 13y agoCan't you distribute plugins as an archive of compiled, but unlinked .obj files and link them on import to the runtime you use?
- malkia 13y agoEven if that was possible, you need a linker. Also recent versions of MSVC plug-in a pragma that contains the version number of the MSVCRT dll and once a .c/.cpp file was compiled with specific version it has this version in the .obj file, so if you try to link it with another version it'll complain. Recently they've added this for debug/release builds (NDEBUG, _DEBUG) (so you can't mix them - but I think this was done only for C++ - because of STL)
- quotemstr 13y ago> Any popular commercial product that has some form of plugin architecture (Autodesk for example) through DLLs would require more or less for one to compile it's own plugins with the exact version the main application was compiled. Maybe Autodesk requires that ,but it's not true in general. Modules using different versions of the C runtime can coexist happily in the same process and talk to each other using plain function calls, COM, or whatever else you come up with. You can't share FILE*, malloc()ed memory, or other CRT-specific objects between them, but you don't have to: use LocalAlloc (on the process heap or an explicitly shared heap), the COM allocator, or something like that.