Effiziente Win32-Programmierung

Win32-Programme ohne Laufzeitbibliothek

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.

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

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

Oftmals will der Linker eine Funktion __ftol oder __ftol2_sse. Siehe hier:

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

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

Statische Konstruktoren und Destruktoren (C++)

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

#include <windows.h>

#pragma data_seg(".CRT$XCA")
 LONG_PTR Anfang = 0;	// Initialisierung ist wichtig, sonst geht's nach .bss!
#pragma data_seg(".CRT$XCZ")
 LONG_PTR Ende = 0;	// irgendetwas
#pragma data_seg()	//zurückschalten

EXTERN_C _CRTIMP void _cdecl _initterm(LONG_PTR*,LONG_PTR*);
 _initterm(&Anfang,&Ende);	// ruft alle statischen Konstruktoren

Meine immer wiederkehrenden Unterprogramme

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)

Beispiel

#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

Mehrsprachen-Ressourcen scheinen nie ordentlich zu funktionieren. So beschweren sich Amerikaner, dass meine zweisprachigen (englisch+deutsch) Programme selbst unter XP überraschend in Deutsch erscheinen. Ich habe hierzu keine gute Lösung. Vielleicht Windows Commander zum Vorbild nehmen und nur Texte übersetzen? Das Problem hierbei sind Dialoge im Rechts-nach-Links-Stil (arabisch).

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 projektname.RC-Datei
1 24 projektname.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>

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

Unicode unter Windows 98

• lstrlen, MessageBox
• 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

Auf der Wunschliste steht ja zumeist:

• Ein normales Hilfefenster mit Inhaltsverzeichnis, Index und Volltextsuche sowie Browse-Buttons (vor/zurück im Inhalt)
• Popup-Hilfefenster für kontextsensitive Kurzhilfe, aber bitteschön mit Zeichenformatierung! Und ohne keyhelp.ocx.
• Bei größeren Projekten:
  • Schlüsselwortsuche
  • Möglichkeit des Mischens und der gegenseitigen Verlinkung mehrerer CHM-Dateien

Siehe auch http://chmspec.nongnu.org/

Ein Beispiel

[OPTIONS]
Binary TOC=Yes
Compiled file=gwbasic.chm
Default Window=main
Contents file=gwbasic.hhc
Index file=gwbasic.hhk
Default topic=default.html
Full-text search=Yes
Language=0x409 Englisch (USA)
Title=GW-BASIC User's Guide

[WINDOWS]
main=,"gwbasic.hhc","gwbasic.hhk","default.html","default.html",,,,,0x62520,,0x70384E,,,,,,,,0
popup=,,,,,,,,,0,,0x80,,,,,,,,

[FILES]
gwbasic.hhp
chapter1.html
…

Das 0x80 bei popup generiert ein ToolWindow mit schmaler Titelzeile.

Wichtig zu wissen:

• Dateinamen dürfen kein Leerzeichen enthalten, sonst klappt die Browse-Funktion nicht!
• *.hhc und *.hhk müssen tatsächlich doppelt in der *.hhp-Datei vorhanden sein, sonst klappt die Rückwärts-Suche (= Finden des Abschnitts im Inhaltsverzeichnis) nicht.
• Das Wechseln des Fenstertitels anhand des HTML-Titels funktioniert schlichtweg nicht.
• Die einzelnen HTML-Titel werden für die Auflösung mehrfacher Index-Einträge benötigt, aber nur wenn sie nicht im Inhaltsverzeichnis (*.hhc) stehen.
• Ohne Angaben von Fenstergrößen merkt sich Windows die zuletzt benutzte Größe und Position, daher am besten nichts angeben

• Kleine Knöpfe (wie SelfHTML.chm)

<HTML><HEAD><!-- Sitemap 1.0 --></HEAD><BODY><UL>
 <LI><OBJECT type="text/sitemap"><param name="Name" value="Chapters"><param name="Local" value="default.html"></OBJECT>
 <UL>
  <li><object type="text/sitemap"><param name="Name" value="1. Welcome"><param name="Local" value="Chapter1.html"></object>
  …
 </UL>
 <LI><OBJECT type="text/sitemap"><param name="Name" value="Appendicies"></OBJECT>
 <UL>
  <li><object type="text/sitemap"><param name="Name" value="A. Error Codes and Messages"><param name="Local" value="AppendixA.html"></object>
 </UL>
 <li><object type="text/sitemap"><param name="Name" value="Glossary"><param name="Local" value="Glossary.html#1"><param name="New" value="1"></object>
</UL></BODY></HTML>

Alles in allem ziemlich geschwätzig; ein Texteditor mit regulären Ausdrücken und Wortersetzung ist hier zweckmäßig. Es kommt der Eindruck auf, das Microsoft die Programmierer quälen möchte. Eine simple ASCII-Datei mit verschiedenen Einrücktiefen und gewöhnlichen HTML-Links hätte es ja auch getan.

Hochkommas kann man weglassen, wo kein Leerzeichen eingeschlossen ist.

Wichtig zu wissen:

• Das mit den Tree-Icons funktioniert nur bei ausgeschaltetem „Binary TOC“! Immerhin generiert Windows von selbst einigermaßen „passende“ Icons. Nur das "New"-Tag funktioniert zuverlässig. Es generiert einen auffälligen „Lichtpunkt“ auf dem Icon.
• Ordner-Symbole statt Bücher erzeugen die Zeile:

   <OBJECT type="text/site properties"><param name="ImageType" value="Folder"></OBJECT>
  

  direkt nach <BODY>, aber eben nur bei ausgeschaltetem „Binary TOC“!
• Alles was im Inhaltsverzeichnis ist, ist auch in der Browse-Reihenfolge. Leider auch die lokalen Labels (also <a name=…>). Daher sollten diese eher sparsam (im Inhaltsverzeichnis) verwendet werden. Alles, was nicht drinsteht, ist auch nicht in der Browse-Sequenz! Die Browse-Buttons schalten automatisch auf grau am Anfang und Ende der Sequenz bzw. wenn ein Thema nicht im Inhalt steht.
• Alle <OBJECT …>-Geschichten werden effektiv entfernt und ersetzt! Diese steuern also allesamt den Browser (oder den Hilfe-Compiler?). Verballhorntes XML schon wieder.
• Der <!-- Sitemap 1.0 -->-Kommentar muss stehen bleiben! Alles andere (!DOCTYPE… und meta generator…) kann weg. Unnötiges Geschwafel bläht ja nur das fertige .CHM auf.
• Mehrfache Nennungen eines Dokuments sind im Inhaltsverzeichnis zu vermeiden. Wenn doch, muss die Bezeichnung (Titel) immer dieselbe sein! Sonst dupliziert der .CHM-Betrachter einfach die zuletzt genannte Bezeichnung! Notfalls behilft man sich mit verschiedenen #-Ankern.

<HTML><HEAD><!-- Sitemap 1.0 --></HEAD><BODY><UL>
 <li><object type="text/sitemap"><param name="Name" value="ABS"><param name="Local" value="ABS.html"></object>
 <li><object type="text/sitemap"><param name="Name" value="ASC"><param name="Local" value="ASC.html"></object>
 … 
</UL></BODY></HTML>

Wichtig zu wissen:

• Die Stichworte MÜSSEN (praktisch) in alphabetischer Reihenfolge stehen, so wie es der Anwender erwartet.
• Schachtelungen sind erlaubt
• Gleiche Stichwörter mit verschiedenen HTML-Zielen sind erlaubt und führen zu einem Auswahldialog, der für jeden Treffer:
  • den „Titel“ der HTML-Datei, das ist der Titel im Inhaltsverzeichnis(!), sofern dort vorhanden, sonst der HTML-<title>-Tag
  • den „Titel“ der CHM-Datei (also den Fenstertitel, siehe HHP-Datei, [Options] Title=)
  anzeigt.
• Gleiche Stichwörter mit gleichen HTML-Zielen werden unterdrückt.

• Wie man ein Popup in passender Größe ohne Rollbalken erzeugt

Tipps (HTML)

HTML zersägen

<object type="application/x-oleobject" classid="clsid:1e2a7bd0-dab9-11d0-b93a-00c04fc99f9e">
 <param name="New HTML file" value="USB-Funktionen.htm">
 <param name="New HTML title" value="USB-Funktionen">
</object>

<br clear=all style='page-break-before:always'>

Die Links im Inhaltsverzeichnis und Index müssen sich auf die zersägten Dateinamen beziehen!

Womöglich kann man sogar Inhaltsverzeichnis und Index mit hineinstecken.

Tricks

Quelle sparen

Das beißt sich allerdings mit der Möglichkeit, HTML-Dateien zu zersägen.