Ich sehe das ganze so (obwohl auch ich noch nicht alles durchschaue) :
die
WinAPi ist mittlerweile eine Sackgasse. Wobei die Betonung auf mittlerweile liegt. Im Laufe der Zeit kam immer mehr dazu, versionsabhängig usw. Dafür die Unmenge an Service-Packs usw.
Wie heißt es so schön ? "Viele Köche verderben den Brei". Und in der Programmierung handelt es sich sogar um eine weltweite Küche. Jeder kann da einen Teil des Gesamtmenüs so kochen, wie er will. Vor allem aber darf er sämtliche Zutaten verwenden, die er kennt.
Das ist für mich das wichtigste. Leider gibt es nämlich auch welche, die das ganze schöne, offene Gebilde ohne Ankündigung mit etwas Gift versetzen. EXE ist eben EXE. Da helfen nur Virenscanner u.Ä. Die haben aber den Nachteil, daß sie im Prinzip zu spät reagieren und nicht automatisch aktuell sind.
Im Prinzip müßte man das ganze Betriebssystem neu programmieren, um solchen Sachen von vorneherein Einhalt zu gebieten. Und das ist nun das Dilemma von M$. Wegen der großen Verbreitung geht das nicht ! Liebend gerne würden die jedem Windows Benutzer ein neues Betriebssystem verkaufen.
Aber sogar verschenken ginge nicht, denn wer weiß wo noch irgendwo ein Uralt-Rechner mit einem wichtigen Programm läuft.
Die Treiber für zigtausende Uralt-Hardwareteile neu programmieren ? Geht wohl auch nicht. Also muß man mit den vorhandenen Gegebenheiten vorlieb nehmen.
Die logische Folgerung ist dann, die Programmwelt zweizuteilen. .NET Programme und der Rest so wie bisher. Vorerst ist das natürlich nichts halbes und nichts ganzes. Aber das kann es (irgendwann) noch werden. In der Praxis bedeutet das, daß für neue .NET Programme ein Zusatz gebraucht wird : das .NET Framework. Mit D8 geschriebene Programme z.B. laufen nämlich nur mit installiertem .NET-Framework.
Im Prinzip laufen die eigentlich gar nicht, zumindest nicht von alleine. Die Zeiten lauffähiger EXEs so wie gewohnt ist dann vorbei. Heißen die dann überhaupt noch EXE ?
Denn : erst durch einen JIT (Just in time) Compiler werden sie zu einem lauffähigen Programm. Es scheint die einzige Möglichkeit zu sein, einen Virus zu 100 % auszuschalten. Denn es wird erst ein Programm ausgeführt, wenn es der JIT-Compiler zuläßt. Werden genau an diesem Punkt geeignete Vorsichtsmaßnahmen getroffen, so kann (theoretisch) eigentlich nichts mehr passieren.
Folgende Nachteile bringt das mit sich : wie gesagt wird das Programm nochmals compiliert. Delphi-"Compilierung" alleine reicht nicht mehr ! Außerdem die Sicherheitsüberprüfungen des Codes. Deshalb die "Lahmheit". Ich würde aber sagen, daß man das in Kauf nehmen kann. Ich glaube, das passiert nur beim erstmaligen starten.
Wegen der ausgeuferten
WinApi und deren Sicherheitslöcher muß für Ersatz gesorgt werden. Die muß weg und was besseres neu programmiert werden. Das sind die WinForms. Sehen für mich schon wesentlich besser aus, als die
WinApi. Da wurde auch vieles reingepackt, was es vorher nicht gab. Einige Fremdkomponenten sind nicht mehr nötig. Für jetzige
Winapi Programme hat das ganze auch noch den Effekt, daß sie später mit Longhorn so laufen, wie unter Win die Dos-Programme. Also nur in einer Emulation. Und ein .NET Programm läuft natürlich nicht ohne installiertes .NET.
Fazit aus meiner Sicht : von außen sichtbare wichtige Veränderungen wird es kaum geben, hinter den Kulisssen um so mehr. Ich werde deshalb auf
WinApi-Zugriffe, wenn es irgendwie geht verzichten. Auf gar keinen Fall werde ich bewußt, so wie einige hier, ein
nonVCL Programm machen. Niemals.
Was jetzt noch an Fragen offen bleibt, ist vor allem die
VCL.NET. Jemand hat behauptet, die würde immer noch
WinApi Aufrufe benutzen. Insofern wäre es unmöglich damit ein reines .NET Programm hinzukriegen. So ganz glaube ich das aber nicht.