[Beta] Selbstentpackende ZIP-Archive

[Juergen]

Das selbstentpackende Modul des ZIP-Packers ist nun 32-bittig (da Windows VISTA keine 16-bit-Programme unterstützt)

Im Packdialog steht unverändert:

[ ] Erzeuge selbstentpackendes ZIP-Archiv (Windows 3.1 oder neuer)

Sollte dieser Punkt nun nicht besser etwa so lauten?

[ ] Erzeuge selbstentpackendes ZIP-Archiv (für 32-bit Windows)

Gruß, Jürgen

[Lefteous]

2Juergen
Ich bin wie du der Meinung, dass sich bei dieser Beschriftung etwas ändern muss. Allerdings bin ich hier für tiefgreifendere Änderungen, die auch Packer-Plugins miteinbezieht.

In jedem Fall gilt: In der 6.55 und auch in allen anderen Bugfix-Versionen gibt es keine Änderungen an irgendwelchen Beschriftungen, weil diese auch übersetzt werden müssten.

[ghisler(Author)]

Im Packdialog steht unverändert:
[ ] Erzeuge selbstentpackendes ZIP-Archiv (Windows 3.1 oder neuer)

Der Entpacker geht leider wirklich nicht unter Windows 3.1 mit Win32s. Leider würde eine Neuübersetzung sehr lange dauern (Wochen bis Monate) bis alle >30 Uebersetzer reagiert haben. Deshalb muss ich das auf TC7 verschieben.

[Juergen]

Auch wenn der TC 6.55 als Bugfix-Version deklariert ist, so handelt es sich bei dem hier besprochenen Punkt nicht um einen Bugfix, sondern um die Veränderung einer bislang offenbar korrekt arbeitenden Funktion. Dass diese Funktion nicht oder nicht vollständig mit Windows Vista zusammenarbeitet, liegt nicht an einem Bug im TC, sondern an einer diesbezöglichen Entscheidung der Vista-Entwickler.
Mit anderen Worten: Ich verstehe nicht, warum diese Funktion in einer reinen Bugfix-Version geändert wird. Wenn sie allerdings geändert wird, so muss auch die dazu gehörende Beschriftung geändert werden. Wenn jetzt keine Zeit dazu ist die Beschriftung zu übersetzen, dann sollte diese Funktion jetzt auch nicht geändert weden.
Muss man hier wirklich darüber diskutieren, ob eine Funktion das machen soll oder nicht, was die zugehörige Beschriftung verspricht??? Ähem ...

Gruß, Jürgen

[Sir_SiLvA]

Sorry aber ich finde die Entscheidung innerhalb einer Bugfix das zu ändern genau richtig!

Schließlich ist jeder in der Lage sich die entsprechenden STRINGS selbst zu ändern....

[Juergen]

Sorry aber ich finde die Entscheidung innerhalb einer Bugfix das zu ändern genau richtig!

Nur handelt es sich hier nicht um einen Bug, und es ist auch sonst nicht irgendwie dringend. (Von Windows Vista gibt es ja noch nicht einmal die offizielle Version.) Und da offenbar keine Zeit ist, das vollständig zu änderrn, warum sollte man es dann unvollständig ändern?

Schließlich ist jeder in der Lage sich die entsprechenden STRINGS selbst zu ändern....

Du meinst die Benutzer sollen die Funktionen des TC mit ihren zugehörigen Beschriftungen vergleichen, und die nicht passenden Beschriftungen dann selbst ändern? Kein Kommentar.

Gruß, Jürgen

[icfu]

Warum braucht ein Übersetzer bis zu drei Monate, bis er reagiert und einen String geändert hat und wo steht geschrieben, daß der TC nur dann ausgeliefert werden darf, wenn alle Übersetzungen vorliegen?

Es reicht doch wohl aus, wenn Deutsch, Englisch und Französisch fertig sind und der Rest nachgeliefert wird.

Wo soll das erst enden, wenn zuküntige TC-Versionen auch Ghanaisch unterstützen? Müssen wir dann vor jedem Release bangen, daß der Postbote auf seiner Zustellungs-Odyssee zum Übersetzer nicht erschossen wird?

Icfu

[Lefteous]

2Juergen
Ist halt ein schwieriger Spagat. Auf der einen Seite kann man die Kompatibilität zu einer neuen Betriebsystemversion nicht durch eine Bugfix-Version herstellen. Auf der anderen Seite ist es eben so, dass durch die öffentliche Beta von Vista viele Leute schon mal an dem neuen Betriebssystem schnuppern. Da ist es halt schön, wenn der SFX-Header für die Zips funktioniert. Das dann solche Inkonsistenzen auftauchen ist zwar blöd, aber dass die Funktion überhaupt geht, ist denke ich wichtiger.

Man könnte natürlich auch fragen, wofür man für ZIP einen SFX-Header braucht, aber das würde sicherlich zu weit führen...

[Lefteous]

2icfu

Warum braucht ein Übersetzer bis zu drei Monate, bis er reagiert und einen String geändert hat und wo steht geschrieben

Es müssen halt alle Übersetzer mitspielen, nicht nur einer. Wegen einem String alle Übersetzer zu kontaktieren, halte ich für reichlich unsinnig.

Was den 7er betrifft:

TC nur dann ausgeliefert werden darf, wenn alle Übersetzungen vorliegen?

Entschuldigung, aber das ist einfach eine Frage der Qualität.

Eine gute Vorgehensweise wäre es meiner Ansicht nach aber, einen Featurefreeze zu machen, dann eine öffentliche Testversion mit den wenigen vorhandenen Sprachen zu machen. In der Zeit können dann auch die Übersetzer aktiv werden. Danach wird dann releast. Ich hoffe das wird dann auch so gemacht.

[icfu]

Ich halte es für unsinnig, in TC-Subversionen Änderungen durchzuführen, die ein finales Betriebssystem zugunsten eines Betriebssystems im Betastadium benachteiligen.
Wenn schon, dann bitte einen richtigen Schlußstrich: Einstellung von Windows 3.1-Support mit der letzten Subversion von TC 6.5, aber bitte so, daß die gewohnte Funktionalität zum Abschied gewahrt wird.

So eine Entscheidung erweckt irgendwie den Eindruck, daß TC 7 erst nach dem Release von Windows Vista erscheinen wird und deshalb was zum Spielen da sein muß.

Ich sehe auch keine Qualität darin, ein fertiges Release mit wissentlich falschen Strings auszuliefern oder ein Release zurückzuhalten, weil irgendein Übersetzer zu langsam ist, deshalb meine Bitte um Beschränkung auf die Kernsprachen beim Release.

Ich habe selbst schon übersetzt und ich kann mir nicht so recht vorstellen, was genau das Problem sein soll, ist ja nicht so, als wenn solche "Notübersetzungen" an der Tagesordnung wären.

Mir als Anwender wäre es jedenfalls lieber, daß ich WEISS, daß eine Sprachdatei veraltet ist, als daß mir das aufgrund von übertriebener Rücksichtnahme auf die Übersetzer verschwiegen wird.

Icfu

[Juergen]

Hallo Lefteus, danke für deine Antwort.

Ist halt ein schwieriger Spagat. Auf der einen Seite kann man die Kompatibilität zu einer neuen Betriebsystemversion nicht durch eine Bugfix-Version herstellen. Auf der anderen Seite ist es eben so, dass durch die öffentliche Beta von Vista viele Leute schon mal an dem neuen Betriebssystem schnuppern. Da ist es halt schön, wenn der SFX-Header für die Zips funktioniert. Das dann solche Inkonsistenzen auftauchen ist zwar blöd, aber dass die Funktion überhaupt geht, ist denke ich wichtiger.

Z.B. gibt es ja von Mozilla diese nightly-builds, also Versionen bei denen man immer die neusten Features ausprobieren kann (und niemend erwartet, dass diese Versionen fehlerfrei und in sich konsistent sind). Wenn hier von einem "TC nightly build" die Rede wäre, würde ich nichts sagen, aber wie ich es verstehe soll der TC 6.55 ja eine offizielle Version für die produktive Verwendung sein. Oder wenn es sich um einen dringend zu fixenden Bug handeln würde ... Auch dass sowas aus Versehen passieren kann ist klar, mir sind menschliche Schwächen durchaus nicht fremd.

Aber ohne Not absichtlich eine falsche und irreführende Funktionsbeschreibung in ein seriöses Programm einzubauen kann ich nicht gut heißen. Das ist -- zurückhaltend beurteilt -- ähnlich einem "unforced error" im Tennis. Mit dem Unterschied, dass in einem Tennisspiel alles sehr schnell geht, während wir hier Zeit haben, die Dinge in epischer Breite zu diskutieren. Wie Icfu richtig schreibt, hat das mit Qualität nichts zu tun ... und auch nichts mit Usability, auf die du dankenswerter Weise in diesem Forum schon wiederholt hingewiesen hast. Auch als vertrauensfördernde Maßnahme kann man das nicht direkt verstehen ...

Vor ca. 1 Woche fragte in einem anderen Diskussionsforum ein Teilnehmer, ob ihm jemand best. Dateien in Form eines sich selbst extrahierenden ZIP-Archivs für Windows 3.1 zur Verfügung stellen könne. Das war für mich mit dem TC schnell und bequem gemacht!
Nun stell dir bitte vor, das wäre ein paar Wochen später passiert, und ich hätte den TC 6.55 mit dieser fehlerhaften und irreführenden Funktionsbeschreibung verwendet. Da ich vorsichtig bin und nicht genau weiß, ob auch diese neue TC-Version noch SFX-Archive für Windows 3.1 unterstützt, kucke ich mir das betr. Dialogfeld nochmal genau an und lese: "(Windows 3.1 oder neuer)" ... alles klar.
Wenig später versucht ein freundlicher Mensch in Argentinien, der mir vertraut hat, vergeblich diese SFX-Dateien auszuführen. Er wird unnütz Zeit vergeuden, sich dann wieder an mich wenden, ich muss die Ursache herausfinden, mir ist das Ganze ihm gegenpber peinlich usw. usf.
Warum? Damit ein paar Leute jetzt schon mal ein bisschen besser mit der Beta-Version von Windows Vista spielen können?

Gruß, Jürgen

[Juergen]

Hallo Icfu.

Ich halte es für unsinnig, in TC-Subversionen Änderungen durchzuführen, die ein finales Betriebssystem zugunsten eines Betriebssystems im Betastadium benachteiligen.

Ich auch.

Wenn schon, dann bitte einen richtigen Schlußstrich: Einstellung von Windows 3.1-Support mit der letzten Subversion von TC 6.5, aber bitte so, daß die gewohnte Funktionalität zum Abschied gewahrt wird.

Ganz meine Meinung. Einstellung von Windows 3.1-Support in der 32-bit Version des TC wäre vielleicht gar nicht mal schlimm, solange es noch die 16-bit Version des TC gibt. Aber dann bitte klare Kante und mit sehr deutlicher Dokumentation.

Ich sehe auch keine Qualität darin, ein fertiges Release mit wissentlich falschen Strings auszuliefern oder ein Release zurückzuhalten, weil irgendein Übersetzer zu langsam ist, deshalb meine Bitte um Beschränkung auf die Kernsprachen beim Release.

Ich denke im vorliegenden konkreten Fall würde es für's erste schon reichen, im betr. Dialogfeld den falschen und irreführenden Text "(Windows 3.1 oder neuer)" einfach wegzulassen. Dafür braucht man keinen Übersetzer zu kontaktieren. Dann enthält das Dialogfeld keinen falschen Inhalt mehr (und erschöpfend können Texte in Dialogfeldern die Situation ohnehin selten beschreiben).

Gruß, Jürgen

[Lefteous]

2Juergen
Also ich denke wenn es echt noch Bedarf an dem 16-Bit SFX Header gibt, dann sollte man ihn in der 7er zusätzlich mit ins Paket aufnehmen. Welcher verwendet wird, könnte man dann im Konfigurieren Dialog einstellen. So machen das Packer-Plugins wie Total SQX ja auch.
Wahrscheinlich ist es echt besser, jetzt in der 6.55 keinen neuen 32-Bit SFX Header einzubauen. Dabei spielt es auch keine Rolle ob 32- oder 16-Bit-Version des TC, denn das zu erstellende SFX-Programm ist ja für eine Zielplattform gedacht.

[ghisler(Author)]

Leider habe ich in letzter Zeit vermehrt Fehlermeldungen von Usern mit 64-bit Windows erhalten, dass der Entpacker nicht gehe - 64-bit Windows unterstützt auch keine 16-bit-Programme mehr. Deshalb sehe ich das schon als Bugfix, und nicht als neues Feature.

Nun habe ich herausgefunden, wieso der Entpacker unter Windows 3.1 nicht geht: Grund ist der UPX-EXE-Packer, mit dem das Entpackmodul verkleinert wurde. Durch Wegoptimieren einiger Units konnte ich die Grösse ungepackt nun auf 35k drücken, weshalb UPX nicht mehr nötig ist. Damit funktioniert der Entpacker nun auch wieder unter Windows 3.1 mit Win32s!

Ich glaube man kann mittlerweile davon ausgehen, dass so gut wie alle alten Windows 3.1-Installationen auch Win32s drauf haben, oder? Dann stimmt auch der Text "Windows 3.1 oder neuer" wieder.

Eine Testversion des neuen sfxhead.sfx gibt es hier:
https://plugins.ghisler.com/beta/sfxheadw32s.zip

Bitte ins totalcmd-Verzeichnis entpacken.

[Juergen]

Leider habe ich in letzter Zeit vermehrt Fehlermeldungen von Usern mit 64-bit Windows erhalten, dass der Entpacker nicht gehe - 64-bit Windows unterstützt auch keine 16-bit-Programme mehr. Deshalb sehe ich das schon als Bugfix, und nicht als neues Feature.

Ich würde das als Inkompatibilität bzw. dessen Beseitigung bezeichnen. Ein Bug ist für mich ein Fehler im Programm. Und es ist ja nicht Total Commanders Fehler, wenn 64-bit Windows keine 16-bit-Programme mehr unterstützt. Außerdem sollte es nach meinem Verständnis nicht sein, dass nach einem reinen Bugfix etwas nicht mehr funktioniert, was davor funktioniert hat und auch offiziell dokumentiert war.

... weshalb UPX nicht mehr nötig ist. Damit funktioniert der Entpacker nun auch wieder unter Windows 3.1 mit Win32s!

Super!

Ich glaube man kann mittlerweile davon ausgehen, dass so gut wie alle alten Windows 3.1-Installationen auch Win32s drauf haben, oder?

Das kann ich nicht beurteilen.

Eine Testversion des neuen sfxhead.sfx gibt es hier:
https://plugins.ghisler.com/beta/sfxheadw32s.zip

Bitte ins totalcmd-Verzeichnis entpacken.

Ich kann das leider nicht testen, da mein altes Notebook mit Win 3.1 seinen Geist aufgegeben hat (um so wichtiger ist es daher, dass ich mich darauf verlassen kann dass es funktioniert, wenn ich anderen solch eine SFX-Datei schicke).

Danke für die Verbesserung!

Gruß, Jürgen