Ich nutze PowerBasic 3.4 unter MSDOS unter OS/2.
Programmieren für DOS/8086 mit Free Pascal?
-
-
wenn "strukturiertes Basic" strukturiert ist, hat es mit Basic aber nur noch den Namen gemein😉
Genauso war Pascal nach Jensen/Wirth außer Lehrzwecken zu nix zu gebrauchen: "Why Pascal is Not My Favorite Programming Language" https://www.cs.princeton.edu/~…l.mirror/notfavorite.html
Deswegen heisst es dann ja auch z.B. Visual Basic oder VBA und nicht einfach nur Basic.
Vor Borland Turbo war Pascal tatsächlich nicht produktiv einsetzbar. Mit Turbo Pascal hat sich das damals geändert. Das war eine Revolution. Ich habe damals viel in Turbo Pascal programmiert. Vor allem DOS-Tools und Prüf-Tools für die Fertigung/Endkontrolle von Industrie-PCs. Aber auch ein kleines Warenwirtschaftssystem.
-
wenn "strukturiertes Basic" strukturiert ist, hat es mit Basic aber nur noch den Namen gemein😉
Genauso war Pascal nach Jensen/Wirth außer Lehrzwecken zu nix zu gebrauchen: "Why Pascal is Not My Favorite Programming Language" https://www.cs.princeton.edu/~…l.mirror/notfavorite.html
Deswegen heisst es dann ja auch z.B. Visual Basic oder VBA und nicht einfach nur Basic.
Vor Borland Turbo war Pascal tatsächlich nicht produktiv einsetzbar. Mit Turbo Pascal hat sich das damals geändert. Das war eine Revolution. Ich habe damals viel in Turbo Pascal programmiert. Vor allem DOS-Tools und Prüf-Tools für die Fertigung/Endkontrolle von Industrie-PCs. Aber auch ein kleines Warenwirtschaftssystem.
Delphi 7 als später TP-Abkömmling wurde bis mind. 2009 noch bei der BKV eingesetzt, wahrscheinlich sogar heute noch. Algol-ähnliche Sprachen sind in der Industrie verbreiteter als mancher denkt. Man sehe sich nur mal PL/SQL von Oracle oder pgsql bei PostgreSQL an
-
1993 habe ich mit Borland Turbo Pascal programmiert.
Beispiel: https://github.com/zhawzid-ottj/skatman1993
Heute würde ich da doch einiges anders machen und meinen Code besser strukturieren und dokumentieren...
...und vermutlich nicht mehr Pascal verwenden.
-
Und was würdest Du verwenden ?
-
Was würde er mit einem modernen Rechner und modernem OS verwenden, oder was würde er verwenden, wenn er das mit einem 486er und MS-DOS machen würde ?
-
Wenn es gerade nicht Pascal sein soll, bietet sich der OpenWatcom C/C++-Compiler an.
Was FreePascal für 8086 angeht, hatte ich sogar schon mit dem Gedanken gespielt, dafür das BGI-Interface mit Graph-Unit nachzubauen, aber irgendwie hat der Tag nicht genug Stunden.
-
Was würde er mit einem modernen Rechner und modernem OS verwenden, oder was würde er verwenden, wenn er das mit einem 486er und MS-DOS machen würde ?
Gemeint war das erstere. Aber es ist natürlich auch interessant, was er heute auf einem 486er was machen würde. Ist aber nicht so wirklich relevant, weil das wohl nur noch wenig Leute machen.
Interessant wäre ja auch: Gäbe es was, was man aus heutiger Sicht damals(TM) besser hätte verwenden sollen.
-
Was FreePascal für 8086 angeht, hatte ich sogar schon mit dem Gedanken gespielt, dafür das BGI-Interface mit Graph-Unit nachzubauen, aber irgendwie hat der Tag nicht genug Stunden.
Sowas gibt es doch bestimmt schon lange. Da muß man mal intensiver suchen gehen.
Außerdem wird es wohl auch andere Grafik-Interfaces geben, die da benutzbar wären. Manche evtl. sogar schneller (?).
-
Da würde ich nicht drauf wetten. FreePascal für 8086 ist ja noch ziemlich brandneu.
Andere Grafik-Interfaces gibt es sicherlich, aber die sind dann auch wieder mit nichts kompatibel.
-
Habe mal bei FreePascal auf der Seite nachgesehen. Da gibt es schon ein paar Empfehlungen für Grafik Bibliotheken, aber für DOS ist wirklich wenig dabei. Außerdem fehlen oft die Webseiten, weshalb man da dann nichts mehr findet, oder woanders suchen muß.
Aber es gibt da was, was irgendwie brauchbar aussieht und schonmal die wichtigen Basics mitbringt
https://sourceforge.net/projects/ptcpas/
So richtig direkte Geometrieanweisungen etc. habe ich nicht gefunden, aber das wäre zumindst was, was anscheinend auhc überall läuft.
-
Das hört sich nach der passenden Gelegenheit an, hier ein paar Links reinzustreuen:
Und zwar einmal: Borland's BGI graphics terminal driver format
Und dann noch diesen FTP-Ordner: ftp://ftp.musoftware.de/pub/uz/bgi/
-
Und was würdest Du verwenden ?
Heute würde ich C++ verwenden (sowohl auf einer alten als auch auf einer neuen Maschine)
Da hat man auch alle Möglichkeiten, tiefer (C++ --> C --> Assembler) zu integrieren, falls man das möchte.
(Geht natürlich mit Turbo Pascal z.B. auch, aber man ist mit Pascal einfach "weiter weg" von der Basis)
Auf alten Maschinen ist das manchmal dann ein guter Ansatz, zeitkritische Dinge zu optimieren.
Und wenn man C++ kann, kommt einem alles andere plötzlich viel einfacher vor.
Das heisst nicht unbedingt, dass C++ zu lernen schwierig ist.
Gut C zu programmieren ist dann schon härter, da man dort die komplette Verantwortung
über das Speicher-Management hat (und auf OOP verzichten muss, und schon deshalb würde ich von Pascal abraten).
-
Alles anzeigen
Und was würdest Du verwenden ?
Heute würde ich C++ verwenden (sowohl auf einer alten als auch auf einer neuen Maschine)
Da hat man auch alle Möglichkeiten, tiefer (C++ --> C --> Assembler) zu integrieren, falls man das möchte.
(Geht natürlich mit Turbo Pascal z.B. auch, aber man ist mit Pascal einfach "weiter weg" von der Basis)
Auf alten Maschinen ist das manchmal dann ein guter Ansatz, zeitkritische Dinge zu optimieren.
Und wenn man C++ kann, kommt einem alles andere plötzlich viel einfacher vor.
Das heisst nicht unbedingt, dass C++ zu lernen schwierig ist.
Gut C zu programmieren ist dann schon härter, da man dort die komplette Verantwortung
über das Speicher-Management hat (und auf OOP verzichten muss, und schon deshalb würde ich von Pascal abraten).
nun ja zu C++ gibts ja durchaus kontroverse Ansichten "C++ is Good for the Economy, It Creates Jobs!" http://harmful.cat-v.org/software/c++/
Um OOP zu verstehen, würde ich eher Java, Smalltalk oder andere moderne Sprachen ohne Altlasten empfehlen.
Und dazu Klassiker lesen wie "Design Pattern" oder "Refactoring". Nach meiner Erfahrung lenkt die immense Komplexität von C++ nur von der eigentlichen Schönheit des OOP-Konzeptes ab. Wenn ich nur an das verkorkste Kon-/De-struktoren-Konzept in C++ denke, wird mir schlecht. Selbst beim String-Handling muss man um Ecken denken. Aber klar, wenn am Ende Maschinencode herauspurzeln muss, gibt es wenige Alternativen
-
Grundsätzlich gebe ich dir Recht, C++ hat sicherlich Haken und Ösen.
Bei alten Maschinen halte ich das aber für relativ alternativlos. Ich denke, Java ist dort gar keine gute Option.
Und auf neuen Maschinen - würde ich natürlich erst mal den Kontext betrachten und danach entscheiden.
Zum Beispiel ist Typescript (=JavaScript Transpiler) inzwischen auch eine schicke Sache geworden.
