Kann man mit normalem C++ irgendwann keine Windows-Programme mehr schreiben?

Hi.

Ihr sagt ja immer das es die WinAPI irgendwann aussterben wird. Aber wie kann man dann noch Programme für Windows mit normalem C++ schreiben? (also ohne Managed C++ bzw. ohne C++/CLI)?

Könnt ihr mir das kurz erklären?
Bitte keine Flames.

rüdiger

Ja, warum sollte man das nicht können? Man braucht halt nur ein Compiler, der kommende Binär-Formate unterstützt.

Aber mit C++ (ohne diese Erweiterungen) kann man das .NET Framework doch gar nicht ansprechen? Wie soll man dann zum Beispiel ein Fenster erstellen?

rüdiger

Jung, du brauchst nur einen Compiler der das richtig macht. C++ kann man vielleicht nicht direkt in dotNET integrieren, da C++ und dotNET nicht dafür ausgelegt wurden. Aber trotzdem kann ein Compiler einen C++ Code nehmen und in entsprechenden dotNET Bytecode umsetzen, so wie er das auch mit C++ Code machen würde, der für einen 80x86 kompiliert wird.

Dann kannst du auch Funktionsaufrufe umsetzen und (indirekt) die Bibliotheken nutzen, die dotNET mitbringt.

ness

Schwachfug

Walli

Was soll damit sein?

es wird ja auch noch die schönen dlls geben, die ja von der verwendeten sprache unabhängig sind.

simon.phoenix

m$oft wird nicht einfach Millionen Tonnen von vorhandenem WINAPI bzw. MFC-SOURCECODE in den Wind schießen. Bis das soweit ist, kommt sowieso wieder was komplett neues und man wird über den dotnet-Unfug nur noch lachen. Also mach euch mal nicht mehr Gedanken als nötig ist...

simon.phoenix schrieb:

Bis das soweit ist, kommt sowieso wieder was komplett neues und man wird über den dotnet-Unfug nur noch lachen.

Du Hirsch. Der dotnet-Unfug ist das komplett neue.
Das neue "native" GUI wird auch kommen. Nennt sich Avalon. Basiert aber eigentlich auf .Net (ist nämlich in C# geschrieben).

Der Gag an .Net ist aber, dass es egal, was du für ein darunterliegendes natives GUI-System hast.
Die Winforms sind zur Zeit das einzig zukunftssichere. Das WinAPI stirbt nach Longhorn. Avalon soll angeblich für XP noch kommen, das heißt aber schon automatisch, dass es für Standard WinXP-Installationen nicht vorhanden ist.
Das einzige Zukunftssichere sind high-level APIs, weil die alles wrappen können.
Swing oder AWT wird immer so funktionieren wie es ist, weil es komplett vom Betriebssystem abstrahiert ist. dito .Net Winforms. Es macht keinen Sinn bei GUIs, die nativen Funktionen zu benutzen.
Der Overhead durch Wrapper ist vollkommen irrelevant bei GUIs, weil sie eh Ereignisbasiert arbeiten.

m$oft wird nicht einfach Millionen Tonnen von vorhandenem WINAPI bzw. MFC-SOURCECODE in den Wind schießen.

Oh doch. WinAPI funktioniert in Longhorn noch, danach nicht mehr. MFC wird vielleicht noch länger funktionieren, weil MFC leicht als Wrapper von Winforms implementiert werden kann. Ist halt mehr high-level.

Ach ja der Optimizer ist ja ein toller Hellseher.

Ja, da braucht es schon wirklich eine große hellseherische Gabe, um festzustellen, dass high-level APIs leichter zu portieren sind. Und um Microsoft's nähere Zukunftspläne zu erfahren, muss man auch überhaupt nicht irgendwie mal ein paar Artikel in der MSDN lesen, das muss man sich alles zusammenreimen, weil MS ja nichts sagt.

WinAPI funktioniert in Longhorn noch, danach nicht mehr.

Hi. Wo hast du diese Information her?
Kann ich mir kaum vorstellen weil Microsoft ja eigentlich immer alles abwärtskompatibel hält. Ok, irgendwann ist vielleicht Schluß, aber vorher weißt du das es nach Longhorn ist?

Das bisherige Win32 API gibt es nativ in Longhorn nicht mehr. Es ist nur noch ein Layer über das dort vorhandene API. So wie der 16Bit - Support aus Windows 3.X in Windows 9X. Den gibt es ab 2000 nicht mehr. Ok, lass diesen Layer noch eine Version nach Longhorn leben.
Aber danach ist definitiv Schluss, das Ding existiert schon seit 10 Jahren inzwischen, nämlich seit Windows '95.
Da muss man wahrlich kein Prophet sein um festzustellen, dass dieses unschöne API irgendwann nicht mehr supported wird. Dass es nativ nicht mehr existiert, ist doch nur der Anfang. High-level APIs leben viel länger, weil man sie leichter portieren kann. Eine MFC Anwendung ist leicht zu portieren, weil es letztendlich wurscht ist, ob ein CWindow intern ein HWND oder ein Form ist.
Aber das low-level API mitzuschleppen kann einfach nicht mehr lange gutgehen.

In der MSDN kann man das eigentlich auch recht oft lesen. Der Gag an Avalon ist doch, dass es nicht mal mehr direkt das GDI nutzt. MS hat schon Schwierigkeiten, die Winforms noch zu portieren. GDI-Funktionen werden über lock & copy der 3D-Hardware emuliert. Alles, was noch mehr low-level ist, hat IMHO definitiv ein Problem.

Wie schreibt man dann eigentlich Treiber oder ähnliches Low-Level Zeug?

rüdiger

Aber danach ist definitiv Schluss, das Ding existiert schon seit 10 Jahren inzwischen, nämlich seit Windows '95.

ROFL. Die WinAPI wird es sicher noch die nächsten 10 Jahre geben. Überleg mal, wie lange MS gebraucht hat, bis DOS gekickt wurde. Und die Entwicklung neuer Software ist ja auch nicht linear verlaufen. Wahrscheinlich kann man zwar viel wegwerfen. Aber ein paar Basiskomponenten in irgend einem riesen Projekt werden sicher noch ewig überdauern. Frag dich mal, warum MS immer noch WinNT unterstützt, obwohl es schon mehrfach tot gesagt wurde oder warum heute noch Leute auf OpenVMS mit COBOL arbeiten

Die Winforms sind zur Zeit das einzig zukunftssichere.

Nope. Weil die Winforms sind wohl doch nicht so ideal zu portieren und außerdem proprietär. Siehe auch die Diskussionen, die es im Mono oder dotGNU Projekt gab.

GTK# oder wx.NET ist da das einzige, was man als zukunftssicher bezeichnen könnte, da es im SourceCode zur Verfügung steht und Platform unabhängig ist.

Aber der Grundtenor ist natürlich richtig, dass Highlevel-APIs einfach zeitgemäß sind. Direkt System-APIs zu nehmen, die nicht standardisiert sind, ist naiv und dumm. Ich versteh nicht, warum die Windows Programmierer das nicht bereits nach dem Umstieg von Win16 verstanden haben und es wohl auch bei dem Umstieg auf dotNET nicht verstehen werden. Aber auch Highlevel-APIs haben gewisse limitierungen, wie die MFC zeigt. Zack der Support des Herstellers weg und schon sitzt man da. Und ob man die WinAPI oder die MFC nachprogrammiert, sollte sich nicht so viel geben (siehe libwine).

Die Win32API könnte man wenn man genau ist sogar selbst als Highlevel-API bezeichnen, da es ja auch nur Kernelaufrufe wrapt.

Shade Of Mine

kingruedi schrieb:

Nope. Weil die Winforms sind wohl doch nicht so ideal zu portieren und außerdem proprietär. Siehe auch die Diskussionen, die es im Mono oder dotGNU Projekt gab.

Zukunftssicher heißt nicht "portabel"

Ob Winforms ideal sind, lässt sich sicher abstreiten. Aber sie sind auf jedenfall gut und zukuntssicher.

Die WinAPI/MFC wird es noch sehr lange geben, es ist nur nicht mehr sinnvoll sie in neueren Projekten zu verwenden.

Obwohl momemntan brauch man einfach noch viel zu oft WinAPI-Aufrufe weil das .net Framework nicht alles abdeckt.

rüdiger

Shade Of Mine schrieb:

kingruedi schrieb:

Nope. Weil die Winforms sind wohl doch nicht so ideal zu portieren und außerdem proprietär. Siehe auch die Diskussionen, die es im Mono oder dotGNU Projekt gab.

Zukunftssicher heißt nicht "portabel"

Nicht? Ich dachte Optimizer wollte dies propagieren.

kingruedi schrieb:

ROFL. Die WinAPI wird es sicher noch die nächsten 10 Jahre geben. Überleg mal, wie lange MS gebraucht hat, bis DOS gekickt wurde.

Ok. überleg. 5 Jahre. Win '95 war das 32Bit - System von MS. 5 Jahre später kam 2000 raus ohne Support für 16Bit Anwendungen.

Nope. Weil die Winforms sind wohl doch nicht so ideal zu portieren und außerdem proprietär. Siehe auch die Diskussionen, die es im Mono oder dotGNU Projekt gab.
GTK# oder wx.NET ist da das einzige, was man als zukunftssicher bezeichnen könnte, da es im SourceCode zur Verfügung steht und Platform unabhängig ist.

Sie sind nicht ganz ideal zum Portieren, ja. Nichts ist ideal, auf Avalon portiert zu werden. Was das allerdings mit OpenSource zu tun hat, ist mir ein Rätsel. Ich könnte ohne allzu große Probleme einen Wrapper um Winforms für MFC schreiben. Für das WinAPI tu ich mich da allerdings schwer.

Aber der Grundtenor ist natürlich richtig, dass Highlevel-APIs einfach zeitgemäß sind. Direkt System-APIs zu nehmen, die nicht standardisiert sind, ist naiv und dumm. Ich versteh nicht, warum die Windows Programmierer das nicht bereits nach dem Umstieg von Win16 verstanden haben und es wohl auch bei dem Umstieg auf dotNET nicht verstehen werden.

full ack.

Aber auch Highlevel-APIs haben gewisse limitierungen, wie die MFC zeigt. Zack der Support des Herstellers weg und schon sitzt man da. Und ob man die WinAPI oder die MFC nachprogrammiert, sollte sich nicht so viel geben (siehe libwine).

Hmmm. Das sollte sich schon was geben. Swing ist wohl leicht auf verschiedene Plattformen zu portieren. Auch AWT, SWT oder Winforms. Das WinAPI dürfte aber nicht zu leicht sein, auch wenn es dafür Portierungen gibt. Bei Swing ist es nämlich wurscht, wie das Event zum Listener kommt, bei WinAPI muss man sehr viel mehr Systemnähe erreicht. Wine funkitioniert IMHO heute noch nicht richtig (davon mal abgesehen, dass mir dieses Projekt generell nicht gefällt).

Die Win32API könnte man wenn man genau ist sogar selbst als Highlevel-API bezeichnen, da es ja auch nur Kernelaufrufe wrapt.

NAJA. Wrappen ist relativ. Das WinAPI ist IMHO der direkte Aufruf an Kernel-Funktionen, ein hauchdünner Wrapper, der nur Fehlbedienung nicht fatal werden lässt. Tausche den Kernel aus und du hast riesen-Schwierigkeiten, das Teil zu portieren. Willst du das leugnen?
Ich kann mir schon denken, warum das boost-Socket nicht so recht voran kommt. Die Idee war, die System-APIs dünn zu wrappen und daraus dann high-level sockets zu basteln. Aber wie willst du unterschiedliche APIs noch dünn wrappen?
Wenn du nen high-level Wrapper bastelst, kann es dir sowas von egal sein, wie die darunter liegenden Kernel-Funktionen aussehen. Wenn du eine Win32-Schnittstelle bereitstellen willst, tust du dich da schwerer.

Nicht? Ich dachte Optimizer wollte dies propagieren.

Nein. Ich wollte das umgekehrte propagieren, nämlich: Portabel heißt Zukunftssicher. Versuch mal, ein System-API zu entwerfen, was es unmöglich macht, ne Swing-Schnittstelle bereitzustellen. Es wird dir IMHO nicht gelingen.

5 Jahre später kam 2000 raus ohne Support für 16Bit Anwendungen.

Mit