Die Bildschirmbehandlung von checkini.exe und cleanini.exe scheint aber nicht kompatibel mit der MESHELL zu sein.
Keine Anzeige! Gibt man allerdings die erwarteten Eingaben blind ein, laufen die Programme an und liefern auch Screenoutput.
Ist das ein Konfigurationsfehler? Geht es nicht besser oder ist das noch ein Bug?
Wahrscheinlich ist dies das bekannte Standardproblem mit stdout und stderr bei manchen Kommandozeilenprogrammen. Siehe Doku ziemlich am Ende Kapitel "Kompatibilitätsprobleme mit existierenden Programmen".
Alle stdout Programmierer, die stdin lesen, müssen ein fflush (file) aufrufen, bevor ein stdin Input erwartet wird. Die zu beantwortende Frage hängt noch im Output-Puffer und der Cursor erwartet schon den Userinput. Bei Stderr tritt das Problem nicht auf, weil stderr laut ISO Norm grundsätzlich nicht gepuffert wird, stdin aber schon. Es ist also ein Programmierfehler im Anwendungsprogramm, das in der normalen Kommandozeile nicht zu Tage tritt. In professionellen von Unix portierten Programmen ist das in der Regel richtig. Bei Info-Zip wird deshalb etwa eine Frage immer über STDERR ausgegeben.
Hat jemand Kontakt zu Henk Kelder in letzter Zeit gehabt oder gibt es die Sourcen?
Ich arbeite aktuell wieder an MeShell. Die letzten Monate ist mir nur ein nerviger Fehler aufgefallen, der das noch nicht richtig funktionierende Wieder-Anmelden der Verzeichnisse nach Neustart betrifft. Wenn Euch Fehler aufgefallen sind, dann bitte jetzt her damit. Inzwischen habe ich den Programmcode Windows-kompatibel gemacht, aber noch Probleme mit sehr speziellen Abweichungen von API-Aufrufen. Ich kann noch nicht sagen, wann die Windows-Version läuft.
Im Prinzip ist das Projekt für mich abgeschlossen. Ich habe auch inzwischen den Code wie schon Martins Editor und Textbuch auch an Windows angepasst. Es hakt noch an OS-spezifischen Stellen bei der Windows-Portierung. Ich weiß noch nicht, wann ich dazukomme, mich darum zu kümmern. Aber immerhin läuft die OS/2-Version jetzt wirklich sehr zufriedenstellend. Diesmal ist das Update wirklich sinnvoll. In den nächsten Tagen werde ich noch die WPI-Datei auf Hobbes hochladen.
Zuletzt geändert von Martin Vieregg am Sa 18. Jun 2022, 00:23, insgesamt 2-mal geändert.
Martin Vieregg hat geschrieben: Mi 8. Jun 2022, 00:10
Ich habe die wenigen gefundenen Ferhler und Kommentare (vor allem vom os2world Forum) abgearbeitet.
Die aktuelle Versionsnummer ist nun 0.90. MeShell Archiv
Im Prinzip ist das Projekt für mich abgeschlossen. Ich habe auch inzwischen den Code wie schon Martins Editor und Textbuch auch an Windows angepasst. Es hakt noch an OS-spezifischen Stellen bei der Windows-Portierung. Ich weiß noch nicht, wann ich dazukomme, mich darum zu kümmern. Aber immerhin läuft die OS/2-Version jetzt wirklich sehr zufriedenstellend. Diesmal ist das Update wirklich sinnvoll. In den nächsten Tagen werde ich noch eine WPI-Datei erzeugen und auf Hobbes hochladen.
das ist doch schön, vielen Dank dafür.
Ist natürlich schade, dass es für so ein interessantes Projekt doch eher wenig Rückmeldungen gibt, aber ist halt so. Für mich "reicht" das leider nicht um OS/2 (wieder) als System zum Arbeiten zu erwägen, weil's an allem anderen fehlt.
PS: WPI für die Installation ist Klasse, aber vielleicht wäre ein RPM auch nicht schlecht?
Vor allem auf OS/2 World hat es viel Feedback gegeben. Ich habe den Eindruck, dass vor allem wichtige OS/2-Entwickler, die mangels aktueller IDE auf die Kommandozeilenversionen von Compilern angewiesen sind, sehr gerne MeShell nutzen, wegen der quasi ewigen Scrollbarkeit und der roten Farbe von STDERR Ausgaben. So konnte ich indirekt einen kleinen Beitrag zur Weiterentwicklung von OS/2 leisten. Bedankt Euch an Corona. Ich bin selbständig und hatte die ersten drei Monate (zweites Quartal 2020) ein Auftragsloch, und mir kurzerhand meinen eigenen Traum von MeShell erfüllt, das auch meine Produktivität nun deutlich erhöht hat.
Ich habe eine wunderbare Unterstützung über das OS/2 World Forum erhalten. Dort haben sich wirkliche Experten sehr engagiert meiner Probleme angenommen. Es gibt dort unter der Sektion Programming diverse Threads von mir. Es war eine extreme Form von API-Programmierung mit Semaphoren, Pipes, Threads, parallelen Prozessen und auch paralleler Sessions. Vor allem, dass ich den Helper in einer eigenen Session laufen lassen muss, damit die Kommunikation klappt, das hätte ich nie alleine geschafft. Es sind zwei Sessions, drei Prozesse und fünf Threads, die alle untereinander agieren, reagieren und kommunizieren.
