Hey, wo ist meine Exception hin?

Ich hatte kürzlich den Fall eines Programms, welches munter mit einem uninitialisierten Pointer hantierte und trotzdem keine Exception auslöste oder von Windows gestoppt wurde. Die tl;dr-Version des Resultats meiner darauf folgenden Abklärung: Wenn 32bit-Programme unter einem 64bit-Windows laufen, werden unter gewissen Umständen Fehler wie ungültige Zugriffe auf Speicher einfach verschluckt. Der Stack wird abgebaut und das Programm läuft weiter, unklar an welcher Stelle, in einem wahrscheinlich inkonsistenten Zustand. Es sieht so aus, als könne man im Moment nichts dagegen unternehmen.

Die lange Version meiner Geschichte:

In unseren „native“ d.h. C++-Programmen haben wir bei Windows mit Hilfe des WIN32-API-Aufrufs SetUnhandledExceptionFilter eine Prozedur installiert, welche sämtliche Laufzeitfehler melden und in einem Log auf Disk vermerken soll.

Beim eingangs erwähnten Fehler mit einem ungültigen Pointer wurde diese Prozedur allerdings nicht aufgerufen, und es passierte mit und ohne Debugger gleichermassen folgendes: Der Fehler wurde verschluckt und das Programm fuhr fort, jedoch an einer unklaren Stelle (Step Into und Step Over im Debugger versagten beide, so dass man nicht sah, wo), in einem ziemlich „wackeligen“ internen Zustand.

Nach einigem Googlen fand ich dann den folgenden Blog-Eintrag: The case of the disappearing OnLoad exception.

Dieser bestätigt: Wenn während der Ausführung eines 32bit-Programms auf einem 64bit-Windows die Prozeduraufrufe so geschachtelt sind, dass es „zwischendurch“ Prozeduren von Windows selbst hat, z.B. wenn man sich in einer eigenen WindowProc befindet, und dann ein Fehler passiert, wird dieser verschluckt.

Als Lösung wird beschrieben, man solle sein Programm per Manifest explizit als unterstützt Windows 7 markieren. Wie genau sich das Programm verhalten soll, wenn man das macht, wurde mir anhand der Ausführungen im Blog-Eintrag nicht ganz klar, aber auf jeden Fall werden Fehler offenbar nicht mehr einfach ignoriert.

Ok, hab‘ ich ausprobiert, eine solche Markierung ist ja nicht schwierig, wie Microsoft hier beschreibt. Resultat: Keine Änderung.

Ich vermute, der Grund dafür ist diese Geschichte: Application Manifest may be ignored in Windows 7 x64: Man kann zwar sagen, man unterstütze Windows 7, aber ein 64bit Windows 7 lässt das 32bit-Programm unter Umständen trotzdem nur als Windows Vista laufen, und da werden Fehler offenbar noch ignoriert.

Es gab zwar einmal einen Hotfix, um dieses Problem zu beheben, aber der will auf meinem Windows 7 SP1 nicht installieren, der Hotfix aus dem Jahr 2010 ist wohl nur für Windows 7 „pur“.

Mir scheint, hier verheddert man sich prächtig in einem Gestrüpp von Windows-Fehlern und -Unzulänglichkeiten; auf jeden Fall habe ich bis jetzt keine Verbesserung hingekriegt.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »

.NET als Nachfolger von Win32

Kürzlich kam mir Petzolds Original-„Hello World“ für Windows in C wieder mal in die Hände. Als ich so am Staunen war über die Schönheit des Win32-API in seiner unverfälschten, puren Form, erinnerte ich mich daran, dass vor nicht allzu langer Zeit ziemlich heftig darüber spekuliert worden ist. Man fragte sich, ob Microsoft .NET nicht nur baut, damit wir Applikationsprogrammierer etwas produktiver werden, sondern um mittelfristig Win32 abzulösen und damit die gesamte Windows-Programmierung auf das nächste Level zu heben: das .NET-Framework als das neue Windows, zumindest was das API angeht.

Das hat meine Neugierde geweckt, und ich habe etwas recherchiert, wie es unterdessen um diese Spekulationen steht.

Per Google findet man relativ leicht heraus, dass der Höhepunkt dieses „Memes“ so um 2003/2004 herum gewesen sein muss, als die Gerüchte ins Kraut schossen, wie wohl das neue Windows Code-Name Longhorn aussehen würde. Von grossen, in .NET implementierten Betriebssystem-Teilen war die Rede. Und in diesem Longhorn FAQ, das offenbar als seriös genommen werden will, findet man folgende Aussage: „In the technology generations leading up to Longhorn, Microsoft has been moving to a .NET-based managed code environment dubbed WinFX, and the Longhorn generation will finally mark a clean split with the Win32 APIs of the past.“

Es ist mir hingegen nicht gelungen, unter Stichworten wie future windows API interessante aktuelle Informationen zu finden. Vielleicht hat ja Microsofts lange und schmerzreiche Schwangerschaft mit Windows Vista zu einer gewissen Ernüchterung geführt, wie schnell man Win32 ablösen könnte und wie gross der Aufwand dafür wirklich wäre.

In einer Diskussion aus dem Jahre 2004 stiess ich noch auf folgendes Argument, das mir heute noch relevant scheint und das ich ganz interessant fand: Microsoft verdient bekanntermassen nur mit 2 Dingen richtig massig Geld, einerseits mit Windows selbst, und andererseits mit Office. Die Office-Programme basieren auf Win32. Wenn also Microsoft mit .NET als Win32-Ablösung wirklich ernst machen will, ohne eine der beiden „cash cows“ zu verlieren, müsste sie einen kompletten Rewrite der Office-Programme ins Auge fassen. Von einem solchen ist nichts bekannt.

Aber wie dem auch sei, ob nun Microsoft etwas zu hoch gezielt hat ursprünglich oder nicht, gedeiht das .NET-Framework prächtig, und es kommt wohl kaum mehr jemandem in den Sinn, ein normales Applikationsprogramm auf Win32 aufzusetzen.

Dass das Framework unterdessen durchaus das Zeug hätte, als Windows-Programmieroberfläche zu fungieren, sieht man übrigens an der PowerShell, die ja mit Hilfe von .NET implementiert worden ist.

Zu guter letzt noch ein paar Links: ein Artikel von Joel Spolsky aus dem Jahre 2004 (immer noch lesenswert, falls man ihn nicht schon kennt), und die Website The Old New Thing mit manchmal geradezu abenteuerlichen Geschichten über die Entstehung gewisser Dinge rund um Win32, etwa diese Story mit dem Titel What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »