Notwendigkeit von Manifesten für DLL’s mit VC-2005

Durch eine Anfrage in meiner Lieblingsgruppe microsoft.public.de.vc bin ich auf folgende interessante Frage gestoßen: Benötigt eine DLL die mit VC-2005 erzeugt wurde ein Manifest?

Nun wie viele Antworten im Leben lässt sich dies nicht eindeutig mit Ja oder Nein beantworten.

Nein! Es wird kein Manifest benötigt, wenn die CRT statisch gelinkt wird. In diesem Fall wird auch kein Manifest benötigt zumindest nicht für die CRT, was nicht heißt, dass nicht auch andere Assemblies per Manifest angebunden werden müssen.

Nein! Wenn die EXE-Datei bereits über ein Manifest verfügt und eine CRT-DLL mit gleichem Namen lädt, hier also z.B. die MSVCR80.DLL. In diesem Fall kann man sich ein Manifest sparen. Es kann aber hier spannend werden, weil die entsprechende DLL natürlich so nicht beeinflussen kann dir 8.0 CRT als SP1 oder RTM zu nutzen. Aber vermutlich ist das sowieso egal.

Ja! Die DLL benötigt ein Manifest, wenn ein beliebiges Programm die DLL nutzt. Zum Beispiel eines, das die CRT statisch linkt, oder das mit einer älteren VC Version erzeugt wurde. In diesem Fall muss die DLL zwingend ein Manifest haben. Und jetzt wird es noch strenger. Wird die DLL per LoadLibrary geladen, dann muss dieses Manifest sogar embedded sein! 🙄
Externe Manifeste bei DLLs werden nur beim impliziten Laden berücksichtigt. Wird eine DLL mit LoadLibrary geladen, dann werden nur eingebette Manifeste berücksichtigt.

❗ Falle: Hat die DLL kein Manifest wird immer garantiert, dass die CRT Version von EXE und DLL passen. Man kann also gefahrlos Speicher in der DLL allozieren und in der EXE freigeben und umgekehrt. Oder eben auch CRT Objekte austauschen. Nutzt die DLL ein eigenes Manifest besteht die Möglichekit, dass EXE und DLL eine unterschiedliche CRT verwenden! Und noch spannender wird es wenn eine EXE mit CRTx eine DLL1 benutzt die per Manifest CRTy verwendet und diese nun eine DLL ohne Manifest lädt… Ja es wird die CRT der EXE verwendet…

Ja ja. Wir haben dank der Manifeste nun keine DLL Hölle mehr. Wir haben eine Manifest Hölle 😀

Meine Empfehlung daher:

  1. Wenn es eigenständige kleine Module sind, dann statisch gegen die CRT linken.
  2. Ansonsten immer ein Manifest einbetten, wenn die DLL eigenständig genutzt wird!
  3. Wird die DLL im Kontext einer bestimmten EXE(s) Datei verwendet, sollte nur die EXE(s) ein  Manifest haben.
  4. In jedem Fall darauf achten, dass gleiche CRT Versionen verwendet werden. RTM, SP1 und irgendwann wahrscheinlich SP2 werden hier Konflikte möglich machen.
  5. MFC Extension DLLs müssen zwingend mit der selben MFC Version (RTM oder SP1) verwendet werden!

Stoff zum weiterlesen:
Isolated Applications and Side-by-side Assemblies

Besonders lesenswert hier der Beitrag von Nicola Dudar:
How to Debug ‚The System cannot Execute the specified program‘ message

Der Tod der Power User…

Nein, es ist kein neuer Horror-Thriller im Kino. Und wir beklagen auch nicht den tragischen Tod einer aktiven Gruppe von Nutzern meiner Software.

Die Gruppe Hauptbenutzer/Power User habe ich gerne auf benutzt um erweiterte Rechte für Entwickler zu geben. Ein Entwickler war damit eben kein Administrator, aber zumindest hatte er Schreibzugriff auf HKEY_LOCAL_MACHINE oder eben auch auf C:\Programme.
Installationen waren damit dann auch kein Problem. Auch zu Hause habe ich meinen Kiddies auch gerne dieser Gruppe zugeordnet. Admin’s waren sie dann keine, aber sie hatten weitgehende Freiheiten.

Wir finden die Hauptbenutzer/Poweruser Gruppe zwar noch in der Benutzer- und Gruppenverwaltung mit dem Kommentar: „Hauptbenutzer sind eingeschlossen aus Gründen der Rückwärtskompatibilität, sie besitzen eingeschränkte administrative Rechte“! Aber das stimmt nicht!

Die Hauptbenutzer/Poweruser Gruppe ist endgültig aus allen Vorgaben in Vista verschwunden.
In den Benutzerrechten für die Registry und C:\Programme finden sich keine vorgefertigten Einträge mehr. Einen Benutzer zum Power User zu machen hat keinen Effekt mehr. Ja schlimmer noch, ein Hauptbenutzer ist nun nicht mal mehr mit Rechten der Gruppe Benutzer ausgestattet.
Wenn, müsste eben selber Hand anlegen. Aber wer will das schon, also machen wir alle ehemaligen Hauptbenutzer zu Administratoren… ob das wohl der Weisheit letzter Schluss ist 😉

Die Power User fristeten ja sowieso schon immer ein nur begrenzt unterstütztes Dasein. Ich hatte mich schon immer geärgert, dass sie nicht automatisch über die Domänen verwaltbar waren. Hier gibt es eben nur Unterstützung für Domänen-Admins, Domänen-Benutzer, Authenifizierte Benutzer etc.

Nun denn… lasst uns trauern, jetzt haben Sie alle unter Vista das Zeitliche gesegnet.

Der VirtualStore und seine Schattenseiten

Es ist ja bekannt, dass Programme, die nicht mit einem entsprechenden Trustinfo Manifest ausgestattet sind, unter Vista besonders behandelt werden. Werden diese Programme nicht im administrativen Rechten ausgeführt werden alle Zugriffe auf das Verzeichne C:\Program Files und auf HKEY_LOCAL_MACHINE\Software in der Registry umgeleitet.

Ein Registry Zugriff landet dann in HKEY_CURRENT_USER auf HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE. Ein Dateizugriff auf C:\Program Files wird umgeleitet nach C:\Users\Username\AppData\Local\VirtualStore\Program Files.

Was passiert aber nun, wenn der Administrator nun tatsächlich die „richtigen“ Daten in HKLM und C:\Program Files ändert UND es existieren bereits entsprechende Daten im VirtualStore?

Die Antwort ist logisch! Eine Änderung der Daten bleibt ohne Wirkung! Denn die Daten aus dem VirtualStore werden hier mit Vorrang behandelt. Sonst macht das ganze ja keinen Sinn, denn der VirtualStore soll ja scheinbar Schreibzugriffe erlauben.

Im Klartext: Existieren Daten sowohl im VirtualStore als auch in den eigentlichen originalen Positionen, dann werden immer die Daten des VirtualStore verwendet. Nur wenn der entsprechende Registry Key nicht vorhanden/gelöscht wird oder die entsprechende Datei nicht vorhanden/gelöscht ist, dann werden die Daten aus den original Verzeichnissen bzw. Registryästen verwendet.

Nur daraus folgt ein Problem:
Macht der Admin Korrekturen an den realen Daten UND es existieren Daten im VirtualStore, dann bleiben die Änderungen des Admins wirkungslos, bis er die Daten aus dem VirtualStore entfernt. Das kann eine spannende Aufgabe werden.
Vielleicht ist dies eine profane Erkenntnis, aber die Implikationen sind meines Erachtens immens.

PS: Gemein ist einfach, dass Software die bisher mit einer Fehlermeldung gerechnet hat, wenn ein Schreibversuch nach HKLM oder C:\Program Files erfolgte, nun auf einmal erfolgreich schreiben kann. Da kann man sich noch so sehr an alle Empfehlungen halten, hier wird man von Vista reingelegt und man muss schleunigst das entsprechende Trustinfo Manifest nachrüsten.

Was mit Visual Studio 2005 SP1 unter Vista zu beachten ist

Ganz Allgemein hier eine kleine Sammlung wertvoller Links für die Nutzung von Visual Studio 2005 unter Vista. Besonders der zweite Link ist wichtig nach meiner Meinung.

Installationshinweise:
http://support.microsoft.com/kb/929470/en-us

Visual Studio 2005 on Windows Vista Issue List – Running with normal user permissions http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx

Visual Studio 2005 on Windows Vista Issue List – Running with elevated administrator permissions http://msdn2.microsoft.com/en-us/vstudio/aa964140.aspx

Microsoft SQL Server Management Studio Express auf Vista schlägt fehl. Fehler 29506

Fehlermeldung 29506Ich wollte mir das Microsoft SQL Server Management Studio Express auf Vista installieren. Aber während der Installation erhielt ich die folgende Fehlermeldung:

Bei der Installation dieses Pakets ist ein unerwarteter Fehler aufgetreten. Es liegt eventuell ein das Paket betreffendes Problem vor. Der Fehlercode ist 29506.

Und nun? Man sollte doch annehmen, dass eine MSI-Datei sich installieren lässt und auch im Admin-Modus installiert wird. Pustekuchen.

Es geht doch, mit einem Trick:

Man starte eine Console im Admin-Modus: Rechtsklick auf die Verknüpfung und Als Administrator ausführen wählen. Dann von dort die entsprechende SQLServer2005_SSMSEE.msi aufrufen. Dann läuft das Setup ohne Fehler durch.

Langsam habe ich das Gefühl, dass dieses Verfahren zur Installation unter Vista grundsätzlich zu empfehlen ist. Leider kann man MSI-Pakete nicht direkt über ein Kontextmenü im Admin-Modus installieren.
Das wäre was für Vista SP1 😉

Nachtrag 22.08.2009:
Das Problem betrifft auch die Installation unter Windows Server 2008 als auch Windows 7, sofern UAC eingeschaltet ist. Das MSI Paket muss in jedem Fall als Admin (elevated) gestartet werden.

Remote debugging mit MSVCMON im Pipe-Mode auf Vista

Man sollte meinen, dass MSVCMON (aus VS.NET 2003) im Pipe Modus unter dem selben User Account sofort funktionieren sollte. Aber dem ist nicht so.

Normalerweise melde ich mich an der Entwicklungsmaschine und dem Remote-PC auf dem gedebuggt werden soll mit dem selben Benutzernamen an. Wird MSVCMON nun ohne Parameter auf dem Remote Computer gestartet kann man normalerweise sofort eine Verbindung herstellen.
Nicht so unter Vista. Dort bekommt man beim Versuch eine Verbindung herzustellen sofort die Meldung: „Unable to connect to ‚DEV-VISTA‘. Zugriff verweigert“, oder auf einem englischen OS „access denied“.

Nach vielem hin und herspielen und dem Versuch MSVCMON im Administrator-Modus zu starten bin ich auf die Lösung gekommen.

Gibt man direkt noch einmal mit dem -u Parameter den gewünschten Usernamen an, dann erlaubt Vista auch den entsprechenden Zugriff.
Also so gestartet MSVCMON -u MeineDomain\MeinUserName hat man keine Probleme und man kann in gewohnter Weise eine Remote Debug-Session starten und auch unter Vista elementar einfach die Programme debuggen.

PS: Es geht in diesem Artikel natürlich um das Debuggen von nativen Programme, sprich unmanaged Code.

ATI Radeon 200M als Bremse in Vista

R40-T5500 CinosoJetzt bin ich doch etwas von meinem kleinen Laptop-Flitzer enttäuscht.
Samsung R40-Cinoso, mit Core 2 Duo T5500, 1GB Ram, 100GB Festplatte, ATI Radeon 200M

Ein Geschoss, so kam es mir jedenfalls vor. Jedenfalls etwas, was man sich auch leisten kann. Der Vista-Leistungsindex hat mich aber etwas ernüchtert. Gerade die oftmals gepriesene ATI Radeon 200M ist hier die Bremse, so der Vista Leistungsindex.

Vista Leistungsindex im Detail:
Prozessor: 4,7
Arbeitsspeicher: 3,5
Grafik (Desktop Aero): 2,3
Grafik (Spiele): 3,0
Festplatte: 4,6

Gesamtnote: 2,3 (als niedrigster Wert aus allen Bereichen)

Ich schiebe das mit der 2,3 mal auf den Beta-Treiber. Vielleicht liefert der neue finale Treiber dann doch etwas bessere Werte.

Allerdings ist diese 2,3 nur eine gefühlte Langsamkeit. Der Laptop ist flink leise, der Lüfter springt kaum an, und selbst im herunter getakteten Silentmode arbeitet er perfekt.

PS: Die 1GB waren mir unter XP schon etwas knapp. Ich habe deshalb vor, in absehbarer Zeit, einen der 512KB Riegel gegen einen 1GB Riegel auszutauschen. Dann wird aus dem 1GB 1,5GB Hauptspeicher. Ob das noch mal etwas Speed bringt ;-), zumindest wird es VS2005 beflügeln.

Vista ist ein nettes Spielzeug das ich nicht mehr weggeben will

Mein Vista Desktop

Die ersten Gehversuche in meiner Firma haben mich verleitet, meinen Laptop (Samsung R40-Cinoso, Core 2 Duo T5500 mit 1GB Hauptspeicher) platt zu machen. Nun läuft Vista Ultimate drauf. Zwar nur mit dem ATI Radeon 200M Beta Treiber, aber er läuft bisher stabil.

Alle anderen Treiber sind bereits final. Sogar für den eingebauten WLAN Adapter habe ich sofort einen neueren Treiber gefunden. Der alte hat die Empfangsstärke immer als ausgezeichnet angegeben was er definitiv nicht war. Der neue Synapsis Touchpad Treiber tut auch perfekt seinen Dienst.
Leider ist Samsung noch nicht so weit und kann Magic Keyboard für Vista liefern. Ich habe die XP Version mit einigen Tricks mal gerade so zum laufen gebracht.

Erstes Fazit. Man kann sich an Vista komplett gewöhnen.

  • Besonders der neue Explorer ist einfach um ein vielfaches besser als der XP-Explorer. Durch die neue Navigationsleiste wird Verzeichniswechsel zum Kinderspiel.
  • Die Suche im Startmenü erlaubt blitzschnelle Dokumenten und Programmauswahl.
  • Auch ansonsten macht Aero einen sehr angenehmen Eindruck. Keineswegs verspielt sonder eher natürlich erscheint einem dieser neue Look & Feel.
  • Malus: VS2005 muss letzten Endes im Admin-Modus gefahren werden. Das erzwingt aber immer auch Bestätigung das ich als Anwender das auch will. An dieser Stelle etwas lästig.
  • Vista läuft auf diesem Laptop viel runder und gleichmässiger als vorher auf XP. Gut er ist auch nicht schwach auf der Brust, aber der erste Eindruck ist einfach um Klassen besser.

Ansonsten laufen auf dem Laptop aktuell folgende Programme ohne Probleme:

  • VS 2005 SP1
  • Visual Assist X, Natürlich! Ohne dieses Ding kann ich VS schon nicht mehr bedienen 🙂
  • Office 2007 Ultimate 
  • Textpad 4.7.3
  • 4NT 8.0 Build 66
  • Trillian 3.1
  • iTunes 7.02 mit Quicktime entsprechend
  • Adobe Reader 8.0
  • Trillian 3.1
  • Thunderbird 1.5.0.9
  • Dazu einige uralte Spiele, die meine Tochter gerne spielt: HyperballoidCE, Pacboy, Zoo Tycoon2 etc. alle laufen ohne Probleme!

Es scheint sogar so zu sein, dass sogar Spiele, die unter Windows 2000 und XP ihren Dienst verweigert haben, wenn man diese nicht als Admin spielte nun ohne weiteres durch das neue UAC sofort spielen kann! Genial!

Ich möchte Vista nicht mehr hergeben!!!
Und werde wohl alsbald meinen Desktop wohl auch platt machen und Vista drauf packen.

Vista und die Notwendigkeit eines Manifestes für die UAC

Bei den vorbereiten von Software für Vista (Certified for Vista) ist mir die UAC (User Access Control) untergekommen. Unter Vista verschärft sich das ganze noch einmal gegenüber Windows 2000.

Einen der wichtigsten Punkte möchte einfach mal hier darlegen.
Unsere Software ist so geschrieben, dass ein Admin entsprechende Einstellungen in bestimmten Dateien im Programmverzeichnis ablegen kann und auch Einstellungen vornehmen kann die in HKLM abgelegt werden. Unter anderem dienen diese Dateien/Registry Einstellungen eben zur Kontrolle von Services und IPC. Sie müssen eben in einem allgemein zugänglichem Bereich liegen. Das ist ja nichts ungewöhnliches.

Brav wie wir sind haben wir entsprechende Prüfungen eingebaut und sagen dem Anwender, wenn er keine Rechte hat in HKLM zu schreiben, oder die entsprechenden Dateien im Programmverzeichnis zu ändern, z.B. INI Dateien die mit WritePrivateProfileString geschrieben werden.

Vista ist es nun egal, dass wir brave Entwickler sind. Vista behandelt uns per UAC Richtlinie wie einen Bösewicht und leitet alle Änderungen in den lokalen Bereich des Anwenders. Meine Software hat keine Chance zu erkennen, dass das schreiben in HKLM und den Programm-Datei Ordner eigentlich nicht erlaubt ist.

Man muss also zwingend ein Manifest für die UAC hinzufügen:

<?xml version=“1.0″ encoding=“utf-8″?>
<assembly xmlns=“urn:schemas-microsoft-com:asm.v1″ manifestVersion=“1.0″>
  <trustInfo xmlns=“urn:schemas-microsoft-com:asm.v3″>
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level=“asInvoker“ />
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

Erst mit diesem Manifest verhält sich meinem Programm wieder so, wie ich es auch erwarte!

Eine gute Anleitung hierfür:
– How To: Tell Vista’s UAC What Privelege Level Your App Requires
http://channel9.msdn.com/Showpost.aspx?postid=211271

Weitere Infos, Dokus und Hilfsprogramme:
– Understanding and Configuring User Account Control in Windows Vista
http://technet.microsoft.com/en-us/windowsvista/aa905117.aspx
– Windows Vista Application Development Requirements for User Account Control Compatibility
http://www.microsoft.com/downloads/details.aspx?FamilyID=BA73B169-A648-49AF-BC5E-A2EEBB74C16B&displaylang=en
– Microsoft Application Verifier
http://www.microsoft.com/downloads/details.aspx?familyid=BD02C19C-1250-433C-8C1B-2619BD93B3A2&displaylang=en
– Microsoft Standard User Analyze
http://www.microsoft.com/downloads/details.aspx?familyid=DF59B474-C0B7-4422-8C70-B0D9D3D2F575&displaylang=en