Kategorie: Vista / Windows 7

Programmieren für Vista und Windows 7

DrawText unter Vista gegenüber XP um bis zu Faktor 50 langsamer!

❗ Ja Ihr habt ganz richtig gelesen und ich irre mich nicht ❗

Wir haben in einem unserer C++/MFC Programmen eine komplexe Anzeige von Reports, die alle unterschiedliche Zeilenhöhe haben und in einem speziellen Fenster angezeigt werden (eigene Entwicklung).
Nun stellten wir fest, dass das Rollen in diesem Programmteil auf Vista-Rechnern mit viel Nachlauf funktionierte und auch einige andere Operationen länger als gewohnt dauerten. Bei meinem Suchen, Profilen und Testen kam ich auf ein sehr lahmes Abarbeiten der Funktion DrawText  mit DT_CALCRECT.

Um das Problem zu isolieren schrieb ich ein kleines Testprogramm, das erstaunliches zu Tage brachte.
Hier die Ergebnisse von 4 verschiedenen Rechnern (Durchlauf von 100×100 DrawText Calls):

  • Pentium Quad-Core Q8200 mit Vista: 48.111 msec
  • Pentium Core2Duo T2310 mit Vista: 78.953 msec
  • Pentium Dual Core 3,2Ghz mit XP: 1.516 msec
  • Alter Pentium 3,0Ghz HT mit XP: 1.922 msec

😯 Der Code ist teilweise um den Faktor 50 langsamer auf Windows-Vista im Vergleich zu Windows-XP ❗

Wer Lust hat es selbst zu testen, der findet hier das Beispielprogramm im Sourcecode (VS-2005):  TestDrawText.zip
Wer das Programm als Exe möchte findet es hier: TestDrawTextExe.zip

Beschreibung:
Dieses Beispielprogramm führt gemäß einem angegebenen Zähler je 100mal DrawText mit DT_CALCRECT für einen längeren mehrzeiligen Text aus. Hierbei werden immer zufällige Textlängen verwendet. Der Algorithmus liefert jedoch immer die gleiche Zufallssequenz, damit der Test auch Vergleichbar bleibt.
Der Zufallsmechanismus wurde nur eingebaut, um für für meinen Fall realitätsnahe Daten zu liefern.

Anmerkung:
Eine entsprechende Supportanfrage bei Microsoft läuft ❗
Was dabei herauskommt werde ich berichten…

Zuletzt angemerkt:
Windows 7 soll ja schneller sein als Windows Vista. Wer weiß? Ich habe es noch nicht getestet.
Vieleicht haben die nur diesen Bug gefixed und einen gigantischen Performanceschub erhalten :mrgreen: … SCNR…

Nachtrag (11.07.2009): 
Die Auiflösung zu diesem Problem findet sich hier in diesem Artikel http://blog.m-ri.de/index.php/2009/07/11/ausloesung-drawtext-unter-vista-gegenueber-xp-um-bis-zu-faktor-50-langsamer/

SETX der kleine Helfer für die wechselnden Environment Variablen des Entwicklers

In manchen Fällen kommt man um Environment Variablen nicht herum. Sie machen es auch einfach, globale Pfade für Linker, Präprozessor und auch für die Ausführung (PATH) zu setzen, oder eben auch EXEs und  DLLs zu steuern.

Solche Environment Variablen, bzw. INCLUDE und LIB Pfade zu setzen für das ganze System kann mühsam sein wenn man die Windows System UI nutzt. Der Aufruf ist umständlich und es erfolgt ein UAC-Prompt. Eine andere Variante wäre die Nutzung einer Reg-Datei. Dazu muss man aber wieder der UAC-Prompt über sich ergehen lassen.

Es geht viel einfacher, mit dem Helferlein SETX.EXE, das seit Vista nicht mehr nur im Windows Ressource Kit drin ist. Mit SETX kann man sich Ruckzuck ein kleines Batch-File schreiben, dass alle wichtigen Umgebungsvariablen für eine bestimmte Projektumgebung setzt.
Genial ist einfach, dass ab diesem Moment für jedes neu gestartete Programm diese Environment Variablen gelten. Natürlich inklusive der Visual Studio Umgebung.

In der Verbindung mit dem Aufruf von DEVENV /useenv kann man damit sehr schnell seinen Rechner auf eine komplett andere Projektumgebung einstellen. Und das ganze auch ohne UAC-Prompt 🙂 Ja! Man glaubt es kaum. Es erfolgt ja auch nur Zugriff auf HKCU.

Anmerkung:Ich benutzt sehr gerne den Property-Manager nur ist es eben nur eine Lösung für alle Software, die aus dem Visual-Studio heraus gestartet wird, und es nützt gar nichts, wenn man die EXE/DLL selber mit unterschiedlichen Umgebungen testen will.

Und SETX ist auch noch wirklich extrem flexibel. Man kann nicht nur einfach eine Environment Variable setzen, wie man es mit SET kennt. Als Quelle können hier sogar Tetxdateien, Registryschlüssel genutzt werden. Und das Multitalent SETX kann sogar bei Angabe von Computername, Nutzername und Kennwort remote benutzt werden und damit auch die Systemweiten Parameter verändern.

Hier die Beschreibung von SETX /?

SetX hat drei verschiedene Ausführungsmethoden:

Syntax 1:
    SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]] var Wert [/M]

Syntax 2:
    SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]] var /K
         Registrierungspfad [/M]

Syntax 3:
    SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]]
         /F Datei {var {/A x,y | /R x,y Zeichenfolge}[/M] | /X}
         [/D Trennzeichen]

Beschreibung:
  Erstellt oder bearbeitet Umgebungsvariablen in der Benutzer- oder
  Systemumgebung. Ermöglicht das Festlegen von Variablen, die auf
  Argumenten, Registrierungsschlüsseln oder Dateieingabe basieren.

Parameterliste:
  /S    System             Remotesystem für die Verbindungsherstellung.

  /U    [Domäne\]Benutzer  Bestimmt den Benutzerkontext, unter dem
                           der Befehl ausgeführt wird.

  /P    [Kennwort]         Bestimmt das Kennwort für den
                           Auslassung fordert zur Kennworteingabe auf.

  Variable                 Bestimmt die zu setzende Umgebungsvariable.

  Wert                     Bestimmt einen zu setzenden Wert
                           für die Umgebungsvariablen.

  /K    Registrierungspfad Bestimmt, dass die Variable auf Informationen
                           aus einem Registrierungsschlüssel basiert.
                           Gültiges Pfadformat:
                           Struktur\Schlüssel\…\Wert, z. B.
                           HKEY_LOCAL_MACHINE\System\CurrentControlSet\
                           Control\TimeZoneInformation\StandardName.

  /F    Datei              Bestimmt den Dateinamen der zu verwendenden
                           Textdatei.

  /A    x,y                Bestimmt die absoluten Dateikoordinaten
                           (Zeile X, Element Y) als Parameter, nach denen
                           innerhalb der Datei gesucht werden soll.

  /R    x,y Zeichenfolge   Bestimmt die relativen Dateikoordinaten im
                           Verhältnis zur „Zeichenfolge“ als Suchparameter.

  /M                       Legt fest, dass die Variable in der
                           systemübergreifenden Umgebung
                           (HKEY_LOCAL_MACHINE) gesetzt werden. Der
                           Standardwert wird unter der Umgebung gesetzt
                           (HKEY_CURRENT_USER).

  /X                       Zeigt Dateiinhalte mit den x,y Koordinaten an.

  /D    Trennzeichen       Bestimmt zusätzliche Trennzeichen, wie z. B.
                           „,“ oder „\“. Standardtrennzeichen sind
                           Leerzeichen, Tabulator, Wagenrücklauf und
                           Zeilenvorschub. Beliebige ASCII-Zeichen können
                           als zusätzliche Trennzeichen verwendet
                           werden. Die max. Anzahl an Trennzeichen,
                           einschließlich Standardtrennzeichen beträgt 15.

  /?                       Zeigt diese Hilfe an.

HINWEIS: 1) SETX schreibt Variablen in die übergeordnete Umgebung
            in der Registrierung.

         2) Auf einem lokalen System sind Variablen, die mit
            diesem Programm erstellt oder bearbeitet wurden,
            erst in zukünftigen und nicht in aktuellen
            cmd.exe Befehlszeilenfenstern verfügbar.

         3) Auf einem Remotesystem sind Variablen, die mit
            diesem Programm erstellt oder bearbeitet wurden, erst
            bei der nächsten Anmeldesitzung verfügbar.

         4) Gültige Registrierungsschlüssel-Datentypen:
            REG_DWORD, REG_EXPAND_SZ, REG_SZ, REG_MULTI_SZ

         5) Unterstützte Registrierungsstrukturen: HKEY_LOCAL_MACHINE
            HKEY_CURRENT_USER (HKCU).

         6) Bei Trennzeichen wird zwischen Groß-/Kleinschreibung
            unterschieden.

         7) REG_DWORD-Werte werden aus der Registrierung
            im Dezimalformat extrahiert.

Beispiele:
    SETX MACHINE COMPAQ
    SETX MACHINE „COMPAQ COMPUTER“ /M
    SETX MYPATH „%PATH%“
    SETX MYPATH ~PATH~
    SETX /S System /U Benutzer /P Kennwort MACHINE COMPAQ
    SETX /S System /U Benutzer /P Kennwort ^%PATH^%
    SETX TZONE /K HKEY_LOCAL_MACHINE\System\CurrentControlSet\
         Control\TimeZoneInformation\StandardName
    SETX BUILD /K „HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
         NT\CurrentVersion\CurrentBuildNumber“ /M
    SETX /S System /U Benutzer /P Kennwort TZONE /K HKEY_LOCAL_MACHINE\
         System\CurrentControlSet\Control\TimeZoneInformation\
         StandardName
    SETX /S System /U Benutzer /P Kennwort BUILD /K
         „HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\
         CurrentVersion\CurrentBuildNumber“ /M
    SETX /F ipconfig.out /X
    SETX IPADDR /F ipconfig.out /A 5,11
    SETX OCTET1 /F ipconfig.out /A 5,3 /D „#$*.“
    SETX IPGATEWAY /F ipconfig.out /R 0,7 Gateway
    SETX /S System /U Benutzer /P Kennwort /F c:\ipconfig.out /X

Dr. Watson starb unter Vista…

… und es war nicht etwa wieder Prof. Dr. Moriarty :mrgreen:

Wenn man unter Vista einen Crashdump benötigt dann sucht man DRWTSN32.EXE unter Vista vergeblich. Für die Qualitätssicherung sind mir Minidumps immer extrem wichtig.

Es stellt sich die nette Frage: Wie kommt man von einem Kunden dann an einen informativen Minidump, wenn man keinen WER-Account hat, oder das Programm nicht signiert war, oder gar der WER Server diese Dumps nicht anfordert?

Unter Vista ist alles noch einfacher und schwieriger geworden. Vista speichert leider nicht grundsätzlich Minidumps, aber es legt für Crashs unter Problemberichte und Lösungen einen eigenen Eintrag an. Zu Crashs von WER registrierten Programme werden hier evtl. direkt Lösungen oder Updates angeboten. Und auch Crashdumps werden hier mit abgelegt, wenn sie erzeugt werden..

So ist es unter Vista aus:

  1. Das WER System in Vista erzeugt normalerweise nur Minidumps für signierte Programme bzw. wenn der WER Server einen Crash abruft.
  2. Um immer einen Minidump zu erhalten muss in der Registry der folgende Wert gesetzt werden:
    HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ (DWORD)  mit Namen ForceQueue  erzeugen und auf 1 setzen.
  3. Dumps werden im Benutzerverzeichnis unter C:\Users\TheUserName\AppData\Local\Temp und hier C:\ProgramData\Microsoft\Windows\WER\ReportQueue abgelegt und sind meistens gepackt. Sie erhalten die Endung *.mdmp.
  4. Der Zugriff kann ganz einfach erfolgen mit Systemsteuerung -> System und Wartung -> Problemberichte und Lösungen -> Probleme anzeigen und überprüfen
  5. Dort findet man das entsprechende Programm und die dazugehörigen entsprechenden Crashs.
  6. Weitere Infos einfach über Details anzeigen lassen.
  7. Wenn es einen Dump gibt, dann findet man hier wieder einen Eintrag Temporäre Kopie dieser Dateien anzeigen
  8. Damit lässt sich der Explorer öffnen und man erhält Zugriff auf die gespeicherten Daten.
  9. Diese kann man sich nun als Entwickler zusenden lassen.

Siehe auch:

Hotfix für UseMSPrivateAssemblies.h und VC-2008

Einige nutzen ja meine Lösung für private CRT und MFC Assemblies unter VC-2005, die ich in dem diesem Artikel unter Codeproject veröffentlicht habe
http://www.codeproject.com/KB/cpp/PrivateAssemblyProjects.aspx

Das Interesse und die Nachfrage ist groß dieses Verfahren auch unter VC-2008 zu nutzen.
Da ich aber aktuell wenig Zeit habe den Artikel komplett zu überarbeiten, veröffentliche ich den relevanten Code hier erst mal vorab als „Hotfix“. Dieser Hotfix setzt voraus, dass das aktuelle Feature Pack installiert ist. Der Code ist nicht auf die RTM Version hin zugeschnitten und getestet.

UseMSPrivateAssemblies.h

// Version 2.0 by Martin Richter [WWJD]
// Supports VC-2005 and VC-2008
#pragma once    

#ifndef RC_INVOKED
// Avoid problems with the resource compiler if included    

// This defines bock the creation in the header files
#pragma message("Using private assemblies for the MS runtimes")
#define _STL_NOFORCE_MANIFEST
#define _CRT_NOFORCE_MANIFEST
#define _AFX_NOFORCE_MANIFEST
//#define _ATL_NOFORCE_MANIFEST    

// The next statements block the linker from including object files in the
// CRT and the MFC, that would create manifest pragmas too.
#ifdef __cplusplus
extern "C" {            /* Assume C declarations for C++ */
#endif    

__declspec(selectany)       int _forceCRTManifest;
__declspec(selectany)       int _forceMFCManifest;
// __declspec(selectany)    int _forceAtlDllManifest;    

// The next symbols are used by the several versions of VC 9.0
__declspec(selectany)       int _forceCRTManifestRTM;
__declspec(selectany)       int _forceMFCManifestRTM;
__declspec(selectany)       int _forceMFCManifestCUR;    

#ifdef __cplusplus
}                        /* __cplusplus */
#endif    

// We use crtassem.h with the defines there. It just gives us the
// versions and name parts for the dependencies.
// Note that there is also a MFCassem.h but this include file has the
// manifest pragma's already in it. So we can't use it
//
// Three files are controlling this crtassem.h, MFCassem.h and atlassem.h!
// Happily __LIBRARIES_ASSEMBLY_NAME_PREFIX is used in CRT, MFC and ATL!
// Doing it right would need to use _MFC_ASSEMBLY_VERSION for the MFC
// but in fact _CRT_ASSEMBLY_VERSION and _MFC_ASSEMBLY_VERSION and
// _ATL_ASSEMBLY_VERSION are the same
//  - VC-2005 SP1 8.0.50727.762
//  - VC-2008 RTM 9.0.21022.8
//  - VC-2008 Feature Pack 9.0.30411.0 (used if _BIND_TO_CURRENT_VCLIBS_VERSION
//    and _BIND_TO_CURRENT_MFC_VERSION are defined to 1)    

#include <crtassem.h>

// We don't have a seperate block for the Debug version. We just handle
// this with a extra define here.
#ifdef _DEBUG
#define __LIBRARIES_SUB_VERSION    "Debug"
#else
#define __LIBRARIES_SUB_VERSION    ""
#endif    

// Manifest for the CRT
#pragma comment(linker,"/manifestdependency:\"type='win32' "                        \
    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX "." __LIBRARIES_SUB_VERSION "CRT' "   \
    "version='" _CRT_ASSEMBLY_VERSION "' "                                          \
    "processorArchitecture='x86' \"")    

// Manifest for the MFC
#pragma comment(linker,"/manifestdependency:\"type='win32' "                        \
    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX "." __LIBRARIES_SUB_VERSION "MFC' "   \
    "version='" _CRT_ASSEMBLY_VERSION "' "                                          \
    "processorArchitecture='x86'\"")    

// #pragma comment(linker,"/manifestdependency:\"type='win32' "                     \
//     "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".MFCLOC' "                        \
//     "version='" _CRT_ASSEMBLY_VERSION "' "                                       \
//     "processorArchitecture='x86'\"")    

// Manifest for the ATL
// #pragma comment(linker,"/manifestdependency:\"type='win32' "                     \
//    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".ATL' "                            \
//    "version='" _CRT_ASSEMBLY_VERSION "' "                                        \
//    "processorArchitecture='x86' \"")    

#endif // RC_INVOKED

Anmerkungen:

  • Im Endeffekt sind nur 3 Zeilen (26-28) hinzugekommen.
  • Diese Version funktioniert sowohl für VC-2005 als auch VC-2008!
  • Unter Vista wird allgemein das Problem beobachtet, das private Assemblies nur genutzt werden können, wenn diese in einem Unterverzeichnis liegen. Liegen die Assembly Dateien im gleichen Verzeichnis wie die EXE kommt es zu einem Fehler „The application failed to initialize properly (0xc0000034). „ Dieser Sache bin ich (und andere) auf der Spur.
  • Es spielt für diesen Code keine Rolle ob die beiden Defines _BIND_TO_CURRENT_VCLIBS_VERSION und _BIND_TO_CURRENT_MFC_VERSION gesetzt wurden. Werden diese Defines auf 1 gesetzt bevor UseMSPrivateAssemblies inkludiert wird, dann werden die Manifeste so erzeugt, dass die Feature Pack DLLs gezogen werden. Sind diese beiden Defines nicht gesetzt werden Manifeste für die RTM Version erzeugt.
    Ich empfehle dringend diese beiden Defines zu setzen ❗

Das ist erstmal ein Schnellschuss für alle, die die es etwas eiliger haben.

Der Vorteil gegenüber der Lösung, bei der die Manifeste manuell bearbeitet werden, wie es zum Beispiel Jochen Kalmbach in seinem Blog vorgestellt hat ist klar:
Man muss eben nichts manuell machen 🙂
Es macht wieder alles der Compiler und Linker.

Vista Stil bei Tree-Controls und List-Controls

Unter Vista wurden die Tree- und List-Controls noch einmal kräftig aufgemöbelt.
Diesen neuen Look kann man auch in seinen Applikationen nutzen und das mit 2 simplen Codezeilen.

#pragma comment(lib,"uxtheme.lib") 
SetWindowTheme(m_myCtrl.GetSafeHwnd(),L"Explorer",NULL);

Und schon hat man die neue Darstellung des Tree-Controls mit den Dreiecken, die Knotenlinien sind weg.
Beim List-Control hat man nun die hellblaue Färbung mit dem Hover-Effekt.

Vorraussetzung dafür ist, dass auch ein Manifest für die Windows Common Controls Version 6 vorliegt. Dem entsprechend ist SetWindowTheme und die Uxtheme.dll erst ab Windows XP verfügbar. Wer das ganze auch kompatibel mit Windows 2000 haben möchte, der verwendet natürlich das dynamische Laden der Uxtheme.dll und sucht den Einsprungpunkt für SetWindowTheme mit GetProcAddress!

Siehe auch MSDN Doku zu SetWindowTheme

„Elevated“ Programme unter Vista / Windows 7 / Windows 8 / Windows 10 haben auf einmal keine gemappten Laufwerke mehr

Ist man Administrator unter Vista, Windows 7, Windows 8 oder Windows 10 und UAC ist aktiviert, dann existieren technisch zwei Sicherheits -Tokens. Ein Token mit den vollen Administrativen Rechten und ein reduziertes gefiltertes Token, ohne Admin-Rechte.

Wenn man sich anmeldet und Netzwerklaufwerke (Freigaben/Shares) zugeordnet werden, dann erfolgen diese Laufwerksmappings in dem Token mit den reduzierten Rechten.

Startet man nun eine Session mit angehobenen, vollen administrativen Rechten, dann sind die vorher zugeordneten Netzwerklaufwerke in dieser Session nicht sichtbar.
Ein etwas ungewöhnliches aber durchaus logisches Verhalten.
Das Logon Skript läuft eben nicht in dem selben Sicherheitskontext, wie Prozesse, die man mit vollen angehobenen Rechten startet. Defakto sind es wirklich zwei verschiedene Logon’s mit zwei verschiedenen Logon-ID’s.

Mit einem einfachen setzen eines Registry Keys kann man jedoch erreichen, dass auch die angehobenen Admin-Sessions die gleichen Laufwerkmappings erhalten:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections = 1 (DWord)

Aber leider ist dieser Schalter nicht als Standard gesetzt.
Ärgerlich wird dies, wenn man ein kleines Setup-Programm schreiben will, dass einige Daten aus dem Nezwerk kopieren soll und dem man ein entsprechendes requireAdministrator-Manifest gibt. Startet man dieses Programm findet es auf einmal nicht mehr die Laufwerke, die eben noch verfügbar waren. Umgehen kann man das ganze nur in dem man UNC-Dateinamen verwendet.

Beschrieben wird dies auch hier auch in diesem KB Artikel und besonders dieser TechNet Artikel.

Installation von VC6 unter Vista

Es ist ein Anachronismus und ich weiß gar nicht warum ich das hier schreibe. 😉 Aber es gibt doch immer wieder Leute die Visual C++ 6.0 bzw. Visual Studio 6.0 auf Vista installieren wollen.

❗ Grundsätzlich rate ich jedem ab, für Neueintwicklungen VC6 weiterhin zu verwenden.
Dieser Compiler und diese IDE sind überaltert und VC2005 ist ein würdiger und wirklich guter Nachfolger. Was die Änderungen bzgl. Wizards etc. betrifft ist es reine Gewöhnungssache.

Nun aber gib es genug Legacy Code der evtl. einen Bugfix braucht. OK Also wie installiert man dann VC6 auf Vista? Bzw. Geht es überhaupt?
Ja! Es geht.

Wichtig ist, nur, dass man UAC für die Dauer der Installation am Besten komplett abstellt. Es genügt IMHO nicht nur das Setup als Admin zu starten. Das erkennt Vista sowie entsprechend und fordert dazu auf. Also bei mir spielte sich die Installation der Visual Studio 6.0 Enterprise Version in etwa so ab:

  • UAC abschalten (am einfachsten über die System-Steuerung) und den Rechner neu starten.
  • Nun unbedingt einen Account verwenden der lokaler Admin ist (Aber das war jedem klar, oder?)
  • VC6 Installation starten. Die nette  Meldung über bekannte Kompatibilitätsprobleme nehmen wir dankbar zur Kenntnis.
  • Jetzt wird evtl. die VM für Java aktualisiert und neu gestartet (was sonst).
  • Zwischendrin erfolgt noch mal eine Warnung über bekannte Kompatibilitätsprobleme die wir wieder gerne quittieren.
  • Nun dürfen wir wie gewohnt installieren. Man kann sich die Data Access Components übrigends sparen. Meistens sind sowieso schon neuere Versionen auf dem Rechner. Gleiches würde ich mit den SDK Tools machen. Diese alten Tools machen manchmal auch Ärger beim registrieren.
  • Irgendwann kommt manchmal noch eine Frage nach den JIT-Debugger  settings, am Besten auch die nicht verändern.
    Und wie gewohnt erfolgt ein Neustart der Maschine am Ende der Installation.
  • Danach VC6 SP6 installieren und Rechner neu starten (was sonst).
    Für SP5 muss man etwas hexen, aber es geht mit Tricks auch.
  • Danach UAC wieder einschalten, und es erfolgt der nächste Neustart 😉


Anmerkungen ❗

  • Der Standard Pfad zum Anlegen der Projekt sollte natürlich nicht verwendet werden. Der liegt dämlicherweise ja unter C:\Program Files, aber ich gehe auch hier davon aus, dass dies logisch ist…
  • Beim ersten Start des Compilers und einiger Tools kommen wieder Meldungen über Kompatibilitätsprobleme (vcspawn.exe, rc.exe), diese schalten wir für immer aus.
  • Man sollte VC6 übrigends auch nicht nach VC2005 installieren. Andernfalls muss man VC2005 einer Reparaturinstallation unterziehen. Einige der Registrierungen für den Explorer werden sonst überschrieben und arbeiten nicht mehr korrekt. Aber das ist ja bei allen Installationen von mehreren VS Versionen schon so gewesen. Immer nacheinander installieren beginnend mit der ältesten Version!

Danach arbeitet VC6 ohne Murren. Wenn man möchte kann man für VC6 (devenv.exe) sogar manuell ein Vista Manifest geben, indem man die entsprechende devenv.exe.manifest Datei erzeugt. Nach Geschmack setzt man requireAdministrator oder asInvoker. Für bestimmte Fälle beim Debuggen bietet sich hier requireAdministrator an.

Die Manifest Pest…

Hier noch mal ein paar wirklich nette Sachen, die zeigen warum ich Manifeste mittlerweile  nicht mehr ganz so mag (um es wirklich vorsichtig auszudrücken):

Was passiert eigentlich wenn man ein internes UND ein externes Manifest zu einer DLL oder EXE hinzufügt?

  1. Auf einem XP Rechner wird der Lader das externe Manifest bevorzugen, das interne Manifest wird ignoriert.
  2. Auf einem Windows 2003 oder Vista Rechner wird das interne Manifest bevorzugt und das externe Manifest wird ignoriert.
  3. Handelt es sich um eine DLL die mit LoadLibrary geladen wird, dann wird niemals ein externes Manifest berücksichtigt, selbst wenn kein internes Manifest vorliegt. Hier verhalten sich XP, 2003 und Vista gleich.

Ein Grund mehr zu meiner Empfehlung: Verwende immer nur interne Manifeste!

Wie einen Prozess unter Vista mit gehobenen Rechten starten?

Was macht man eigentlich wenn man einen Prozess unter Vista hat, der mit normalen Rechten arbeitet, nun aber einen Prozess starten möchte, der angehobene Rechte (elevated) benutzen soll? Also quasi eine Abkürzung für „rechter Mausklick -> Als Administrator ausführen“.

Das ist ausgesprochen einfach! Man verwendet ShellExecute oder ShellExecuteEx mit dem neuen Verb „runas“.

Der nachfolgende Code startet die Systemsteuerung mit angehobenen (administrativen/elevated) Rechten. Vorher erfolgt natürlich die allseits bekannte UAC Nachricht. Ist der User kein Administrator bekommt er eine Meldung, dass er sich entsprechend anmelden soll. Ansonsten muss er dem Zugriff zustimmen. Bricht der User den Dialog ab wird nichts ausgeführt.

int _tmain(int argc, _TCHAR* argv[])
{
  SHELLEXECUTEINFO shExecInfo;
  
  shExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);
  shExecInfo.fMask = NULL;
  shExecInfo.hwnd = NULL;
  shExecInfo.lpVerb = _T(„runas“);
  shExecInfo.lpFile = _T(„control.exe“);
  shExecInfo.lpParameters = NULL;
  shExecInfo.lpDirectory = NULL;
  shExecInfo.nShow = SW_SHOW;
  shExecInfo.hInstApp = NULL;
  
  ShellExecuteEx(&shExecInfo);
  return 0;
}

❗ PS: Übrigens versteht auch Windows 2003 Server und Windows XP das „runas“ Verb. In diesem Fall wird der entsprechende Anmeldedialog gezeigt, der es erlaubt den aktuellen Benutzer zu verwenden (mit evtl. eingeschränkten Rechten), oder eben einen anderen Account. Nett! 🙂
Nur scheinbar auch ein Feature, dass wieder mal nicht dokumentiert ist.

Bug in CPropertyPage und „Certified for Vista“

Der von mir gemeldete Bug Bug in der MFC71.DLL bzgl. CPropertySheet/CPropertyPage führt dazu, dass ein Programm, dass den genannten Voraussetzungen entspricht, bei den Test für „Certified for Vista“ durchfällt!

Der Application Verifier führt bei den Basic Test einen Page Boundary Check durch. Dabei werden alle Allokationen so durchgeführt, dass sie immer am Ende einer Memory Page erfolgen. Jeder Zugriff über die Grenze hinweg führt dann zu einem Crash.

Im realen Leben ist der Crash wirklich selten, aber mit dem Application Verifier kracht es sofort. Das Problem ist, dass dieser Basic Test Bestandteil von „Certified for Vista“ ist.

Die Folge man rasselt mit 100% Sicherheit durch!

Bug Report hier:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=270493

Dämlicherweise wurde auch dieser Bug von Microsoft als „Gelöst (Nicht reproduzierbar)“ markiert. Da kann man wirklich nurmit dem Kopf schütteln.

Und ein kleines Demo findet ihr hier:
Testprogramm für CPropertyPage Bug in MFC 7.1