Hilfen und Übersetzungen

Rainer

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

bolle732

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

Rainer

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.

jpolzfuss

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.

bolle732

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.

Achim

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.

Rainer

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???

Lockesoft

Mit der Dosbox bzw. basebox habe ich hier auch keinen Erfolg. Könnte schon sein, das es da hakt...

Achim

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.

jpolzfuss

Zitat von 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.)

t.hass

Hallo,

die normale/offizielle DOSBox kann kein LFN. Es gibt Patches, aber dann muß man sie halt selber bauen. Für DOSBox Staging (von der sich die BaseBox ableitet) wurde ein entsprechender Feature-Request erst kürzlich abgelehnt. Die DOSBox ist halt für DOS-Spiele gemacht und die brauchen kein LFN...

Gruß Thomas

Rainer

Danke, gut zu wissen. Wider was gelernt

Rainer

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

Achim

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.

nschu

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

Rainer

Es gibt Routinen, die das Datum nach den System-Voreinstellungen formatieren (Localize~ oder Local~ oder so). Die würde ich benutzen.

Rainer

nschu

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 ?

Achim

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.

Rainer

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

Zitat von 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

nschu

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 !