Mit welchem Setup entwickelt man heute?

[Alexco]

Habe hier in meinem alten OS/2 Fundus noch Visual Age C++ 3.0/4.0 gefunden. Damals (TM) benötigte man unter Umständen ja auch irgendwelche kostenpflichtigen SDK/DDK. Wie ist das denn heute? Gibt es ein modernes Setup, was man als All-In-One Paket installieren kann/sollte, z.B. GCC, Clang, Open Watcom? Oder kann man die alten Sachen weiter nutzen?

[aschn]

Bei den IBM-Compilern sind es 3.08 und 3.6.5. Die Version 4.x ist zu unstabil.

Bei neueren Projekten wurde häufig Open Watcom oder GCC verwendet.

Das aktuellste IBM-Toolkit 4.5 (einige Fixes sind in den Arca-Noae-Produkten enthalten) sollte immer verwendet werden. Die Umgebungsvariablen müssen so gesetzt werden, dass zuerst vorhandene Dateien aus dem Toolkit geladen werden, danach erst aus dem Compilerbaum. Wichtig ist häufig auch, dass man ein gepatchtes rc.exe verwendet (bei AN im Toolkit dabei).

Nachdem das Toolkit feststeht, ist der Compiler nicht so entscheidend. Die Pakete unterscheiden sich ordentlich durch ihre Debugger. Dafür ist wohl immer noch die IBM-Schiene deutlich im Vorteil.

Bei Portierungen nimmt man GCC, evtl. mit einigen Komponenten (Linker, IPF-Kompiler) aus OW.

[Andi B.]

Gibt es ein modernes Setup, was man als All-In-One Paket installieren kann/sollte,

Eher nicht. Ein nahezu Komplettpaket welches nicht ganz so extrem veraltet ist wie die anderen Lösungen, ist OpenWatcom. Aber wenn man was mit GUI machen will, die Ansätze die bei Watcom dafür dabei waren, sind seit mehr als 10 Jahren schon rausgeflogen und ohnehin nicht mehr brauchbar. Ebenso die mitgelieferte Spielzeug IDE welche nur zum ersten basteln und lernen brauchbar ist. CLI Programme, auch CrossPlatform, kann man damit durchaus machen. Brauchbar, aber mit moderner SW Entwicklung hat das alles nichts zu tun.

Es kommt drauf an was man machen will. Die IBM Compiler haben für OS/2 Programme auch ein passendes Toolkit dabei. Wobei man heute für neuere Sachen aber eher die Installation umbiegen sollte auf das os2tk45 mit den Fixes. Beste Quelle dafür - netlabs rpm.

Visual Age C++ 4.0 war seiner Zeit weit voraus und selbst heute noch sind die Ansätze dort wie man SW entwickeln konnte, nicht so veraltet (graphisch Klassen Zusammenklicken und deren Interaktionen definieren). Ich hab es nicht als so instabil in Erinnerung, aber vom Ansatz im Zusammenhang mit der OpenClass Library sehr gewöhnungsbedürftig. Ein kleines Projekt welches ich damit machte war, sagen wir aufregend und lernintensiv. Ein größeres welches damit compiliert wird, ist LarsenCommander. Da wird aber nur der Compiler/Linker genutzt, nicht die Library und nicht die graphische Classen-/Code Erstellung. Zusammengefasst, interessant, aber man ist dabei auf sich alleine gestellt und deshalb eher was zum Spielen für kleine eigene Projekte. Ansonsten unbrauchbar. Ev. ist noch der integrierte Debugger für Remote Debugging von OS/2 GUI Programmen brauchbar. Aber auch da würde ich eher mit ICAT rangehen.

VAC3.65 - ebenso hoffnungslos veraltet. Aber zum Warten von alten Projekten oft notwendig.

VAC3.08 - Hände weg, uralt. Wohl nur beim warten von sehr wenigen Uraltprojekten sinnvoll.

GCC vom rpm - DIE Umgebung für alle Sachen die portiert werden. Den Linker muss man aber eher von OpenWatcom nehmen und den Debugger von VAC3.xx. Ev. auch ICAT. Also Compiler halbwegs modern, aber von einer Entwicklungsumgebung (z.B. Eclipse) können wir unter OS/2 nur träumen.

Du müsstest schon genauer sagen was du machen willst. Wenn du nur spielen willst und mit C++/Klassenprogrammierung vertraut bist, ist VAC4 noch immer am ehesten ein Komplettpaket. Aber mach damit besser nichts, wenn auch mal andere das brauchen könnten bzw. mitarbeiten sollen.

[ThomasOF]

Hallo,

Wolfgang Draxlers WDSibyl sollte noch erwähnt werden, ist in vielem mit Delphi seelenverwandt. So kann man schnell GUI-Programme erstellen. Allerdings dann Pascal- statt C-basiert. Aber das ist ja auch etwas sehr schönes.

Thomas

[Alexco]

Erst mal danke für die Tipps. Idee oder Pläne habe ich grad nicht. Ich kam halt drauf, weil ich VAC4 hier halt liegen habe und weil ich auf Netlabs (sieht leider sehr verwaist aus) mir mal einen Überblick über deren Projekte verschafft habe. Und dort steht halt mal Watcom 1.9 oder 1.8 oder nix. Scheint wohl bei Treibern erforderlich zu sein.
Das mit dem RPM Zeugs habe ich noch nicht geblickt. Läuft das so auf eCS 1.1?

[Andi B.]

VAC4 hier halt liegen habe

Wenn du C++ beherrscht wäre VAC4 eine komplette Entwicklungsumgebung (GUI Editor, Klassenlibrary, Editor, IDE zum Projektverwalten und Options einstellen, Debugger, ....). Aber leider ziemlich inkompatibel zu allem. Außer zu VAC4 für Win , welches aber wohl genauso nirgends verwendet wird. Man kann sich das installieren und in Nostalgie schwelgen und bedauern, dass es sich nie breit durchgesetzt hat. Man kann sich aber auch die Zeit sparen.

Wenn man Treiber entwickeln will, muß man zu Watcom (geht mit Uraltversion bis zu aktuellem OpenWatcom) greifen, oder/und Assembler (MASM6 ist auch bei den DDKs dabei).

RPM - wenn du noch nichts damit gemacht hast, dann am Besten starten mit ANPM und den wiki Seiten dazu bei ArcaNoae (https://www.arcanoae.com/wiki/anpm/). Ist gratis GUI für yum/rpm und sollte auch mit eCS1 laufen.

[Alexco]

RPM - wenn du noch nichts damit gemacht hast, dann am Besten starten mit ANPM und den wiki Seiten dazu bei ArcaNoae (https://www.arcanoae.com/wiki/anpm/). Ist gratis GUI für yum/rpm und sollte auch mit eCS1 laufen.

Ach ja, das war wieder was für schlaflose Nächte. Wo kann ich denn Fehler zu anpm melden?
Soweit konnte ich das alles auch installieren, leider gab es bei der Einrichtung das Problem, dass ANPM meine config.sys nicht geändert hat (obwohl es das behauptet hat). Leider finde ich nirgendwo Infos, was man dort alles ändern/setzen muss.
Ein Screenshot hier im Forum hat zumindest gezeigt, wie man UNIXROOT und PATH anpassen muss. Leider klappt das immer noch nicht ganz, irgendwas wird noch angemeckert.
Darüber, dass mein Hauptverzeichnis nun mit diversen neuen Unterordner "zugemüllt" wird, lasse ich mich erst wieder aus, wenn ich das mal zum Laufen bekommen habe

[Andi B.]

Man kann ja auch das ganze auf eine andere Partition legen. Bei mir ist das dort, wo alle anderen Programme sind.

Auf Anhieb fallen mir nur diese Zeilen ein -

Code: Alles auswählen

SET UNIXROOT=P:
LIBPATH=P:\USR\LOCAL\LIB;P:\USR\LIB;.;......
SET PATH=p:\usr\local\bin;p:\usr\sbin;p:\usr\bin;.....

Wobei ANPM den .; im Libpath lieber am Anfang stehen haben will, was ich persönlich aber weniger gut finde.

Code: Alles auswählen

\usr
\etc
\var

würde ich nicht zumüllen nennen. Oder hab ich was vergessen? %TEMP% gesetzt wird wohl auch nötig sein. Das sollte aber sowieso auf jedem System gesetzt sein.

Fehler zu ANPM im Mantis bugtracker. Ich fürchte dazu muss man aber Acra Noae Kunde sein. Keine Ahnung ob man sich da so auch registrieren kann. Sollte aber eigentlich in der ANPM Beschreibung stehen. Wenn nicht, dann ticket

[Alexco]

Auf Anhieb fallen mir nur diese Zeilen ein -

Code: Alles auswählen

SET UNIXROOT=P:
LIBPATH=P:\USR\LOCAL\LIB;P:\USR\LIB;.;......
SET PATH=p:\usr\local\bin;p:\usr\sbin;p:\usr\bin;.....

So, das ist die fehlende Info, danke. Damit läuft anpm erst mal und es lassen sich Pakete installieren.
Zum Thema "zumüllen". Ja, klar kann man eine andere Partition nehmen, wenn man denn eine hat
Und ich finde es generell immer besser, wenn Verzeichnisse, die zusammen gehören, auch zusammen in einem übergeordneten Verzeichnis liegen. Aber das ist natürlich nicht zwingend, sondern nur meine Meinung.
Aber jetzt spiele ich erst mal yum rum.

[LotharS]

Zum Thema "zumüllen". Ja, klar kann man eine andere Partition nehmen, wenn man denn eine hat
Und ich finde es generell immer besser, wenn Verzeichnisse, die zusammen gehören, auch zusammen in einem übergeordneten Verzeichnis liegen. Aber das ist natürlich nicht zwingend, sondern nur meine Meinung.

Ok, wir sind es in OS/2 gewohnt, dass jeder seine bewährte Ablagephilosopie hat

Eigentlich hätte ANPM bei Installation die genannten Standard-Verzeichnisbäume anlegen sollen, zusammen mit config.sys-Pfaden, hatte er jedenfalls hier auf eCS 2.1 getan. Nun gut Nur sollte man vorher bei ArcaNoae die Anweisungen studiert haben und später Zusätzliches. Die Systematik entspricht der aus *nix bekannten, und man sollte das tunlichst auch so lassen, vor allem dann, wenn man mal Support braucht. ANPM schiebt dann Updates gleich an die gebrauchte Stelle.

Es empfiehlt sich auch sehr, hinterher aufzuräumen und insbesondere DLL-Duplikate beseitigen (altes entfernen oder umbenennen -> "Müll"). Auf eCS gibt es dazu in der Systemkonfiguration das praktische Objekt 'eCS Kernel' (bzw. 'OS/2-Kernel' in vollem XWP).