Hallo, ich suche nach Vorschlägen für eine Programmiersprache, die folgende Voraussetzungen möglichst erfüllt: -es sollte kostenlose oder zumindest preiswerte Compiler für Windows geben -es muss möglich sein, ohne grossen aufwand GUIs zu erstellen -eine grosse Bekanntheit wäre vorteilhaft -möglichst direkte Kommunikation mit Hardware ist zwingend -platformunabhängigkeit wäre schön, ist aber nicht zwingend(kratzt sich natürlich mit dem oberen Punkt) -Compilierte Programme müssem auf dem Zielsystem ohne runtime environment laufen(Java geht folglich nicht) Ich programmiere sonst nur AVRs in C und habe kleine erfahrungen mit Processing und ganz wenig BASIC. Daher wäre eine an C angelehnte SPrache sehr vorteilhaft, ich bin aber offen für alles. Schöhne Festtage, Patrick P.S.: Bitte keinen Glaubenskrieg starten, ein Vorschlag mit kleinen erläuterungen reicht mir ;)
Wie wäre es mit C oder C++, da gibt es den gcc-mingw Compiler. Als GUI kannst du gtk verwenden. http://www.gtk.org/
also ich würde C# empfehlen. Es ist wenn man mono mit betrachtet Plattformunabhängig. Es braucht zwar eine Runtime die aber schon bei allen aktuellen Windows-systemen vorhanden ist. Auch wenn man C oder C++ programmiert braucht man oft eine Runtime. (z.b msvcrt). Aber was meinst du mit direkter Kommunikation mit der Hardware - unter Windows darf man nur dafür vorgesehen Schnittstellen verwenden. Nur Treiber sollte auf die Hardware zugreifen.
Hallo, Peter II schrieb: > Aber was meinst du mit direkter Kommunikation mit der Hardware - unter > Windows darf man nur dafür vorgesehen Schnittstellen verwenden. Nur > Treiber sollte auf die Hardware zugreifen. das war zugegeben etwas unklar formuliert. Natürlich sollte die kommunikation über Treiber stattfinden. Aber eben über schon vorhandene, so dass ich keine eigene schreiben muss. Die serielle Schnittstelle und USB zum Beispiel sollten möglichst einfach und nativ zu verwenden sein. Frohes Fest, Patrick
Patrick W. schrieb: > Die serielle Schnittstelle und > USB zum Beispiel sollten möglichst einfach und nativ zu verwenden sein. Serial ist kein Problem. USB kommt halt darauf an, was für eine USB gerät. USB selber kann man kaum nativ verwenden. z.b USB zu Serial Adapter sind kein Problem weil es wie eine normale Serielle Schnittstelle zu behandeln ist. FTTI bieten für ihre Chips meines Wissens sogar C# binding an.
Ich weiss ja nicht, worauf deine Ideen dann laufen sollen, aber Qt klingt so, als könnte es viele deiner Anforderungen erfüllen: Kost nix. Massenweise (gute/auf das wesentliche konzentrierte) Codebeispiele. Sehr bekannt, man findet eigentlich zu jedem Problem ein Posting mit Lösung ;) Aber sowas von plattformunabhängig (Linux[so gut wie alle CPUs]/Win/Mac, neuerdings auch Android+iOS). Die GUI ist dann auch automatisch immer sehr nah an den nativen Elementen dran. Basis C++, das mit gnu/cygwin/ming/VisualC++ und entweder deren "nativen IDEs" (make.../Visualstudio) oder der Qt-IDE entwickelt werden kann. Es gibt aber auch eine Javascript-ähnliche Interpreter-Sprache. Schöne und schnelle OS/HW-Abstraktion (File-IO, Sound, Netzwerk, Serial, ...). Für USB gibts AFAIR nichts von Qt, dafür die libusb (C), die auch überall läuft. Sehr hilfreiche Klassen (Strings, Container, Threads, etc). Dagegen sind die Standard-C++-Strings fast schon Assembler... Laufzeitumgebung in dem Sinn brauchts nicht, halt die Libs (so ca. 10MB). Ist eine sehr überschaubare Anzahl von Files, nicht so wie der Java-Moloch. Kann man aber auch statisch dazulinken.
Lazarus bzw. halt Delphi sollte das abdecken. Ich guck da gerade selber hin. Wirkt so altbacken und 90er, aber es scheint gut zu funktionieren, ohne viel Hype, dafür mit beachtlicher Community.
Entweder C mit GTK+ oder C++ mit Qt. Der zweite Teil jeweils fürs Grafische. Die Grenzen zwischen beiden sind fließend. Von C# kann man nur abraten. Läuft nur mit dem fetten .NET-Framework. Davon braucht man tollerweise auch noch alle Versionen auf dem System, weil Programm A 3.5 braucht, Programm B 4.0 und Programm C läuft nur mit dem aktuellen 4.5. Auch wenn es Mono gibt, ist die Unterstützung unter Linux noch lange nicht perfekt.
T.roll schrieb: > Von C# kann man nur abraten. Läuft nur mit dem fetten .NET-Framework. > Davon braucht man tollerweise auch noch alle Versionen auf dem System, > weil Programm A 3.5 braucht, Programm B 4.0 und Programm C läuft nur mit > dem aktuellen 4.5. aber es ist doch schon drauf, also braucht man es nicht extra zu installieren. Wenn man ein Programm für 3.5 erzeugt, dann hat man überhaupt keine Probleme auf Windows. Damit sind die Programm sogar viel kleiner als mit C, weil das Framework schon vorhanden ist. Der Vorteil von .net ist das es auf 64bit System auch gleich als 64bit läuft. Man braucht also nicht 2 Versionen auszuliefern.
Peter II schrieb: > aber es ist doch schon drauf, Nur wenn man beim Windows up-to-date ist oder auf eine alte Version abzielt. Wenn aber die Kundschaft noch mit älteren Versionen rumeiert, vielleicht auch mit älterer Hardware, und das Prog eine neue will, dann kommt Freude auf. Erst bei der Installation der fehlenden Runtime, dann bei jedem Windows-Update, der bei DotNet unangenehm lang dauert.
:
Bearbeitet durch User
A. K. schrieb: > Nur wenn man beim Windows up-to-date ist. Wenn aber die Kundschaft noch > mit älteren Versionen rumeiert, vielleicht auch mit älterer Hardware, > dann kommt Freude auf. über wie alt reden wir denn? WinXP ist kein Problem. Und auf win2k oder noch älter laufen auch aktuelle C Programm nicht immer. (siehe Firefox).
Peter II schrieb: > WinXP ist kein Problem. Doch, nämlich wenn die benötigte Runtime nicht drauf ist. Und wenn du mal erlebt hast, wie lange ein Atom rumeiert, bis er 4 DotNet Updates verdaut hat...
A. K. schrieb: > Doch, nämlich wenn die benötigte Runtime nicht drauf ist. Und wenn du > mal erlebt hast, wie lange ein Atom rumeiert, bis er 4 DotNet Updates > verdaut hat... darum habe ich geschrieben 3.5. Es ist keine Pflicht 4.0 Programm zu schreiben.
A. K. (prx) schrieb: > wenn du > mal erlebt hast, wie lange ein Atom rumeiert, bis er 4 DotNet Updates > verdaut hat Liegt wohl dann am Atom. Wenn das was du hier schreibst bereits eine Hürde darstellt will ich gar nicht wissen was der Arme macht, wenn er 3D-Konstruktionszeugs startet oder Office oder ...
Skeptiker schrieb: > Liegt wohl dann am Atom. Auch. Einerseits ist ein Atom langsam. Andererseits sind Microsofts Updates immer langsam, egal was für Hardware drunter klebt. Bei DotNet kommt hinzu, das die Updates als Halbfertigware ausgeliefert und erst auf dem Zielsystem nativ kompiliert werden. Was die Sache auch nicht grad beschleunigt. > 3D-Konstruktionszeugs Der TO hat nicht geschrieben, um welche Maschinenklasse es geht.
:
Bearbeitet durch User
A. K. (prx) schrieb: Skeptiker schrieb: >> Liegt wohl dann am Atom. > Auch. Einerseits ist ein Atom langsam. Andererseits sind Microsofts > Updates immer langsam, egal was für Hardware drunter klebt ... Dafür hast du bei MS aber auch keine täglichen Updates und letztlich kann man das Updaten auf den Reboot hinausschieben, also dann wenn man bsp. die Kiste eh ausschaltet.
Was genau war eigentlich an den Forderungen des TO nach - Plattformunabhängigkeit und - lauffähig ohne Runtime nicht verständlich? Damit ist doch C# genauso raus wie Java. Unterm Strich wäre Java vermutlich auf Windows-Systemen noch eher anzutreffen, als .NET. Allein schon, weil das JRE meistens immer irgendwie um Dunstkreis der Webbrowser mitinstalliert wird - und das schon lange vor .NET.
Ich würde zu C# raten. Im Gegensatz zu C++/Qt ist das WIRKLICH Cross-Platform (eine .exe läuft ohne nochmaliges Kompilieren auf Win, Mac, Linux (z.B. Raspberry Pi), und sogar Windows Phone, iOS und Android werden unterstützt). Außerdem ist das erstellen von GUIs damit wirklich einfach, und die Sprache bzw. das Framework erlaubt eine sehr effiziente Entwicklung. Dass eine Runtime benötigt wird ist dafür (so finde ich) zu verschmerzen.
Boris B. schrieb: > Dass eine Runtime benötigt wird ist dafür (so finde ich) zu > verschmerzen. Die Forderung war aber, dass es ohne Runtime läuft. M.M.n. kommen da ernsthaft noch C/++ und Lazarus/Pascal in Frage.
Ganga schrieb: > Die Forderung war aber, dass es ohne Runtime läuft. > M.M.n. kommen da ernsthaft noch C/++ und Lazarus/Pascal in Frage. und das braucht keine Runtime? Also überhaupt keine Abhängigkeiten zu msvcrt8 oder einer andere System lib? Viele C / C++ Programm braucht auch eine Rumtime die teilweise erst installiert werden muss. http://www.microsoft.com/de-de/download/details.aspx?id=30679 Patrick W will vermutlich keine extra runtime installieren, und diese Forderung ist bei C# erfüllt.
Peter II schrieb: > und das braucht keine Runtime? Also überhaupt keine Abhängigkeiten zu > msvcrt8 oder einer andere System lib? Ein C/++-Programm braucht i.d.R. seine Standardbibliothek, das ist richtig. Das wäre die MSVCRT. Die gehört aber schon zu einer standardkonformen hosted-C-Umgebung dazu. Und die wird auch vom CLR des .NET benötigt. Peter II schrieb: > Patrick W will vermutlich keine extra runtime installieren, und diese > Forderung ist bei C# erfüllt. Da sich Patrick über das Zielsystem ausschweigt, ist diese Forderung bei C# überhaupt nicht erfüllt. Man kann jetzt natürlich die eigentlich recht simple Fragestellung von Patrick solange umdiskutieren, bis u.A. C# die bestmögliche Lösung dafür ist. Am besten reduzieren wir das jetzt darauf, dass zumindest ein Prozessor benötigt wird - dann passt auf einmal jede Programmiersprache wieder...
Ganga schrieb: > Das wäre die MSVCRT. Die gehört aber schon zu einer > standardkonformen hosted-C-Umgebung dazu. nein ebend nicht, zumindest nicht jeder Version. Aus dem Grund gibt es sie ja als extra Installation.
Peter II schrieb: > nein ebend nicht, zumindest nicht jeder Version. Aus dem Grund gibt es > sie ja als extra Installation. MSVCRT und MSVCPP sind die Standardbibliotheken für C und C++. Und die gehören zu einer standardkonformen, 'hosted' C- bzw. C++-Umgebung dazu. Und sie ist bei jeder Windows-Installation dabei. Dass man sie nachinstallieren kann und/oder muss, liegt daran, dass Microsoft bis heute keine Versionierung von Bibliotheken hinbekommt ('DLL hell').
Ganga schrieb: > Dass man sie nachinstallieren kann und/oder muss, liegt daran, dass > Microsoft bis heute keine Versionierung von Bibliotheken hinbekommt > ('DLL hell'). nein. An der msvrt steht hinten eine Versionnummer dran. Und die aktuellen (10er) ist auf einen XP nicht vorhanden muss also nachinstalliert werden.
Peter II schrieb: > nein. An der msvrt steht hinten eine Versionnummer dran. Und die > aktuellen (10er) ist auf einen XP nicht vorhanden muss also > nachinstalliert werden. Es zwingt dich ja niemand, dein Programm gegen die aktuellste zu linken. Mingw zum Beispiel linkt gegen MSVCRT.DLL, die ist seit 1998 bei Windows dabei. Ungeachtet dessen ist das aber immer noch Sache der C/++-Umgebung. Plattformunabhängigkeit bedeutet ja nicht, dass man einen Binärfile 1:1 übertragen kann. Genau dann nämlich hast du das Problem, dass die falsche Version der VCRT installiert ist. Wenn man eine C-Umgebung auf dem Zielsystem hat und das Programm auf dem Zielsystem (oder für das Zielsystem) kompiliert, dann wird ja quasi zwangsläufig gegen die auf dem Zielsystem vorhandene Bibliothek gelinkt und gut ist.
Wenn man Programme statisch linkt, gibt es auch keine Abhängigkeiten von irgendwelchen MSVCRT.DLL o.ä. Zumindest die Compiler von Microsoft unterstützen das schon immer.
Rufus Τ. Firefly schrieb: > Wenn man Programme statisch linkt, gibt es auch keine Abhängigkeiten > von irgendwelchen MSVCRT.DLL o.ä. > > Zumindest die Compiler von Microsoft unterstützen das schon immer. Der GCC kanns auch. Aber dann krachts vermutlich im ABI... Die Standardbibliothek ist ja auch nur eine (abstrakte) Schicht zwischen Betriebssystem und Anwendung, die ihrerseits wieder Abhängigkeiten zu anderen Bibliotheken usw. hat. Wenn man die statisch in die Anwendung hineinlinkt, kommt als nächstes der Kernel oder was auch immer. Dann müsste man schon das ganze Betriebssystem statisch dazulinken...
Sven P. schrieb: > Dann müsste man schon das ganze Betriebssystem statisch > dazulinken... Wenn man das Betriebssystem im Sinne des Fragesteller als Runtime Environment betrachtet, dann ist die Forderung tatsächlich nur völlig ohne ein Solches zu erfüllen. Da wir und hier in einem Forum für Microcontroller befinden, bei denen das ja meistens so ist, sollte das jedoch kein Problem darstellen. ;-)
Sven P. schrieb: > Aber dann krachts vermutlich im ABI... Interessant wird es, wenn man DLLs verwendet, die ihrerseits eine dynamische Runtime nutzen, und die gleichen Funktionen sowohl von dieser Runtime als auch vom eigenen Programm verwendet werden. Beispielsweise die stdio FILE Pointer. Die gibts dann zweimal, was in die Hose geht, wenn so ein Pointer gemeinsam genutzt werden soll.
Vermutlich wollte Patrik nur die Zeit bis zur Bescherung amüsant überbrücken. Jetzt hat er seine Eisenbahn ausgepackt und hat was zum Spielen. OS???-ABI's sind jetzt uninteressant ;-)
Sven P. schrieb: > Aber dann krachts vermutlich im ABI... Nö. Das funktioniert ohne Probleme. Ist ja auch nicht so, daß das eine hochgradig spezielle Frickelei ist, den Compiler dazu zu bringen, die statische Version zu verwenden. Dazu liefert MS verschiedene Varianten der Runtime-Library aus: msvcrt.lib /MD dynamisch, multithread, nutzt msvcr100*.dll msvcrtd.lib /MDd dynamisch, multithread, debug, nutzt msvcr100d*.dll libc.lib** /ML statisch, singlethread libcd.lib** /MLd statisch, singlethread, debug libcmt.lib /MT statisch, multithread libcmtd.lib /MTd statisch, multithread, debug Welche davon verwendet wird, ist allerdings keine Linkereinstellung, sondern eine Compilereinstellung, die jede einzelne Objektdatei betrifft. Der Compiler erzeugt in der Objektdatei einen Eintrag, der auf die jeweilige zu verwendende Library hinweist. Ein Mischen von Objektdateien, die mit unterschiedlichen Einstellungen übersetzt wurden --das schließt auch andere Libraries mit ein-- führt zu Linkerfehlermeldungen, die loszuwerden vielen Leuten schon viele graue Haare eingebracht hat. Mit dumpbin und dem Kommandozeilenargument /directives kann angezeigt werden, welche Libraries als Default für eine Objektdatei verwendet werden sollen. *) Die Dateinamen hängen von der verwendeten Compilerversion ab: VS6.0 msvcrt(d).dll VS2005 msvcr80(d).dll VS2008 msvcr90(d).dll VS2010 msvcr100(d).dll VS2012 msvcr110(d).dll VS2013 msvcr110(d).dll (kein Tippfehler, wie VS2012) **) Die single-Thread-Varianten gibt es nur bei VS6.0
Rufus Τ. Firefly schrieb: > Nö. Das funktioniert ohne Probleme. Sicher? Für Funktionalität, die gänzlich in der Bibliothek steckt (Strings, ...) kann ich mir das ja vorstellen. Aber was ist denn mit Funktionen, die weiter in Richtung Kernel linken? Spätestens beim Syscall sollte die Bibliothek schon irgendwie zum Kern passen, denke ich...
Sven P. schrieb: > Spätestens beim Syscall sollte die Bibliothek schon irgendwie zum Kern > passen, denke ich... Das geschieht natürlich durch dynamisches Linken mit den Betriebssystem-DLLs. Aber deren ABI ist weitestgehend konstant, so daß hier kein Änderungsbedarf besteht. Inkompatibilitäten der verschiedenen Varianten der Win32-API betreffen nicht die von der C-Runtime-Library abgedeckte Funktionalität.
Sven P. schrieb: > Aber was ist denn mit Funktionen, die weiter in Richtung Kernel linken? > Spätestens beim Syscall sollte die Bibliothek schon irgendwie zum Kern > passen, denke ich... Das ist unter Windows etwas anders als unter Linux: API-Aufrufe bleiben unverändert oder bekommen allenfalls neue Parameter, die Aufrufe nach alter Art funktionieren aber weiter. Bei neuen Funktionen werden eher neue Aufrufe vorgesehen in der Art FunktionXY_Ex. Wer also nicht gerade bewusst Funktionen verwendet, die erst mit W7 oder W8 eingeführt wurden, muss sich keine Gedanken machen, dass sein Programm auch auf einem uralten Windows läuft. Erste Ausnahmen: Windows 3.11-Programme laufen unter 64bit-Windows nicht mehr - nach rund 30 Jahren! Selbst Terminal-Programme für WfW3.11 mit der unsäglichen 16bit-COM-Schnittstellen-API laufen noch (unter 32bit), obwohl es längst komplett neue APIs dafür gibt. Gruss Reinhard
Patrick W. schrieb: > Hallo, > > ich suche nach Vorschlägen für eine Programmiersprache, die folgende > Voraussetzungen möglichst erfüllt: > > -es sollte kostenlose oder zumindest preiswerte Compiler für Windows > geben GCC oder Microsoft VisualStudio > -es muss möglich sein, ohne grossen aufwand GUIs zu erstellen Platformunabhängig Qt oder MS VisualStudio nur für Windows > -eine grosse Bekanntheit wäre vorteilhaft > -möglichst direkte Kommunikation mit Hardware ist zwingend Also für Treiber unter Windows braucht es das DDK und damit dürfte GCC erstmal schwieriger werden als VisualStudio > -platformunabhängigkeit wäre schön, ist aber nicht zwingend(kratzt sich > natürlich mit dem oberen Punkt) Ja was nun, es gibt keine plattformunabhängige Treiberentwicklung ??? > -Compilierte Programme müssem auf dem Zielsystem ohne runtime > environment laufen(Java geht folglich nicht) > Dann sag mal an welche "Zielsysteme" bedient werden sollen und welche davon Treiber benötigen ??? Wie schon erwähnt kann man statisch linken dann wird das Programm zwar größer braucht aber keine Version XYZ vom Zielbetriebssystem. Also werde mal konkret um was es eigentlich geht, wenn Windows XP/VISTA/7/8 das aktuelle VisualStudio nehmen und dazu passende DDK. doppelkopfkratz VISTA Treiber laufen unter Win7, XP Treiber nicht oder ? Was ist mit Win8, gehen da auch die VISTA/Win7 Treiber ? Ist zu lang her :-P
Reinhard Kern schrieb: > Wer also nicht gerade bewusst Funktionen verwendet, die erst mit W7 oder > W8 eingeführt wurden, muss sich keine Gedanken machen, dass sein > Programm auch auf einem uralten Windows läuft. Und wer sie unbewusst benutzt? Weil er in seiner Testumgebung gar nicht merkt, dass er damit eine Inkompatibilität erzeugt? Wenn man sein aktuelles System nicht für den Test auf die reduzierte API eines früheren "eindampfen" kann, kann man sowas zumindest nicht verlässlich als "läuft auch unter XYZ" verkaufen. Mein Lieblings-Binary hier ist übrigens:
1 | % ls -l /usr/local/bin/utree |
2 | -rwxr-xr-x 1 bin bin 179639 Apr 30 1992 /usr/local/bin/utree |
Läuft immer noch. ;-) (Zugegebenermaßen allerdings nur noch mit den passenden CompatXY-Optionen im Kernel.) Das wurde compiliert unter 386BSD 0.0 (Version 0.1 kam im Juni 1992 heraus). Boris B. schrieb: > Ich würde zu C# raten. Im Gegensatz zu C++/Qt ist das WIRKLICH > Cross-Platform Aber nur aus dem eingeschränkten Blickwinkel eines eingefleischten Windowsianers. (Dass es der Forderung des TE, ohne Runtime auszukommen, widerspricht, wurde ja schon erwähnt.) .NET gibt es halt autoritativ nur für Windows. Damit steht es schlechter da als Java. Mono hinkt der jeweiligen .NET-Umgebung von Microsoft immer noch ausreichend hinterher (was von Microsoft sicher gewollt ist), und benimmt sich deutlich schwerfälliger (was sicher ebenfalls gewollt ist). Mein Votum wäre auch für Qt: echte Multiplattformfähigkeit, die Abstraktion der jeweiligen Plattform geht weit über die für die GUI-Programmierung notwendigen Dinge hinaus (Verzeichnis-/Dateinamen, Threads), die Dokumentation ist gut, und man bekommt es entweder frei für Opensource-Projekte, oder gegen einen Obulus für kommerzielle Dinge.
Jörg Wunsch schrieb: > Und wer sie unbewusst benutzt? Dann hat er nicht in die Dokumentation gesehen. Aber das passiert nur mit API-Funktionen, nicht --und ich wiederhole: Nicht-- mit Funktionen, die von der C-Laufzeitumgebung aufgerufen werden. Solange man nicht direkte Aufrufe der Win32-API veranstaltet, besteht also überhaupt keine wie auch immer geartete "Gefahr". Erst wenn man irgendeine der zum Win32-SDK gehörenden Headerdateien einbindet und darin deklarierte Funktionen aufruft, erst dann sollte man in der Dokumentation nachsehen, welche OS-Version Voraussetzung ist. Aber auch das ist kein unentwirrbares Problem; da die Win32-API-Aufrufe durch die Verwendung von Importlibraries der entsprechenden DLLs abgewickelt werden, gibt es beim Verwenden solcher Funktionen auf einer diese nicht zur Verfügung stellenden OS-Version ein ganz klar definiertes Fehlerverhalten -- der Programmlader stellt fest, daß er einen "Prozedureinsprungspunkt" nicht finden kann und gibt das als Fehlermeldung aus, das Programm selbst wird gar nicht erst gestartet. Das sieht dann z.B. so aus: "Prozedureinsprungspunkt LogonAsUserW in Kernel32.dll nicht gefunden". > Wenn man sein aktuelles System nicht für den Test auf die reduzierte > API eines früheren "eindampfen" kann, kann man sowas zumindest nicht > verlässlich als "läuft auch unter XYZ" verkaufen. Das ist natürlich immer ein Problem. Nur, welchen Windows-Programmierer interessiert ernsthaft noch die Entwicklung von Programmen, die auf musealen Windows-Versionen laufen? Da gibt es erst recht die geplante Obsoleszenz ...
Rufus Τ. Firefly schrieb: > Aber das passiert nur mit API-Funktionen, nicht --und ich wiederhole: > Nicht-- mit Funktionen, die von der C-Laufzeitumgebung aufgerufen > werden. Hmm, worauf setzt denn dann die C-Laufzeitumgebung aber auf, wenn nicht auf dem OS-API? Klar, fast alles, was zum Standard-Sprachumfang von C89 gehört (C99 ist ja zumindest bei Microsoft sowieso ein Fremdwort), braucht kaum was vom OS-API. system() wäre da noch die berühmte Ausnahme. Aber mit dem bisschen kann man auch nicht viel machen. Einen Compiler schreiben vielleicht :), der muss nur Dateien lesen und schreiben, das ist ausreichend im Standard genormt. Aber für jede reale Applikation kommt man doch über kurz oder lang in Bereiche, in denen man mehr vom OS braucht, als Standard-C hergibt.
Jörg Wunsch schrieb: > Hmm, worauf setzt denn dann die C-Laufzeitumgebung aber auf, wenn > nicht auf dem OS-API? Auf den Teilen, die sich seit Jahrzehnten nicht geändert haben. Die API-Definitionen, die MS 1993 mit der ersten NT-Version herausgegeben hat, sind für die Laufzeitumgebung ausreichend. > Aber für jede reale Applikation kommt man doch über kurz oder lang in > Bereiche, in denen man mehr vom OS braucht, als Standard-C hergibt. Ja. Und da muss man sich sowieso die API-Dokumentation durchlesen. Kein Grund aber, auf den Komfort statisch gelinkter Anwendungen zu verzichten.
Rufus Τ. Firefly schrieb: > Kein Grund aber, auf den Komfort statisch gelinkter Anwendungen zu > verzichten. es gibt aber auch Nachteile! die C-Runtime kann auch Sicherheitslücken enthalten diese werden, hoffentlich, durch MS behoben. Aber in statisch gelinkten Anwendungen sind sie dann immer noch enthalten.
Peter II schrieb: > es gibt aber auch Nachteile! Es bläst die Größe des Executables auch 'ein wenig' auf...
Jörg Wunsch schrieb: > Und wer sie unbewusst benutzt? Weil er in seiner Testumgebung gar > nicht merkt, dass er damit eine Inkompatibilität erzeugt? Das kann es eigentlich nicht geben: wer halbwegs ernsthaft verkaufbare Software programmiert, muss natürlich alles an Testumgebung haben, was er als zulässige Umgebung garantieren will. Das ist ja heute auch kein Problem mehr, ich habe z.B. virtuelle Maschinen von DOS6.22 bis Windows8.1 (und natürlich Linuxe, Solaris, Berkeley...). Und wer noch tiefer einsteigen will, enthält von MS auch Betriebssysteme in allen Sprachen, einschliesslich Chinesisch usw. Bei den API-Funktionen steht im übrigen dabei, ab welcher BS-Version sie verfügbar sind, lesen hilft also auch hier weiter. Wenn ich meine Software nicht unter Windows2000 teste, kann ich natürlich nicht dafür garantieren, dass sie dort auch läuft, aber erfreulicherweise ist das fast immer so. Unter Linux gibt es das anscheinend so nicht, mein VMWare Player muss nach jedem Kernelupdate neu compiliert oder gelinkt werden, manchmal geht es auch erst nach neuem Download. Da wird Kompatibilität also von vornherein überhaupt nicht angestrebt. Gruss Reinhard
Jörg Wunsch schrieb: > Mein Votum wäre auch für Qt: echte Multiplattformfähigkeit, die > Abstraktion der jeweiligen Plattform geht weit über die für die > GUI-Programmierung notwendigen Dinge hinaus (Verzeichnis-/Dateinamen, > Threads), die Dokumentation ist gut, und man bekommt es entweder > frei für Opensource-Projekte, oder gegen einen Obulus für kommerzielle > Dinge. Qt kann man auch mit Closed-Source-Software nutzen, seit es unter der LGPL steht, was soweit ich mich erinnere seit Version 4 so ist. Einzige Einschränkung: Man muß dynamisch linken, um die Lizenzbedingungen zu erfüllen.
Reinhard Kern schrieb: > Und wer noch > tiefer einsteigen will, enthält von MS auch Betriebssysteme in allen > Sprachen, einschliesslich Chinesisch usw. Braucht man auch nur dort. Alle anderen Systeme müssen für diesen Zweck nur die jeweiligen Sprachmodule nachinstallieren. ;-) Nur bei MS muss man dann gleich das ganze OS neu installieren ... > Unter Linux gibt es das anscheinend so nicht, mein VMWare Player muss > nach jedem Kernelupdate neu compiliert oder gelinkt werden, ... VMware greift sehr tief ins System ein, und benötigt die aktive Mithilfe eines Kerneltreibers. Nur dieser wird jedesmal neu compiliert und gelinkt, damit er auch exakt zum Kernel passt. Mit einem normalen API (welches auf dem OS aufsetzt) hat das rein gar nichts zu tun.
Reinhard Kern schrieb: > Unter Linux gibt es das anscheinend so nicht, mein VMWare Player muss > nach jedem Kernelupdate neu compiliert oder gelinkt werden, manchmal > geht es auch erst nach neuem Download. Da wird Kompatibilität also von > vornherein überhaupt nicht angestrebt. Ist aber nur die halbe Wahrheit. Unter Linux strebt man i.d.R. (der geneigte Leser mag die Grenze selbst ziehen...) nicht Binärkompatibilität an, sondern Quellenkompatibilität. Dass es meistens dann doch auch noch binärkompatibel ist, ist ein schöner Seiteneffekt. Dafür kann man dann auch öfter mal die Schnittstellen aufräumen, ohne Jahrzehnte lang alten Ballast mitschleppen zu müssen. Aber gerade für Kernelschnittstellen gibts DKMS.
Hi, zunächst zu den Fragen des Threaderöffners: aufgrund seiner Vorkenntnisse würde ich an dieser Stelle eher zu einem dezenten Mix raten. Wenn eine Oberfläche zu schreiben ist: nimm C#, Java oder einen in C/C++ eingebetteten Webserver. Und letzteres wirklich nur dann, wenn C# oder Java nicht gehen. Wenn hardwarenah zu schreiben ist: nimm C oder C++. Und damit meine ich nicht das Lesen und Schreiben von COM-Ports oder ähnlichen Schnulli, sondern Sachen mit hohen Datenraten, z.B. Frames von 'ner Kamera oder so. Wenn du minimale Dependencies willst: statisch gelinkte C/C++-Binaries sind da das Non-Plus-Ultra. Sei dir bitte im Klaren, dass dein beschriebener Kenntnisstand keine klare Empfehlung einer Programmiersprache zulässt. Wenn du noch nie 'ne UI mit C/C++ gebaut hast, wird das Erlernen von C/C++ kurz- bis mittelfristig teurer für dich sein. Denn die Dottie- bzw. Kaffeebohnen-Programmierer mit ihren Frameworks sind damit um Welten schneller fertig, als du mit C/C++ je sein wirst, weil sie getestete und simpel zu verwendende Komponenten haben. Selbst wenn du QT, wxWidgets, MFC oder welches UI-Framework auch immer nutzt: um Daten zu visualisieren oder anzuzeigen, komplexe Webabfragen, usw. usf. da biste mit .NET oder Java viel schneller fertsch. Fazit: schreib 'ne DLL oder 'ne shared library wo's hardwarenah wird und nutze für UIs Programmiersprachen, deren Design dir den UI-Entwurf einfach macht, sprich: erstell dir ein Portfolio an Programmiersprachen für die jeweiligen Zwecke. C/C++ wäre für den Einstieg eine gute Brücke zwischen hardwarenah und UI, es gibt viele fertige Libs und DLLs - aber ohne diese Zusätze bist du auch aufgeschmissen und erfindest das Rad neu. So wie du deinen Post geschrieben hast, implizieren deine Anforderungen fast C/C++. -- zur Diskussion -- Bei Windows [XP] wird es nur durch die GDI32.dll, Kernel32.dll und User32.dll systemnah. Kommt man daher und schreibt mit dem MASM Code dagegen mit x86-ASM per Hand, kann man über diese Dll-Importe direkt systemnah Grafikfunktionen aufrufen. Diese Stabilität der API ist echt ein Riesen-Plus bei Microsoft. Dabei sind Spracheinstellungen halt feste Constraints des Systems. Ist halt eher ein Top-Down-Design mit bewussten Einschränkungen. In der Linux-Welt funktioniert der dezentrale Entwicklungsansatz sehr gut, mit der Einschränkung, dass sich ABI's ändern können und man sich auch schnell mal das System zerschiessen kann. Der Kernel selber ist da freilich ein Musterbeispiel für Abwärtskompatibilität, das ist schon klar. Und da das System auf vielen kleinen Applikationen aufsetzt, verteilt sich die Komplexität aber eben auf das Gesamtsystem - und nicht wie bei Windows - nur auf die Applikationen. Im Endeffekt isses wurscht: baust du dir so ein Windows Embedded zusammen und lässt Funktionen weg, die deine Software braucht, hast du das gleiche Problem wie bei einem selbstgebauten Linux (z.B. ELDK oder OpenEmbedded) auch: du kannst die Software nicht ausführen.
Jörg Wunsch schrieb: > Braucht man auch nur dort. Alle anderen Systeme müssen für diesen > Zweck nur die jeweiligen Sprachmodule nachinstallieren. ;-) Nur bei > MS muss man dann gleich das ganze OS neu installieren ... Das muss man auch bei MS nicht unbedingt müssen; die Windows-7-Enterprise-Variante, die mit dem MSDN-Paket ausgeliefert wurde, ist eine englischsprachige, der mit verschiedenen Languagepacks nachgeholfen wird. Da kann man dann auch, wie es sich gehört, mit verschiedenen Benutzerkonten in verschiedenen Sprachen gleichzeitig arbeiten. Können tun sie es also schon, die Microsofts, nur standardmäßig machen sie es aus irgendwelchen Gründen nicht.
Hallo, du kannst dir mal PureBasic anschauen. http://www.purebasic.com/german/index.php Ist zwar nicht kostenlos (kostet 79€), lässt sich aber auf Windows, Linux und Mac kompilieren, ist sehr schnell in der Programmausführung, benötigt außer des ausführbaren Datein nichts und hat auch eine gute Commuinty, wenn auch nicht so groß wie die von C/C++. Zudem ist es hervorragend dokumentiert. Zum GUI erstellen ist ein Tool dabei, mit dem das ganze per Drag & Drop sehr intuitiv und schnell geht. Gruß Kai
Thread beobachten
Seitenaufteilung abschaltenBitte 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.