Effiziente Win32-Programmierung

Alle meine Programme sind auf Robustheit ausgelegt. Ein Programm ist robust, wenn es ohne zu murren und ohne Installiererei einfach läuft (und läuft und läuft). Auf möglichst jeder Zielplattform. (Das gilt sinngemäß auch für Webseiten!) Wichtig ist dabei die Unabhängigkeit von nicht-immer-vorhandenen Zusatzbibliotheken. Etwa den rechts gelisteten, manchen geplagten Anwender sattsam bekannten, mit Updates nervenden Softwarebomben.

Es gibt nur noch recht wenige Ausführungen anderswo, mit Win32 zu programmieren. Der typische Anfänger beginnt mit .NET und C#. Oder, noch schlimmer, mit Python.

• Willemer (deutsch!)
• Mike V

Einfache Win32-Programmbeispiele

Was die Fachliteratur als „Einfachstes Windows-Programm“ so anbietet ist schlichtweg abschreckend! Hier sind die wirklich einfachen Programme.

Nr. 1

#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.

Nr. 2

#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.

Nr. 3

#include <windows.h>
EXTERN_C int WinMainCRTStartup() {
  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.

Nr. 4

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 ohne Quelltext! 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.)

MSVC6 installieren

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. Ist relativ unwichtig.
  • Für die kontextsensitive Hilfe (C++- und Windows-Funktionen) muss eine geeignete MSDN-Library installiert sein. 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.

Win32-Programme ohne Laufzeitbibliothek

Fast alle meiner Win32-Programme sind ohne Laufzeitbibliothek geschrieben. Die nachfolgende Übersicht gibt einige Hinweise auf die Unterschiede der Programmierung.

Prinzipiell gibt es da zwei Wege:

Dem Leser sollte Win32-Programmierung bekannt sein, wenn nicht, dann bitte den „Petzold“ lesen!

Ich bin mit Windows-Programmierung in Pascal groß geworden, und habe Objektbibliotheken zu hassen gelernt, weil sie eben nur so tun, als ob sie Komplexität verbergen könnten. Deswegen wird der Leser bei mir kein einziges MFC-Programm finden. Auch wenn es nach außen so (modern) aussehen möge, schon die Dateigröße verrät, dass es kein MFC sein kann.

Generelle Unterschiede:

#include <stdafx.h>

#define WIN32_LEAN_AND_MEAN
#include <windows.h>	// Windows eben
#include <windowsx.h>	// Nützliche Makros
#include <shlwapi.h>	// String-Funktionen
#include <comdlg32.h>	// Datei-öffnen-Dialog
#include <comctl32.h>	// erweiterte Dialogelemente
...

Diese Tabelle spiegelt nur den Unterscheid bei Microsoft Visual C++ (ab Version 6 geprüft) wider. Bei Borland C++ gelten andere Regeln!

Konstanten im Kodesegment (/GF) ersparen initialisierte statische Variablen. (Alle nicht initialisierten statischen Variablen werden vom EXE-Loader stets mit Null initialisiert, muss man wissen. Es ist ohnehin unschöner Programmierstil, mit Nicht-Null initialisierte statische Variablen nicht const zu setzen. Bei der Verwendung von unicows.lib bzw. libunicows.lib kommt man um solche Variablen nicht herum.) Den Erfolg der Maßnahme kann man mittels dumpbin /headers prüfen: das Datensegment (.data) muss in der EXE-Datei leer sein.

SECTION HEADER #3
   .data name
     6F4 virtual size
    8000 virtual address (00408000 to 004086F3)
       0 size of raw data
       0 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0000040 flags
         Initialized Data
         Read Write

Ohne Standardbibliothek kann man nicht „portabel“ im Sinne des ANSI-Standards programmieren. Aber kein Windows-Programm ist jemals ANSI-konform. Es gibt kein main, kein printf. (Wohin denn?) Muss ich weiter argumentieren? (Ich rede hier nicht von Konsolen-Programmen.)

Also, Portabibiltät ist etwas für den Elfenbeinturm (Informatiker, Lehre) oder für Unix (Linux - da kommt man nicht herum!). Für Windows: da sage ich einfach Tschüss und winke-winke!
Jetzt muss man nur noch wissen, was man statt der gewohnten Funktionen verwenden muss. Ganz nebenbei wird das Programm unicode-fähig, ohne jedesmal den TCHAR-Präfix (bspw. _tprintf statt printf) verwenden zu müssen (was ja auch nicht ganz portabel ist).

Hier eine kurze Übersicht

void _declspec(naked) _fastcall FillMemB(size_t l,void*d,BYTE fill){ _asm{
	mov	eax,[esp+4]
	xchg	edi,edx		// Zeiger in EDX
	rep	stosb		// Länge in ECX, keine Aktion bei ECX=0
	mov	edi,edx		// EDI restaurieren
	ret	4
}}
#define FillMemory(d,l,f) FillMemB(l,d,f)
#define ZeroMemory(d,l) FillMemB(l,d,0)

#undef RtlZeroMemory
EXTERN_C void _declspec(dllimport) WINAPI RtlZeroMemory(PVOID,SIZE_T);
#undef RtlFillMemory
EXTERN_C void _declspec(dllimport) WINAPI RtlFillMemory(PVOID,SIZE_T,BYTE);

void _declspec(naked) _fastcall MoveMemB(size_t l, void*d,const void*s){ _asm{
	mov	eax,[esp+4]	// Quelle auf Stack
	xchg	esi,eax
	xchg	edi,edx		// Ziel in EDX
	cmp	esi,edi
	jnc	l1
	lea	esi,[esi+ecx-1]
	lea	edi,[edi+ecx-1]
	std			// abwärts
l1:	rep	movsb		// Länge in ECX, keine Aktion bei ECX=0
	cld
	mov	edi,edx
	mov	esi,eax		// Register restaurieren
	ret	4
}}
#define CopyMemory(d,s,l) MoveMemB(l,d,s)
#define MoveMemory(d,s,l) MoveMemB(l,d,s)

#undef RtlMoveMemory
EXTERN_C void _declspec(dllimport) WINAPI RtlMoveMemory(PVOID,const VOID*,SIZE_T);
#undef CopyMemory
#define CopyMemory MoveMemory

#pragma inline(memcpy,memset)

BYTE* _declspec(naked) _fastcall ScanMemB(size_t l,const BYTE*s,BYTE c){ _asm{
	mov	eax,[esp+4]
	xchg	edi,edx
	repne	scasb
	lea	eax,[edi-1]
	mov	edi,edx		// EDI restaurieren
	jz	l1
	xor	eax,eax		// NULL liefern wenn nicht gefunden
l1:	ret	4
}}
#define memchr(s,c,l) ScanMemB(l,s,c)

int _declspec(naked) _fastcall CmpMemB(size_t l,const BYTE*d,const BYTE*s){ _asm{
	jecxz	l1		// undefiniertes Ergebnis bei Länge 0
	mov	eax,[esp+4]
	xchg	esi,eax
	xchg	edi,edx
	repe	cmpsb
	movsx	edi,byte ptr [edi-1]
	movsx	esi,byte ptr [esi-1]
	sub	esi,edi
	mov	edi,edx
	xchg	esi,eax
l1:	ret	4
}}
#define memcmp(d,s,l) CmpMemB(l,d,s)

Hier könnte man noch beliebig fortsetzen.
Bei Einsatz von Gleitkomma bei Ein- und Ausgabe ist es besser, ein funktionierendes sprintf() und sscanf() zu haben, diese beschafft man sich wie folgt:

EXTERN_C int (_cdecl*_stprintf)(PTSTR,int,PTSTR,...);
EXTERN_C int (_cdecl*_stscanf)(PTSTR,PTSTR,...);
#ifdef UNICODE
# define __IMP__STPRINTF "_snwprintf"
# define __IMP__STSCANF "swscanf"
#else
# define __IMP__STPRINTF "_snprintf"
# define __IMP__STSCANF "sscanf"
#endif

// irgendwo in der Programminitialisierung:
 HINSTANCE hLibMSVCRT=LoadLibraryA("MSVCRT.DLL");
 (FARPROC)_stprintf=GetProcAddress(hLibMSVCRT,__IMP__STPRINTF);
 (FARPROC)_stscanf=GetProcAddress(hLibMSVCRT,__IMP__STSCANF);

long _declspec(naked) _cdecl _ftol(void){ _asm{
	push	eax
 	fistp	dword ptr [esp]
	pop	eax
	ret
}}

__forceinline __int64 llrint(double f) {
 __int64 i;
 _asm	fld	f
 _asm	fistp	i
 return i;
}

Intrinsische Funktionen

Neuere Visual Studios

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

Statische Konstruktoren und Destruktoren (C++)

Für diese gibt es die MSVCRT.DLL-Funktion _initterm. Diese bekommt den Zeiger auf eine Liste von Funktionszeigern zum Fraß sowie deren Endadresse. Von den einzelnen Modulen werden diese Adressen in das Datensegment ".CRT$XCC" geworfen. Der Linker pappt diese Datensegmente in eher zufälliger Reihenfolge hintereinander und baut so eine Tabelle auf, die (wegen der nicht ganz sicheren Segmentausrichtung des Linkers) Nullen enthalten kann; _initterm() übergeht Nullen automatisch. Siehe auch: Wie ein Linker arbeitet.

Und so kommt man an die Anfangs- und Endadresse dieser Tabelle, siehe auch Microsoft-CRT-Quelle:

#include <windows.h>

#pragma bss_seg(".CRT$XCA")
static void* Anfang;	// Keine Initialisierung
#pragma bss_seg(".CRT$XCZ")
static void* Ende;
#pragma bss_seg()	// zurückschalten zu ".bss"

Es wird schlichtweg darauf vertraut, dass der Linker die Segmente in alphabetischer Reihenfolge zusammensetzt! Damit stehen diese beiden Tabellenelemente am Anfang und am Ende der Tabelle, und man kann _initterm() aufrufen:

extern "C" _CRTIMP void _cdecl _initterm(void*&,void*&);
 _initterm(Anfang,Ende);	// ruft alle statischen Konstruktoren

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.

Meine immer wiederkehrenden Unterprogramme

Manchmal habe ich den Eindruck, dass Microsoft einige immer wieder benötigte Funktionen und Makros verschläft zu implementieren. Die 1997 aufkommende shlwapi.dll war da schon ein kleiner Durchbruch, lieferte diese doch endlich die fehlenden String-Funktionen nach.

Immer noch fehlen Funktionen für Gleitkomma-Ein/Ausgabe, obwohl dieses Zahlenformat ins Win32-GDI eingezogen ist (siehe SetWorldTransform) und bei GDI+ für exakte Positionierung kantengeglätteter Figuren äußerst nützlich ist.

#define T(x) TEXT(x)

#define elemof(x) (sizeof(x)/sizeof(*(x)))

#define nobreak

void _fastcall InitStruct(LPVOID p, UINT len) {
 __stosd(p,0,len>>2);
 *(UINT*)p=len;
}

void EnableDlgItem(HWND Wnd, UINT id, BOOL state) {
 Wnd=GetDlgItem(Wnd,id);
 if (Wnd) EnableWindow(Wnd,state);
}

void ShowDlgItem(HWND Wnd, UINT id, int state) {
 Wnd=GetDlgItem(Wnd,id);
 if (Wnd) ShowWindow(Wnd,state);
}

void SetCheckboxGroup(HWND Wnd, UINT u, UINT o, UINT v) {
 for (; u<=o; u++,v>>=1) CheckDlgButton(Wnd,u,v&1);
}

UINT GetCheckboxGroup(HWND Wnd, UINT u, UINT o) {
 UINT v,m;
 for (v=0,m=1; u<=o; u++,m+=m) if (IsDlgButtonChecked(Wnd,u)==1) v|=m;
 return v;
}

#if _MSC_VER < 1400	// Visual C++ 6, nur X86
__forceinline char _BitScanForward(DWORD*Index, DWORD mask) {
 _asm	bsf	eax,mask
 _asm	mov	ecx,Index	// ohne ECX einzusauen geht es hier nicht
 _asm	mov	[ecx],eax
 _asm	setnz	al
}
__forceinline char _BitScanReverse(DWORD*Index, DWORD mask) {
 _asm	bsr	eax,mask
 _asm	mov	ecx,Index
 _asm	mov	[ecx],eax
 _asm	setnz	al
}
#endif

HINSTANCE ghInstance;	// kann je nach Ressourcen-DLL gesetzt werden, sonst 0 = aus EXE-Datei
TCHAR MBoxTitle[64];	// typischerweise mit LoadString() am Programmstart vorbelegen

int vMBox(HWND Wnd, LONG_PTR id, UINT style, va_list arglist) {
 TCHAR buf2[1024];
 if (IS_INTRESOURCE(id)) {	// String aus Ressource (kein Zeiger)
  TCHAR buf1[256];
  LoadString(ghInstance,(UINT)id,buf1,elemof(buf1));
  wvnsprintf(buf2,elemof(buf2),buf1,arglist);
 }else wvnsprintf(buf2,elemof(buf2),(PCTSTR)id,arglist);	// id ist Zeiger
 return MessageBox(Wnd,buf2,MBoxTitle,style);
}

int _cdecl MBox(HWND Wnd, UINT id, UINT style,...) {
 return vMBox(Wnd,id,style,(va_list)(&style+1));
}

Das fehlende typeof-Makro kann ich leider nicht nachliefern…

Realisierung von Plug-and-Play

Hier hat Microsoft eine Menge unterdokumentierter Fallstricke in die Kopfdateien eingebaut. Dies beginnt schon damit, dass man für manche noch so kleine Funktion oder GUID das DDK benötigt. Auch wenn's nur um das Auflisten verfügbarer serieller Schnittstellen geht.

SetupDi- und CfgMgr-Funktionen

Hier zähle ich nur die wichtigsten Funktionen auf.

SetupDi mit Klassenbezug

Diese Funktionen sind ab Windows 95 und Windows NT 4 verfügbar.

• SetupDiGetClassDevs() erzeugt einen Schnappschuss der aktuellen Konfiguration und liefert davon ein Handle. Dieser wird für alle nachfolgenden Funktionen benötigt. Der gemachte Schnappschuss kann (und wird im Allgemeinen) durch die Angabe einer klassenspezifischen GUID (Class-GUID) eingeschränkt, etwa GUID_DEVCLASS_PORTS. Diese GUID und die englische Klassenbezeichnung findet sich im [Version]-Abschnitt von gerätespezifischen INF-Dateien wieder.
• SetupDiEnumDeviceInfo(), typischerweise im Kopf einer for-Schleife, liefert davon ein Handle zu einem bestimmten Gerät dieser Klasse, etwa ein COM-Port. Mit dem Handle geht es dann mit CfgMgr-Funktionen weiter.
  Diese Funktion funktioniert unter Windows 95 nicht so recht.
• SetupDiDestroyDeviceInfoList() zerstört diesen Schnappschuss.

SetupDi mit Interface-Bezug

Im Laufe der Entwicklung hat Microsoft aber entschieden, dass bspw. parallele und serielle Schnittstellen doch etwas unterschiedlich sind (wer wäre nicht vorher drauf gekommen?), und hat neben den Geräteklassen (nicht unterhalb der Geräteklassen!) die Interfaces eingeführt. Diese haben andere GUIDs und benötigen z.T. auch andere Zugriffsfunktionen.

Die Unterstützung des Interface-Bezugs beginnt mit Windows 98 (IMHO Zweite Ausgabe), ist dort noch etwas hakelig (funktioniert bspw. bei seriellen Schnittstellen nicht), und ist ab Windows 2000 einigermaßen vollständig implementiert.

Die hauptsächliche Anwendung ist das Finden und Ansprechen von USB-Geräten, für die es für jede USB-Geräteklasse (nach USB-IF-Spezifikation) ein eigenes Interface mit eigener GUID gibt.

Um mit Interfaces zu arbeiten, ist beim Aufruf von SetupDiGetClassDevs() das Flag DIGCF_DEVICEINTERFACE anzugeben, und es sind statt SetupDiEnumDeviceInfo() folgende Funktionen zu verwenden:

• SetupDiEnumDeviceInterfaces() liefert ein für die nachfolgende Funktion geeignetes Handle für jedes Gerät im Schnappschuss.
• SetupDiGetDeviceInterfaceDetailliefert einen ziemlich kryptischen aber systemweit eindeutigen Dateinamen für die weitere „Unterhaltung“ mit dem Gerät via CreateFile() und dateibezogener Ein/Ausgabe.
  Man findet im Internet eine Unmenge sehr umständlich programmierter Schleifen mit irrwitziger Speicherverwaltung; eins meiner Beispiele zeigt ab Zeile 42, wie es auch ohne geht.

CfgMgr-Funktionen

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!

Rückrufe (Callbacks)

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!) 2 Sekunden sind ein gutes Maß.

Beispiel

Das ist natürlich 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 (zumindest Zweite Ausgabe). 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.

Ressourcen - ein ewiges Drama mit MSVC

MSVC enthält eher einen RC-Zerstörer als einen -Editor.

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

Das Problem hat sich inzwischen gelegt, bei mir funktioniert die automatische Sprachselektion immer korrekt. Viele meiner neueren Programme sind nunmehr zweisprachig ohne viel Federlesen.

Manifest-Dateien und -Ressourcen

Zeile in .RC-Datei

1 24 .manifest

Der Inhalt der Manifest-Datei ist immer der gleiche:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
 <dependentAssembly>
  <assemblyIdentity
   type="win32"
   name="Microsoft.Windows.Common-Controls"
   version="6.0.0.0"
   processorArchitecture="*"
   publicKeyToken="6595b64144ccf1df"
   language="*"
  />
 </dependentAssembly>
</dependency>
</assembly>

Was auch immer Microsoft mit Manifest-Dateien eigentlich wollte (irgend­was mit C# und Microsoft Forms, ich habe es nicht verstanden), ich stecke jetzt immer eine Manifest-Datei ins Projekt und stecke sie in die Res­sour­ce. Damit sind die Echsen etwas größer, sehen aber modern aus. Für je­man­den, der Tele­tubbie-​Optik nie eingeschaltet hat (oder wie ich Win­dows 2000 oder noch äl­ter be­nutzt), nur sinn­lose Luft. Be­son­ders un­ver­ständ­lich für mich ist die Aus­wir­kung der Name­space-​Ele­mente (xmlns). Kann man den Quatsch viel­leicht weg­las­sen, oder spinnt dann ir­gend­eins der Mi­cro­soft-​Be­triebs­sys­te­me?

Besonderheiten ab Vista

<?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.

Gleitkomma-Operationen auf AMD64-Architektur

(Betrifft nur Programme, bei denen nicht einmal der Bezug zur msvcrt.dll erwünscht ist.)

Die Situation beim 32-Bit-Compiler

• 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.

Beim 64-Bit-Compiler

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.

Die in jeder Hilfe fehlende Liste von Ersetzungsroutinen

Weitere Operatoren für Gleitkommazahlen

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;
};

Unicode unter Windows 98

• lstrlen, MessageBox (kann aber keine ANSI-fremden Zeichen ausgeben!)
• WideCharToMultiByte, MultiByteToWideChar (auch von/zu UTF-8)
• TextOut, ExtTextOut, GetTextExtentPoint32
• shlwapi-Funktionen (?)
• msvcrt.dll-Funktionen (sind allesamt unicode-fähig)

Das Microsoft-Paket unicows hilft da nicht wirklich weiter, denn:

• Es muss installiert werden – zumindest muss man eine dicke DLL mitliefern
• Das Programm muss speziell für unicows angepasst sein (beim Erstellen)
• Einige Funktionen sind nicht durch unicows abgedeckt, nach Murphy genau die, die man gerade braucht, etwa EnumPrinters.
• Dialogelemente („Controls“) und Fenstertitel bleiben nicht-unicode-fähig

int MyLoadStringW(HINSTANCE hInst, UINT id, PWSTR 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--;
 if (len<0) return *p+1;	// Allokationsgröße in Zeichen
 if (len>*p) len=*p;
 p++;
 __movsw(buf,p,len);	// inklusive etwaiger Nullen!
 buf[len]=0;
 return len;
}

__forceinline void __movsw(void*d, const void*s, DWORD count) {
 _asm	mov	edi,d
 _asm	mov	esi,s
 _asm	mov	ecx,count
 _asm	rep movsw
}

OEM-Zeichensatz

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.

CHM-Hilfe