Windows-API: Speicherverbrauch der laufenden Anwendung abfragen

[Der Martin]

Hallo,

nicht wirklich; einen Teil der dort verlinkten Funktionen hatte ich gestern schon gefunden. Es scheitert immer daran, dass ich zuerst "meine eigene" Prozess-ID herausfinden muss, über deren Herkunft die API-Dokumentation den Mantel des Schweigens deckt.

denk POSIX: Es gibt auch unter Windows getpid.

dort heißt es, der Funktionsname sei deprecated und ein Alias für _getpid. Und da wiederum lese ich: "This API cannot be used in applications that execute in the Windows Runtime."
Was will uns der Dichter damit sagen?

Ja. Aber in der Beschreibung von HeapAlloc() habe ich auch empfindliche Einschränkungen gefunden. Zum Beispiel, dass ich mit HeapAlloc() maximal 0x7FFF8 Bytes am Stück anfordern kann. Das sind knapp 512kB. Mit GlobalAlloc() kann ich dagegen auch mal 12MB am Stück kriegen.

Da dein Programm eh in C ist, könntest du mal testen, wie viel Speicher dir malloc auf einmal liefern kann 😉

Soweit ich weiß, gibt es da keine Beschränkungen (außer dem verfügbaren Speicher). Aber ich pobier's gelegentlich mal aus.

Wenn mir das Betriebssystem direkt eine API-Funktion für eine bestimmte Aufgabe bietet, dann nutze ich die auch direkt, anstatt vergleichbare CRTL-Funktionen, die dann irgendwann auch nur die API-Funktion aufrufen. Deswegen benutze ich auch CreateFile() und Co. anstatt fopen(). Das Ziel ist, dass ein großer Teil der CRTL beim Linken als überflüssig (nicht benutzt) erkannt wird und rausfällt - im Idealfall die komplette Runtime. Das ergibt kleinen, kompakten Code.

Da spricht jemand, der wirklich nur auf einer Plattform arbeitet 😉

Nein, das nicht. Aber die Projekte, die ich bisher gebastelt habe, waren von ihrer Zweckbindung her von Anfang an *Windows only". Wenn ich das Zielsystem von Beginn an kenne, lasse ich mich auch darauf ein. Wenn ich weiß, dass das Zielsystem ein Raspberry Pi oder ein ESP8266 ist, gehe ich ja auch komplett auf die Eigenheiten dieser Plattformen ein.

Ich habe privat schon unter Mac OS X, Linux und Windows eigenen Software geschrieben und laufen haben wollen – da wollte ich nicht jedes Mal Code portieren.

Wenn man diese Absicht hat, tut man natürlich gut daran, allgemein zu bleiben.

Live long and pros healthy,
 Martin