So weit ich es verstehe, gibt es keine Möglichkeit, einen C ++ - GUI-Designer zu haben und Ihre Anwendung als eine eigenständige ausführbare Datei zu versenden. Alle 3rd-Party-Frameworks fügen ihre Abhängigkeiten in Form von .dll-s usw. hinzu, sei es MFC, Qt, WTL, wxWidgets, GTK. Das lässt mich mit nur einer Lösung - Design die GUI für meine aktuelle Anwendung selbst mit Win32 API. Sind meine Annahmen richtig oder fehlt mir etwas? Ich habe mich immer gefragt, wie es uTorrent und einigen anderen gelungen ist. Danke.
Nein, Sie können die meisten gängigen GUI-Frameworks statisch verknüpfen, einschließlich MFC, Qt, ATL / WTL und wxWidgets. Ich weiß nichts über GTK, aber ich nehme an, dass Sie es wahrscheinlich auch statisch verknüpfen können.
Statisches Verknüpfen bedeutet, dass Sie den Code nicht direkt mit dem in einer DLL vorhandenen Bibliothekscode verknüpfen, sondern ihn direkt mit Ihrer ausführbaren Datei verknüpfen. Dies führt zu einer eigenständigen EXE-Datei, die Sie ohne externe Abhängigkeiten versenden können.
Aber natürlich sind diese Abhängigkeiten auch dort und sie werden immer noch die Größe Ihrer ausführbaren Datei aufblähen, was je nach Ihrem Bereitstellungsmechanismus ein Problem sein kann. Es gibt auch etwas, das für die Programmierung in der Nähe des Metalls gesagt werden kann, also ist die Verwendung der Win32-API direkt eine Option. Das wird die absolut kleinste, leichteste Anwendung und wahrscheinlich auch die schnellste erzeugen. Tatsächlich glaube ich, dass dies genau das ist, was μTorrent macht (oder zumindest ist es das, was sie vor mehreren Versionen gemacht haben).
Einige Frameworks ermöglichen es Ihnen, eine autarke "Standalone Monolyte" EXE ohne zusätzliche Abhängigkeiten zu erstellen (abgesehen von der offensichtlichen API, die vom Betriebssystem bereitgestellt wird). Zum Beispiel haben Sie in MFC eine Option, entweder "statische" oder "dynamische" MFC-Nutzung. Die erste Option bedeutet, dass alle benötigten Sachen in Ihrer EXE verlinkt sind.
Abhängig von den minimalen Betriebssystemanforderungen Ihrer Anwendung können Sie dynamisch eine Verbindung zu einer MFC- oder ATL-Version (im Fall einer WTL-Anwendung) herstellen, die in der minimal angepassten Version von Windows enthalten ist.
Und es gibt einen zusätzlichen Vorteil einer solchen Lösung: Wenn ein Sicherheitsupdate der verwendeten Bibliothek herauskommt, müssen Sie Ihre Anwendung nicht aktualisieren, um davon zu profitieren.
Aber es ist trotzdem nicht so schlimm, für die reine Windows-API zu kodieren, also würde ich vorschlagen, dass Sie damit fortfahren.
Ein Problem besteht darin, dass Apps, die mit neueren Versionen von Visual Studio kompiliert wurden, die neueste CRT-Laufzeitbibliothek benötigen, die Sie im Installationsprogramm bereitstellen müssen, oder dass der Benutzer sie selbst installieren muss. Es gibt Möglichkeiten, das zu überwinden. Ich denke, dieser Blogeintrag ist der Einer, über den ich vor einiger Zeit gestolpert bin. Natürlich müssen Sie dabei vorsichtig sein, als ob Sie dynamisch eine Verbindung zu einer alten CRT-Bibliothek herstellen würden, am besten wäre es auch, die Header zu codieren. Vielleicht gibt es eine Möglichkeit, die CRT-Abhängigkeit vollständig loszuwerden.
Ich beschloss, nach einer hitzigen Diskussion mit Cody Grey weiter unten zu kommentieren, um vielleicht meine Punkte zu wiederholen und einige Warnungen auszusprechen.
Rant ankommend
Auch Desktop-Software ist ein Service, den Sie nach dem Versand für den Benutzer pflegen müssen. Betriebssystemversionen ändern sich, ihre APIs und ausgelieferten Bibliotheken ändern sich ebenfalls. Apple hat kein Problem damit, Apps mit neueren OS X- und iOS-Versionen zu "kapern", und Entwickler verstehen, dass sie ihre Produkte auf dem neuesten Stand halten müssen oder dass sie Kunden verlieren oder mit Supportanrufen zu beschäftigt sind. Microsoft unter anderem in der "großen Geschäftswelt" schuf eine Klasse von Programmierern, die Software als Gebäude betrachten. Sie entwerfen es, bauen es auf, jemand genehmigt es und Sie sind fertig, nachdem Sie es vielleicht noch zwei Jahre lang unterstützt haben. Und das sollte nicht sein.
Auch wenn man möglichst viel zukunftssichere Anwendungen schreibt, dh abhängig von einem vollständig definierten, allgemeinen und dokumentierten Verhalten des Zielbetriebssystems und allem, was danach kommen könnte, und sogar statisch mit allen verwendeten Bibliotheken verknüpft, Sie machen es in sich geschlossen, korrekt und alt-neu-genehmigt , sie müssen es noch jahrelang aktiv pflegen. Die Bibliotheken, von denen es abhängig ist, ändern sich. Sie werden aktualisiert, verbessert, Fehler werden entfernt, Schwachstellen behoben, Betriebssystemabhängiges Verhalten wird aktualisiert, behoben oder generalisiert.
Auch wenn die App von der absolut minimalen Menge an Systembibliotheken abhängig ist, gilt auch alles oben.
Unabhängig davon, ob Ihre App für eine begrenzte Zeit genutzt werden soll oder nicht, müssen Sie übernehmen und planen , wenn sich etwas ändert, was mit Ihrer App zusammenhängt App Selbst wenn es sich um eine reine Win32-API-Anwendung handelt, müssen Sie überprüfen, wie sich das Programm in der neueren Version von Windows verhält, ob es Benutzeroberflächenelemente oder Dienste bereitstellt, die Benutzer dieses neuen Betriebssystems von ihren Apps erwarten.
Und wenn Sie nicht sagen, dass Sie die reine Win32-API-Route verwenden, denken Sie an die Kompromisse, die Sie machen, wenn und if eine der Methoden verwenden Hacks habe ich ursprünglich erwähnt.
Auch wenn Ihr Projekt zu einer Wegwerf-App führt. Selbst wenn Sie sich nur selbst zukunftssicher machen.
Tags und Links c++ user-interface frameworks