Wieviele mallocs und ProcessHeaps

Wieviele Exemplare von malloc() und wieviele ProcessHeaps befinden sich in
meinem Programm, wenn:
- Mein Programm ruft Funktionen aus Ws2_32.dll auf. Diese dll ist statisch
gegen msvcrt.dll gelinkt, d.h. auch dort gibt es ein malloc(), das seinerseits
von den Ws2_32.dll Funktionen aufgerufen wird.
- Mein Programm wird auch z.B. mit Visual C++ erstellt, und da z.B. gegen die
Importbibliothek von msvcr90.dll gelinkt. Diese msvcr90.dll hat ja jetzt ihr
eigenes Exemplar von malloc().
Bedeutet das, dass in meiner Anwendung letzten Endes zwei verschiedene malloc()
Funktionen importiert werden, einmal indirekt wegen msvcrt.dll, und zum anderen
direkt, wegen msvcr90.dll ?
Es heißt, dass der Speicher, den das statisch gelinkte msvcrt-malloc() (mit dem Ws2_32.dll arbeitet) allokiert, auch nur
vom free() aus der msvcrt wieder freigegeben werden kann (Was wohl auch der Grund dafür ist, warum man nach z.B.
getaddrinfo() idR freeaddrinfo() aufrufen muss).

Fünf Fragen:
(1) Ist es also tatsächlich so, dass in meiner 'fertig gelinkten' Anwendung
ein und dieselbe Funktion malloc() doppelt exisitiert?
(2) Allokiert eigentlich das indirekt vorhandene malloc() aus msvcrt.dll den
Speicher vom selben ProcessHeap wie mein eigenes malloc() aus msvc90.dll ?
(3) Richten die C-Runtimes msvcrt.dll und msvc90.dll eigentlich für meinen
Prozess jeweils auch einen separaten PrivateHeap ein ?? Kann mein Prozess
überhaupt zwei verschiedene PrivateHeaps haben, die nichts voneinander wissen ??
(4) Wie sieht die Sache eigentlich aus, wenn ich meine Anwendung statt dynamisch
statisch mit der libcmt.lib linke?
Wieviele distinkte Exemplare von malloc() und wieviele PrivateHeaps befinden
sich dann zur Laufzeit eigentlich in meinem Prozess ? 2 oder gar 3 ?
Da ja malloc() vermutlich nur ein Decorator von HeapAlloc() ist:
Warum ist eine M$-DLL wie Ws2_32.dll eigentlich ungeschickter Weise gegen die
msvcrt.dll gelinkt worden, wo doch in Ws2_32.dll ohnehin auch der Großteil von
kernel32.dll hineingelinkt wurde (d.h. warum geht die Ws2_32.dll den Umweg über
das malloc() aus der msvcrt.dll ? Ist das nicht ungeschickt ? Das sorgt doch nur
für unnötige Code-Duplikation und fördert das DLL-Dependency Chaos ! Am Ende
gibt's in jeder Anwendung, die die Ws2_32.dll Funktionen nutzen möchte, eine
unüberschaubare Fülle von malloc()s und womöglich auch ProcessHeaps.

Thx wenn sich da jemand genauer mit den DLLs auskennt.

(5) Gibt's eigentlich auch eine wirklich minimalistische C Standard Library für
Windows, wo nur genau der C95 Standard angeboten wird und keinerlei darüber
hinausgehende Funktionen und Fleißaufgaben. Ein Großteil der Hosted Environment
Funktionen kann man ja recht einfach selber als Decorators von kernel32.dll
basteln, einzig die Gleitkomma-Funktionen aus <math.h> sowie sprintf("%f")
wären recht schwierig zu implementieren(weil wohl nur mit sehr guten Assembler-
Kenntnissen FLD & Co) und müsste man selber machen. D.h. muss man natürlich
nur dann, wenn's so eine Mindest-C95-Runtime (ohne Fleißaufgaben vom Typ
_beginthreadex u.ä.) für Windows noch nicht geben sollte.

Jochen Kalmbach

1. Sie kann beliebig oft vorkommen... Du kannst auch verschiedene CRT Versionen verwenden...
2. Jede CRT verwendet ihren eigenen Heap; der Standard-Prozess-Heap wird von der CRT nicht verwendet
3. Du kannst beliebig viele Heaps haben
4. Ob die ws2?32.dll überhaupt die CRT verwendnet mag ich bezweifeln... es hat AFAIK einen anderen Grund, dass diese Abhängigkeit da drin ist (kann den Link aber gerade nicht finden; auf jeden Fall nicht, das die Windows-DLLs dort was verwenden würden). Wenn Du statisch linkst, dann linkst du ja auch gegen die CRT und somit wird auch wieder ein CRT-Heap erzeugt. Wenn dann *alle* LIBs/Dateien gegen die _gleiche_ Version der CRT erstellt wurden, wird nur diese CRT für diese Dateien verwendet. Wenn Du eine LIB einbindest, die gegen eine andere CRT-Version erstellt wurde bekommst Du entweder Linker-Fehler oder bei einer Import-LIB wird dann die entsprechende CRT nochmals geladen...
5. Es gibt die CRT. Wenn Du statisch linkst, werden auch nur die Funktionen eingebunden, welche die Applikation verwendet. Ist also automatisch "minimalistisch".