Keine Zukunft für Win32Api, wenn .NET Standard wird?

[graphicar]

Schönen guten Abend,

ich habe heute in einem Gespräch mit einem alten Bekannten einiges über diese für mich
neue, aber im Programmierbereich allseits bekannte .NET-Technologie unterhalten. Er
schreibt als Angestellter teils mit der Delphi 8.0 Version Programme auf Basis von .NET.

Ich selber habe mich nie viel um das ganze .NET-Gerede gekümmert. Ich habe es schlicht
als Marketing und simple Erweiterung vorhandener Standardbibliotheken (bspw. der MFC/VCL)
abgehandelt. Nun wurde mir aber durch seine Erzählungen bewusst, dass die .NET-Technologie
ein neues Grundgerüst für die Programmierung in einem Betriebsystem bzw. in den kommenden
Betriebsystemen darstellt.

Das heißt, die API wird eingestellt und durch das neue, zeitgenössische .NET ersetzt.
Demnach würden althergebrachte Win32Api-Programme nicht mehr lauffähig sein. Er meinte,
das M$ sicherlich Emulatoren für ältere Sopftware liefern würden, doch wenn man sich
die Assembler-Hardware-Ecke anschaut, so haben M$-Ideen & -Vorschläge meist geringere
Funktionalität und bringen demnach auch nicht viel. Verständlich, wenn man bedenkt, wie
alt das Prinzip der Win32Api und wie uralt DOS-Programmierung ist.

Nun stellt sich mir ein Konflikt, da ich selber die letzten Monate mich intensiv mit dem
Thema der API beschäftigt habe. Ich habe zwei Projekte am Laufen, mein aktuelleres ist ein
Modeller auf OpenGL-Basis (9 Units, 2400 Zeilen, 30.5 KB) und ich würde den gerne über einen etwas
längeren Zeitraum nutzen. Wenn man gezwungen wird durch ein neues OS, auf die API zu ver-
zichten, dann kann man sicherlich nicht seine alten Quellcodes übernehmen - für mich ein Dilemma.

Desweiteren habe ich keine Lust mir jetzt Dinge anzueignen,
die in vielleicht zwei Jahren nicht mehr "Stand der Zeit" sind.

Wie denkt ihr darüber? Das würde mich äußerst stark interessieren. Das es die Win32Api
noch eine Weile geben wird, dass ist klar, DOS ist auch nicht tot zu bekommen, doch wie
stabil (kein Emulator notwendig), wie sie heute ist, wird sie in Zukunft bleiben?


Cii jaa©$me
graphi

:: member of aitiba

[Hansa]

Dein Bekannter hat das schon richtig gesagt. So ist es. Die WinApi-Programme werden ab Longhorn in einer WinApi-Box laufen, so wie momentan die DOS-Programme.

[Robert_G]

Ich würde es nicht so schwarz sehen.
Zum Beispiel C# lernt sich wirklich sehr schnell und tippt sich locker 5-mal schneller als Delphi. (IntelliSense sei dank )

Stelle dir einfach mal vor, 1992 hätten damalige 16Bit-Entwickler die Möglichkeit bekommen Win32-anwendungen zu schreiben und verkaufen zu können. Wenn es so zu sagen einen Aufsatz auf Win16 gegeben hätte, in dem eine Win32-Anwendung problemlos gelaufen wäre. Und das 3 Jahre vor Win95!

Ich denke nicht, dass die Entwickler damals so schwarz gesehen hätten, wie es heute viele gegenüber .Net sind.
Denn genau das macht .Net -> Es führt eine Abstraktionsschicht ein, die dich unabhägig von der API des darunterliegenden OS entwickeln lässt.
Beispiel: Ein Großteil des Codes einer WinForms-Anwendung lässt sich auf das Compact FrameWork für PocketPCs portieren.

.Net ist also nicht die schwarze, alles zermalmende Zukunft, sondern eher ein nötiger Tapetenwechsel in einem uralten maroden Haus.

p.s.:

Zitat:

Er schreibt als Angestellter teils mit der Delphi 8.0 Version Programme auf Basis von .NET.

Richte ihm bitte mein Beileid aus.

[scp]

Naja, zu Win16-Zeiten gab es schon das sogenannte Win32s zum nachinstallieren, es ist zwar nicht ganz mit dem .NET Framework vergleichbar, aber das gab es auch schon vor Win95 und schätze mal genau wie die Win32 API gewachsen ist, wird auch .NET noch wachsen, ohne das das Framework für ältere Windowse mitwachsen wird.

Nachtrag: Damals lief eine mit Delphi 2 erstellte Adressverwaltung unter Win 3.11 mit Win32s, nicht das ich die dort noch ernsthaft genutzt hätte, aber es lief.

[Robert_G]

Zitat von scp:

...genau wie die Win32 API gewachsen ist, wird auch .NET noch wachsen, ohne das das Framework für ältere Windowse mitwachsen wird.

Das verlangt auch keiner.

[Phoenix]

.Net ist - ganz grob gesagt - als eine neue Abstraktionsschicht geplant gewesen.

Ziel war es, eine Schicht zu entwerfen und den Entwickeln an die Hand zu geben, auf der sie Anwendungen erstellen können die es dem Betriebssystemhersteller (in dem Fall Microsoft, aber eben auch dem Linux-Lager) erlaubt, den Unterbau (derzeit Win32 und Win CE, bald eben die Longhorn-API, auf der anderen Seite eben aber auch Linux) jederzeit nach Belieben umzubauen ohne das darauf laufende Anwendungen beeinträchtigt werden.

.NET ist derzeit die einzige Möglichkeit für Microsoft noch so halb Rückwärtskompatibilität zu gewährleisten - ohne in den Code von Windows sowas zu schreiben wie "if RunningSoftware = 'Civilisation' then UseOldBuggyCode else UseNewCorrectedCode;" - UNd nein, das ist kein Scherz - es gibt ein paar Leute bei MS im Backward-Compatibility Team die genau so sachen reinprogrammiert haben und je nach programm immernoch alte fehler ausgeführt haben.