Hallo, auch wenn die Forensuche schon verwandte Threads hergiebt bin ich etwas egoistisch und stelle die Frage hier nochmal. Ich selbst arbeite in der PLC Programmierung, also Maschinenbau und Automatisierung. Falls das überhaupt jemandem etwas sagt, die hierbei verwendeten Sprachen wären Siemens(AWL,SCL), IEC-Normiert(ST). Alles was ich über Windows-Programmierung weis ist selbst beigebracht, also liest es sich wahrscheinlich ziemlich laienhaft. ;) Ich habe schon vor längerem angefangen mir für die Inbetriebnahme oder Steuerung meiner PLCs Programme in Python3 zu schreiben, womit ich an sich auch auf Anhieb sehr gut zurecht gekommen bin. Mit tkinter und sockets sind Programme mit GUI und TCP-Kommunikation schließlich kinderleicht zu erstellen. Mein Problem mit dieser Sprache ist schlichtweg, dass es eine Interpretersprache ist und ich immer wenn ich ein Programm weiter gebe Python3 installieren muss und man den Programmcode sofort einsehen und ändern kann. Ich suche jetzt letztendlich eine Möglichkeit Programme mit grafischer Oberfläche zu erstellen, die ich dann zu einer EXE-Datei (und ein paar DLLs) kompilieren kann, um sie auf jedem Windows-Rechner starten zu können. Ich bin natürlich für jeglichen Ansatz dankbar, aber ich wäre froh wenn nicht jeder einfach nur Namen von Programmiersprachen posten würde, sondern auch ein bisschen Hintergrundinfos dabei wären. PS: So Ansätze wie py2exe können wir uns sparen, das ist einfach nur nutzlos.
Julian R. schrieb: > Ich suche jetzt letztendlich eine Möglichkeit Programme mit grafischer > Oberfläche zu erstellen, die ich dann zu einer EXE-Datei (und ein paar > DLLs) kompilieren kann, um sie auf jedem Windows-Rechner starten zu > können. Es kommt darauf an, was du mit "grafischer Oberfläche" meinst. In den meisten Fällen wirst du mit einer .NET Sprache (C#, VB.Net, C++ CLI) am schnellsten gute Ergebnisse erzielen. Du must dann noch entscheiden, ob die Windows Forms oder WPF einsetzen willst. C++ native geht natürlich auch, aber da muss man viele Bibliotheken erst mal zusammensuchen, die im .NET Framework schon enthalten sind. Dafür hat man dabei die volle Kontrolle und (bei entsprechendem Programmieraufwand) die beste Performance. Das wird in vielen Fällen nicht erforderlich sein.
Natürlich XProfan für kleine exe, oder PureBasic für noch kleinere! Gruss Chregu
Julian R. schrieb: > Ich suche jetzt letztendlich eine Möglichkeit Programme mit grafischer > Oberfläche zu erstellen, die ich dann zu einer EXE-Datei (und ein paar > DLLs) kompilieren kann, um sie auf jedem Windows-Rechner starten zu > können. Qt? Wenn du es richtig anstellst, dann kannst du sogar den gleichen Code auch noch für Linux, MAC, im Extremfall Android ... kompilieren! Ach ja, deine "Hintergrundinfos" -> https://de.wikipedia.org/wiki/Qt_%28Bibliothek%29 -> http://www.qt.io/ ...
:
Bearbeitet durch User
Naja, bei den genannten Lösungen (.NET, (Visual-)C++, Qt) hast du allerdings auch das Problem, dass das von deiner Compile-Umgebung abhängige Runtime-Environment auf dem Ziel-Rechner vorhanden sein muss. MMn war Visual-C++ am schlimmsten - jede Compiler-Version hat seine eigene Runtime, die dann mit ziemlicher Sicherheit nicht auf dem Ziel-System vorhanden war (und evtl auch gar nicht existierte). Die einzige mir [1] bekannte Umgebung, die Windows-Versionsübergreifend[2], ohne zusätzliche RTEs/DLLs lauffähige Executables erstellt, ist MinGW. Dort fehlt natürlich der ganze moderne Zuckerguß. Ich glaube, Delphi war in der Beziehung auch nicht schlecht, würde ich aber heute keinem mehr empfehlen. [1] Bin allerdings hauptsächlich Unix-Programmierer. Windows hab ich nur ein paar Jahre machen müssen - war während der Zeit ständig am fluchen ;-) [2] das hieß bei uns WinNT bis Win7.
Volker S. schrieb: > Qt? > Wenn du es richtig anstellst, dann kannst du sogar den gleichen Code > auch noch für Linux, MAC, im Extremfall Android ... kompilieren! WinForms funktioniert auch mit Mono... Die Frage bei Qt ist, wie viel Zeit der TO entweder in das Erlernen von C++ investieren will oder ob die Bindings an die Lieblingssprache gut funktionieren. .NET-Vorteile: C#, Visual Basic sind leichter als C++ zu erlernen und das .NET-Framework ist auf den allermeisten Windows-Rechnern vorinstalliert, ist sehr umfangreich, keine (L)GPL-Probleme* .NET-Nachteile: GUIs nur mit WinForms mehr oder weniger portabel, neuere .NET-UI-Frameworks werden von Mono nicht unterstützt (wohl aber von Xamarin) Qt-Vorteile: Auf so gut wie allen Betriebssystemen verfügbar, Qt-Nachteile: weniger umfangreich als .NET, u.U. (L)GPL-Probleme* Was ich hier allerdings mittlerweile gerne für kleinere Tools insb. Kommandozeilen-Tools nutze: Go https://golang.org/ Erzeugt per Default ohne Libraries/Frameworks lauffähige Programme (Windows, Linux, BSD, Mac), imo sehr gute HTTP/Web-Packages und die Qt-Bindings sind ebenso brauchbar (https://github.com/go-qml/qml). IDE: https://github.com/visualfc/liteide *) (L)GPL-Lizenz vereinfacht: Qt statisch gelinkt: Wenn das Programm unter der GPL oder einer kompatiblen Lizenz steht -> kein Problem, ansonsten ist bei kommerzieller Verwendung eine Lizenz von Digia nötig. Qt dynamisch gelinkt: Meist keine Probleme, auch kommerziell ohne kommerzielle Lizenz möglich http://www.qt.io/faq/ asdfasd schrieb: > Naja, bei den genannten Lösungen (.NET, (Visual-)C++, Qt) hast du > allerdings auch das Problem, dass das von deiner Compile-Umgebung > abhängige Runtime-Environment auf dem Ziel-Rechner vorhanden sein muss. > MMn war Visual-C++ am schlimmsten - jede Compiler-Version hat seine > eigene Runtime, die dann mit ziemlicher Sicherheit nicht auf dem > Ziel-System vorhanden war (und evtl auch gar nicht existierte). Man hätte auch einfach statisch linken können (was afair schon immer ging bzw. kenne VS/VC nur seit V6...). Problem dabei: U.U. schleppt man dann diverse Sicherheitslücken mit sich rum...
:
Bearbeitet durch User
Für kleine Sachen die eine GUI brauchen benutze ich ganz gerne mal Autoit. http://www.autoitscript.com
C#- und dann eben WinForms, oder, wenns ausgefuchste GUIs sein wollen, WPF. VisualStudio ist die überragendste IDE die ich kenne, da kommt einfach nichts dran. -> und das ganze wird mittlerweile auch für Linux und MAC portiert, also fällt dieses nicht-systemabhängig sein wollen Argument auch weg. http://www.heise.de/developer/meldung/Build-2015-CoreCLR-nun-fuer-Linux-und-OS-X-verfuegbar-2630938.html
Julian R. schrieb: > um sie auf jedem Windows-Rechner starten zu > können. Das ist natürlich unmöglich. Um Deine Programme auf einem Windows Rechner zu starten, benötigt dieser zumindest die darin benutzten Bibliotheken, und zwar in der richtigen Version. Stellt sich die Frage: Welche Bibliotheken gibt es auf allen Windows Versionen? Antwort: Die CLR (Common Language Runtime) und die CRL (C Runtime Library). Alleine diese Tatsach legt Dich auf das Visual Studio mit seinen unterstützten Programmiersprachen fest: C++ (CRL), sowie C#, VB, C++/CLI (alle CLR). Da aber die Entwicklung im Laufe der Jahre nicht stehen geblieben ist, findet man von XP über Vista bis Windows 10 immer andere Versionen der CLR bzw. CRL. Diese Versionen sind natürlich nicht / nur bedingt kompatibel. Deshalb ist man auch oft gezwungen, sog. Redistributable Packages zu installieren, welche dafür sorgen, dass eben die gewünschte Bibliothek auf dem entsprechenden Windows dann auch vorhanden ist. Ich habe mich jetzt schon einige Zeit nicht mehr damit auseinandergesetzt, aber bei mir hat das immer gut geklappt mit dem .NET4.0 (CLR) oder der Version 10 der CRL. Wobei diese Versionen vermutlich längst veraltet sind. Gruß Kurt
Kurt schrieb: > Julian R. schrieb: >> um sie auf jedem Windows-Rechner starten zu >> können. > > Das ist natürlich unmöglich. > > Um Deine Programme auf einem Windows Rechner zu starten, benötigt dieser > zumindest die darin benutzten Bibliotheken, und zwar in der richtigen > Version. Und was sind DLLs deiner Meinung nach? Ich quote nochmal ein paar Wörter mehr von deinem obigen Zitat: Julian R. schrieb: > [...] zu einer EXE-Datei (und ein paar DLLs) kompilieren kann, um sie auf > jedem Windows-Rechner starten zu können. Davon abgesehen können Bibliotheken auch statisch gelinkt werden.
Der Charme von Scriptsprachen besteht darin, dass die erstellten Scripts (meist) unabhängig von Hardware und Betriebssystem laufen. Die heute verbreiteten Scriptsprachen wird es vermutlich in einigen Jahrzenten immer noch geben. Selbst wenn du eines Tages nichts mehr mit dem Thema zu tun hast oder haben willst, können andere deine Scripts immer noch nutzen und auf deiner Arbeit aufbauend die Scripts anpassen und erweitern. So geht deine Arbeit nicht verloren.
Konrad S. schrieb: > Der Charme von Scriptsprachen besteht darin, dass die erstellten Scripts > (meist) unabhängig von Hardware und Betriebssystem laufen. Die heute > verbreiteten Scriptsprachen wird es vermutlich in einigen Jahrzenten > immer noch geben. Selbst wenn du eines Tages nichts mehr mit dem Thema > zu tun hast oder haben willst, können andere deine Scripts immer noch > nutzen und auf deiner Arbeit aufbauend die Scripts anpassen und > erweitern. So geht deine Arbeit nicht verloren. und wo soll jetzt der unterschied zu C, Java oder C# sein? Wenn es den Interpreter in ein paar Jahren nicht mehr gibt, hilft das Script auch nicht weiter. C, Java oder C# Quellcode ist genauso unabhängig von Hardware und Betriebssystem.
Peter II schrieb: > und wo soll jetzt der unterschied zu C, Java oder C# sein? Neben der Laufzeitumgebung, die du in beiden Fällen brauchst, bist du zusätzlich auf eine funktionsfähige Entwicklungsumgebung angewiesen. > Wenn es den Interpreter in ein paar Jahren nicht mehr gibt, hilft das > Script auch nicht weiter. Richtig. Ebenso hast du bei kompilierten Programmen ein Problem, wenn die ursprünglich benötigte Runtime nicht mehr läuft. Denk da mal an Oldies wie DOS-Programme oder 16-Bit-Windows-Programme. Es gibt zu dieser Problematik ein paar Threads hier im Forum. > C, Java oder C# Quellcode ist genauso unabhängig von Hardware und > Betriebssystem. Bei C stimme ich dir zu. Java gibt es nicht für alle Platformen. C# gibt es nur für einige wenige Plattformen.
Schau dir mal "nuitka" an. Hab mir das Mai gebookmarked, selber aber noch nicht getestet. Damit kann man anscheinend den py-code in c übersetzen+kompilieren lassen. http://nuitka.net
Hi Leute, ich bedanke mich für die vielen Informationen. Mehmet K. schrieb: > Für kleine Sachen die eine GUI brauchen benutze ich ganz gerne mal > Autoit. > http://www.autoitscript.com Ich muss sagen das ist genau das was ich gesucht habe, klein, einfach, und schnell zu verstehen. Hat tolle Tools mit an Bord und eine komplett offene Lizenz, gefällt mir wirklich sehr gut. Außerdem unterscheidet sich dieser BASIC-Dialekt nicht groß von dem womit ich normalerweise arbeite. ^^ dunno.. schrieb: > C#- und dann eben WinForms, oder, wenns ausgefuchste GUIs sein wollen, > WPF. > VisualStudio ist die überragendste IDE die ich kenne, da kommt einfach > nichts dran. Ich denke das ist dann der nächste Schritt, falls AutoIT meine Ansprüche nicht mehr abdecken kann. Ich hatte mir Qt schonmal angeschaut bevor ich mit Python angefangen habe, aber ich werde mit der Umgebung einfach nicht warm, und mein Bedürfnis C++ zu lernen hält sich auch in Grenzen. ovbd schrieb: > Schau dir mal "nuitka" an. > > Hab mir das Mai gebookmarked, selber aber noch nicht getestet. Damit > kann man anscheinend den py-code in c übersetzen+kompilieren lassen. > > http://nuitka.net Das werde ich mir definitv mal ansehen, aber rein aus interesse, ich verspreche mir von solchen Ansätzen eigentlich nicht sonderlich viel.
Lazarus wurde noch nicht genannt, ist ebenfalls geeignet da es kleine statisch gelinkte .exe erzeugt die keinerlei Abhängigkeiten haben.
Julian R. schrieb: > PS: So Ansätze wie py2exe können wir uns sparen, das ist einfach nur > nutzlos. Darf ich fragen warum? Der Code ist nicht mehr direkt ersichtlich und meiner Erfahrung nach funktioniert py2exe hervorragend. Es entsteht eine einzelne EXE die alles enthält was zur Ausführung des Scripts gebraucht wird. Matthias
asdfasd schrieb: > MMn war Visual-C++ am schlimmsten - jede Compiler-Version hat seine > eigene Runtime, die dann mit ziemlicher Sicherheit nicht auf dem > Ziel-System vorhanden war (und evtl auch gar nicht existierte). > > Die einzige mir [1] bekannte Umgebung, die > Windows-Versionsübergreifend[2], ohne zusätzliche RTEs/DLLs lauffähige > Executables erstellt, ist MinGW. Visual C++ kann das auch - man muss das Ding nur dazu bringen, statisch zu linken. (Vorausgesetzt, es geht hier um echtes C++ und nicht um das .Net-Geraffel)
Μαtthias W. schrieb: > Julian R. schrieb: >> PS: So Ansätze wie py2exe können wir uns sparen, das ist einfach nur >> nutzlos. > > Darf ich fragen warum? Der Code ist nicht mehr direkt ersichtlich und > meiner Erfahrung nach funktioniert py2exe hervorragend. Es entsteht eine > einzelne EXE die alles enthält was zur Ausführung des Scripts gebraucht > wird. Ich habe mich nicht tiefgehend damit beschäftigt, also wäre vielleicht noch Optimierungspotential da gewesen, aber bei meinen Versuchen waren die Ergebnisse eher bescheiden. Zunächst wird die Datei(en) sehr speicherintensiv, da ja die ganze Laufzeitumgebung mitgeliefert werden muss. Außerdem hängt es von den verwendeten Bibliotheken ab ob man alles in eine Exe-Datei bekommt. Ein Beispiel von mir, kleine Anwendung mit ein bisschen GUI und Kommunikation ergab 12 Dateien mit einer Gesamtgröße von 25Mb.
Julian R. schrieb: > Mehmet K. schrieb: >> Für kleine Sachen die eine GUI brauchen benutze ich ganz gerne mal >> Autoit. >> http://www.autoitscript.com > > Ich muss sagen das ist genau das was ich gesucht habe, klein, einfach, > und schnell zu verstehen. Hat tolle Tools mit an Bord und eine komplett > offene Lizenz, gefällt mir wirklich sehr gut. Außerdem unterscheidet > sich dieser BASIC-Dialekt nicht groß von dem womit ich normalerweise > arbeite. ^^ Du hättest gleich sagen sollen, dass Du Dir einen Bot fürs Computerspiel programmieren willst, statt so allgemein nach Programmiersprachen zu fragen.
Knut schrieb: > Du hättest gleich sagen sollen, dass Du Dir einen Bot fürs Computerspiel > programmieren willst, statt so allgemein nach Programmiersprachen zu > fragen. Eigentlich habe ich eingehend ziemlich genau beschrieben was ich so mache, oder findest du nicht? Julian R. schrieb: > Ich habe schon vor längerem angefangen mir für die Inbetriebnahme oder > Steuerung meiner PLCs Programme in Python3 zu schreiben [...] Aber da du hier je eh nur herumt(r)ollst ist's schon gut...
Rufus Τ. F. schrieb: > Visual C++ kann das auch - man muss das Ding nur dazu bringen, statisch > zu linken. (Vorausgesetzt, es geht hier um echtes C++ und nicht um das > .Net-Geraffel) ...ich ergänze mal: Wenn man sowieso einen Installer liefert und die Redistributables mit-installieren könnte, sollte man das allerdings nicht unbedingt tun: "We recommend that you avoid static linking when you redistribute Visual C++ libraries. Although static linking almost never significantly improves application performance, it almost always makes servicing more expensive. For example, consider an application that's statically linked to a library that's been updated with security enhancements — the application cannot benefit unless it is recompiled and redeployed. Instead, we recommend that you dynamically link your applications to the libraries they depend on so that the libraries can be updated wherever they're deployed." https://msdn.microsoft.com/en-us/library/ms235316.aspx https://msdn.microsoft.com/en-us/library/dtba4t8b.aspx
Wenn schon AutoIt genannt wird, möchte ich auch Autohotkey nennen. Finde die Sprache noch etwas besser zum Programmieren und es gibt auch einen GUI-Creator. --> http://ahkscript.org/ Ansonsten ist C# auch eine gute Wahl. Bzgl. der Problematik "es muss ja .NET vorhanden sein, damit das Programm geht": Es gibt teilweise die Möglichkeit, die benötigten Libs von .NET in die exe reinzubinden, damit es auch auf einem System ohne .NET läuft. Details --> google. Bzw. falls man Mono verwendet: http://www.mono-project.com/docs/advanced/aot/ Nachteil: die exe wird wieder größer. Für wirklich kleine Standalone-Projekte finde ich Autohotkey gut. Da habe ich schon oft Sachen in compilierter Form an Kollegen weitergegeben. Kleiner Nachteil: diese Scriptingsprachen sind recht schlampig (implizites Casting in alle Himmelsrichtungen) und werden ab einer gewissen Größe schnell unübersichtlich.
Julian R. schrieb: > Ich habe schon vor längerem angefangen mir für die Inbetriebnahme oder > Steuerung meiner PLCs Programme in Python3 zu schreiben, womit ich an > sich auch auf Anhieb sehr gut zurecht gekommen bin. Dann steige auf Pascal um. Das findest du in diversen Delphi's und in Lazarus. Was dabei herauskommt, sind .exe Dateien, die schlichtweg alles enthalten. Also keinerlei Runtime-Gedöns im System erforderlich. Und bei Lazarus hast du sogar die Möglichkeit, den ganzen Kram auch auf Linux laufen zu lassen. Nebenbei bemerkt, laufen Anwendungen, die mit Delphi 6 geschrieben wurden, auch auf Windows 7 immer noch - und da liegen inzwischen ca. 18 Jahre dazwischen. Und bei Embarcadero ist derzeit die Starteredition Delphi XE8 für noch erträgliche 300 Euro zu haben und die bedient Win10, Apple, Android. Was will man mehr? Wenn ich hier Empfehlungen für Qt, VisualC++ oder Scriptsprachen lesen, wird mir schlecht. W.S.
W.S. schrieb: > wenn ich hier Empfehlungen für Qt, > VisualC++ oder Scriptsprachen lesen, wird mir schlecht. Du Armer! Da hast du ja echt ein scheiß Leben, wenn's dir jedes mal gleich schlecht wird. Entspann dich ;-)
:
Bearbeitet durch User
Kurt schrieb: > Julian R. schrieb: >> um sie auf jedem Windows-Rechner starten zu >> können. > > Das ist natürlich unmöglich. Ich schreibe ja seit mehr als 30 Jahren Programme, die aus nur einer EXE bestehen und unter Windows laufen ohne weitere Voraussetzung. Aber man muss immer bereit sein dazuzulernen, jetzt weiss ich also dass das garnicht geht. Das geht sicher auch vielen anderen Programmierern so, besonders den älteren, daher herzlichen Dank für diese revolutionäre Erkenntnis. Georg
Georg schrieb: > Ich schreibe ja seit mehr als 30 Jahren Programme, die aus nur einer EXE > bestehen und unter Windows laufen ohne weitere Voraussetzung. Verrätst Du auch, WOMIT? Ich meine, nur, damit die Eingangsfrage beantwortet wird.... MfG Paul
W.S. schrieb: > Nebenbei bemerkt, laufen Anwendungen, die mit Delphi 6 geschrieben > wurden, auch auf Windows 7 immer noch - und da liegen inzwischen ca. 18 > Jahre dazwischen. Und bei Embarcadero ist derzeit die Starteredition > Delphi XE8 für noch erträgliche 300 Euro zu haben und die bedient Win10, > Apple, Android. Was will man mehr? Wenn ich hier Empfehlungen für Qt, > VisualC++ oder Scriptsprachen lesen, wird mir schlecht. Ich bin da ganz bei Dir! Aber wahrscheinlich sind Deine Statements hier in den Wind gesprochen.
Albert M. schrieb: > Aber wahrscheinlich sind Deine Statements hier in den Wind gesprochen. https://www.youtube.com/watch?v=vWwgrjjIMXA MfG Paul
Georg schrieb: > Ich schreibe ja seit mehr als 30 Jahren Programme, die aus nur einer EXE > bestehen und unter Windows laufen ohne weitere Voraussetzung. Aber man > muss immer bereit sein dazuzulernen, jetzt weiss ich also dass das > garnicht geht. Das geht sicher auch vielen anderen Programmierern so, > besonders den älteren, daher herzlichen Dank für diese revolutionäre > Erkenntnis. kannst du uns das Geheimnis verraten wie eine EXE zwischen ARM und x86 kompatibel ist? Oder meinst du eine .net exe?
Rufus Τ. F. schrieb: > Wo war von ARMen die Rede? > Ich schreibe ja seit mehr als 30 Jahren Programme, die aus nur einer EXE > bestehen und unter Windows laufen ohne weitere Voraussetzung. das liest sich für mich so, als ob die exe auf jedem Windows System läuft. Und da es Windows auch für ARM gibt muss die exe ja auch dort laufen.
> Paul B. schrieb: >> Verrätst Du auch, WOMIT? Georg schrieb: > Netter Versuch ins Mobbing einzusteigen. Was soll man da noch sagen... Ach doch -Eines schon: Behalte Deine nebulösen Andeutungen für Dich. "Rate mal mit Rosenthal" kann ich mir im Archiv ansehen. Paul
Peter II schrieb: > da es Windows auch für ARM gibt Für wieviel der Windows-Installationen trifft das zu? ARM auf Windows Installationen geht doch im Rauschen unter. Seit Windows 3.0 ist Windows ein BS für x86 Prozessoren. Ich verstehe diese ganze Diskussion nicht. Immer hat irgendeiner einen Einwand der eine Sondersituation beschreibt und versucht diese Sondersituation zum Mainstream in seiner "Wichtigkeit" zu erheben. Da wird übers statische Linken gemault, weil man damit angeblich sich Sicherheitslöcher einfangen würde. In der Praxis läuft es aber ganz anders. Ein FreeCAD beispielsweise kommt mit einem Haufen QT DLLs in einem Unterverzeichnis. Nix ist statisch gelinkt, geht nicht aus lizenzrechtlichen Gründen. Gepatcht wird da aber trotz Bindung zur Laufzeit auch niemals was, weil die DLLs ja gar nicht im System registriert sind. Erst beim runterladen einer neueren Programmversion kommen auch neue QT DLLs (die dann wieder für eine Zeit lang sicherheitsbereinigt sind). Wenn einer sein FreeCAD aber nicht updatet, weil es einfach schön läuft für ihn, lebt er auch weiter mit seinen Sicherheitslücken, auch ganz ohne statisches linken. Statisch gelinkte Programme kann man genauso updaten. Es muss einfach nur eine neue Programmversion zum Download angeboten werden. Dann liegt es am Anwender, ob er aktualisieren möchte oder nicht. Beides ist in der Summe gleich sicher oder unsicher, ob statisch oder dynamisch gelinkt. System DLLs bilden hier eine Sonderrolle. Die pflegt der Hersteller des BS.
Paul B. schrieb: >> Paul B. schrieb: >>> Verrätst Du auch, WOMIT? > Georg schrieb: >> Netter Versuch ins Mobbing einzusteigen. > > Was soll man da noch sagen... > > Ach doch -Eines schon: Behalte Deine nebulösen Andeutungen für Dich. > "Rate mal mit Rosenthal" kann ich mir im Archiv ansehen. > > Paul Er wird halt einen der vielen BASIC-Dialekte verwenden (warum auch nicht wenn's er damit gut klar kommt) und hat nun Bammel, dass man ihn dafür für wenig(er) kompetent hält (als die coolen C++'ler, für die immer alles sooo easy ist). ;)
Gelegenheitsprogrammierer schrieb: > Seit Windows 3.0 ist Windows ein BS für x86 Prozessoren. Windows NT 4 hat neben x86 auch MIPS, PowerPC und Alpha unterstützt.
Peter II schrieb: > Rufus Τ. F. schrieb: >> Wo war von ARMen die Rede? > >> Ich schreibe ja seit mehr als 30 Jahren Programme, die aus nur einer EXE >> bestehen und unter Windows laufen ohne weitere Voraussetzung. > das liest sich für mich so, als ob die exe auf jedem Windows System > läuft. Und da es Windows auch für ARM gibt muss die exe ja auch dort > laufen. Nein, liest es sich nicht. Und es ist egal, ob du ein Klugscheißer bist, der nichts anderes findet, was er beitragen könnte, oder ob du nur Rufus anmachen willst. In beiden Fällen wäre es ausgesprochen nett, wenn du dieses Forum verlassen würdesr.
Lazarus..geht extrem fix damit was au die Beine zu stellen!
Rolf M. schrieb: > Windows NT 4 hat neben x86 auch MIPS, PowerPC und Alpha unterstützt. Und was ist aus denen geworden? Hat sich der PowerPC oder DEC Alpha durchgesetzt? Mal abgesehen davon ist doch keiner gezwungen sein Kompilat für alle möglichen Plattformen bereitzustellen. Man sieht doch wozu solche eierlegenden Wollmilchsäue führen. MS meinte ein bisher erfolgreiches weil Maus bedienbares Desktop BS nun mit einer verallgemeinerten dämlichen Schiebe-Kachel-Oberfläche für Smartphones beglücken zu müssen und schon geht der Terz los. Wer es allen recht machen möchte muss sich mit dem kleinsten gemeinsamen Nenner zufrieden geben. Heraus kommt dann ein Brei, den viele nicht möchten. Dann wird wieder mühsam nachgebessert und nachgebessert. Ikonen, die keine Sau versteht und Farben so kräftig, wie sie nie sein sollten. Damals zur 386er Zeit mussten Farben und 3D-Look noch eingeschränkt werden, weil die HW es von der Rechenleistung nicht wuppte. Dann kam endlich leistungsfähigere Hardware für Umme und der Desktop konnte plastischer werden, ohne das es stockte im Grafikaufbau. Das hielt lange, war Konsens. Nun wieder der Rückschritt ins Flachland bei Fensterrahmen und Pastellfarben sterben aus. Zurück in die Zukunft oder was?! Schau mal hier her http://www.eevblog.com/2015/08/22/eevblog-783-dumpster-dive-power-macs/ ein anschauliches Beispiel was das hippe Zeugs von gestern, das mal eine Schweinekohle gekostet hat, mit dem sich Leute vom Mainstream abgrenzen wollten (wie heute die IPhone-Besitzer - nur sind die selber längst Mainstream) und die Nase vor jedem PC hoch erhoben trugen, später noch wert ist. Was wurde aus OS halbe? Was aus NeXTStep oder BeOS? Kompiliert einer heute noch für ein Museums BeOS? Man liest nichts mehr davon.
Lazarus Programme können auch beliebig kopiert werden! Keine installation oder deinstallation etc erforderlich!
und die Community erst!! Stell diese Frage mal hier oder in einem C Forum..da werden 5 Seiten raus, ohen eine Lösung..aber mit Lösungsvorschlägen, die Du dir selbst erarbeiten sollst LOL http://forum.lazarus.freepascal.org/index.php/topic,20438.0.html
Marc schrieb: > Nein, liest es sich nicht. > > Und es ist egal, ob du ein Klugscheißer bist, der nichts anderes findet, > was er beitragen könnte, oder ob du nur Rufus anmachen willst. nein, ich will damit nur sagen. Das man .net nicht ignorieren sollte. Damit kann man wirklich alle aktuellen Windows-Plattformen beliefern und das mit einer exe. Ohne Irgendwelche LIBs statisch zu linken. Meist sind die .net Anwendungen sogar kleiner als bei c++. (natürlich ohne das Framework gerechnet).
bevor ich .net nehmen würde würde ich C++ oder Lazarus einsezten wenn wir schon im Mikrocontroller net sind :-) Den beide Sprachen, also pascal und zumindest C kann man dann auch für Controller verwenden..net nicht
Gelegenheitsprogrammierer schrieb: > Er wird halt einen der vielen BASIC-Dialekte verwenden Das ist nun eine der wenigen Sprachen, die ich noch nie verwendet habe. Es ist aber völlig egal, was ich hier konkret nennen würde, Paul wartet nur darauf sich mit Schaum vor dem Mund drauf zu stürzen und die Wahl niederzumachen - was weder hier im Thread noch überhaupt irgendwo einen Fortschritt bringen würde, nur eine weiteren sinnlosen Flame War. @Paul wenn du unbedingt stänkern willst, such dir selbst eine Sprache aus. Georg
@Georg Mit verschraenkten Armen trotzig mit dem rechten Fuss auf den Boden aufschlagen und "Sag ich nicht! Sag ich nicht!" brüllten ... okay, im Kindergarten faellt das nicht besonders auf. Oder mit der einen Hand in der Hosentasche herumfummeln und "ich habe was was du nicht hat!" flüstern und dabei die Zunge rausstrecken ... okay, auch das faellt im Kindergarten nicht besonders auf. Aber ab einem gewissen Alter sollte man solche Formen der Kommunikation nicht mehr anwenden.
Mehmet K. schrieb: > okay, im > Kindergarten faellt das nicht besonders auf. Ich füttere Trolle prinzipiell nicht - klar dass die armen hungrigen Trolle dann aufheulen. Wie man sieht hindert dich das ja nicht an weiteren Hasstiraden. Wenn man keinen Ansatzpunkt hat um auf eine bestimmte Computersprache einzuprügeln, pöbelt man halt darüber, dass man gerade nichts zum Pöbeln hat. Sozusagen ein Flame War aus dem Nichts. Georg
Was soll der Unsinn? Was hat das überhaupt mit der Programmiersprache zu tun? Viele (die meisten?) Windows95-Programme laufen auch heute noch, und wenn man noch die Quelltexte hat bekommt man wahrscheinlich auch den kleinen Teil der heute nicht mehr läuft in 5 Minuten zum Laufen. Man könnte also wahrscheinlich so ziemlich jede beliebige Sprache, Toolchain und Framework von damals nemen und Windows-10 lauffähige Software damit bauen. Natürlich ohne Kacheln und andere Neuerungen seitdem. Aber lauffähig. Das ist übrigens der einzige Grund warum Microsoft heute noch existiert und nicht bereits seit langem vieder in der Versenkung verschwunden ist. Microsoft wird (oder sollte zumindest) sich hüten an diesem einen einzigen verbliebenen Ast zu sägen auf dem ihr gesamtes Unternehmen ruht denn sonst sind sie weg vom Fenster. MS-Windows hat kein einziges anderes Feature zu bieten als dass die ganze Software drauf läuft in die man Zeit und Geld investiert hat.
Georg schrieb: > @Paul wenn du unbedingt stänkern willst, such dir selbst eine Sprache > aus. Verfolgungswahn? Wenn man nur nicht mal so wird... MfG Paul
Bernd K. schrieb: > Was soll der Unsinn? Und was soll_dein_ Beitrag? Bernd K. schrieb: > bekommt man wahrscheinlich ... > Man könnte also ... > oder sollte zumindest Ach, du ergehst dich in Konjunktiven und Mutmaßungen. Ich sag's dir her mal ganz trocken: Windows war und ist das Beste, was man für den PC haben kann und genau deshalb benutzen es die Leute. Auch der TO benutzt es und dein Gemosere ist fehl am Platze. Die Frage war und ist, wie der TO es hinkriegt, seine Inbetriebnahme-Programme als simple EXE zu schreiben, die man ohne irgendwelche Installationen eben "mal eben" vom Stick oder so auf einem anderen Windows-PC laufen lassen kann. Da kommt eben nur etwas in Frage, was keine fetten Interpreter, Laufzeitsysteme usw. auf dem betreffenden PC vorinstalliert haben muß, weil es "direktemang" auf dem API aufsetzt. Und da wird die Luft dünne und übrig bleibt eben MAL WIEDER nur was pascalhaltiges, also entweder Delphi in irgendeiner der bisherigen Versionen oder eben Lazarus. Obendrein ist die Sprache deutlich besser geeignet als fast alles andere für jemanden, der ansonsten mit SPS und Automatisierung befaßt ist. Der Rest dieses Threads ist mal wieder sinnlose heiße Luft. W.S.
W.S. schrieb: > Windows war und ist das Beste, was > man für den PC haben kann und genau deshalb benutzen es die Leute. Windows hat den unschlagbaren Vorteil daß es das einzige existierende System ist mit dem man alle Windows-Programme aus mehreren Jahrzehnten ausführen kann. Deshalb wollen es die Leute und deshalb benutzen sie auch nichts anderes. Darüberhinaus sind mir keine weiteren Vorteile von Windows bekannt, auch nicht den Leuten die so vehement darauf schwören und kein anderes System kennen, auch die können keine weiteren Vorteile nennen. Darüberhinaus erschließt sich mir nicht warum Du meine vollkommen neutralen Tatsachenfeststellungen jetzt als "Gemosere" kritisierst ohne sie im Kern anzugreifen oder gar zu widerlegen. Ich habe überhaupt nicht gemosert. Und übrigens: Lazarus benutze ich selbst jeden Tag, ganz schlicht aus dem Grund weil kein auch nur ansatzweise vergleichbar mächtiges Werkzeug existiert auf diesem Planeten.
:
Bearbeitet durch User
Bernd K. schrieb: > Lazarus benutze ich selbst jeden Tag, ganz > schlicht aus dem Grund weil kein auch nur ansatzweise vergleichbar > mächtiges Werkzeug existiert auf diesem Planeten. Jetzt mal ehrlich. Da kennst du meine Knippex nicht. Nicht nur kann man damit Hosen anziehen, auch lassen sich Bierflaschen wundervoll öffnen. Ganz nebenbei kann man sie auch ungeliebten Kunkurrenten and den Kopf werfen und Frauen aus der Patsche helfen. Kann das dein geliebtes Lazarus auch? Ich würde mal Sagen meine Knippex ist das mächtigste Werkzeug hier. (PS: Wenn man sich die in die Hose tut. Hoho, das macht mächtig Eindruck bei der holden Weiblichkeit, oder was man sonst bevorzugt). Zum Topic: Die QT dlls sind schnell mitgeliefert. Ein .Net Framework ist gewöhnlich auch schon vorinstalliert. Von dem Pythoen-Exe dingens halte nicht nicht viel. Da macht sich debuggen nicht sonderlich. Es gibt auch einen Compiler für Matlab scripts (musste ich mal benutzen. Grusel). WinAPi ist quasi auch immer mit an Board und die Java runtime haben die meisten auch installiert. Merkt Ihr was? Grüße PS: Ich mag natürlich C# nochmal lobend erwähnen :)
Ich liebe es ganz besonders, wenn man bei der Installation eines Tools nur deshalb nicht ans Ziel kommt, weil noch irgendeine winzige Runtime-Bibliothek geladen werden muss, aber kein Internet verfügbar ist. Sowas kommt bei mir bei industriellen Kunden öfter mal vor, weil die nicht jedem externen Dienstleister einen Internetzugang zur Verfügung stellen wollen. Ist es noch erwähnenswert, dass Delphi und Lazarus meine bevorzugten Werkzeuge sind, wenn ich selber solche Tools baue?
Edi R. schrieb: > Ist es noch erwähnenswert Ja. In genau DIESEM Forum jedenfalls. Da brechen sich die anderen Schreiber lieber sämtliche Zacken aus der Krone, um gigabyte füllende Runtime Libs 2.0, 2.2, 3, 3.5, 4. 4.x bereits installiert haben zu wollen (natürlich ALLE und eine jede mit Servicepack xyz) und bloß nicht von C sich entfernen zu müssen. Ja, hier ist es erwähnenswert. W.S.
W.S. schrieb: > Da brechen sich die anderen Schreiber lieber sämtliche Zacken aus der > Krone, um gigabyte füllende Runtime Libs 2.0, 2.2, 3, 3.5, 4. 4.x > bereits installiert haben zu wollen (natürlich ALLE und eine jede mit > Servicepack xyz) und bloß nicht von C sich entfernen zu müssen. Überraschung: C-Compiler können auch statisch linken.
Rufus Τ. F. schrieb: > Überraschung: C-Compiler können auch statisch linken. Ach, ich dachte das machen die linken Linker ;-)
C kann so viel und alles..nur nichts ist mal eben so! Wenn man ein Buch mit 1000 Seiten durch hat UND verstanden hat geht viel...aber wenn man darauf keinen Bock hat, kommt man mit Pascal mit wenigen 100 Seiten erledigt und kann dennoch alles damit machen was 98% der user benötigen. Macnhmal ist weniger mehr...nicht umsonst wird selbst Visual basic heute noch eingesetzt
.NET-Anwendungen kann man auch als eine einzige exe ohne externe Abhängigkeiten verfügbar machen, wenn man statt dem .NET-Framework auf mono setzt und dessen "mkbundle"-Tool nutzt. Hab ich aber mangels Bedarf bisher selbst nie ausprobiert ;D
Martina schrieb: > Wenn man ein Buch mit 1000 Seiten durch hat UND verstanden hat geht > viel... Man kann über jeden Mist UNENDLICH viel schreiben, WIR hier in diesem Forum sind doch dass beste Beispiel ;-)
na ich meinte damit eher, das alleine die ganzen GRUNDFUNKTIONEN von C 1000 Seiten füllen..so viel bekommt man mit Pascal sicher nie zusammen... Schlussendlich bentutz man nur einen kleinen Teil dessen was C kann, weil niemand der damit nicht regelmäßig arbeiten, das wirklich noch überblickt. Daher ist für gelegeneheitsprogrammeirer basic oder Pascal in keinem Fall die schlechtere Wahl.. ABER durch LAZARUS und dessen super Oberfläche is tes die BESSERE! Laso eigentlich ist die GUI das was Pascal hier nach vorne katapultiert! Wenn es sowas auch für C gäbe mit all der Einfachheit und einrichtung wie Pascal..könnte das schwieriger für PAscal werden. Egal, ich mag Pascal :-)
Martina schrieb: > Egal, ich mag Pascal :-) Ist doch OK! (Ich bin mir nicht mal wirklich sicher ob ich irgendwas mag ;-)
Martina schrieb: > na ich meinte damit eher, das alleine die ganzen GRUNDFUNKTIONEN > von C 1000 Seiten füllen..so viel bekommt man mit Pascal sicher nie > zusammen... Was genau meinst du? Free Pascal hat 106 Schlüsselwörter, zusätzlich noch die Typbezeichnungen wie Byte, Boolean etc. ANSI C hat 32 Schlüsselwörter, die Typen wie int, float etc. schon mitgezählt. Eine handvoll C-Operatoren kommt zwar noch dazu (% statt "mod", ! statt "not" etc.), aber das ändert am Gesamtverhältnis fast nichts.
Martina schrieb: > Schlussendlich bentutz man nur einen kleinen Teil dessen was C kann, > weil niemand der damit nicht regelmäßig arbeiten, das wirklich noch > überblickt. Das was du da mal aufgeschnappt hast und jetzt meinst hier verbreiten zu müssen, gilt höchstens für C++, aber ganz sicher nicht für C. Nichts über die andere Seite wissen, aber wenigstens Werbung für die Eigene gemacht...
Pascal kennt keine variadischen Funktionen, aber enthält eine im Sprachumfang. So etwas wie "Writeln" kann man in Pascal selbst nicht schreiben. Toll.
Und was soll uns dieses Argument sagen? "writeln" habe ich zuletzt zu DOS-Zeiten verwendet, und eine variadische Funktion wollte ich nie selber bauen. Da gibt es andere (und bessere) Lösungswege.
Wenn man ein hier bekanntes Programm eines bekennenden Deplhi-Fans runterläuft, dann stellt man erstaunt fest, daß es nur funktioniert, wenn auch eine QT-DLL mit dabei ist. Nicht schlimm, aber mal so als Randbemerkung zum Thema "Delphi macht alles in einer Exe". Und was war QT nochmal? Ein C++ Framework. Wenn das die Verfechter des reinen P's wüßten ;-)
Hallo W., W.S. schrieb: > Ich sag's dir her mal ganz trocken: Windows war und ist das Beste, was > man für den PC haben kann und genau deshalb benutzen es die Leute. Die Leute benutzen Windows wegen des Ökosystems an Software, die darauf läuft. Windows selbst ist eine hübsch verpackte Fehlkonstruktion. Das siehst Du ja schon an dieser Diskussion um ein Deployment von Software ohne die Notwendigkeit zur manuellen Installation externer Bibliotheken. Die Frage von Standalone-Binaries zu deren Vermeidung würde sich gar nicht stellen, wenn Windows ein ordentliches Paketmanagement hätte, wie es unter UNIXen schon seit zwanzig Jahren üblich ist. Oder wenn es eine Möglichkeit zum Deployment von Images anbieten würde, wie es MacOS mit den Apple Disk Images schon seit bald fünfzehn Jahren anbietet. Leider hat es Microsoft nichtmal für die eigenen Produkte geschafft, etwas Ähnliches anzubieten, sonst würde sich die Frage nach dem Deployment von .NjET-Bibliotheken in der passenden Version nämlich gar nicht erst stellen. Andererseits hilft es dem TO und der Diskussion nicht weiter, die Gründe dafür breitzutreten. Es ist, wie es ist, und solange Microsoft nichts an dieser Situation ändert, wird es auch so bleiben. Insofern kann der TO sich jetzt überlegen, ob er jetzt statisch gelinkte Binaries (die man im Übrigen nicht nur mit Delphi erstellen kann, da ist es nur der Default) oder einen richtigen Installer wie Windows Installer oder InstallShield nutzen möchte. Von der verwendeten Programmiersprache und -Umgebung ist das allerdings weitestgehend unabhängig. Übrigens ist die angeblich besondere Stärke von Delphi, daß die Programme meist keine externen Bibliotheken brauchen, eigentlich eine Schwäche. Da die Delphi-Leute einfach davon ausgehen, daß ihre Laufzeitumgebung nicht auf dem Zielsystem installiert ist, linken sie sie einfach statisch. Das führt jedoch zu relativ großen Programmen und einer recht ineffizienten Speichernutzung.Das ist zwar in Zeiten von Handies mit gigabytegroßem Arbeitsspeicher kein allzu großes Problem mehr, aber im Jahre 2015 auch nicht mehr wirklich Stand der Technik -- auch wenn es für Anwender und Entwickler sicherlich ganz angenehm ist. Liebe Grüße, Karl
Moin, kleiner Tip am Rande. Ihr könnt aufhören. Der TE hat sich schon vor 5 Tagen entschieden und mein Popkorn ist alle :)
Carl D. schrieb: > Wenn man ein hier bekanntes Programm eines bekennenden Deplhi-Fans > runterläuft, dann stellt man erstaunt fest, daß es nur funktioniert, > wenn auch eine QT-DLL mit dabei ist. > Nicht schlimm, aber mal so als Randbemerkung zum Thema "Delphi macht > alles in einer Exe". > Und was war QT nochmal? Ein C++ Framework. Wenn das die Verfechter des > reinen P's wüßten ;-) Wenn Du damit SerialComInstruments meinst :) Ja stimmt. Aus Unachtsamkeit bei den Ursprüngen des Programms habe ich unüberlegt eine CLX Komponente eingebaut, die diese qtintf70.dll benötigt. Ich hätte dafür auch eine Alternative nehmen können. Im späteren Verlauf der Programmierung war ich zu faul dies wieder zu ändern und so ist diese Qt-Abhängigkeit bis heute drin. Dies heisst aber keinesfalls, dass Delphi generell irgendwie darauf angewiesen ist, wie man auch schön bei SerialComCNC und anderen Programmen sehen kann.
:
Bearbeitet durch User
nur mal als Anmerkung ein extrem gutes Beispiel das Lazarus zumindest grafisch ohne QT durchaus was kann ist mAirList. Klar werden hier auch dll's mitgeliefert, das sind jedoch die bass.dll und 2 Crypto dll's die für die Server und Netzwerksachen gebraucht werden. Ich möchte hier jedoch nicht rein zu Lazarus die Empfehlung abgeben. Es kommt immer drauf an was das Programm können muss. Da kann je nach Fall C, C++, C#, Pascal, oder auch Java zur Anwendung kommen. Bei Java ist es z.B. mit XDev möglich eine Exe zu linken die mit wenig Zubehör auskommt (wenn eine JVM installiert ist) und was benötigt wird legt XDev gleich in den Release Ordner mit rein, notfalls sogar mit passender JVM die nicht installiert werden muss. Gruß René
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.