Hallo zusammen, bei einigen Projekten in der Vergangenheit habe ich VB5 benutzt, um Daten zwischen PC und einer Embedded Schaltung auszutauschen. Z.B. Daten für Parametrierung (PC>MCU) oder Visualisierung im Chart von Messdaten (MCU>PC). Mittlerweile habe ich auch C zum Programmieren im Griff. Welches Programmiertool würdet ihr mir als Nachfolger für neuere Projekte empfehlen. VB5 war so schön einfach zu programmieren.....
Dirk F. schrieb: > VB5 war so schön einfach zu programmieren..... Es gibt VB6. Das ist immerhin etwas neuer. Und noch neuer gibt es natürlich VB.net, das auf dem .Net-Geraffel aufsetzt. Die entsprechende Entwicklungssoftware dafür, "Visual Studio", ist allerdings ein ziemlicher Moloch, wenn auch in der "Community Edition" kostenlos verfügbar. https://visualstudio.microsoft.com/de/vs/community/ (Nicht mit "Visual Studio Code" verwechseln, das ist etwas komplett anderes). Python gegenüber hat das den Vorteil, daß weiterhin *.exe-Files hinten rauskommen, und daß graphische Editoren für Dialoge etc. enthalten sind. Andersherum kann einem Python (zusammen mit irgendeinem Toolkit für die GUI-Programmierung) auch den Weg bahnen, auch für andere Betriebssysteme als Windows zu programmieren. Toolkits für GUI-Programmierung wären z.B. https://doc.qt.io/qtforpython-6/ https://wxpython.org/index.html https://www.gtk.org/docs/language-bindings/python
>Python gegenüber hat das den Vorteil, daß weiterhin *.exe-Files hinten >rauskommen Stichwort "pyinstaller": To make an executable (.exe) file from a Python script, you can use tools like PyInstaller, which is the most popular and easy-to-use option.
Dirk F. schrieb: > Welches Programmiertool würdet ihr mir als Nachfolger für neuere > Projekte empfehlen. > VB5 war so schön einfach zu programmieren..... Sieh dir mal "Xojo" an, ist aber nicht kostenlos. Die IDE gibts für Windows, MacOS, und Linux. Man kann auf jedem System auch für jedes andere compilieren. Die IDE enthält einen GUI-Designer, bei dem die jeweils gewünschten Events übersichtlich ein- und ausgeschaltet werden können und nicht das Projekt mit kaum lesbaren Code vollmüllen. Man kann in der IDE ohne jede Einschränkung beliebig lange programmieren und den Code auch ausführen, nur für eigenständige Programme compilieren braucht eine Lizenz. Ausnahme: Zielsystem Raspberry, das ist frei. Xojo kann Console-Programme/Dienste/Dämons, normale Desktop-Apps mit GUI und sog. "Web-Apps". Letzters ist ein multi-user-fähiger Webserver mit GUI, dessen Seiten man in der IDE visuell zusammenbaut - ziemlich einzigartig! Ausserdem Apps für Android und iOS ... https://documentation.xojo.com/resources/system_requirements_for_current_release.html
Frank E. schrieb: > Sieh dir mal "Xojo" an Hieß früher "RealBASIC", und ist in der Tat empfehlenswert, um alten VB-nicht-.net-Code weiterzubetreiben.
Mein Weg war von ..., VB5, RealBasic/Studio, Xojo 2014 zu PureBasic. Die wichtigsten Vorteile beim Wechsel zu PureBasic waren für mich: - man kann die GUI komplett per Code erstellen. - es gibt echte Threads. - die IDE ist portabel und funktioniert auch mit alten PCs und aktuell noch mit Windows 7. - kostete damals € 70,- mit Updates auf Lebenszeit für alle Platformen (gilt noch, wird in Zukunft geändert). Peter
Dirk F. schrieb: > Hallo zusammen, > bei einigen Projekten in der Vergangenheit habe ich VB5 benutzt, um (...) > Welches Programmiertool würdet ihr mir als Nachfolger für neuere > Projekte empfehlen. VB5 war so schön einfach zu programmieren..... Am Anfang (vor sehr vielen Jahren) habe ich VB6 für das Erstellen von PC-Anwendungen (.exe) genommen, später habe ich dann zu vb.NET, der als Nachfolger betrachtet werden kann, gewechselt (mit Visual Studio 2010, 2019 und 2022), was aber mit einem relativ großen Aufwand bezüglich der Umstellung beim Programmierstil verbunden ist, weil es hier deutlich objektorientierter zugeht. Mittlerweile bin ich bei vb.NET von WinForms- zu WPF-Applikationen (Visual Basic XAML) übergegangen, weil das sehr viele grafischen Vorteile bittet und das Bild beim Skalieren nicht unscharf wird (die Unschärfe kann man bei WinForms mit einem Trick aber auch unterbinden, was ich eine zeitlang auch genutzt habe). Eine gute, ausgereifte Einarbeitung dauert in der Regel Monate bis Jahre, es hängt immer davon ab, wieviel Zeit man pro Woche oder pro Tag investieren kann oder möchte – lohnen tut es sich aber trotzdem. Erste sehr simple Anwendungen mit Buttons, Text- oder ComboBoxen etc. kann man mit dem kostenlosen Visual Studio 2022 aber sofort erstellen und ausprobieren, insofern ist das immer auch eine Frage, wie tief man hier in die Materie einsteigen will, es gibt außerdem auch viele VideoTutorials auf youtube. Mit Klassenerstellung, Vererbung, Überschreibung, Einkapselung, Multithreading, SyncLock muss man sich nicht unbedingt sofort am Anfang auseinandersetzen und herumplagen – das begreift man am Anfang eh nicht, wenn man von VB5 oder VB6 wechselt.
:
Bearbeitet durch User
Dirk F. schrieb: > VB5 war so schön einfach zu programmieren..... Noch schöner wars dann, wenn danach der Schmerz nachließ. Wie oben schon gesagt wurde, nimm Python. Oliver
Peter D. schrieb: > Die wichtigsten Vorteile beim Wechsel zu PureBasic waren für mich: > - man kann die GUI komplett per Code erstellen. > - es gibt echte Threads. > - die IDE ist portabel und funktioniert auch mit alten PCs und aktuell > noch mit Windows 7. Die GUI komplett per Code erstellen mache ich zwar auch lieber, aber es gibt einige, die sowas nur per Designer erstellen können oder wollen. Naja, was mich betrifft, ist der Designer, den Purebasic mitliefert, auch nicht das Gelbe vom Ei. Was mich auch etwas stört, ist die Abwärtskompatibiltät zu älteren Quellcodes. Oftmals müssen da einige Änderungen gemacht werden, bis älterer Quellcode wieder läuft, wenn man natürlich immer Up to date mit den PB-Versionen sein möchte. Aber vielleicht bin ich auch nur etwas verwöhnt.
:
Bearbeitet durch User
Vielen Dank für die Hinweise. Also es geht mir nicht darum ale VB5 Projekte weiter zu bearbeiten. Vielmehr suche ich ein IDE für neue Projekte, bei der man das GUI schön einfach grafisch per Drag&Drop erstellen kann, und dann am Besten den Code in C schreiben.
:
Bearbeitet durch User
Ich finde Purebasic recht gelungen. Gibt's für Linux und Windows, erzeugt nur ein executable und hat vieles was man braucht. Edit: habe selber vor vielen Jahren sehr viel beruflich in VB5 programmiert.
:
Bearbeitet durch User
Dirk F. schrieb: > Vielmehr suche ich ein IDE für neue Projekte, bei der man das GUI schön > einfach grafisch per Drag&Drop erstellen kann, und dann am Besten den > Code in C schreiben. Hast du dir schon mal Eclipse angesehen? Abgesehen davon wären ein paar Grundkenntnisse und -Techniken in Java auch nicht so verkehrt. Mit Python-Sachen habe ich in Windows so meine Probleme (Admin/Benutzerkonto, Versionen) weswegen ich für Python eher Linux als OS empfehlen würde. Wobei..Eclipse war früher auch einfacher, ..recht beliebt war damals auch C# -wäre aber dann auch Net-Arbeitstisch (https://www.uni-trier.de/fileadmin/urt/doku/csharp/v60/csharp6.pdf). Für C wäre aber auch VisualStudio (s.o.) nett, u.a. wegen dem Debugger da.
Falls es auch C++ sein darf würde ich QT Creator empfehlen. Da kannst du deine Fenster per drag&drop mit Widgets gestalten und dann mit der rechten Maustaste leere Funktionen erstellen, die beim Klick (und anderen Ereignissen) ausgeführt werden. Um mit dem QT Framwork zurecht zu kommen muss man C++ nicht in der vollen Komplexität beherrschen. Es genügen wenige Grundlagen der OOP. http://stefanfrings.de/qt_lernen/
:
Bearbeitet durch User
Und wenn wir schon dabei sind: Dann kann man auch wxWidgets verwenden (ja, das habe ich mit einem Python-Binding schon erwähnt), für das gibt es z.B. mit DialogBlocks einen GUI-Editor, der mittlerweile frei verfügbar ist. Ein anderer GUI-Builder ist https://github.com/wxFormBuilder/wxFormBuilder wxWidgets ist das GUI-Toolkit, das u.a. von Audacity verwendet wird. Freunde des 3d-Drucks kennen vielleicht auch den PrusaSlicer oder Slic3r. Auch die nutzen wxWidgets.
Warum muss es dann eigentlich Basic sein, wenn du sowieso auch in C arbeiten magst? Wenn es dir um GUI geht, wäre ja Lazarus / Freepascal die Referenz https://www.lazarus-ide.org/ Hier wird der Gui Creator gezeigt https://www.youtube.com/watch?v=gjlBbQca1k8 https://www.youtube.com/watch?v=2PDhv_q4gyU Aber wenn du auch mit Ca Arbeiten magst, dafür gibt es doch auch GUI Creator? Vielleicht nicht so einfach und ausgereift wie bei Lazarus oder BAsic, aber das geht doch auch
:
Bearbeitet durch User
Dirk F. schrieb: > Vielen Dank für die Hinweise. > Also es geht mir nicht darum ale VB5 Projekte weiter zu bearbeiten. > > Vielmehr suche ich ein IDE für neue Projekte, bei der man das GUI schön > einfach grafisch per Drag&Drop erstellen kann, und dann am Besten den > Code in C schreiben. Dann nimm Embarcadero C++ Builder. Der ist als Community-Edition kostenlos, Du muß Dich aber registrieren. Du klickst Dir die Gui zusanmmen, und verbindest sie dann mit Deinem C, Cpp oder Pascalcode. Der Builder erzeugt dann Quellcode und kompiliert diesen dann zu ner nativer Exe. mfg
:
Bearbeitet durch User
Angehängte Dateien:
Dirk F. schrieb: > Vielmehr suche ich ein IDE für neue Projekte, bei der man das GUI schön > einfach grafisch per Drag&Drop erstellen kann, und dann am Besten den > Code in C schreiben. Ich habe vergessen zu erwähnen, dass quasi alles in Visual Studio alternativ auch mit C# geht – der VB- und C#-Code bewirken oder führen im Hintergrund eigentlich das gleiche aus, nur wird es halt anders ausformuliert/geschrieben. Wenn man die richtige Anwendung wählt, bekommt man (zumindest unter .NET-Framework) am Ende nach dem Build auch nur eine .exe-Datei, die Ressourcen werden in diese integriert – falls diese sehr groß sein sollten, muss man das anders lösen. Auf kleine Unterschiede und Ausnahmen (Vor- und Nachteile) der beiden Sprachen wird man aber auch stoßen, wenn man z.B. mit mehreren Fenstern im Code arbeiten möchte – u.a. deswegen habe ich mich bei meinen Projekten für den VB-Dialekt entschieden. Durch die strukturierte Programmierung schreibt sich selbst der VB-Code mittlerweile aber fast schon wie C-Code, so etwas wie GOTO braucht man schon lange nicht mehr. WPF ist übrigens deutlich komplexer und komplizierter als WinForms, der Vorteil ist aber, dass die auf dem Bildschirm dargestellte Grafik hier direkt über die Grafikkarte verfügen und man somit zusätzliche, bessere Effekte erzielen kann. Eine WPF-App kann man auch sehr unkonventionell (wie ich es tue) programmieren, also nicht nach dem immer wieder nachgeplapperten Dogma der ganzen „Gurus” im Netz.
:
Bearbeitet durch User
Gregor J. schrieb: > Ich habe vergessen zu erwähnen, dass quasi alles in Visual Studio > alternativ auch mit C# geht – der VB- und C#-Code bewirken oder führen > im Hintergrund eigentlich das gleiche aus, nur wird es halt anders > ausformuliert/geschrieben. In Wirklichkeit ist es so, dass in C# sogar noch ein wenig mehr geht. Und der Abstand wird leider mit jeder neueren DotNet-Version größer. Effektiv hat MS die Weiterentwicklung von VB(.net) schon seit Jahren praktisch eingestellt. Es wird noch mitgeschleppt, es kommt aber nix Neues mehr dazu. Inzwischen ist sogar von VB aus nicht mehr das gesamte Framework nutzbar. Dieser Sachverhalt ist allerdings relativ neu. Lange Zeit war es so, dass man zwar einige Komponenten des Frameworks mit VB nicht mehr hätte programmieren können, aber immerhin die Nutzung dieser Komponenten war auch von VB aus immer noch in vollem Umfang möglich. > Durch die strukturierte Programmierung > schreibt sich selbst der VB-Code mittlerweile aber fast schon wie > C-Code Tsss.... Von Anfang an war VB.net sehr viel besser als C, was die Codestruktur betrifft. Das war immerhin von Anfang an typsicher und eine echte OO-Sprache. Man konnte allerdings historischen VB5/6-Code oft mit keinen oder nur geringen Änderungen auch als VB.net-Code verwenden. Dann war die Struktur natürlich genauso Scheiße, wie sie halt in diesen historischen VB-Programmen war. Aber: Das sind historische Betrachtungen. Das war so Anfang der 2000er Jahre, also vor fast einem Vierteljahrhundert.
Hier noch ein Video zum Anschauen auf Deutsch – ist schon etwas älter, aber immer noch sehr aktuell – vielleicht inspiriert es den einen oder anderen, wirklich real in Richtung Programmieren etwas zu tun, statt immer nur in einer Endlosschleife auf µC.Net zu labern und gefangen zu sein ohne jemals wirklich etwas gemacht zu haben (das gilt auch für die Elektronik): https://av.tib.eu/media/9700 Und hier noch zwei Links zum Code-Translator zwischen C# und vb.NET – ist manchmal sehr nützlich, da Microsoft (https://learn.microsoft.com *) die Code-Beispiele sehr oft nur in C# veröffentlicht; hier sieht man auch, dass der Code dieser Sprachen quasi weitestgehend untereinander austauschbar sein muss, wenn ein einfaches Programm das in beide Richtungen übersetzen kann (das klappt allerdings nicht immer, was aber auch am Übersetzungsprogramm selbst liegen kann): 1. https://converter.telerik.com/ (**) 2. https://www.e-iceblue.com/tools/online-csharp-vbnet-converter.html Jemandem, der wirklich etwas machen will, wünsche ich viel Erfolg, Kraft und vor allem Ausdauer beim Recherchieren und Lesen der Inhalte, um weiterzukommen. ___ (*) ein Beispiel: https://learn.microsoft.com/de-de/dotnet/api/system.windows.forms.openfiledialog?view=netframework-4.8 (**) dieser Translator kommt mit dem Using-Block nicht klar und man muss es zum Übersetzen aus dem C#-Code entfernen
:
Bearbeitet durch User
Angehängte Dateien:
-
processing_cover.jpg
26 KB
Ich, als eingefleischter XOJO-User hab mir tatsächlich mal PureBasic für Mac installiert und ein wenig damit herumgemacht. Meine Lieblings-Demo für die "Handlichkeit" einer Programmierumgebung ist immer ein kleines Tool (mit GUI), mit einer Listbox und zwei Buttons, "Run" und "Quit", das eine ASCII-Liste anzeigt (Code von 0 bis 255 und Zeichen in zwei Spalten). Mein Fazit: Hmmm, naja, könnte man machen, habs mir schlimmer vorgestellt. Die gemeinsamen Basic-Wurzeln machen es halbwegs verständlich. Aber Xojo ist trotzdem wesentlich "handlicher". Alleine das Aufteilen eines Projektes in mehrere Dateien, die (gefühlte) Überflutung mit Optionen und Events (die auch Xojo alle hat und kennt, die ich aber erst aktiviere, wenn ich sie wirklich benötige) usw ... Da ist sicher auch vieles einfach nur Gewöhnung. Wie gesagt, habs mir schlimmer vorgestellt :-) Dann will ich mal noch ein weiteres plattform-übergreifendes Tool (free) in den Ring werfen: "Processing" (processing.org)! Das verwende ich seit einiger Zeit recht erfolgreich für Kurse "Grundlagen des Programmierens". Zusammen mit dem Buch von Bartmann, was auf sehr unterhaltsame Weise richtig Lust aufs Programmieren macht - wichtig für die Motivation. Der Code ist eine Mischung aus C++ und Java, also gut weiterverwendbar ...
:
Bearbeitet durch User
Frank E. schrieb: > Dann will ich mal noch ein weiteres plattform-übergreifendes Tool (free) > in den Ring werfen: "Processing" (processing.org)! Das ist die Ursuppe, aus der das Arduino-System entstanden ist.
Harald K. schrieb: > Frank E. schrieb: >> Dann will ich mal noch ein weiteres plattform-übergreifendes Tool (free) >> in den Ring werfen: "Processing" (processing.org)! > > Das ist die Ursuppe, aus der das Arduino-System entstanden ist. Ich glaube,es war eher umgekehrt: Man wollte dem Arduino-System auf PC/Mac-Seite einen Kommunikations-Partner gegenüberstellen. Vorzugsweise mit nahezu identischer Syntax. Aber sei es wie es sei, deswegen ist es nicht schlecht. Wichtiger Vorteil aus meiner Sicht: Wegen der Java-"Seele" gut plattform-übergreifend, heutzutage einfach ein Muss.
Nachtrag zu Purebasic: Wirklich beeindruckt hat mich die geringe Größe der compilierten Testanwendung (ASCII-Liste mit GUI): Ganze 123kB (k!!! nicht M!!!). Allerdings kann ich im Moment nicht einschätzen, wie viele zusätzliche bzw. versteckte Abhängigkeiten da noch dranhängen, musste schließlich extra XCode (MacOS) installieren. Bei einem Java-Programm kommt schließlich auch noch die JRE mit zig MByte hinzu. Ich werde die App mal auf einen anderen Mac kopieren, der vorher noch nie mit PureBasic und XCode in Berührung gekommen ist ... mal sehen, ob es läuft ... ------------ So, Test gemacht, die App schleppt keine versteckten Abhängigkeiten mit sich herum. Nach dem üblichen "... stammt von einem nicht verifizierten Entwickler, trotzdem ausführen?" ist es problemlos gestartet. Wegen der geringen Größe ist es für mich insbesondere für kleinere Raspis interessant. Werde mal forschen, was da so geht. Das auf dem Raspi von aller Welt bevorzugte Python ist aus meiner Sicht gerade für GUIs ein ziemlicher Krampf ...
:
Bearbeitet durch User
Frank E. schrieb: > Ich glaube,es war eher umgekehrt: Man wollte dem Arduino-System auf > PC/Mac-Seite einen Kommunikations-Partner gegenüberstellen. Vorzugsweise > mit nahezu identischer Syntax. Processing gibt es seit 2001; Wiring als Vorläufer des Arduino gabs 2004 und ein Jahr später als Fork von Wiring dann den Ur-Arduino.
"Nachtrag zu Purebasic: Wirklich beeindruckt hat mich die geringe Größe der compilierten Testanwendung (ASCII-Liste mit GUI): Ganze 123kB (k!!! nicht M!!!)." Das ist auch das tolle an Lazarus Pascal Programmen, simpel, extrem klein. Basic und Pascal sind schon schöne Sprachen.
123 kB ist ziemlich fett für so eine einfache Anwendung, nichts was heute weh tut aber auch nichts zum Jubeln. Nimm eine Win32 Anwendung mit Visual Studio, da kommst du auf unter 32 kB für ein GUI mit einer Liste. Die Entwicklung ist mit dem grafischen Visual Studio Editor super einfach.
Udo K. schrieb: > Nimm eine Win32 Anwendung > mit Visual Studio, da kommst du auf unter 32 kB für ein GUI mit einer > Liste. Kann es sein, daß Du da diverse zig Megabytes an DLL-Geraffel unterschlägst?
Udo K. schrieb: > 123 kB ist ziemlich fett für so eine einfache Anwendung, nichts > was > heute weh tut aber auch nichts zum Jubeln. Nimm eine Win32 Anwendung > mit Visual Studio, da kommst du auf unter 32 kB für ein GUI mit einer > Liste. Die Entwicklung ist mit dem grafischen Visual Studio Editor super > einfach. Ganz sicher inklusive aller Laufzeit-Module, die du mitsamt der IDE installiert hast?
Als Beispiel mal ein einfaches Direct2D Program mit 33 kB und ein Dialogfenster mit einem RichEdit Control, einer ListBox, einer normalen EditControl und einigen Buttons mit 59 kB und einem Notepad.exe mit Richedit Unterstützung und umschaltbaren Themes mit 210 kB (das leider noch nicht fertig ist). Die Programme laufen auf jedem 64 Bit Windows ohne zusätzliche DLLs und verwenden nur das Win32 Api. Die Basis ist eine ältere Version des Win32++ Framework von David Nash ohne dem C++ Bloat der neueren Version: https://sourceforge.net/projects/win32-framework/. Das Framework ist ähnlich zu dem MFC von Microsoft. Da möchte ich auch noch https://codejock.com/ in den Raum werfen. Das kostet zwar einmalig, aber damit lassen sich technische Anwendungen schnell erstellen. Der Vorteil vom Windows API ist das es in C programmiert werden kann, und das kann der TE, und bei Bedarf kann man fliessend auf C++ oder auf C# wechseln.
:
Bearbeitet durch User
Thomas R. schrieb: > Basic tut weh! Immer wenn ich "goto" lese werden meine Zehennägel hoch gerollt.
Thomas R. schrieb: > Thomas R. schrieb: >> Basic tut weh! > Immer wenn ich "goto" lese werden meine Zehennägel hoch gerollt. Dann wirst du wohl eines Tages mit nicht gerollten Nägeln sterben. Moderne Basic-Versionen haben das längst nicht mehr. Xojo und PureBasic sind längst in der OOP-Welt angekommen, im Gegensatz zu manchem C-Klempner (sofern er sich das "++" spart) :-) Bei der Installation von PureBasic auf dem Mac wurde ich zur gleichzeitigen Installation von Xcode genötigt. Beim ersten Versuch, ein Testprojekt zu compilieren, erschien eine Meldung, dass nun GCC ... verwendet würde. Das "riecht" m.E. danach, dass die ganze "Basic-Welt" davor ohnehin nur eine Art Code-Mapping darstellt und im Hintergrund alles über C/C++ läuft. Schattenspiele?
Udo K. schrieb: > Der Vorteil vom Windows API ist das es in C programmiert werden kann, > und das kann der TE, und bei Bedarf kann man fliessend auf C++ oder auf > C# wechseln. Ja und der Nachteil ist, dass es ausschließlich unter Windows läuft. Das ist zwar wichtig, aber die Welt ist größer ...
Frank E. schrieb: > Das "riecht" m.E. danach, dass die ganze "Basic-Welt" > davor ohnehin nur eine Art Code-Mapping darstellt und im Hintergrund > alles über C/C++ läuft. Das wird eher an restriktiven Auflagen von Apple liegen, was Codesignierung, das Linken etc. angeht. Könnte aber auch mit der iOS-Unterstützung von Xojo zu tun haben, dafür ist definitiv xcode erforderlich. Andererseits ist auf einem Mac sowieso schon ein C- bzw. C++-Compiler anwesend, ganz ohne daß man xcode installieren müsste. Das ist llvm bzw. clang. Keine besonders aktuelle Version, aber immerhin:
1 | % clang --version |
2 | Apple clang version 12.0.0 (clang-1200.0.32.21) |
3 | Target: x86_64-apple-darwin23.6.0 |
4 | Thread model: posix |
5 | InstalledDir: /Library/Developer/CommandLineTools/usr/bin |
(das ist jetzt von einem Mac mit "Sonoma") Und mit dem Ding kann man ausführbare Binaries erzeugen. Ruft man "gcc" auf, landet man auch bei clang:
1 | gcc --version |
2 | Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 |
3 | Apple clang version 12.0.0 (clang-1200.0.32.21) |
4 | Target: x86_64-apple-darwin23.6.0 |
5 | Thread model: posix |
6 | InstalledDir: /Library/Developer/CommandLineTools/usr/bin |
Dirk F. schrieb: > Welches Programmiertool würdet ihr mir als Nachfolger für neuere > Projekte empfehlen. Gar keines, das musst du selber entscheiden.
Frank E. schrieb: >> Der Vorteil vom Windows API ist das es in C programmiert werden kann, >> und das kann der TE, und bei Bedarf kann man fliessend auf C++ oder auf >> C# wechseln. > > Ja und der Nachteil ist, dass es ausschließlich unter Windows läuft. Das > ist zwar wichtig, aber die Welt ist größer ... Stimmt doch nicht. Dank Wine laufen Win32 API Programme problemlos unter Linux oder auch auf dem Mac.
Udo K. schrieb: > Stimmt doch nicht. Dank Wine laufen Win32 API Programme problemlos > unter Linux oder auch auf dem Mac. Schon unter Windows selbst ist die Idee, native Win32-API-Programme mit GUI in C zu schreiben mehr als grenzwertig, aber Wine als Portabilitätsargument anzuführen setzt dem Fass noch die Krone auf.
Cobol, Forth und Fortran sind DIE ZUKUNFT!
Harald K. schrieb: > Schon unter Windows selbst ist die Idee, native Win32-API-Programme mit > GUI in C zu schreiben mehr als grenzwertig, aber Wine als > Portabilitätsargument anzuführen setzt dem Fass noch die Krone auf. Warum nicht, die W32 API ist stabil daran wird nicht mehr rumgepfuscht, Wine deckt die praktisch komplett ab und steht somit dauerhaft zur Verfügung. Das ist ne solide Basis ohne Überraschungen. Genau das will man als Entwickler haben, deshalb ist auch Java so erfolgreich, superstabile APIs, wenn geändert dann mit Bedacht und zur Not kann man immer noch ein älteres jre/jdk betreiben - läuft. Probier mal hingegen alte Sourcen aus der i386er Linuxära auf einem aktuellen x86_64 Linux zu bauen, mit den gängigen Libs von damals: gtk1, oder ein olles qt oder sonst was aus der Zeit was da noch üblicherweise drann hin, das geht schon bei der glib los, viel Spass beim Anpassen, wenn du je irgendwann fertig wirst.
Frank D. schrieb: > Warum nicht, die W32 API ist stabil daran wird nicht mehr rumgepfuscht, Ja, das stimmt. Aber GUI-Programmierung in C, mit einem ereignisorientierten System, das bereitet so viel Schmerzen, daß Leute nicht ohne Grund angefangen haben, Klassenbibliotheken für C++ dafür zu entwickeln und die zu nutzen. Sicher, das Zeug zu kennen, ist wertvolles Grundlagenwissen, aber ... Ich hab vor 35 Jahren auch die Windows-Api (damals noch 16 Bit) in C zu programmieren, der Petzoldt war dabei hilfreich. Und ich hab das dann ab etwa Herbst '92 auch mit der Win32-Api gemacht (mit einer der Beta-Versionen von Windows NT 3.1), ich kenne das Zeug also durchaus. Aber ... man muss schon an hartem Masochismus leiden, wenn man das benutzen will, um GUI-Programmierung zu betreiben. Und/oder die Programme sehen grindig aus, halten sich an keinerlei GUI-Konventionen ... manchmal begegnet man solchen Fossilien. Und das als Grundlage für plattform"unabhängige" Programmierung, immer darauf hoffend, daß man nicht vielleich doch etwas so abartiges anstellt, daß die Wine-Nachbildung nicht doch auf die Fresse fällt? Da würde ich mir eher sowas wie Gtk antun. Das ist unter unixoiden Systemen nativ, das wird aktiv genutzt ... und auch weiterentwickelt.
Beitrag #7920570 wurde vom Autor gelöscht.
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.