Win32API noch sinnvoll?
-
flenders schrieb:
Jo, soviel wusste ich auch - war mir eben nur nicht ganz sicher, ob sie nur die WinAPI kapselt, oder ob sie auch plattformunabhängig ist (sprich: zum Beispiel auch mit Linux o.ä. funktioniert)
Dafür ist dann die CLX da.
-
OK - schon wieder was dazugelernt
-
win_noobie schrieb:
Welche vernünftigen kostenlosen Alternativen hat man, vor allem cross platform?
Das Wort vernünftig kann sicherlich unterschiedlich ausgelegt werden, ich hab jedenfalls noch keine brauchbare Alternative gefunden (obwohl ich gern eine hätte
). Es gibt zwar einige, wobei jede ihre Eigenheiten (oder sollte ich Mankos sagen ) hat. GTK+ (bzw gtkmm) hat zB Linux Feel'n'Look, relativ ungewohnt für Windows User. wxWindows hat imo eine mangelhafte Konzeption, Qt hab ich noch nicht probiert. Um nur mal einige zu nennen. Diese Unzulänglichkeiten haben allerdings auch damit zu tun, dass Standard C++ imo für GUI's noch unzureichend spezifiziert ist (zB Thema Properties).
Bin deshalb jetzt wieder dazu übergegangen das Framework für mein aktuelles Projekt mit der WinAPI aufzubauen. Da ich momentan keinen Linux, Mac oder anderen Port für wichtig halte, scheint mir das am vernünftigsten.
Wenn es dir reicht, dass dein Programm auf Windows läuft und du etwas anderes als die WinAPI ausprobieren willst, versuch mal .NET in Verbindung mit Managed C++ (mit MFC würd ich nicht mehr anfangen, da es stirbt). Leider brauchst du dazu die .NET IDE
(jaja ist nicht kostenlos) um effektiv Programme entwickeln zu können, obwohl es mit dem MSC Compiler (ab Version 7.0), den richtigen Headern und Libs wohl auch ohne geht. Im .NET Framework SDK ist jedenfalls der Standard MSC 7.1 enthalten, was man bei Microsoft kostenlos runterladen kann.
Ansonsten, wenn dir Plattformunabhängigkeit wichtig ist, probier wxWindows, wie es hier schon einige male empfohlen wurde.
-
thx. wenn ich das hier richtig sehe, hängt c++ richtig in der krise, was GUI angeht. für wxWindows gibt es zumindest ein package zum dev-c++. ist das innenleben von wxWindows auch winapi? da kann man doch gleich winapi pur nehmen, so schwer ist das doch nicht.
was macht ihr winapi-freaks, wenn es kein winapi mehr gibt? wie sieht eure migrations-strategie aus? was würdet ihr einem neuling in GUI empfehlen, wenn er c++ mag? wirklich managed-c++ mit .net? das ms visual studio ist doch sauteuer und alle paar tage gibt es eine modifikation. das sollte man nicht mitmachen.
bin ratlos.
-
1.) wxWindows ist eine cross-platform library -> für Windows wird wohl WinAPI verwendet, für Linux z.B. was anderes
2.) Warum sollte es kein WinAPI mehr geben
Für was du dich im Endeffekt entscheidest hängt auch damit zusammen, welches Ziel du verfolgst
Willst du etwas hinter die Kulissen schauen und das Prinzip verstehen -> WinAPI
Willst du schnell entwickeln, ohne dich dabei groß darum kümmern zu müssen, wie und warum das funktioniert -> irgendeiche Library
-
win_noobie schrieb:
was macht ihr winapi-freaks, wenn es kein winapi mehr gibt? wie sieht eure migrations-strategie aus?
Dass WinAPI ausstirbt, ist wohl nur eine Frage der Zeit. Spätenstens mit neuen MS Betriebssystemen wird die .NET Technologie WinAPI ablösen, wahrscheinlich aber in einer stark weiterentwickelten Version als die jetzige. MS versucht mit C# ganz klar die gleiche Struktur aufzubauen, wie sie bei Visual Basic schon seit Jahren vorhanden ist. Für mich stellt sich die Frage, ob MS die C++ Unterstützung für .NET aufrechterhält. Momentan ist dazu Managed C++ erforderlich, was lediglich der MSC Compiler unterstützt und auch im Standard nicht spezifiziert ist (und hoffentlich auch nicht wird
).flenders schrieb:
Willst du schnell entwickeln, ohne dich dabei groß darum kümmern zu müssen, wie und warum das funktioniert -> irgendeiche Library
Schnell ist relativ. Ich denke es macht geschwindigkeitsmässig keinen Unterschied ob man sich in WinAPI oder irgendeine Lib einarbeitet. Der Vorteil einer Lib liegt woanders (plattform-unabhängig, besser strukturierte Programme). Am schnellsten gehts wohl, wenn du eine IDE mit allem was nötig ist hast (Visual Studio .NET). Wenns kostenlos sein soll, kann man sich vielleicht auch mal Qt anschaun, da ist wohl ein entsprechender Editor dabei, um sich seine Oberfläche zusammenzubasteln. Würde mich jedenfalls mal interessieren. Vielleicht kann ja jemand seine Erfahrungen dazu hier posten.
-
groovemaster2002 schrieb:
Dass WinAPI ausstirbt, ist wohl nur eine Frage der Zeit. Spätenstens mit neuen MS Betriebssystemen wird die .NET Technologie WinAPI ablösen, wahrscheinlich aber in einer stark weiterentwickelten Version als die jetzige. MS versucht mit C# ganz klar die gleiche Struktur aufzubauen, wie sie bei Visual Basic schon seit Jahren vorhanden ist. Für mich stellt sich die Frage, ob MS die C++ Unterstützung für .NET aufrechterhält. Momentan ist dazu Managed C++ erforderlich, was lediglich der MSC Compiler unterstützt und auch im Standard nicht spezifiziert ist (und hoffentlich auch nicht wird
).Und in welcher Sprache wird dann Windows geschrieben? Solange Windows in C geschrieben wird, wird auch die Win-API existieren.
Gruß Tobias
-
tobidope schrieb:
Und in welcher Sprache wird dann Windows geschrieben? Solange Windows in C geschrieben wird, wird auch die Win-API existieren.
Nicht wenn MS keine Schnittstelle (API) zur Verfügung stellt.
-
Luckie schrieb:
tobidope schrieb:
Und in welcher Sprache wird dann Windows geschrieben? Solange Windows in C geschrieben wird, wird auch die Win-API existieren.
Nicht wenn MS keine Schnittstelle (API) zur Verfügung stellt.
API = Application Programming Interface
Und wie wird dann die .NET-Umgebung entwickelt?
Gruß Tobias
-
Naja, DOS-Programme laufen ja auch zum Teil noch unter XP, da werden die die WinAPI auch nicht von heute auf morgen killen
-
Eine Programmierschnittstelle ist aber was anderes als eine Softwareschnittstelle. Und alte Programme laufen auch noch ohne erstere weiter. Nur Programmieren kann man dann auf diese Art und Weise nix mehr.
-
solang du die alten Header und Libs noch hast, könntest du aber trotzdem auf jeden Fall noch muter weiterhin Anwendungen erstellen (evtl. musst du dabei dann halt auf neue Features verzichten)
-
Soll ich euch mal was sagen. Solange Windows in der Sprache C geschrieben wird, wird es auch eine C-API geben. Diese ganze .NET Gerümpel ist doch nur ein Aufsatz. Ihr wollt mir ja wohl nicht sagen, dass ich einen Datenbank-Server, der eigentlich nur low-level-Zugriffe braucht (memory mapped I/O ...) nicht diekt mit API-Aufrufen schreiben kann und sollte. Natürlich wird das ganze gekapselt. Aber letztenendes wird Windows solange es in C geschrieben wird eine C-API haben.
-
sollte man nicht auf wxWindows umsteigen?
-
was ist, wenn 64-bit prozessoren kommen? dann müsste WIN64API folgen.
-
nicht unbedingt Link
-
Interessant. Es lebe ULONG_PTR.
-
moin meisters ...
jetzt geht die Sch***e wieder los wie früher mit near und far oder ? :
UINT_PTR Unsigned INT_PTR.
ULONG_PTR Unsigned LONG_PTR.Und was ist das ?
UHALF_PTR Unsigned HALF_PTR."... test your code on 32-bit Windows, and recompile with the 64-bit compiler ..."
Sieht so aus als müßte man sich so langsam fit machen ... ich meine mal nen SDK-Update saugen um die neuen Header zu bekommen ...
mfg
RB