Hilfen und Übersetzungen

    Liebe Mitstreiter,

    ich habe eine Bitte an die fleißiegen Übersetzer, Hilfe-Schreiber usw.

    Ich war auf der Suche nach der Lösung für ein Problem, dass mir schon mehrfach viel (sehr viel) Arbeit gemacht hat. Windows hat die Eigenart, zwar in den Dateinamen Groß- und Kleinschreibung zu unterscheiden, trotzdem sind PAUL.TXT und paul.txt die gleiche Datei. Git (das Versionskontrollsystem, das wir benutzen) hingegen sieht das auch unter Windows anders ....

    Wenn man also jetzt bei einer Datei die Groß- und Kleinschreibung ändert, ohne das git davon weiß (Also direkt mit DOS, Windows oder Linux), gibt es Probleme. Probleme, die ich unter Windows lokal nicht lösen kann, sondern immer die Hilfe von Falk brauche, der das auf github wieder gerade biegt. Und das ist schon mehrfach passiert. z.B. wurde die Datei Adress.000 versehentlich nach ADDRESS.000 umbenannt. Für Git und auf github existiren dann beide Dateien, für Windows nur eine - das Chaos ist vorprogrammiert. Lösche ich z.B. die eine Datei, taucht die andere dafür auf.

    Nach mehreren Mailwechslen mit Nico und Achim ist die wahrscheinliche "Ursache" die Arbeit mit GEOS selbst. GEOS bennnt neue Dateien grundsätzlich mit Großbuchstaben. Verschiebt man unter GEOS eine Datei, kopiert sie oder wählt man "Speichern unter" (gleiche GEOS-Name, aber anderer Ordner), so hat die neue Datei den Namen in Großbuchstaben (Verschieben = Kopieren + anschließendens Löschen) . Aus Address.000 wird ADDRESS.000, ohne dass der Nutzer etwas davon merkt.
    Lädt man diese Datei jetzt auf Github hoch, existieren dort beide Varianten, lädt ein anderer Nutzer (mit Windows, z.B. ich) die Änderungen jetzt herunter, glaubt git, es gäbe zwei Dateien, Windows kennt aber nur eine davon. Das ist der Stoff, aus dem Konflikte sind.

    Lange Rede, kurze Bitte: Bevor ihr etwas hochladet, achtet bitte darauf, ob die Groß/Kleinschreibung des DOS-Namens korrekt ist! Notfalls kann man das vom Host aus anpasssen.

    Für die Dateien im Ordner pcgeos\Tools\build\product\bbxensem\HelpSource und ~\HelpSource\german sowie ~\Help habe ich einen PR gemacht, der alle Dateinamen groß schreibt, so dass das Problem nicht mehr auftreten kann. (Wenn man die Git-Tools benutzt kann man natürlich die Groß/Kleinschreibung konfliktos ändern.)
    Leider musste ich dazu die Hilfedatei 'ui' (Ui.000) in 'ui help' (UI_HELP.000) umbenenen, da der Konflikt zwischen Ui.000 und UI.000 nur scheinbar gelöst war. Wenn (falls) Falk den PR akzeptiert hat, bitte besonders aufpassen, falls ihr diese Datei bearbeitet. Sorry, falls das Umstände macht.

    In ~\HelpSource(\german) betrifft die Umbennenung folgene Dateien: Chat.000, Freecell.000, Map.000, Mail.000, Ui.000 (umbenannt, s. vorne), Wrdmatch.000 und Wavplay.000

    In ~\HelpSource(\german) betrifft das Cuihelp.000

    In ~\Trans(\german) habe ich keine Dateien gefunden, die noch Kleinbuchstaben haben.

    Viele Grüße
    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Rainer

    Moechte noch anmerken, dass GEOS mit dem LFN-Treiber (Long File Name / Lange Dateinamen) die Dateien in Kleinbuchstaben erstellt. Zumindest bei mir unter DOSEmu2... Ob das nun von GEOS oder DOS abhaengig ist, kann ich nicht mit Sicherheit sagen.

    Eventuell braucht es mal ein Tool, dass die Konvertierung / Umstellung der Datei- und Ordnernamen zwischen SFN und LFN macht. Aber im Moment ist das ja nicht so prioritear...

    Gruss Andreas

    Hallo Andreas,

    spannend, den LFN Treiber habe ich noch nie probiert. Aber m.E. ist das ein eigenes Thema. Das Problem ist, das GEOS (und evtl. Freedos ?) im Normalfall Großbuchstaben vorrausetzt /erzeugt. Nach meiner Meinung lässt sich das am einfachsten und sichersten handeln, wenn man festlegt, dass alle GEOS-Dateien im Repo im DOS-Namen ausschließlich Großbuchstaben enthalten.

    Rainer


    P.S. Wie aktivert man den LNF?

    Original:

    Code
    fs = ntfat.geo
primaryfs = ntfat.geo

    nach

    Code
    fs = ntfat.geo
primaryfs = mslf.geo

    zeigt keine langenDateinamen an. Alle anderen Varianten, z.B.

    Code
    fs = mslf.geo
primaryfs = mslf.geo

    Starten nicht.

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hi!

    a) Variante 3 (beides =mslf.geo) wäre die richtige Variante gewesen.

    b) Unter Windows gibt es zwei verschiedene, zu einander inkompatible LFN-Versionen. Die eine stammt aus Win95, die andere aus WinNT4.0 (oder 3.5?). Geos unterstützt nur die aus Win95, die auch in Win98 und WinME zu finden ist - sowie in diversen DOS-Versionen, die ab 1995 erschienen sind (inklusive FreeDos). Startete man Geos in Win95/98/ME erst, nachdem die grafische Nutzeroberfläche von Windows gestartet war, lief die LFN-Unterstützung „einfach so“. Brach man das Laden von Windows ab, so dass man im reinen DOS blieb, musste man erst in der Config.sys einen LFN-Treiber für DOS laden, damit die langen Dateinamen dann auch im VC oder Geos funktionierten. Auch unter FreeDos braucht es diesen zusätzlichen Treiber - siehe http://adoxa.altervista.org/doslfn/ oder http://home.mnet-online.de/willybilly/fdh…util/doslfn.htm

    Dieser Zusatztreiber funktioniert jedoch nicht „einfach so“, sondern benötigt auch ein DOS, das damit klar kommt. (Läuft also z.B. unter MS-DOS oder ROM-DOS erst ab der Version 7.0.)

    Läuft das DOS zudem noch in einem Emulator, wie z.B. DosBox, muss auch der Emulator das unterstützen.

    There are two rules in life:
    1. Never give out all of the information.

    Für die Standard-Distribution von PC/GEOS sind kurze Dateinamen mit gross geschriebenen Dateinamen ok. Lange Dateinamen ist definitiv ein eigenes Thema.

    Für lange Dateinamen unter DOSEmu2 habe ich mir folgendes notiert:

    Code
    fs = msnet.geo
primaryFSD = mslf.geo

    Anscheinend stellt DOSEmu2 die Laufwerke anders als DOSBOX zur Verfügung. Quasi als Netzwerk-Laufwerk.

    Moin.

    In meiner geos.ini habe ich folgendes eingetragen:

    [system]
    primaryfsd = mslf.geo
    fs = {
    ms4.geo
    msnet.geo
    }

    Damit habe ich lange Dateinamen; damit werden z. B. die langen Ordner- & Dateinamen meines Linux-Hostsystems in Geos angezeigt, sofern sie 32 Zeichen nicht überschreiten. Nun habe ich folgendes Kuriosum: Mein DOS-Programm Norton Commander zeigt alle Dateien IMMER klein geschrieben an, egal, wie real geschrieben sind. Mein DOS-Editor zeigt sie so an, wie sie auch in Linux angezeigt werden, sowohl gross, klein als auch gemischt. Ich werde die Schreibweise meiner Dateien also mit dem Editor kontrollieren müssen, bevor ich sie zum Hochladen weiterreiche.

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Hm, sobald mslf.geo als erstes steht, startet er nicht mehr.

    fs = {
    ntfat.geo
    mslf.geo
    }
    zeigt keine langen Dateinamen an. Kann es an meiner DosBox liegen???

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Wie gesagt, ich verwende diese Konfiguration mit dosemu2. Das im Emulator verwendete DOS muss auch dafür geeignet sein. Könnte sein, dass das bei dosbox nicht der Fall ist. Dann wird dieser LFN-Treiber nicht mit dosbox funktioniert.

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Quote from Rainer

    zeigt keine langen Dateinamen an. Kann es an meiner DosBox liegen???

    Werden Dir denn beim DOS-Prompt in der DosBox lange Dateinamen angezeigt? Wenn nicht, brauchst Du es in Geos gar nicht erst zu probieren…

    (Und wie schon geschrieben, muss es nicht an der DosBox liegen, sondern kann auch am DOS bzw. an nicht geladenen DOS-Erweiterungen liegen.)

    There are two rules in life:
    1. Never give out all of the information.

    Der im Eingangsthread erwähnt Pull request it übrigend durch. Das heißt, alle GEOS-Dateien unter Trans, Help und HelpSource sind in Großbuchstaben. Ausnahme: die @dirname.000 unter Trans/DirNames

    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Moin zusammen.

    Im Zuge meiner Arbeit an der deutschen Hilfedatei für Verzeichnis- bzw. Ordnerliste ist mir aufgefallen, daß es dort beim Drucken dieselben Probleme wie bei Gourmet gibt.

    1. Bei Drucken auf Papier wird die letzte Zeile bei mehrseitigem Druck zur Hälfte horizontal weggeschnitten, die letzten 4 Zeilen einer Seite erschienen als erste Zeilen auf der nächsten Seite. Bei Drucken in PDF sind es dann die letzten 8 Zeilen. Kurios: Wird die Seite nicht komplett bedruckt, werden die letzten 5 Zeilen trotzdem auf eine zweite Seite gedruckt.

    Kopiere ich alles in ein GeoWrite-Dokument, werden alle letzten Zeilen einer Seite korrekt dargestellt und auch ausgedruckt.

    2. In der Liste werden alle Dateien mit Uhrzeit und Datum der letzten Speicherung angegeben. Es wird dort aber die amerikanische Schreibweise mit Schrägstrich und Reihenfolge Monat/Datum/Jahr verwendet.

    Ich finde, man sollte sich darum kümmern.

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Bei mir wird das gedruckt in PS Datei wie wenn es Endlospapier wäre obwohl A4 Normal eingestellt ist.

    Habe nun auch festgestellt dass die Schrift Mono nicht gut lesbar ist und Dirlist mit Sans versucht , sieht echt besser aus.

    Datum kann im Code korrigiert werden aber ist dann auch in der englischen Version so "26/02/2024"

    Schrägstrich kann auch im Code geändert werden.

    Was sagt Ihr ?

    Gruss von Nico

    Im Code ist das so :

    /* Get the file's modification date and time... */

    modifStuffAddr = (dword *)((bufBaseAddress + DATE_AND_TIME_OFFSET)+(count * FEDOSINFO_SIZE));
    modifStuff = *modifStuffAddr;

    /* Convert to ASCII and put after file size... */

    modItem = (dword) FDATExtractDay(modifStuff); /* the day */
    UtilHex32ToAscii(fileSizePtr, modItem, flags);
    if (modItem < 10)
    strcat(lineBuffer, "0");
    strcat(lineBuffer, fileSizePtr);
    strcat(lineBuffer, "/");

    modItem = (dword) FDATExtractMonth(modifStuff); /* the month */
    UtilHex32ToAscii(fileSizePtr, modItem, flags);
    if (modItem < 10)
    strcat(lineBuffer, "0");
    strcat(lineBuffer, fileSizePtr);
    strcat(lineBuffer, "/");

    modItem = 80 + (dword) FDATExtractYear(modifStuff); /* base year is 1980 */
    if (modItem > 99)
    modItem = modItem - 100; /* for the years 2000 and later */
    UtilHex32ToAscii(fileSizePtr, modItem, flags);
    if (modItem < 10)
    strcat(lineBuffer, "0");
    strcat(lineBuffer, fileSizePtr);
    strcat(lineBuffer, " ");

    Ich habe nur die Reihenfolge geändert.

    Rainer wie machen ?

    Um das nochmals zu verdeutlichen:

    Trotz deutscher Datums- und Trennzeichen-Einstellungen - also Punkte und dd.mm.jj bei kurzem Datum - werden in Verzeichnisliste amerikanische Formate benutzt.

    @Nico: Nimm mal einen Ordner mit viel Inhalt, der über mehr als eine Seite reicht und drucke dann auf Papier und in PDF bzw. PDF; das wird bei mir trotz aller verschiedener Einstellungen immer noch so merkwürdig gedruckt, wie ich es weiter oben beschrieben habe.

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Achim: Ja, die Schrägstiche stehen im Code, siehe Post von Nico.

    Quote from nschu

    strcat(lineBuffer, "/");

    @Nico: Versuch folgendes (ungetestet .. ausprobieren!):
    1. LocalGetDateTimeFormat() liefert dir laut Doku das eingestellte Datumsformat.
    2. LocalFormatdateTime() liefert dir den passenden String.
    Über die Bedeutung der Parameter/Strukturen müsstest du dich in der Dokumentation oder in den Headern schlau machen.
    ... Nach kurzem Grep in meinen Sourcen: Wahrscheinlich reicht LocalFormatdateTime(), dem du ein DTF_xx deiner Wahl übergibst.

    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Bei mir Druckt es in PS Datei als Liste wenn ich mit Sumatra PDF öffne ist es eine lange Seite , wenn ich die selbe Datei (PS) mit Ghostview öffne sind es mehrere Seiten die trotz Einstellung A4 als Liste angezeigt werden.

    Hier Original aus Breadbox Ensemble 4.1.3

    Das Problem Datum werde ich versuchen.

    Das Druckproblem , da muss die komplette Druckfunktion neu geschrieben werden.

    Leider kann ich nicht direkt auf Papier drucken.

    Achim teste mal mit anderen Pdf Viewern !