Ich hab jetzt im HowTo eine Liste der 23 CONFIGURE-Versionen aufgeführt die ich gefunden habe, inkl. der 2.1.1. Wobei es auch ein 2.1+ gibt wo die GeoRAM ebenfalls schon mit 4Mb erkannt wird. Die max. unterstützte DACC-Größe hab ich bei jeder Version mit aufgeführt.
Und ja, 4Mb-Versionen bringen kaum Mehrwert, außer das RAM-Process ein paar mehr freie Blocks findet. Seltsamerweise aber nur etwas mehr, ca. 2000 Blocks. Keine Ahnung was man mit so viel freiem Speicher und dem Programm anfängt.
Ich weiß nicht, ob es so gut ist, da auf externe Links zu setzen. Solche Links können schnell mal ungültig werden. Willst Du die Anleitung "ständig" anpassen?
.
Hab ich nicht vor. Wichtig sind ja eher die zu erledigenden Schritte bis zum Ziel, woher die Disketten kommen kann mir egal sein. Das deutsche GEOS ist ja auch nicht verlinkt. Da die Anleitung in Deutsch ist werden die meisten sich das Material aus der Wolke laden... Die Links sollen nur eine erste Anlaufstelle sein, zur Not weiß man wonach man suchen muss.
Patch System
...
Ein besserer externer Link ist vielleicht der:
http://www.zimmers.net/anonftp…k/Programme/gt115a.d64.gz
Da ist das zumindest erfüllt.
Kann ich anpassen, Danke.
Wenn Calender für das Jahr 2000 gepatcht ist, stimmt der Kalender! Bei den Bildern von darkvision ist er noch nicht für das Jahr 2000 gepatcht.
Genau... Anfangs war der Y2K-Patch ja nicht enthalten. Soweit ich das sehen konnte könnte man den Patch auch so ändern, das Calendar das ":millenium"-Byte ($9FAD) auswertet und verwendet, dann läuft Calendar (beinahe) ewig
Werd ich aber nicht mehr erleben, und die meisten C64 bestimmt auch nicht. Sind ja noch ~60Jahre bis der jetzige Y2K-Patch nicht mehr funktioniert. Von daher belassen wir es bei der aktuellen Lösung, der Patch-Code ist ja gut dokumentiert damit künftige IT-Archäologen wissen was Sie ändern müssen
Ich hab jetzt auch mal alle CONFIGURE-Versionen rausgesucht... für 64/128, reu/georam/ramlink, 2.0/2.1/2.1.1 ... deutsch/english... sind bis jetzt 16 Versionen. Werde da zumindest eine Auflistung ergänzen welche Version wofür geeignet ist.
Zumindest die 2.1.1 scheint auch mit InstallDriveD zu funktionieren. Die letzte Version davon war 1.2? Ich hab das Programm nur auf TopDesk-Disketten gefunden (eine V3.2/DE findet sich bei zimmers.net). Evtl. ergänze ich noch einen Abschnitt dazu, falls man mit DualTop mit vier Laufwerken unter GEOS2 nutzen will. Oder wer will mit TopDesk3.x.
Und ja, konnte bei 2.1.1 die von wweicht aufgezeigten Fehler nachstellen. Ich hab es aber geschafft A-C mit RAM1581 zu konfigurieren. Ich konnte das Programm danach aber nicht mehr beenden. Also irgendwie ist das bei MP3 einfacher
GEOS-Install-HowTo ist aktualisiert, die Patches für Calculator (1.0/1.2de/us)
Quatsch... ich meinte natürlich Calendar... nicht Calculator... 
Ja schon, aber es gibt z.B. auch geoZIP für MP3. Da bekommt man von den .CVTs nichts mit, da das Programm das automatisch macht, beim Packen und Entpacken.
Das Hauptproblem bleibt aber selbst mit SuperCPU gleich: Man muss das ZIP auf den C64 oder zumindest auf eine DOS-Diskette bekommen. OK, 3,5" sind heute wieder der "Standard" ( siehe Mega65 ) und mit dem WiC64 kann man von HTTP auch direkt auf den C64 downloaden. Als Befehlszeilen-User kann man noch VICE verwenden. Das kann aber nicht jeder (letzteres ist aber im HowTo beschrieben...)
Also hat man diese ZIPs oder CVT und muss die erstmal auf ein von GEOS lesbares Dateisystem übertragen, und daher ist D64/D81 der deutlich einfachere Weg. geoZIP/MP3 selbst liegt ja als CVT/7Zip in der Wolke... das kann geoZIP bestimmt nicht entpacken...
GEOS-Install-HowTo ist aktualisiert, die Patches für Calculator (1.0/1.2de/us) und Blackjack (1.0/1.1/1.2-de/us) hab ich auf meiner geos-patchfiles-disk (D64 / TXT) auch online gestellt (mit dem RunTime-Patch), braucht man aber nur wenn man GeoDesk64 nutzt und daher werde ich mir in GeoDesk jetzt eine Option einbauen, mit der man das so einstellen kann wie in TopDesk oder es wird zuvor der Standard-GEOS-Hintergrund aktiviert. Dann ist der Patch auch nicht mehr nötig. Aber wo ich den Patch habe lösche ich den natürlich nicht, hat ja irgendwie trotzdem Spaß gemacht damit zu experimentieren.
Ist blanke Theorie, was ich jetzt schreibe:
Muß nicht sein. Man ändert einfach: bei "Neue Datensatzlänge = 0" so, daß nicht mehr gespeichert wird ....
Ja, aber das setzt dann für Calendar die neue PATCHSYSTEM-Version voraus. Und bis die Fertig ist...
Gut, ich muss meine Patches noch weiter testen, hat also noch etwas Zeit.
Ich passe meine Texte noch so an das man einfach eine Seite im Quelltext löscht um den Runtime-Patch zu entfernen, dann könnte man auch die neue PATCHSYSTEM-Version verwenden.
Und die 80 Zeichen-Version gibt es offiziell ja garnicht (Patch eines Anwenders
Ansichtssache... zumindest ist die Version im Umlauf und in der Wolke.
Vorweg Danke für die Infos zu den Patchtexten. 
Und nochmal wichtig: Alle Patches die vor "4 Laufwerke für Geos" entstanden, sind in den "4 Lfw. für Geos"-Paches enthalten. Ältere Patches braucht man also nicht mehr.
Warum ich jetzt ausgerechnet beim 64er geoPaint dieses Änderung nicht mit aufgenommen habe (im 128 geoPaint-Patch ist sie drin) kann ich nicht mehr sagen. Dann brauchen wir wohl noch das Publish-Patch aus SH 59...
Ich hab heute morgen write, paint und publish 64/128 mit den drei extra Patches und dann 4LWK, MP3 und Y2k-Patches versehen. Wenn die extra Patches als erstes angewendet werden dann dürfte das ja kein Fehler sein, stellt aber sicher das alles enthalten ist. Sonst müsste man jetzt den 64er-Paint-Patch eine Beschreibung beilegen das hier gPp2.01 benötigt wird und beim 128er nicht.
Für die drei Patches hab ich auch eine öffentliche Download-Quelle gefunden, die kann also jeder auch auf ein pures GEOS 2.x ohne extra Patches anwenden.
Keine Ahnung, ob das wirklich eine gute Idee ist.
1. es gibt nur wenige Programme, die das Problem haben
2. bisher ist es bei etlichen Patches nur bei "Calendar" aufgetreten
Der RunTime-Patch wird nur 1x direkt beim ersten Start ausgeführt und passt die Dateigröße an, danach verbleibt der Code am Ende des Programms, wird aber nicht mehr ausgeführt. Die Startadresse im Infoblock kann man nämlich ändern und beim ersten Start wird der Runtime-Patch angesprungen. Der ändert dann die Endadresse+Startadresse und speichert den Infoblock.
Es findet danach auch keine Prüfung mehr statt, der Code hängt dann einfach nur noch hinten dran. Der Rest des Programms ist bis auf die eigentlichen Patches unverändert.
Da der Speicher in dem Bereich sowieso uninitialisiert ist gibt es hier keine Nachteile außer die 50Byte größere Dateigröße.
Vertretbar wenn man so in Zukunft auch weitere Korrekturen einpatchen kann ohne eine Patch-Anwendung zu schreiben.
3. eigentlich müßte man mal sehen, ob man PatchSystem anpassen kann...
Das wäre sicherlich die beste Lösung, dann setzen Patches aber eine bestimmte PATCHSYSTEM-Version voraus und dann haben wir neben der 64er/128-Version noch eine spezielle 128er-Version (bei den MP3DE64-Patches enthalten) und eine aktualisierte Version. Das macht es dann doch eher undurchsichtiger.
Und wenn es dann nur wegen Calendar 1.2 ist (1.0 geht auch ohne diesen RunTime-Patch), dann würde ich den Patchtext mit Runtime-Patch einer zusätzlichen PATCH-SYSTEM-Version vorziehen.
Wobei ich es schon als Fehler sehe das die Datensatzlänge #0 korrigiert wird, auch wenn nur der Infoblock als Datensatz #254 gepatcht wird.
Display MoreOh man, da wird mir ja übel, wenn man das Ganze verstehen oder überblicken will
Aber eines ist mir doch aufgefallen:
gPp2.01
wird erwähnt (obwohl in einem anderen Patch von mir bereits enthalten)Aber wie gesagt: Alle 3 sind eigentlich obsolet, da definitiv in einem der Paint-, Publish-, Write-Patches von mir bzw. bei Write von F. Rehwagen enthalten.
Ich bin auch nicht sicher, ob die wie in der Anleitung beschrieben für DE- und US-Geos sind. Die 3 Patches stammen definitiv aus Deutschland von J.-M. Groß.
Jetzt wird mir übel... Wenn der gPp2.01 Patch in einem Deiner Patches enthalten ist, warum gibt es dann keine Fehlermeldung? Keine Check-/Prüfsummen? Ist da noch mehr obsolete? Der Patch ist ja nach wie vor im 4LWK-Patchset enthalten das man für MP3 benötigt. Dann soll man den nicht anwenden ? 
Ich hab heute wegen eines neuen Bugs in MP3/GDOS+RAMLink-ohneSuperCPU geoWrite 2.1 getestet... der Bug bringt geoWrite ganz schnell zum Absturz. Egal... lässt sich ggf. lösen.
Da war in meinem alten geoWrite ein Patch von JMG auf 2.11 enthalten, keine Ahnung wo der herkam. Und jetzt kommt da noch ein 2.12 dazu? Man, wie soll das ein Neu-Anwender finden?
Danke für die Hinweise... muss ich mir mal zusammensuchen... aber es gibt auch gutes zu berichten (hoffentlich):
Ich hab die Patches für die Fensterfarbe+Y2k für Calendar zusammengefasst... ohne das die Endadresse geändert wird. OK, die Adresse wird geändert, aber ich hab das Patch-System überlistet 
(jaja... es macht aber das Programm auf Disk ca. 50Byte größer weil RunTime-Patch, aber besser als die 30Blocks mit der neuen Größe des Datensatzes).
Jetzt muss ich erstmal die bisher unbekannten Patches suchen... dann passe ich die Anleitung an und uploade ggf. meine Patches für Calendar+Blackjack.
Aahhh, ja, ich erinnere mich dunkel. Da war doch was ....
Aus der Erinnerung:
Calendar war/ist ein Hilfsmittel und nutzt eine Trick, um den Geos-Bildschirm beim Starten des DAs zu sichern. Es wurde einfach die Endadresse so hoch gesetzt, daß der Bildschirm mit gesichert wurde. Das machte es leider unmöglich, eine Patch-Text zu schreiben, da Patch-System die Endadresse immer geändert hat. Deshalb habe ich das als Programm veröffentlichen müssen.
Das Problem kam so aber recht selten vor, Calendar war also eher die Ausnahme ....
Und über genau diesen "Fehler" bin ich jetzt gestolpert... Meine Version funktionierte unter GeoDesk, aber bei TopDesk gab es dann einen Absturz... und es war die Endadresse.
Das DA hat eine größere Endadresse als Daten im Programm vorhanden sind. Wie Du sagst wird damit Speicher reserviert. Und was macht das PATCH-SYSTEM? Trotz #0 für keine neue Dateilänge ändert es die Endadresse im Infoblock. Das ist für mich nicht logisch. Es ist sogar noch schlimmer, denn ein Patch der nur den Infoblock ändert, verändert die Datensatzlänge des Programms trotzdem. Sonst könnte ein zweiter Patch die Dateilänge wieder korrigieren.
Man kann es zwar mit dem Patch-System selbst lösen (Neue Datensatzlänge setzen), dann wird die Calendar-Datei aber 30 Blocks größer 
Das Jahr 2000 - Patch für den Kalender gibt es ziemlich sicher
Ich hab Calendar auch mit und ohne die Y2K-Patches getestet, um zu sehen ob die Änderungen funktionieren. Man soll die Patches ja ausgiebig *VORHER* testen
Und Calendar ist doch eine Patch-Anwendung, kein Patch-Text. Ich müsste also jetzt den Source-Code analysieren was da geändert wird um es zu ergänzen. Ich glaub ich würde das schon hinbekommen, wenn ich denn wollte.
Also: man benutzt den vorhanden Patch-Text und ergänzt spätere Änderungen einfach in diesen Patch (ein Patchtext kann ja 60 Seiten haben
Deshalb haben die Patch-Texte ja Versionsnummern im Dateinamen (2.0_1, 2.0_2 usw...). Aus meiner Sicht etwas unübersichtlich, und gerade bei TextPrint war das mit der Programm-Version im Dateinamen noch unübersichtlicher.
Über Checksummenprüfung (Checksummer) kann man auch verhindern, daß ein Programm, wo ein Bereich anders ist (falsche Checksumme) nicht gepatcht wird.
Sind für alle Bereiche die ich ändere enthalten. Sogar für den Infoblock.
PatchSystem ist eigentlich recht einfach und simpel. Man muß sich nur drauf einlassen
Es ist einfach, es ist simpel. Manche Dinge sind aber in der Anleitung gar nicht beschrieben oder ich musste mir die Informationen aus dem Kontext heraus selbst erschließen. Aber bevor ich da die Anleitung anpasse ergänze ich lieber ein paar Kommentare in meinen Texten. Die Anleitung selbst verweißt ja darauf das man aus anderen Patch-Texten lernen soll
Jetzt haben wir mit den Y2K-Patches und Deinen schon wieder 2 Patches für ein und das selbe Programm ....
Man kann den Patch weglassen wenn ich das in GeoDesk so regele wie TopDesk, der einfach die Bildschirmfarbe löscht. Daher ist zumindest der Patch OPTIONAL, der Y2K-Patch aber empfohlen oder erforderlich.
Für andere DAs (Calc64 help, Publish help... kennst Du sicherlich...) müsste ich jetzt auch einen Patch schreiben, weil die komplett die Farbe vom Bildschirm löschen anstatt nur im Bereich der Anwendung selbst (wie Calendar und Blackjack das z.B. machen). Würde schicker aussehen, für MP3 gibt es da ja extra Routinen für. Aber lohnt den Aufwand wohl nicht denn ich müsste mich wieder mit MP128 beschäftigen
Ich sammle mal ein paar DAs und dann überlege ich mir wie ich die Optionen in GeoDesk einbaue, damit Farbe+Hintergrund für DAs vom DeskTop aus ordentlich rüberkommen. Der Calendar+Blackjack-Patch waren eher für das verstehen des PatchSystems gedacht, das ich künftig nicht mehr benötigen werde
Ich hab zum testen mal Patches für Calendar und BlackJack aus dem DeskPack erstellt. Die Patch-System-Anleitung ist sehr, sehr rudimentär. Einiges musste ich mir aus Beispielen via Try&Error herauslesen
Aber hier mal ein vorher...:
Calendar und BlackJack nehmen die Farbe von einer bestimmten Stelle des Bildschirms und nehmen das als Fensterfarbe. Unter MP3 ändert Calendar+BlackJack damit die Hintergrundfarbe passend zum Hintergrundbild.
Nach dem Patch:
..wird die Fensterfarbe verwendet. Im Patchtext selbst kann man das aber auch auf die GEOS-Standardfarbe ändern.
Ich hab das jetzt für Calendar 1.0/1.2 und Blackjack 1.0/1.1/1.2 angepasst, für V1.2 auch in de/us. Ich werde das noch etwas testen und in das HowTo mit aufnehmen. Die Patchtexte (die es mit Sicherheit schon gibt, wollte aber mal eigene Texte schreiben) kann ich dann auf der AREA6510 hochladen.
Ja, das wissen wir inzwischen
Von mir gemeint waren (getestet wurden) die 2 Versionen aus Posting #350 und #351
OK, dann hab ich das missverstanden, dachte Du hättest nochmal das Archiv in der Wolke getestet... immer diese ungenauen Angaben
Sorry 
Ich hab das HowTo aktualisiert.
Ich hab mich jetzt auch durch die ganzen Patches gewühlt und für mich zum Teil alternative Dateinamen gewählt, damit alle Dateien auf ein D81 kopiert werden können ohne das etwas überschrieben wird. Einiges war ja auch doppelt. Auf den letzten Seiten findet sich das Inhaltsverzeichnis. Verteilen werde ich die Disk aber nicht, sind ja nicht meine Patches
Jedenfalls konnte ich alle Standardanwendungen patchen, welche Patches ich in welcher Reihenfolge verwendet habe findet sich im hinteren Teil des HowTos.
Gibt auch ein paar Beispiele wie man CVT auf den C64 bekommt und wie man die nach GEOS konvertiert. Wie immer gilt: Es führen viele Wege nach Rom, ich hab mir nur ein paar ausgesucht. Den direkten Download mit dem WiC64 hab ich mal weggelassen
Da das PDF nach wie vor zu groß ist für das Forum anbei nur der Index. Das PDF selbst gibt es auf der AREA6510.
Falls ich da keine Änderungen mehr vornehme lade ich das ODF auch noch hoch... aber noch sehe ich das als Entwurf.
Beim testen sind mir jetzt auch ein paar Anwendungen aufgefallen (z.B. Calendar), die nicht so funktionieren wie ich es mir vorstelle. Evtl. schreibe ich da selbst einen PATCH für das Patch-System (selbst wenn es da schon einen geben sollte, will mal verstehen wie das System funktioniert) oder ich passe GeoDesk an, damit Calendar so aussieht wie er soll... sind dann Anpassungen für MP3.
Wie kann man ein aktualisiertes C128 GEOS ROM neu erstellen mit der Version [V2.0 + MegaPatch 3] ?
Mit MegaPatch? Gar nicht... wurde an anderer Stelle bereits diskutiert. Wer ein ROM nutzen will sollte bei GEOS 2.0 bleiben, wobei da mit JiffyDOS GEOS auch direkt von der Diskette fast genauso schnell startet und man auch mit dem ROM eine Diskette benötigt.
P.S. Vielleicht noch ein paar Erklärungen:
MP3 benötigt schon 64Kb an RAM nur für externe Funktionen, die passen wohl nicht auf das ROM. Die werden von Disk nachgeladen und direkt in die REU/GeoRAM übertragen. Das dürfte mit dem ROM alleine schwierig werden.
Je nach Hardware (z.B. Ultimate, NeoRAM, TC64...) gibt es aber andere Möglichkeiten schnell zu starten...
Jetzt bin ich endlich dazu gekommen, das (geoFile128-Disk) auszuprobieren. Sowohl geoFile128 als auch geoMerge128 lassen sich von dem G64 anstandslos installieren und funktionieren dann auch
Eben frisch heruntergeladen. Software - GEOS - APPS+TOOLS - GEOS V2.0_DE - geofil128-uninstalliert_DE.zip
Datum der ZIP-Datei: 17.04.2016
MD5SUM: 51334b76a50573d8e0ed255ac18e0185 geofile128-uninstalliert_DE.zip
Datum des G64 innerhalb des Zip: 20.02.2016
MD5SUM: f149330ee80b87ca8c47207417622fe3 geofile128.g64
GEOS128/Deutsch gestartet... Diskette geöffnet. geoMerge 2.0 -> siehe Screenshot #1.
Dann GeoFile gestartet... Meldung "Installiert"...
Dann geoMerge gestartet... siehe Screenshot #2.
P.S. Die Version von markusC64 aus Post#350 funktioniert jedenfalls... siehe ScreenShot #3.
meine Lösung (geofile128_DE.7z).
Letztere enthält ein installiertes geoFile128 und ein installiertes geoMerge. Grund: Es existiert kein Uninstaller für die GeoFile-Diskette. Auf der Zusatzdiskette ist neben dem Programm zur Änderung der Installation von geoFile 128 auch eine Version von geoMerge, die keine Installation mehr benötigt.
Super, Danke für den Hinweis. Dann werde ich die Version für meine Tests verwenden.
Wie auch immer, hier ein uninstalliertes Geofile 128 US - also die originale englische Version von Berkeley Softworks - und nicht die von M&T. Mitsamt original Kopierschutz und Seriennummerncheck.
Bei der US-Version hab ich beide Dateien geoFile und geoMerge installieren können. In der Wolke gibt es ein geoFile128-uninstalliert-DE.zip bei dem geoMerge aber noch installiert ist, geoFile selbst ist OK.
Wenn ich geoMerge starte kommt nur der Hinweis auf die falsche ID.
wweicht : Gibt es vom "deutschen" geoFile128 eine Version bei der geoMerge nicht installiert ist?
Das hat ja nichts mit der Übersetzung von Texten u.ä. zu tun. Vielleicht mußte durch die Unterschiede zwischen deutschem und amerikanischen Geos eine Anpassung für das deutsche Geos gemacht werden.
Das dürfte es sein!!! Ich hab eben mit Calc&Chart gearbeitet. Das "," im deutschen Calc erzeugt eine weitere Spalte im non-GE Chart. Das englische Calc nutzt KOMMA als 1000er-Trennung und den PUNKT als Trenner für zehntel und hundertstel...
Also dürfte die GE-Version für das deutsche GeoCalc stehen, auch wenn es selbst noch in englisch ist. Die GeoCalc-US-Version und die non-GE-Version arbeiten aber auch mit dem deutschen GEOS/MP3. Es müssen halt nur passende Dateien sein!
Danke für den Tipp!
Bei den Tests hab ich jetzt auch entdeckt das die geoCalc64-Version in der unkeyed-Edition fehlerhaft ist. Die scrollt permanent nach unten. Bei zimmers.net gibt es eine unkeyed-Version von geoCalc-US die mit dem englischen+deutschen GEOS funktioniert.
Wer von "GEOCHART 128" spricht, naja, lassen wird das.
Wer hat davon gesprochen? Der Autor vom README schreibt ja selbst das es das nicht gibt und das da jemand anderes gepfuscht hat...
Nur weil es ein Dokument gibt, wo das drin seht
Doch... beide Dateien (GE und non-GE) sind nicht binaer-Identisch, weder auf Disk noch im Speicher. Das sind zwei unterschiedliche englischsprachige, komplett assemblierte Versionen, GE hin oder her. Da sind nicht nur einzelne Bytes geändert. Und der 1.0de-Patch und der DEUTSCH-Patch brauchen die GE-Version.
Vielleicht das ja auch keine "GE"rman-Version sondern eine "G...E"dition, wird man wohl nicht mehr klären können.
Hab da jetzt einen Hinweis in der Anleitung ergänzt. Eigentlich müsste man 1.0er-Patches für die GE-Version erstellen, die keine deutschen Texte in das Programm einbauen. Damit könnte man die neuere GE-Version in englisch nutzen. Der 1.0er-Patch für 4LW bindet nämlich einige Texte in Deutsch ein und damit müssen sich englische Anwender entscheiden: Die alte non-GE-Version mit MP3-Support oder die neue GE-Version mit MP3-Support und ein paar deutschen Texten.
Als alternative fällt mir da natürlich Vice ein. Der kann doch mit .g64 umgehen. Oder täusche ich mich da
Ich habs auch mit VICE getestet. Und ich glaube nicht das es so einfach ist ein G64 Originalgetreu auf Disk zurückzuschreiben, daher versuche ich das erst gar nicht
Mit Ultimate oder TC64 sollte man aber in den emulierten Laufwerken ein G64 öffnen können. Ansonsten braucht es da spezielle Programme bzw. Hardware um ein G64 auf Disk zu schreiben.
Ohne das jetzt 100%ig geprüft zu haben
Ich hab in einem englischen geochart_ge_d64.gz-Archiv bei zimmers.net folgenden README-Text gefunden:
Und das passt schon, Deutsch ist in der Version nichts, zumindest nicht das Menü. Aber die 1.1er-Patches und der Patch von Jens setzen die GE-Version voraus. War hier im Forum auch schon mal Thema, die GE-Version ist ca. 6Monate neuer.
Die Patches von J. Weigt sind Eindeutschungen (gibt es auch für Calc, File, ..., wo die deutschen Versionen z.B. englische Menü-Texte haben).
Das hab ich jetzt in der Doku auch vermerkt. Mich hat nur gewundert das es die 1.1er-Patches nur für Chart gab. Bei geoFile ist der Deutsch-Patch erst am Ende anzuwenden, dann lassen sich alle drei fehlerfrei anwenden. Bei Chart muss der Deutsch-Patch der erste sein und dann dürfen es nur die 1.1er-Patches sein.
Also kommt zur Liste der Patches auch noch eine Liste mit der richtigen Reihenfolge. Das wird noch einiges an Arbeit sein.
