Effiziente Win32-Programmierung

#include <stdio.h>
int main() {
  printf("Hallo Welt!\n");
  return 0;
}

Wer kennt das nicht? (Quelle: Kerninghan+Ritchie: C-Programmierung)

Mit den richtigen Projekteinstellungen entsteht ein Konsolenprogramm, welches „Hallo Welt“ ausspuckt und mit ca. 32 Kilobyte ziemlich fett ist. Hier den Speck zu entfernen ist für Anfänger etwas knifflig, daher werde ich im folgenden nicht darauf eingehen. Außerdem sieht es nicht wie ein Windows-Programm aus. Sondern wie ein Fremdkörper.

#include <windows.h>
int WinMain(HINSTANCE, HINSTANCE, LPTSTR, int) {
  return MessageBox(0,"Hallo Welt!","Nr. 2",0);
}

Das ist ein einfaches Windows-Programm!

Beinahe selbsterklärend erscheint ein (kleines) Fenster in der Mitte des Bildschirms mit dem Text „Hallo Welt!“ und einem „OK“-Knopf zum Beenden des Programms.

Mit etwa 20 Kilobyte ist es aber immer noch Bloatware. Diese lassen sich ganz einfach entfernen, siehe nächstes Beispiel.

#include <windows.h>
EXTERN_C int WinMainCRTStartup(void) {
  return MessageBox(0,"Hallo Welt!","Nr. 3",MB_OK);
}

Dieses Programm macht genau dasselbe wie Nr. 2, die EXE-Datei ist mit den richtigen Projekteinstellungen nur noch rund 2 Kilobyte groß. Kleiner geht's nicht, die für Windows erforderlichen Verwaltungsinformationen im EXE-Header kosten ihren Fixpreis. Der eigentliche Kode und die Stringkonstanten bedürfen nur weniger als 100 Bytes und würde in den kleinsten Mikrocontroller passen: An der Intel-Architektur liegt's jedenfalls nicht.

Vergleicht man die drei Beispiele mit dem Dependency Walker, wird man feststellen, dass dieses genau eine externe Abhängigkeit aufweist, nämlich nach USER32:MessageBoxA. Die Bloatware vorher ruft noch Dutzende anderer Funktionen auf, die überhaupt nicht benötigt werden.

#include <windows.h>
EXTERN_C __declspec(noreturn) void WinMainCRTStartup(void) {
  ExitProcess(MessageBox(0,"Hallo Welt!","Nr. 3.1",MB_OK));
}

Schließlich der Ausgangspunkt für 95 % aller praktischen Programmieraufgaben.

Programme die wie Dialoge aussehen sind das Butterbrot des Programmierers. Der Erfolg von VisualBasic und Delphi bestätigt dies. Denn oftmals sind es die kleinen Probleme, die ein kleines Programm benötigen. Sogar „große“ Programme mit größenveränderlichem Hauptfenster lassen sich ganz ohne CreateWindow() und RegisterClass() schreiben, nur ist's dann nicht mehr so vorteilhaft.

#include <windows.h>

static INT_PTR WINAPI MainDlgProc(HWND Wnd, UINT msg, WPARAM wParam, LPARAM lParam) {
  switch (msg) {
    case WM_INITDIALOG: {
    }return TRUE;

    case WM_COMMAND: switch (wParam) {
      case MAKELONG(IDCANCEL,BN_CLICKED): EndDialog(Wnd,wParam); break;
    }break;

  }
  return FALSE;
}

EXTERN_C void WinMainCRTStartup() {
  ExitProcess(DialogBox(0,MAKEINTRESOURCE(100),0,MainDlgProc));
}

Wie man am Quelltext „sieht“, fehlt jegliche Ausgabe, etwa Zeichenketten. Diese befinden sich nunmehr in einer Ressource: (Maus darüberhalten für Erklärungen!)

1 24 "manifest"

100 DIALOG 0,0,220,100
STYLE DS_3DLOOK|DS_NOFAILCREATE|DS_CENTER|WS_MINIMIZEBOX|WS_VISIBLE|WS_CAPTION|WS_SYSMENU
CAPTION "Nr. 4"
FONT 8, "Helv"
{
  CTEXT		"Hallo Welt!",-1,10,10,200,8
  DEFPUSHBUTTON	"Ende",2,60,50,100,14
}

So eine Ressourcendatei (*.rc) sieht aus wie C, ist aber kein C, und wird vom Resource Compiler (rc.exe) entweder in eine Binärressource (*.res) oder gleich in die EXE-Datei eingebunden. Ressourcen sind (u.a. für Dialoge) standardisiert und mehrsprachig, sie können auch nachträglich mit geeigneten Editoren korrigiert, übersetzt und hinzugefügt werden. So hat der Kunde die Möglichkeit der Anpassung und Übersetzung ohne Quelltext! Das ist die Idee hinter den Ressourcen! Keine Idee von Microsoft sondern von Apple. Mit .NET oder Qt geht das nicht.

Die EXE-Datei ist nun größer geworden (4 Kilobyte), weil eine weitere „Section“ (die Ressource nämlich) mit hineingewandert ist. Dafür ist dieses Programm nun beliebig ausbaufähig.

Wie man sieht, kommt man für lange Zeit um RegisterClass() und CreateWindow() herum! Wer so etwas als „Erstes Windows-Programm“ anbietet, will wohl nur davon abschrecken. (Schade, Herr Petzold.)

Ein unterschätztes Problem der (nicht nur Windows-)Programmierung ist das Merken der Fensterposition sowie weiterer „kleiner“ Konfigurationseinstellungen wie:

• Fenstergröße und -Erscheinungszustand (minimiert, normal, maximiert)
• Wenn vorhanden: Position von Teilern, von Kind-Dialogen, etwa die von GetOpenFileName()
• COM-Port, Baudrate
• Sämtliche sonstigen Einstellungen

Tatsächlich kümmern sich viele Windows-Programme in der freien Wildbahn nicht die Bohne um das Speichern — und sind dadurch elend unkomfortabel!

Am praktischsten hat es sich erwiesen, immer zu speichern und gar nicht erst den Benutzer zu fragen! Also kein Menüpunkt „Konfiguration speichern“ oder so anzulegen.

Zum Glück gibt es unter Windows den perfekten Speicherort dafür: Die Systemregistrierung (Programmierer-Jargon: Registry) unter HKEY_CURRENT_USER\Software\Firma_oder_Programmierersignet\Programmname. Das elend lange HKEY_CURRENT_USER wird mit HKCU abgekürzt. Und hier kann man problemlos Binärdaten speichern!

Hier habe ich folgende Lösung für die beste herausgefunden:

• Um sich wenig Ärger mit Schlüsselnamen aufzuhalsen (= Code Bloat) werden alle Konfigurationsdaten in eine struct gesteckt: • Fensterposition, Größe, Erscheinung — siehe GetWindowPlacement(), sowie • Sonstige Einstellungen.
• Die struct-Elemente („Member“) halte ich minimal klein (short für Fensterposition und -Größe, char und BYTE für nahezu alles andere, um die Registry nicht mit Nullen zu überfrachten.
• Schließlich wird die struct „in einem Rutsch“ beim Starten geladen und beim Beenden gespeichert. So ist's schön aufgeräumt, bei hervorragender User Experience.

Gibt man schon seit Windows 3.1 mit OutputDebugString() aus. Diese erscheinen im Output-Fenster der Entwicklungsumgebung. Oder mittels Mark Russinovichs DebugView.

Neu: Da das Vorhandensein von DebugView nicht immer sichergestellt werden kann ist die alternative Ausgabe auf eine Konsole wünschenswert: Die Funktion AttachConsole(-1) verwendet das Konsolenfenster des Aufrufers. Mit anderen Worten: Es verwendet die Konsole beim Aufruf aus einem Konsolenfenster (d.h. aus cmd.exe oder command.com) wie ein Konsolenprogramm aber öffnet keine Konsole beim Aufruf vom Startmenü, Explorer oder Total Commander im Gegensatz zu einem Konsolenprogramm.
Ergo: Als Windows-Programm compilieren (SUBSYSTEM:WINDOWS). Gelingt AttachConsole(-1) dann mit WriteConsole() ausgeben sonst wie gehabt mit OutputDebugString(). Zudem lassen sich so „bimodale“ Programme generieren: Konsole und Windows. Gut für alles was man auch mal von einem Makefile starten möchte.

Das gute alte MSVC6 aus dem Jahr 1998 (1 CD) ist bei mir immer noch die beste Grundlage, um derartig kleine Programme zu schreiben. Dazu passt am besten die Online-Hilfe „MSDN April 2001“. Bei mir auf 3 CDs. Leider macht die Installation Probleme ab Windows XP:

• Installation von MSVC6 läuft nicht erfolgreich durch:
  • Alles Datenbank-Geraffel bei der Installation abwählen, auch wenn der Installer meint, es sei unbedingt notwendig: Ist es nicht!
  • Bei dieser Gelegenheit kann man auch alles was mit MFC zu tun hat abwählen.
  Wenn die Installation nicht erfolgreich durchläuft, funktioniert die MSDN-Hilfe nicht!
• msdev.exe wird als „altes Programm“ angemeckert, welches „nicht mehr unterstützt“ wird:
  • msdev.exe umbenennen, den Link im Startmenü anpassen
  Windows 10 meckert nicht mehr.
• Beim Versuch, Dateien zum Projekt hinzuzufügen, verabschiedet sich die Entwicklungsumgebung mucksmäuschenstill ohne irgendetwas zu speichern
  • Normalerweise: Service Pack 6 installieren. Aber dann funktioniert der Compiler nicht mehr. Es genügt die Datei c:\programme\MSVC\common\msdev98\bin\devshl.dll zu ersetzen.
• Die Hilfe funktioniert nicht. (An diesem Problem kranken eigentlich alle Studios! Nicht nur Visual Studio, auch Code Composer Studio, Atmel Studio …)
  • Für die Visual-Studio-Hilfe muss die HLP-Unterstützung installiert sein. Gibt's bei Microsoft. Leider nicht für Windows 10. Jene Hilfe ist relativ unwichtig.
  • Für die kontextsensitive Hilfe (C++- und Windows-Funktionen) muss eine geeignete MSDN-Library installiert sein. Sehr wichtig. Dann funktioniert F1 auf jedem Quelltext-Wort.
• Was installiert man von der MSDN?
  • Volltextsuche
  • C++ (= Programmiersprache)
  • Platform SDK (= Win32-Funktionen und -Strukturen)
  • „All other files“ (das ist wichtig, leider groß)
  • Sonst nichts! Insbesondere nicht den Punkt „Windows“, das ist das ausgestorbene Windows CE.
• Viele (auch meine) Programme lassen sich nicht kompilieren, es fehlen einige Kopfdateien.
  • Wie auch beim allerneuesten Visual Studio sind SDKs und DDKs zu installieren. Mein Renner ist das Windows 2003 DDK, da ist fast alles drin. Leider kann auch dieser kein C++11

Was man mit MSVC6 (und allen C++-Dialekten vor C++11) nicht tun sollte ist die Verwendung von std::vector mit richtigen Objekten! Dadurch, dass der Raubkopierkonstruktor und std::vector::emplace() fehlt, wird das Einbetten von Handles und deren automatischer Destruktoraufruf zu einer elend windigen Angelegenheit. Man tut besser daran, keine Objekte sondern nur einfache Datentypen hineinzutun. Bei Strukturen, die Handles enthalten, muss man diese zu Fuß freigeben. Oder man tut Zeiger auf Objekte in den Vektor. (Bei virtuellen Objekten geht das ohnehin nur so.) Nun, das macht das Iterieren umständlicher. Weil die Iteratoren nun Zeiger auf Zeiger sind.

Normalerweise gibt es keinen Grund, den Gnu-C-Compiler mingw zu benutzen. Außer man folgt einen gewissen Fetisch. Denn der Compiler compiliert noch schlechter als der von Microsoft, den Microsoft-Compiler gibt's in einer freien Version ohne Einschränkungen, und die Microsoft-Lizenz macht keine Einschränkungen zur Verwendung des entstehenden Kompilats.

Die folgenden Kommandozeilenoptionen sind nötig, um die Laufzeitbibliothek loszuwerden und die Echse kleinzukriegen:

• -Os = Größe optimieren (Optimize size)
• -s = keine Debuginformation (strip debug info)
• -fno-exceptions = keine Ausnahmebehandlung (C++ try..except bzw. C __try..__except)
• -fno-ident = unsäglichen Gnu-Copyright-String weglassen — damit klopft man sich niemals auf die Brust!
• -fno-stack-protector = kein __chkstk, lokale Variablen muss man pro Funktion auf 4096 Byte begrenzen
• -fomit-frame-pointer = keine Rahmen-Zeiger = Optimierung von push ebp; mov ebp,esp; sub esp,local_variables_size zu etwas kürzerem
• -fno-asynchronous-unwind-tables = keine Tabellen zur Rückabwicklung einer asynchronen Ausnahmebehandlung (aus einem Thread?)
• -nostdlib = keine Standardbibliothek einbinden, weder statisch noch dynamisch. Auf Standardbibliotheksfunktionen wie printf(), strlen(), memcpy() und new muss man konsequent verzichten. Für alles außer Gleitkomma gibt es Win32-API-Funktionen.
• -nostartfiles = keinen Startupkode einbinden. Gegebenenfalls muss man den Startupkode nachäffen.
• -e WinMainCRTStartup = Einsprungpunkt festlegen. Im Gegensatz zum Microsoft-Compiler muss der Einsprungpunkt festgelegt werden! Vergisst man das, legt mingw diesen ungefragt an den Anfang des Kodesegments. Was da steht lässt sich nur in einem Assemblerprogramm sicher vorhersagen.
• -Wl,--no-seh = (nochmal) keine Ausnahmebehandlung
• -lkernel32 -luser32 -lshlwapi ... = Importbibliotheken für alle benötigten DLL-Aufrufe
• -Wl,--subsystem=windows:4.0 = Eintrag im PE-Header. Die Versionsnummer legt das minimale Ausführungssystem fest:
  • 3.10 = Win32s, Windows NT 3.1
  • 3.50 = Windows NT 3.5
  • 4.0 = Windows95, Windows NT 4.0
  • 4.10 = Windows98, Windows98 Zweite Ausgabe
  • 4.90 = Windows Me
  • 5.0 = Windows 2000
  • 5.1 = Windows XP
  • 5.2 = Windows Server 2003
  • 6.0 = Windows Vista, Windows Server 2008 SP2 KB4489887
  • 6.1 = Windows 7
  • 6.2 = Windows 8, Windows Server 2012
  • 6.3 = Windows 8.1, Windows Server 2012 R2
  • 10 = Windows 10, Windows 11
• -Wl,--dynamicbase = Eintrag im PE-Header (variable Basisadresse = geringer Schutz vor Fremd-Daten, die eigene Programmfehler durch Pufferüberläufe ausnutzt)
• -Wl,--nxcompat = Eintrag im PE-Header (Daten und Stapel nicht ausführbar (ging gar nicht anders bei 16-Bit-Programmen) = Schutz vor Fremd-Daten, die eigene Programmfehler durch Pufferüberläufe ausnutzt)

Auf den fehlenden Ressourcen-Editor kann man verzichten, wenn man von einer vorhandenen Ressource ausgeht und die .RC-Datei als Text editiert. Nur das Gestalten der Dialoge ist damit sehr mühevoll. Die Aufrufzeile geht (typisch Gnu-Gläubige) mal wieder nicht ohne Pflichtoption: windres -o ziel.res -O coff quelle.rc

Ich habe jetzt mal mingw64 auf die wirklich benötigten Dateien eingedampft. Dabei kam diese Dateiliste heraus. Immer noch reichlich 40 Megabyte. Unsäglich wirr verstreut. Das war zu Zeiten von Borland C++ die ganze Festplatte!

C-Compiler ab dem Jahr 2005 bringen unglaublich viele Intrinsics für MMX, 3DNow, SSE, SSE2, SSE3, SSE4, AVX2011 und AVX5122015 mit. Für leistungshungrige Programme mit massiv-parallelem Gleitkomma-Einsatz lohnt sich der Einsatz von SSE2. SSE2 ist implizit vorausgesetzt für 64-Bit-Programme, da x64-Prozessoren immer SSE2 haben. MMX und 3DNow (64 Bit Parallel-Integer aus der Pentium-Ära) kann man heutzutage (2024) ignorieren und den zugehörigen Datentyp __mm64 als „giftig“ (= lahm, nie verwenden!) betrachten. Die SSE-Befehle bauen auf 128 Bit breiten Registern auf (__mm128). Darin passen vier float-Gleitkommazahlen. AVX und AVX512 verdoppeln jeweils die Registerbreite.

In meinen Programmen „fehlt“ die Datei resource.h. Ich halte es für überflüssig, numerischen Konstanten per #define eine Zeichenkettenkonstante zuzuordnen, die:

• den Bezug zu einer Zahl verdeckt
• Schleifen optimierende Gruppierungen verdeckt, wie aufeinanderfolgende IDs eine Gruppe von Checkboxen (Ankreuzfelder), Menüpunkten und Radiobuttons
• große Zahlen ≥128 ungestraft bevorzugt
• mehr Tipparbeit und trotzdem ständiges Nachgucken verlangt

Zur Kompensation muss bei Verwendung numerischer Konstanten deren Bedeutung im Quelltext-Kommentar aufgeführt werden. Zum Beispiel:

 switch (msg) {
  case WM_COMMAND:{
// Gängiger, von Microsoft und Petzold propagierter Stil
   switch (GET_WM_COMMAND_ID(wParam,lParam)) {
    case ID_BUTTON1: TueIrgendwas(GET_WM_COMMAND_HWND(wParam,lParam)); break;	// Nun, was ist "BUTTON1"?
   }
// Mein Stil
   switch (LOBYTE(wParam)) {	// Kürzerer Kode durch Bytezugriff, Win16 ignorierend
    case 44: TueIrgendwas(HWND(lParam)); break;	// Button "TuWas!" ← unverzichtbarer Kommentar
   }
  }break;
 }

Mit jeder neuen Version von Visual Studio lauern neue Überraschungen. Zum einen wurden Stringfunktionen als potenziell unsicher eingestuft:

• sprintf(): Recht so! Zielpufferüberwachung gehört heutzutage dazu!
• _sntprintf(): Nö! Man kann und muss die Zielpuffergröße angeben. Nur die terminierende "\0" ist nicht sichergestellt. Wenn man den Rückgabewert der Funktion benutzt, braucht man das Stringende nicht, etwa für GDI TextOut().

Zum anderen werden die printf-Funktionen zusammengefasst zu __stdio_common_*printf. Ein Schritt, der die Verwendung der msvcrt.dll in Verbindung mit msvcrt-light.lib bzw. msvcrt-light-x64.lib unmöglich macht.

Zum Glück gibt es dafür Rückfall-Makros, die am besten für das gesamte Projekt festgelegt werden:

#define _NO_CRT_STDIO_INLINE	// Visual Studio 2017+: Verhindert __stdio_common_vswprintf
#define _CRT_SECURE_NO_WARNINGS	// Visual Studio 2008+: verhindert sinnlose (ja, falsche) Warnungen wegen drohender Pufferüberläufe

┌──┬────┐	╔══╦════╗	╒══╤════╕	╓──╥────╖
│  │	│	║  ║	║	│  │	│	║  ║	║
├──┼────┤	╠══╬════╣	╞══╪════╡	╟──╫────╢
└──┴────┘	╚══╩════╝	╘══╧════╛	╙──╨────╜
¡¿‼¦§©®‹›«»­¶–—―‗‾‘’‚“”„†‡
¼½¾⅛⅜⅝⅞ …‰Ω ←↑→↓↔↕↨ ¬±×÷⁄ ∂∆∏∑−•∙√∞∟∩∫ ≈≠≡≤≥
▀▄█▌▐░▒▓ ■▬▲►▼◄◊○◘◙ ☺☻☼♀♂♠♣♥♦♪♫
ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣ ΤΥΦΧΨΩ
αβγδεζηθικλμνξοπρςστυφχψω
АБВГЃДЕЄЁЖЗИІЇЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ
абвгѓдеєёжзиіїйклмнопрстуфхцчшщъыьэюя

Die Konstruktoren enthalten auch Kode, um die statischen Destruktoren in die Liste für _onexit einzutragen. Das gesonderte Aufrufen der Destruktoren ist daher nicht notwendig.

In C sieht man extrem selten die Rückgabe einer struct. Ein klassisches Beispiel dafür ist div_t der Standardbibliotheksfunktion div(). Dabei sind derartige Funktionen so gemacht, dass die struct in ein Register oder notfalls in ein Doppelregister passt. Bei X86 wäre das eax bzw. edx:eax. Bei X64 entsprechend rax bzw. rdx:rax.

Der C-Standard schreibt vor, dass bei Rückgabe zu großer oder nichttrivialer struct/union/class der Aufrufer einer solchen Funktion einen versteckten Zeiger auf einen (üblicherweise auf dem Stapel frei gehaltenen) Speicherbereich übergeben muss. Logisch also, warum das so selten zu sehen ist und nicht zur Win32-API bzw. zu DLL-Aufrufen passt: Wie dieser Zeiger übergeben wird ist dem C/C++-Compiler freigestellt. So steht zusätzlich zum Klassenzeiger (this, nur bei nicht-statischer Memberfunktion) dem Unterprogramm ein weiterer Zeiger zur Verfügung. Bei MSC hat dieser einen Namen: __$ReturnUdt. Diesen Namen sieht man im Debugger.

Die einzige Möglichkeit in C oder C++, eine Struktur zurückzugeben ist das Anlegen einer lokalen Variable derselben Struktur, deren Elemente zu füllen und die Struktur zurückzugeben. (Abgesehen vom Aufruf einer weiteren Funktion, die dieselbe Struktur liefert.)

MyStruct funktion(const char*s) {
 MyStruct ret;	// Normale lokale Variable, kann auch ein hier konstruiertes Objekt sein
// Tue irgendwas und fülle die Struktur
 return ret;	// faktisch ein Kopierkonstruktor, bei C++11 ein Verschiebekonstruktor, kopiert alle Bytes
// Wenn ret ein Objekt mit Destruktor ist, wird an dieser Stelle ret->~Mystruct() aufgerufen
}

Normalerweise muss man sich nicht um den versteckten Zeiger kümmern, der Optimizer vermeidet den allfälligen Kopierkonstruktor (C++11: Verschiebekonstruktor wenn vorhanden, siehe Dreierregel) bei der return-Anweisung, indem er statt der lokalen Strukturkopie den übergebenen Zeiger nutzt.
Bei MSVC6 muss man dem Optimizer allerdings unter die Arme greifen. Dabei sieht man, wie modernere Compiler optimieren:

MyClass funktion(const char*s) {
 MyClass&ret = *__$ReturnUdt;	// Der (künftige) Rückgabeparameter wird auf den vom Aufrufer bereitgestellten Platz gedacht
// Tue irgendwas und fülle die Referenz
// Konstruktoraufruf geht hier mit Placement-new, der in MSVC6 ebenfalls noch deklariert werden muss.
 return ret;	// Das ruft den Kopierkonstruktor auf den Plan, der Zeigergleichheit feststellt und keine Bytes kopiert.
// C++ fügt hier keinen Destruktoraufruf ein, weil Referenzen genauso wie Zeiger nicht automatisch aufgeräumt werden.
}

Artikel zum Placement new.

Die Klasse std::string baut auf das Feature der Rückgabe von Strukturen auf. Dabei ist die innere Struktur von std::string nicht festgelegt und unterscheidet sich von Compiler zu Compiler sowie von Version zu Version. Somit ebenfalls nicht geeignet für publizierbare DLL-Aufrufe. Im einfachsten Fall enthält std::string einen Zeiger auf einen nullterminierten String. Wäre also dasselbe wie std::unique_ptr<char*>. Wirklich schade dass C++ solch eine zeigergroße Struktur nicht in ein Register packt. Bloß weil's dafür einen Destruktor gibt bzw. geben muss. Sonst wäre das der ideale Kandidat für DLL-Funktionen wie GetWindowText() — mit dem Destruktor LocalFree() dunnemals. Der simple Zeiger wäre außerdem kompatibel zu printf(), mit Augenzwinkern. Üblich ist hingegen eine Implementierung in eine größere struct, die kurze Strings ohne Heap speichert sowie „counted strings“ (= Zeichenarray und irgendeine, oftmals sehr geschickt gemachte Längenangabe) verwendet. Oft sieht man die Implementierung für bis zu knapp 32 Zeichen, wie im C-Beispiel oben, weil da ein Datumsstring hineinpasst.

// Definition in einer projektglobalen Kopfdatei (hier: C++)
#ifdef _MSC_VER
# define UDT(x) &x=*__$ReturnUdt
#else
# define UDT(x) x
#endif

// Anwendung im C++-Programm
MeinTyp funktion() {
 MeinTyp UDT(ret);
 TuWas(ret);
 return ret;
}

Hier zähle ich nur die wichtigsten Funktionen auf.

Die Funktionsnamen beginnen mit CM_ und bestehen allesamt aus mit Unterstrichen zusammengesetzten Abkürzungen: Für Windows eher untypisch, war aber so ganz typisch für VxDs.

Es gibt sie ab Windows 95 sowie Windows NT 4 in einer 32-Bit-DLL namens cfgmgr32.dll.

Ab Windows 2000 sind die Funktionen in der setupapi.dll implementiert, und die noch vorhandene cfgmgr32.dll leitet die Aufrufe „älterer“ Programme einfach durch. Dies ist auch bei den 64-Bit-Windows-Versionen und -DLLs so, obwohl es da gar keine „alten“ Programme geben kann.

Einige häufiger benutzte Funktionen sind:

• CM_Open_DevNode_Key() liefert einen Registrierungsschlüssel in den „Parameters“-Teil des betreffenden Gerätes. Hier kann man gerätespezifische Einstellungen vornehmen (wenn man den Treiber kennt!) bzw. den (symbolischen DOS-) Namen der Schnittstelle erfahren.
  Sieht man eigentlich nur wegen des in der Microsoft-Dokumentation fehlenden Verweises auf SetupDiOpenDevRegKey(). Diese macht genau dasselbe. Allerdings ist der Parameter Flags unterdokumentiert.
• CM_Get_First_Log_Conf(), CM_Get_Next_Res_Des(), CM_Get_Res_Des_Data(), CM_Free_Res_Des_Handle(), um die Portadresse(n) einer Schnittstellenkarte zu erfragen.
  Aus unerklärlichen Gründen funktioniert CM_Get_First_Log_Conf() unter Windows 8 nicht!

Wichtig: Die meisten mit CM_ beginnenden Funktionen funktionierten bei einem 64-Bit-Windows nur aus einem 64-Bit-Programm heraus! Das betrifft IMHO auch einige SetupDi-Funktionen.

Um mitzubekommen, dass neue Geräte dazugekommen sind oder etwas entfernt wurde, genügt es, den Rundruf WM_DEVICECHANGE mitzubekommen und dann die Neuauflistung von Geräten zu bewerkstelligen. Da bisweilen mehrere dieser Rundrufe vorbeikommen, ist das Verwenden eines Windows-Timers (SetTimer()) sinnvoll, damit die Auflistung verzögert erfolgt, vor allem, wenn die Auflistung länger dauert. (SetTimer() setzt vorherige SetTimer()-Aufrufe mit gleicher ID zurück!) 1,5 Sekunden sind ein gutes Maß.

Der häufigste Fall ist ein Programmschnipsel zur Auflistung aller COM-Schnittstellen. Im Internet findet man auch viel Unsinn. Auf bis zu 256 COM-Ports CreateFile() anwenden dauert zu lange. Dieses hier läuft ab Windows 98 Zweite Ausgabe und ist dabei rasend schnell. Hier klicken ⇒

#include <setupapi.h>
  …

  case WM_DEVICECHANGE: {
   HWND hCombo;
   int i;
   hCombo=GetDlgItem(Wnd,ID_MEINER_COMBOBOX);
   ComboBox_ResetContent(hCombo);
   HDEVINFO devs;
   devs=SetupDiGetClassDevs(&GUID_DEVCLASS_PORTS,0,0,DIGCF_PRESENT);
// devs=SetupDiGetClassDevs(&GUID_DEVINTERFACE_COMPORT,0,0,DIGCF_PRESENT|DIGCF_DEVICEINTERFACE); funktioniert nicht unter Win98!
   if (devs!=INVALID_HANDLE_VALUE) {
    SP_DEVINFO_DATA devinfo;
    devinfo.cbSize=sizeof devinfo;
    for (i=0; SetupDiEnumDeviceInfo(devs,i,&devinfo); i++) {
     TCHAR s[16];
     DWORD size=sizeof s;
     int k;
     HKEY hKey;
     if ((hKey=SetupDiOpenDevRegKey(devs,&devInfo,DICS_FLAG_GLOBAL,0,DIREG_DEV,KEY_READ))
        ==INVALID_HANDLE_VALUE) continue;
     if (!RegQueryValueEx(hKey,TEXT("PortName"),NULL,NULL,(LPBYTE)s,&size)
     && _stscanf(s,TEXT("COM%d"),&k)==1) {	// LPTs herauswerfen
      int idx=ComboBox_AddString(hCombo,s);	// PortName-Wert, so wie er ist
      ComboBox_SetItemData(hCombo,idx,k);	// numerischen Wert extra setzen, erspart späteres sscanf()
      if (k==MEINE_GERADE_AKTIVE_SCHNITTSTELLE) ComboBox_SetCurSel(hCombo,idx);
     }
     RegCloseKey(hKey);
    }
    SetupDiDestroyDeviceInfoList(devs);
   }
  }break;

Der Kode kommt ohne Abhängigkeit zu cfgmgr32.dll aus. Das vermeidet etwaige Probleme unter Windows 98.

Es sollte sogar unter Windows NT 4 laufen. (Nur SetupDiOpenDevRegKey() habe ich nicht getestet.) Obwohl NT 4 gar kein richtiges Plug-and-Play-System hat. Die Eintrittspunkte sind auch unter Windows 95 verfügbar; allerdings liefert die Funktion SetupDiEnumDeviceInfo() FALSE, und GetLastError() liefert 0x103 == ERROR_NO_MORE_ITEMS.

Hier ein AWK-Skript, diese Dateien wieder menschenlesbar zu machen. Für meine Web-Seiten, und für kleinere .RC-Dateien: nice_rc.zip

Ersetze \t\t\t<Tool\n\t\t\t\tName="[^"]*"\n\t\t\t/>\n durch Nichts.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"><security><requestedPrivileges><requestedExecutionLevel level="asInvoker" uiAccess="false"/></requestedPrivileges></security></trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"><application><supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/><supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/></application></compatibility>
<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"><asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"><dpiAware>true</dpiAware></asmv3:windowsSettings></asmv3:application>
<dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" /></dependentAssembly></dependency></assembly>

Manifest-Ressource, auch zum nachträglichen Einbau in Programme, die unscharf aussehen; Anleitung für MSVC6:

• Betreffende EXE-Datei ausfindig machen und mit MSVC6 „als Ressource“ öffnen, das startet den eingebauten Binärressourcen-Editor
• Ressource „benutzerdefiniert“ anlegen, Name = Nummer = 24. Falls diese mit Nummer 1 bereits existiert, öffnen
• Inhalt der o.a. Datei einfügen bzw. überschreiben
• Eigenschaften dieser Ressource anzeigen, Nummer von 101 auf 1 ändern
• Speichern; bei Schreibschutz „Speichern als“ in eine temporäre Datei und mit Admin-Rechten überbügeln

Diese Maßnahme funktioniert gegenüber dem Windows-Rezept (Rechte Maustaste auf EXE-Datei, Eigenschaften, Hohe DPI-Einstellungen usw.) auch dann, wenn die Echse über eine Verknüpfung (.lnk oder Dateiverknüpfung) geöffnet wird. Etwa bei der Keil-µVision-IDE uv2.exe und der verknüpften Projektdatei *.uv2.

Der beliebte Registry-​Schlüssel HKEY_​LOCAL_​MACHINE ist praktisch tabu. Dieser Schlüssel wird für Programme mit normalen Benutzerrechten weg-​virtualisiert, und die Daten gelangen an eine unschöne, schwer auf­zu­findende Stelle. Für Ordnung in der Registrierung sollte man daher alle Ein­stellungen schön brav nach HKEY_​CURRENT_​USER speichern. Maschinen­spezifische Einstellungen wie etwa die Port­adresse einer Schnitt­stellen­karte lassen sich faktisch nur sehr umständ­lich (in einer INI-Datei; das Programme-Verzeichnis kann aber schreib­geschützt sein) speichern, für Ordnung und Einfachheit tue ich's ebenfalls zu HKEY_CURRENT_USER.
Diese Einstellungen sind „umziehend“, was bspw. für Portadressen Quatsch ist. Hier hilft eventuell das (missbräuchliche?) Speichern nach HKEY_CLASSES_ROOT als benutzer­spezifische, aber nicht „umziehende“ Daten.

Manifest-Ressourcen für DLLs, genauer: Eigenschaftsseiten-Lieferanten („Property Sheet Provider“)⚓

Im konkreten Fall ging es darum, eine Erweiterung für MMC.EXE, genauer, dem Gerätemanager (Aufruf einfach mit devmgmt.msc) modern aussehen zu lassen. Laut Microsoft-Dokumentation muss man wie folgt vorgehen:

• Nimm ein genügend neues SDK zum Compilieren (also XP-SDK)
• Lege die RT_MANIFEST-Ressource mit dem numerischen Bezeichner ISOLATIONAWARE_MANIFEST_RESOURCE_ID = 2 an
• Schreibe an den Anfang des Quelltextes #define ISOLATION_AWARE_ENABLED 1

Lässt man auch nur einen Schritt weg, bleibt alles altbacken. Warum eigentlich dieses Mehr an Aufwand? Ist mir total unverständlich.

Alt und neu zusammen in einem Fenster sieht eben nicht toll aus! Man beachte vor allem die unterschiedlichen Knöpfe

Das ISOLATION_AWARE_ENABLED bewirkt ein Aufblähen des Kodes und den Zwang zur Laufzeitbibliothek! Dies wird seitens Microsoft über *.inl-Dateien erreicht, das sind Kopfdateien mit einer Menge Inline-Code. Dieser Inline-Code ist absichtlich kryptisch gehalten und damit kaum lesbar! Außerdem werden so unsinnige Sachen gemacht wie UNICOWS.DLL zu laden.

UNICOWS.DLL ist die Hauptdatei für Unicode-Unterstützung unter Windows 98/Me, aber diese Systeme haben mit Manifest-Ressourcen eh' nichts am Hut!

Der Schalter ISOLATION_AWARE_ENABLED ist also für mich völlig inakzeptabel, und so habe ich mich so lange durch die kryptischen *.inl-Dateien gewurstelt, bis nur noch der wirklich benötigte Kode übrig blieb. Das ist nun erfreulich wenig.

Einschalten der Teletubbie-Optik⚓

Irgendwie braucht man dazu immer einen Aktivierungskontext hActCtx.

Beschaffen des Aktivierungskontextes⚓

HANDLE hActCtx;		// „Aktivierungskontext“, das Ding mit der Teletubbie-Optik

BOOL APIENTRY _DllMainCRTStartup(HANDLE hModule, DWORD reason, LPVOID lpReserved) {
 switch (reason) {
  case DLL_PROCESS_ATTACH: {
   ACTIVATION_CONTEXT_BASIC_INFORMATION actCtxBasicInfo;
   BOOL (WINAPI*pQueryActCtxW)(DWORD,HANDLE,PVOID,ULONG,PVOID,SIZE_T,SIZE_T*);
   HANDLE hKernel;
   hInst=(HINSTANCE)hModule;
   DisableThreadLibraryCalls(hModule);
   InitCommonControls();
   hKernel=GetModuleHandle(T("KERNEL32.dll"));
   (FARPROC)pQueryActCtxW=GetProcAddress(hKernel,"QueryActCtxW");
   if (pQueryActCtxW
   && pQueryActCtxW(	// ziemlich undokumentiert
     QUERY_ACTCTX_FLAG_ACTCTX_IS_ADDRESS|QUERY_ACTCTX_FLAG_NO_ADDREF,
     &hActCtx,		// irgendeine Adresse
     NULL,
     ActivationContextBasicInformation,
     &actCtxBasicInfo,
     sizeof(actCtxBasicInfo),
     NULL)
   && actCtxBasicInfo.hActCtx!=INVALID_HANDLE_VALUE)
     hActCtx=actCtxBasicInfo.hActCtx;	// <hActCtx> nie freigeben, da ohne AddRef!
  }break;
 }
 return TRUE;
}

Der dynamische Einsprungpunkt via GetProcAddress() wird benötigt, damit die DLL auch unter Windows 2000 ladbar ist.

Der Trick bei Win16, mit UndefDynLink zur Laufzeit zur vergleichen, klappt bei Win32 nicht.

Wo (und ob?) InitCommonControls() aufgerufen wird, ist irrelevant. Beim Debuggen sieht man, dass InitCommonControls() zu nichts weiter als einem ret-Befehl führt.

Bei einer 64-bit-DLL kann man sich das Beschaffen des Einsprungpunktes zur Laufzeit ersparen, da es 64-bit-Editionen von Windows erst ab Windows XP gibt.
(Ja, gibt es! Wenn auch nur in englisch. Die meisten kennen das erst ab Windows Vista.)

Aktivieren der Teletubbie-Optik⚓

Normalerweise kann man die Aktivierung mittels ActivateActCtx() während des Programmlaufs bewirken. Das klappt aber nicht mit Eigenschaftsseiten („Property Sheets“)! Da verreckt irgendwo MMC.exe, der Gerätemanager.

Eigenschaftsseiten verlangen ein besonderes Vorgehen:

 HPROPSHEETPAGE hpage;
 PROPSHEETPAGE page;
 …				// die normale Initialisierung
 page.dwFlags = … |PSP_USEFUSIONCONTEXT;
 page.hActCtx = hActCtx;	// Die erweiterte PROPSHEETPAGE-Struktur steckt in der Kopfdatei des XP-SDKs oder -DDKs
 hpage = CreatePropertySheetPage(&page);

Die übrigen Fenster, wie Unter-Dialoge oder Messageboxen bekommen automatisch Teletubbie-Optik, da braucht man sich nicht mehr zu kümmern. Keine Wrapper mit ActivateActCtx() und DeactivateActCtx(). Und, das ist sehr nett, keine weiteren dynamischen Einsprungpunkte.

Zu bedenken ist, dass das Hervorheben bestimmter Dialogelemente durch Farbe, insbesondere bei Checkboxen, nicht mehr mittels SetTextColor() innerhalb von WM_CTLCOLORSTATIC möglich ist. Die einfachste Lösung ist es, derartige Dialogelemente mittels SetWindowTheme() in ihr altes Aussehen zurückzuverwandeln.

Inzwischen ist mir der Sinn von Manifests (zumindest der <dependency>-Abschnitt) etwas klar geworden:

• Windows XP hat mehrere Versionen der COMCTL32.dll, eine normale „alte“ (in WINDOWS\SYSTEM32) und mindestens eine „neue“ für XP-Stil (in – festhalten – WINDOWS\WinSxS\x86_​Microsoft.​Windows.​Common-​Controls_​6595b64144ccf1df_​6.0.0.0_​x-ww_1382d70a
  Damit wollte man wohl das Problem der DLL-​Hölle angreifen.
• Das SxS steht offenbar für „Side By Side Assemblies“, also soviel wie „neben­ein­an­der ste­hen­de DLLs“.
• Die „al­te“ COMCTL32.dll ist fak­tisch die glei­che wie unter Windows 2000. Die „neue“ bietet die Tele­tubbie-​Optik und „su­per­klas­si­fi­ziert“ auch die alt­be­kann­ten Fens­ter­klas­sen wie „Button“, „Edit“, „ListBox“ usw., die ei­gent­lich in der USER32.dll im­ple­men­tiert sind.
• Der EXE/DLL-​Loader von Win­dows (also bspw. Create​Process() und Load​Library()) ent­schei­det an­hand der Ma­ni­fest-Res­sour­ce oder -Datei, die in bzw. neben der zu la­den­den .EXE/.DLL liegt, welche Ver­sion von COMCTL32.dll ge­la­den und dy­na­misch ge­linkt wird.
  Dies kann man im mo­der­nen Dependency Walker sehen, der auch die Pfa­de aus­spuckt.
• Das Ver­fah­ren lässt sich auch auf an­de­re DLLs an­wen­den (bspw. MSVCRT.dll oder GDIplus.dll); die fol­gen­den Er­läu­te­run­gen be­zie­hen sich aus­schließ­lich auf COMCTL32.dll:

• Die „neue“ COMCTL32.dll ent­hält of­fen­bar Kode, zur „alten“ COMCTL32.dll zu­rück­zu­sprin­gen, wenn der sog. „Ak­ti­vie­rungs­kon­text“ (ActCtx) nicht ein­ge­schal­tet ist. Win­dows schal­tet die­sen beim Start von EXE-Da­tei­en stan­dard­mä­ßig ein. Zu­min­dest bei Vor­han­den­sein der CREATE​PROCESS_​MANIFEST_​RESOURCE_​ID.
• Bei Ei­gen­schafts­sei­ten (Property Sheets) gibt es eine Ak­ti­vie­rungs­kon­text-Ver­wal­tung auf Per-​Seiten-​Basis (siehe obiger Quell­text-​Ab­schnitt). Aus Kom­pa­ti­bi­li­täts­grün­den ist diese stan­dard­mä­ßig aus­ge­schal­tet (Flag PSP_​USE​FUSION​​CONTEXT und Mem­ber hActCtx nicht ge­setzt).
• Man braucht das Handle für den Ak­ti­vie­rungs­kontext (hActCtx). Wahr­schein­lich kön­nen DLLs Tele­tubbie-​Optik be­nut­zen, auch wenn das Wirts­pro­gramm ohne aus­ge­stat­tet ist; dazu muss Create​Act​Ctx() auf­ge­ru­fen werden.
  Wenn das Wirts­pro­gramm (hier: MMC.exe) mit Tele­tubbie-​Optik aus­ge­stat­tet ist, darf Create​Act​Ctx() nicht auf­ge­ru­fen wer­den (Absturz!!). Statt­des­sen muss Query​Act​CtxW() mit un­do­ku­men­tier­ten Pa­ra­me­tern und Schal­tern auf­ge­ru­fen wer­den.

• Immer intrinsisch:
  • Punktrechnung, Strichrechnung
  • Typumwandlungen int→float↔double↔long double←__int64
  • Typumwandlungen nach →int sind nicht intrinsisch, es sei denn, man benutzt die Kommandozeilen-Option /QIfist. Dann gilt das Rundungsverhalten von _controlfp(). Standardmäßig gilt „Banker's Rounding“ (mathematisches Runden), während eine C-konforme (int)-Typumwandlung gegen Null rundet.
• Intrinsisch bei Kommandozeilen-Option /Oi:
  • fabs(x): 1 x87-Befehl
• Intrinsisch bei Kommandozeilen-Optionen /Oi und /Og und /fp:fast:
  • sin(x), cos(x), atan2(y,x), fmod(y,x)?, sqrt(x): 1 x87-Befehl
  • tan(x), atan(x), log(x), log10(x): einige x87-Befehle
  • Beachte: Die float-Formen (etwa sinf(x)) sind blödsinnigerweise niemals intrinsisch!
• Einige Funktionen sind niemals intrinsisch, können jedoch mit der Option /fp:fast und irgendeiner Optimierungsoption (etwa /O1) die Gleitkomma-Parameter-Übergabe auf dem x87-Stapel machen (diese Funktionen fangen mit _CI an):
  • häufig: exp(x), fmod(x,y), pow(x,y); Beispielkode, um die Laufzeitbibliothek zu vermeiden:

    double _cdecl _CIexp() {
     _asm{	fldl2e
    	fmulp	st(1),st	// st = f * log2 e
    	fld	st		// duplizieren
    	frndint			// st = ganzzahliger Teil (Rundung mathematisch)
    	fsub	st(1),st	// st(1) = gebrochener Teil (± 0,5)
    	fxch	st(1)
    	f2xm1			// st = 2^gebrochener_Teil-1 (f2xm1 kann nur im Intervall ±1 arbeiten!)
    	fld1
    	faddp	st(1),st	// 1 addieren: st = 2^gebrochener_Teil
    	fscale			// st = 2^gebrochener_Teil * 2^ganzzahliger_Teil
    	fxch	st(1)
    	fstp	st		// ganzzahligen Teil entfernen
     }
    }
    
    double _cdecl _CIfmod() {
     _asm{	fxch	st(1)		// Operanden vertauschen
     	fprem			// eigentliches fmod
    	fxch	st(1)
    	fstp	st(0)		// Divisor verwerfen
    }}
     

  • Areafunktionen: acos(x), asin(x) = _copysign(atan(sqrt(x*x/(1-x*x))),x)
  • Hyperbolische Funktionen: cosh(x), sinh(x), tanh(x)
  • Für die o.a. intrinsischen Funktionen gibt es ebenso solche, die mit _CI anfangen. Logischerweise erübrigt sich damit das Vorhalten von Gleitkomma-Funktionen für den einfach genauen Datentyp float; der 80x87 rechnet sowieso mit long double (80 Bit).
  • Leider kann man selbst keine derartigen Funktionen definieren
• Alle übrigen Funktionen führen zum Aufruf der Laufzeitbibliothek!
  • Option /fp:fast und irgendeine Optimierungsoption (etwa /O1 oder /Ox): Parameter-Übergabe auf dem x87-Stapel (Funktionen fangen mit _CI an; wozu sollte das gut sein, wenn es intrinsische Funktionen gibt?)
  • Sonst: Parameter-Übergabe auf dem normalen Stack des 80x86. Beispielsweise:
    • floor(x), ceil(x), _copysign(x,y), _hypot(x,y), modf(x,ip)
    • Bessel-Funktionen: _j0(x), _j1(x), _jn(n,x), _y0(x), _y1(x), _yn(n,x)
  • MSVC ist nicht in der Lage, die DLL-Einsprünge ohne Stub zu realisieren. Ursache ist letztlich eine fehlerhafte math.h.

Da SSE2 keine transzendenten Funktionen anbietet, führen alle diese Funktionen zur Laufzeitbibliothek, die das Ergebnis trickreich ausschließlich per SSE2-Befehlssatz berechnet.

Trotzdem ist es möglich, derartige Funktionen mit der x87-Einheit ausrechnen zu lassen. Um den betreffenden Kode zu generieren, benötigt man einen alternativen Assembler. Ich habe kurzerhand YASM, ein Ableger von NASM ausprobiert.

Und so sieht eine selbstgeschriebene Sinusfunktion aus, die von C aus aufrufbar ist:

sin:	movq	rax,xmm0	;Der double-Parameter kommt in xmm0; dieser muss erst mal in den x87-Stapel
	push	rax		;Dazu muss der Operand speicheradressierbar sein, da bietet sich der Stack an
	fld	qword[rsp]	;Nun kann st(0) mit dem Winkelargument geladen werden
	fsin			;Die eigentliche Berechnung (fwait braucht man nicht mehr)
	fstp	qword[rsp]	;Jetzt der ganze Spaß in der anderen Richtung: Auf den Stack
	pop	rax		;runter vom Stack
	movq	xmm0,rax	;wieder ins SSE2-Register
	ret			;fertig

All die War­nun­gen, dass der x87-​Re­gis­ter­satz Kon­text­wech­sel nicht über­lebt, kann man vor­erst ge­trost ig­no­rie­ren. Denn das stimmt schlicht­weg nicht. Zu­min­dest im User Mode. Denn da­mit 32-​Bit-​Pro­gram­me un­ter 64-​Bit-​Win­dows lau­fen, muss Win­dows den x87-​Zu­stand beim Kon­text­wech­sel si­chern. Da wür­de es kaum nut­zen, wenn man das nur für 64-​Bit-​Pro­zes­se nicht tä­te. Erst wenn 32-​Bit-​Pro­gram­me aus­ge­stor­ben sind (schät­zungs­wei­se im Jahr 2030), könn­te sich das än­dern, aber wo­mög­lich tau­chen vor­her schon x64-​Pro­zes­so­ren oh­ne x87 und oh­ne 32-​Bit-​Kom­pa­ti­bi­li­täts­mo­dus auf.

Der C-Standard unterstützt die Operatoren <<, >> sowie % und ^ nicht. Warum eigentlich nicht? In der Standardbibliothek sind entsprechende (naheliegende) Funktionen ja bereits vorhanden. Eine kleine Hilfsklasse schafft Abhilfe in C++:

struct Double{
  Double(double v) : val(v)		{}
  operator double()		  const	{return val;}
  Double& operator <<=	(int exp)	{val=ldexp(val,exp); return *this;}
  Double  operator <<	(int exp) const	{Double o(*this); return o<<=exp;}
  Double& operator >>=	(int exp)	{return *this<<=-exp;}
  Double  operator >>	(int exp) const	{return *this<<-exp;}
  Double& operator %=	(double n)	{val=fmod(val,n); return *this;}
  Double  operator %	(double n)const	{Double o(*this); return o%=n;}
  Double& operator ^=	(double n)	{val=pow(val,n); return *this;}
  double  operator ^	(double n)const	{return pow(val,n);}
  double  operator &	(double n)const	{return hypot(val,n);}		// Betrag des Vektors
  Double  operator |	(Double n)const	{return ~(~*this+~n);}			// Parallelschaltung (von Widerständen)
  Double  operator ~	()	  const	{return Double(1/val);}			// Inversion
private: double val;
};

int LoadStringOem(HINSTANCE hInst, UINT id, PSTR buf, int len) {
 HRSRC r=FindResource(hInst,MAKEINTRESOURCE((id>>4)+1),RT_STRING);
 PCWSTR p=(PCWSTR)LoadResource(hInst,r);
 if (!p) return 0;
 for (id&=15; id; id--) {
  p+=*p+1;
 }
 len=WideCharToMultiByte(CP_OEMCP,0,p+1,*p,buf,len-1,NULL,NULL);
 buf[len]=0;
 return len;
}

Sieht logischerweise so ähnlich aus wie die MyLoadStringW()-Routine oben.

Die Ressourcendatei selbst muss in UTF-16 abgespeichert werden und kann nur mit RC.EXE ab Visual Studio 2005 compiliert werden; MSVC6 geht hierfür nicht.

Sollten auf dem Zielsystem keine Rahmensymbole zur Verfügung stehen wandelt WideCharToMultiByte() diese in optisch entsprechende ASCII-Zeichen um. Daher braucht man beim Export eines solchen Programms in exotische Länder keine Angst zu haben.

Windows hat sich lange Zeit geweigert, UTF-8 als 8-Bit-Zeichensatz anzunehmen. Standard ist es nur bei der Hindi-Version von Windows.

Seit Windows 10 gibt es die Möglichkeit, UTF-8 als ANSI-Zeichensatz festzulegen. Als „experimentelles Feature“. Leider ist die Nebenwirkung, dass Notepad++ und Programmer's Notepad ANSI-Dateien von MSVC6 fehlerhaft darstellen.