NativeExecutive

The wet dream of every memory manager architect is the ability to insert their custom malloc implementation into every application on every platform. I am glad to say that I am successfully able to replace the malloc set of functions on both Win32 and Linux. While it is easier to replace on Linux due to the PLT being a nice-guy, on Windows we rely on compiler-implementation-specific static library symbol management. Thus I want to highlight quirks of the Win32 behaviour so you do not give your hopes up if something seems odd.

If you are not calling any NativeExecutive code inside of your application project but have the NativeExecutive lib file included into your project then you may see the following errors:

4>main.cpp
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _msize ist bereits in libucrt.lib(msize.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _msize_base ist bereits in libucrt.lib(msize.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _recalloc ist bereits in libucrt.lib(recalloc.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _recalloc_base ist bereits in libucrt.lib(recalloc.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: calloc ist bereits in libucrt.lib(calloc.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: free ist bereits in libucrt.lib(free.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: malloc ist bereits in libucrt.lib(malloc.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _calloc_base ist bereits in libucrt.lib(calloc_base.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _free_base ist bereits in libucrt.lib(free_base.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _realloc_base ist bereits in libucrt.lib(realloc_base.obj) definiert.
4>rwlib.lib(CExecutiveManager.memory.obj) : error LNK2005: _malloc_base ist bereits in libucrt.lib(malloc_base.obj) definiert.
4>X:\DEVEL\(CONFIDENTIAL)\build\..\bin\x64\Release\(CONFIDENTIAL).exe : fatal error LNK1169: Mindestens ein mehrfach definiertes Symbol gefunden.

This is well-observed behaviour. You can safely ignore this set of errors because you are not using NativeExecutive in any way so why bother including it? You can fix this set of errors by actually using NativeExecutive. A simple call to...

NativeExecutive::CExecutiveManager::Create()

will get rid of the errors above.

You will get to know the same quirk if you are writing the malloc replacement as part of an own lib file that you include into your application. For some reason the linker does ONLY eliminate the CRT .obj files that are overshadowed by your code IF your code is actually used! Just get used to enforcing the usage-condition: it is common sense to use your own code, after all.

Will keep you guys up to date with any further funny stories about memory management details.