Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp [EMAIL PROTECTED] schrieb am 07.02.06 um 18:53: Warum 'copy' ab Pos. 0? Das muß IMO Pos. 1 sein. Wenn das mit 0 funktioniert, würde mich interessieren, warum. Bisher hat Copy auch immer ab Pos 0 genauso wie Pos 1 funktioniert. Vermutlich eine interne Fehlerkorrektur für den Sonderfall 0. Jedenfalls zählt 'copy' die Positionen ab 1. Denke ich auch. Ist ja eigentlich logisch, das man in so einem Fall einfach den Anfang des Strings als Anfang des neuen Strings haben will. -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Reinhard Irmer [EMAIL PROTECTED] schrieb am 06.02.06 um 20:17: Unter ftp://ftp.freexp.de/freexp/test/RC4R2.ZIP gibts jetzt eine Testversion die die Korrekturen von Heute enthaelt. Das Archiv enthaelt nur die XP.EXE + XP.OVR. Danke. Habs mir geholt und upgedated. Funktioniert :-). Aber ich haette noch eine Bitte: Koenntest Du auch die Version 3.45 (exe+ovr zusammengebaut) dergestalt fixen, denn ich moechte zu gern wissen, ob damit die Note eliminiert wird. Sei beruhigt, der Fix ist natürlich auch im Hauptbranch drin. Und der Fix besteht eben daraus den String zu verlängern und abzusichern, das CRLF wirklich immer angehängt werden kann. Von daher ist eine 3.45 Alpha eigentlich unnötig. Wenn bei dir bei der 3.40 RC4 R2 nichts abgeschnitten wird, dann auch nichts bei der 3.45 Alpha. Wenn du es wirklich testen willst, kann ich natürlich auch eine 3.45 bauen. -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp [EMAIL PROTECTED] schrieb am 06.02.06 um 19:22: Und das es so bei anderen nicht aufgetretten ist, ist allein die doch eher seltene Konstellation einer Kom-Reg, die den Stringaufbau ein wenig intern ändert, Er wird dadurch einfach länger, Richtig. Es ist aber auffällig: Als ich mich vor der Behebung dieses Problems mit Testen beschäftigt hatte, konnte ich niemals ein fehlendes CRLF sehen, sondern immer nur verstümmelte XP-Werbesignaturen. Bei einer normalen Reg stünde dann da halt ein R statt einem K, aber die Folgen wären dieselben. Sollten zumindest so sein. War aber komischerweise nicht so. Der Code gibt es aber auch nicht wirklich her, warum das so ist. Nur ist nach dem R einer normalen Reg der Teilstring zuende. Bei der Kom-Reg geht er erst noch weiter. Dennoch ist es natürlich eine gewöhnliche Stringaddition. Es ist wohl nur deshalb nicht aufgetreten (oder in den wenigen Fällen nicht aufgefallen), weil im RFC-Raum kaum jemand die XP-Signatur aktiviert hat. Das kommt allerdings dazu. Die XP-Werbesignatur ist früher auch sowieso sehr unbeliebt gewesen. Es gab da einen Typen der es sich zur Aufgabe gamacht hatte Bitte abstellen-Postings zu versenden, wenn einer die Sig anhatte. Ja, KomReg gegenüber Standard-Reg ist ein kleiner Unterschied, der einen kleinen Unterschied macht. Ganz sicher? IMO liegt es nur an der Stringlänge. Natürlich ist es die Stringlänge. Normal sollte übrigens sowieso ein String in XP immer ein CRLF bekommen, egal was man sich so zusammenprogrammiert. Das kommt ganz auf die Routine an. Wenn 'writeln' verwendet wird, wird natürlich ein CRLF angehängt, aber das ist im Falle der Signatur offenbar nicht der Fall. Da wird das CRLF zum Bestandteil des Signatur- Strings, vermutlich deshalb, weil er irgendwann danach mit 'blockwrite' weggeschrieben wird. Stimmt, hast natürlich recht. Es kam aber wohl eine besonders unglückliche Kombination zusammen, die das CRLF irgendwie nicht ans Ende gebracht hat. Es ist wegen Überlänge einfach hinten aus dem String rausgefallen, oder nicht? Ja, natürlich. Nur ist es eben seltsam, das ich immer ein CRLF am Ende hatte. -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp [EMAIL PROTECTED] schrieb am 06.02.06 um 19:30: Also würde ich ein relativ zeitnahes Recompilat der RC4 vorschlagen. Und zwar sobald meine Änderungen von Heute sauber getestet sind. Hmm, wollen wir nicht vielleicht den nächsten RC erst fertigstellen? Natürlich, und danach brauchen wir natürlich kein Recompilat der RC4 mehr. Ich dachte nur wegen der Schwere, wäre ein schneller Fix angebracht. Noch eine Zwischenversion, weiß nicht... Und extra eine RC-Nummer dafür zu verbraten fänd ich jetzt auch übertrieben. Ok, also jetzt den RC5 fertigstellen. Es ist xp6s.inc wo die Werbe-Signatur und die Tearline gebaut werden. In xp6.pas wird die XP_ID declariert. War mir klar, daß es in der Ecke sein muß. Aber was ich meinte, war: Das sind so typische Routinen, die entstehen, wenn jemand alleine an einem Programm arbeitet. Das ist natürlich richtig. Der hat dann eine relativ gute Chance, daß ihm beim Bauen solcher Strings einfällt Da war doch was Zumal die sich zu Zeiten von v3.12 und davor ja auch nicht ganz so oft in der Gesamtlänge geändert haben. Richtig, es gab eignetlich diese Vielzahl von öffentlichen Zwischenversionen nicht. Also Variable verlängern, da sie sonst immer mal wieder an seine Längengrenze stossen könnte. Jetzt 80 Zeichen + Absicherung nach 78 Zeichen. Ok. 78 Zeichen find ich auch einen sinnvollen Wert. Ok. Trotzdem bin ich der Meinung, daß das Halloween an der Stelle gar nix zu suchen hat. Was die Halloween-Version selbst angeht: Diese habe ich in diesem Punkt natürlich nicht geändert, da nur echte Probleme dort geändert werden sollten. Was alle zukünftigen Versionen angeht: Der Rufname ist jetzt eine eigne Stringkonstante, und gleichzeitig wird dieser String nur noch dort eingebaut, wo er sinnvoll erscheind. Also: X/S/S About und MAILER: b) zusätzlich sicherstellen, daß selbst bei versehentlich längeren Strings auf jeden Fall ein CRLF angehängt wird (z.B. indem man ein 'truncstr(s,sizeof(variable)-3)' davorschaltet). Das sieht dann bei gekürzten Strings zwar unschön aus, führt aber wenigstens zu einer technisch sauberen Nachricht. Ebenfalls geschehen. Gut. Man sollte natürlich zukünftig trotzdem darauf achten, daß die Summe aller für die Signatur verwendeten Variablen (inkl. Leerzeichen) nicht länger als 78 Zeichen wird. Vielleicht wäre ein Kommentar in xpglobal.pas angebracht. done. -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Reinhard Irmer [EMAIL PROTECTED] schrieb am 07.02.06 um 10:43: Wenn du es wirklich testen willst, kann ich natürlich auch eine 3.45 bauen. Wäre nett.wenn es Dir nicht all zu viel Zeit wegnimmt ;-) Das Compilieren geht schnell, und das Hochladen kann im Hintergrund geschehen. BTw: Läd gerade hoch als ftp://ftp.freexp.de/freexp/test/FXP345.ZIP (nur EXE+OVR) -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Martin Wodrich schrieb: Reinhard Irmer [EMAIL PROTECTED] schrieb am 07.02.06 um 10:43: Wenn du es wirklich testen willst, kann ich natürlich auch eine 3.45 bauen. Wäre nett.wenn es Dir nicht all zu viel Zeit wegnimmt ;-) Das Compilieren geht schnell, und das Hochladen kann im Hintergrund geschehen. BTw: Läd gerade hoch als ftp://ftp.freexp.de/freexp/test/FXP345.ZIP (nur EXE+OVR) Geholt und ausprobiert: Die Note ist weg :-) btw: Ich dachte, die 3.45 zeichnet sich dadurch aus, daß exe+ovr in der exe zusammengezogen sind? -- gruss Reinhard FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Martin Wodrich [EMAIL PROTECTED] wrote on 05.02.06:
Michael Heydekamp [EMAIL PROTECTED] schrieb am 02.02.06 um 17:08:
b) zusätzlich sicherstellen, daß selbst bei versehentlich längeren
Strings auf jeden Fall ein CRLF angehängt wird (z.B. indem man
ein 'truncstr(s,sizeof(variable)-3)' davorschaltet). Das sieht
dann bei gekürzten Strings zwar unschön aus, führt aber
wenigstens zu einer technisch sauberen Nachricht.
Ebenfalls geschehen.
Hab ich mir eben mal im daily diff angesehen:
--8--
procedure Set_XP_ID;
begin
XP_ID:='## '+xp_xp+' '+verstr+betastr+
- ovrstr+iifs(is_freereg,'',krk(regstr))+' ##'+#13#10;
+ ovrstr+iifs(is_freereg,'',krk(regstr))+' ##';
+ XP_ID:=Copy(XP_ID,0,78)+#13#10;
end;
--8--
Warum 'copy' ab Pos. 0? Das muß IMO Pos. 1 sein. Wenn das mit 0
funktioniert, würde mich interessieren, warum.
Und im Code mit festen Werten wie 78 zu arbeiten, ist auch immer eine
gute Bugquelle, denn wenn jemand irgendwann mal die Stringvariable
wieder anders dimensioniert, muß er daran denken, auch den Code
anzupassen. Nicht ohne Grund hatte ich oben mit 'sizeof' gearbeitet.
Gibt verschiedene Möglichkeiten:
1) XP_ID:=left(XP_ID,sizeof(XP_ID)-3)+#13#10;
2) truncstr(XP_ID,sizeof(XP_ID)-3));
XP_ID:=XP_ID+#13#10;
3) XP_ID:=copy(XP_ID,1,sizeof(XP_ID)-3)+#13#10;
Ich würde 1) nehmen, dürfte am schnellsten sein. Bei 'sizeof' muß man
berücksichtigen, daß das Längenbyte mitgezählt wird, deshalb -3.
Noch etwas:
--8--
{ CrossPoint - First Unit }
@@ -257,7 +257,7 @@
writeln(t);
write(t,xp_xp);
if (xp_xp='CrossPoint') then write(t,'(R)');
- writeln(t,' ',verstr,betastr,ovrstr);
+ writeln(t,' ',verstr,betastr,iifs(rufstr'',' ('+rufstr+')',''),ovrstr);
writeln(t,x_copyright,' by ',author_name,' (',author_mail,')');
writeln(t);
if _deutsch then
@@ -361,6 +361,14 @@
--8--
Wir hatten ja gesagt, daß Rufnamen sowohl immer in Klammern als auch in
Anführungszeichen eingeschlossen werden sollen. Offenbar sind die
Anführungszeichen Bestandteil der Stringvariablen, die Klammern werden
aber erst beim Schreiben ergänzt.
Ich würd's insofern vereinheitlichen, als daß entweder beides
Bestandteil des Strings ist und man dann einfach übersichtlicher
schreibt ...
writeln(t,' ',verstr,betastr,rufstr,ovrstr);
... oder beides eben nicht Bestandteil des Strings ist und auch die
Anführungszeichen erst beim Schreiben ergänzt werden. Ich würde die
erste Variante bevorzugen, dann muß man nur darauf achten, daß die
Variable ein leading blank hat. Die anderen Stellen wären entsprechend
anzupassen.
iifs()-Konstrukte vermeide ich jedenfalls gerne da, wo sie ohne großen
Aufwand zu vermeiden sind.
Michael
FreeXP Entwickler-Mailingliste
Dev-List@freexp.de
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Reinhard Irmer [EMAIL PROTECTED] wrote on 07.02.06: btw: Ich dachte, die 3.45 zeichnet sich dadurch aus, daß exe+ovr in der exe zusammengezogen sind? Nein, das war auch in der ursprünglichen Halloween-Version schon so, die bis zum Erscheinen des Re-Compilats am 23.01.1006 auf dem Server lag. Das Splitten von EXE und OVR war doch genau der Grund und Anlaß für das Re-Compilat. Steht im Announce, auf der Website, im FILE_ID.DIZ ... Eine Version mit eincompilierter OVR wird's erst dann wieder geben, wenn UKAW so gefixt ist, daß es die EXE nicht mehr im R/W-Modus öffnet. Da die Entwicklung von UKAW aber (angeblich) abgeschlossen ist (auch wenn TG selbst bereits mit einer v3.55 unterwegs ist), ist damit kaum zu rechnen. Michael FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp [EMAIL PROTECTED] schrieb am 07.02.06 um 14:52: Warum 'copy' ab Pos. 0? Das muß IMO Pos. 1 sein. Wenn das mit 0 funktioniert, würde mich interessieren, warum. Bisher hat Copy auch immer ab Pos 0 genauso wie Pos 1 funktioniert. Und im Code mit festen Werten wie 78 zu arbeiten, ist auch immer eine gute Bugquelle, Stimmt. 1) XP_ID:=left(XP_ID,sizeof(XP_ID)-3)+#13#10; Ich habe deine Varinate 1 eingebaut. Wir hatten ja gesagt, daß Rufnamen sowohl immer in Klammern als auch in Anführungszeichen eingeschlossen werden sollen. Offenbar sind die Anführungszeichen Bestandteil der Stringvariablen, die Klammern werden aber erst beim Schreiben ergänzt. Hab ich jetzt so geändert, das beides beim Schreiben ergänzt wird. Ist imho besser, da man den Rufnamen meist relativ spontan setzt. Und dann weiß man vielleicht im Momenbt nicht, das man Klammern und Anführungszeichen setzen muß. Daher wird beides beim Schreiben ergänzt. -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Martin Wodrich [EMAIL PROTECTED] wrote on 07.02.06: Michael Heydekamp [EMAIL PROTECTED] schrieb am 07.02.06 um 14:52: Warum 'copy' ab Pos. 0? Das muß IMO Pos. 1 sein. Wenn das mit 0 funktioniert, würde mich interessieren, warum. Bisher hat Copy auch immer ab Pos 0 genauso wie Pos 1 funktioniert. Vermutlich eine interne Fehlerkorrektur für den Sonderfall 0. Jedenfalls zählt 'copy' die Positionen ab 1. Und im Code mit festen Werten wie 78 zu arbeiten, ist auch immer eine gute Bugquelle, Stimmt. 1) XP_ID:=left(XP_ID,sizeof(XP_ID)-3)+#13#10; Ich habe deine Varinate 1 eingebaut. Ok. :) Wir hatten ja gesagt, daß Rufnamen sowohl immer in Klammern als auch in Anführungszeichen eingeschlossen werden sollen. Offenbar sind die Anführungszeichen Bestandteil der Stringvariablen, die Klammern werden aber erst beim Schreiben ergänzt. Hab ich jetzt so geändert, das beides beim Schreiben ergänzt wird. Auch gut. Michael FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Martin Wodrich [EMAIL PROTECTED] wrote on 05.02.06: Michael Heydekamp [EMAIL PROTECTED] schrieb am 02.02.06 um 13:19: ## CrossPoint/FreeXP v3.40 RC4 (Halloween) (XMS) K---==_CrossPoint_Next_MIME_Part_==- --8-- Daher findet XP das im Header deklarierte Boundary nicht und kann die einzelnen Teile nicht erkennen. Das hat jetzt aber nix mit mir zu tun, oder? Nein, sondern mit XP natürlich. Klarer Bug. Und das es so bei anderen nicht aufgetretten ist, ist allein die doch eher seltene Konstellation einer Kom-Reg, die den Stringaufbau ein wenig intern ändert, Er wird dadurch einfach länger, aber: Das müßte auch bei einer normalen Reg auftreten, weil das K von Kom-R exakt das 50. Zeichen ist. Bei einer normalen Reg stünde dann da halt ein R statt einem K, aber die Folgen wären dieselben. Es ist wohl nur deshalb nicht aufgetreten (oder in den wenigen Fällen nicht aufgefallen), weil im RFC-Raum kaum jemand die XP-Signatur aktiviert hat. Definitiv. Wundert mich nur, weil ich das bei meiner Version nicht reproduzieren kann. Vielleicht auch deshalb, weil nicht dieselben Ranfbedingungen zutreffen. Als ich das schrieb, war mir der Zusammenhang mit der Stringlänge noch nicht klar. Ja, KomReg gegenüber Standard-Reg ist ein kleiner Unterschied, der einen kleinen Unterschied macht. Ganz sicher? IMO liegt es nur an der Stringlänge. Normal sollte übrigens sowieso ein String in XP immer ein CRLF bekommen, egal was man sich so zusammenprogrammiert. Das kommt ganz auf die Routine an. Wenn 'writeln' verwendet wird, wird natürlich ein CRLF angehängt, aber das ist im Falle der Signatur offenbar nicht der Fall. Da wird das CRLF zum Bestandteil des Signatur- Strings, vermutlich deshalb, weil er irgendwann danach mit 'blockwrite' weggeschrieben wird. Es kam aber wohl eine besonders unglückliche Kombination zusammen, die das CRLF irgendwie nicht ans Ende gebracht hat. Es ist wegen Überlänge einfach hinten aus dem String rausgefallen, oder nicht? Michael FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Martin Wodrich [EMAIL PROTECTED] wrote on 05.02.06: Michael Heydekamp [EMAIL PROTECTED] schrieb am 02.02.06 um 17:08: Dadurch kommt es zu einer Nachricht ohne abschließendes CRLF, was wiederum dazu führt, daß alle nachfolgenden Strings unmittelbar an das Ende der Signatur angehängt werden (u.a. mit der Folge, daß ein MIME- Boundary nicht mehr erkannt werden kann oder eine nachfolgende Nachricht mit der vorherigen zusammengezogen wird). Ich würde das sogar als einen relativ kapitalen Bug bezeichnen (kleine Ursache, große Wirkung). Also würde ich ein relativ zeitnahes Recompilat der RC4 vorschlagen. Und zwar sobald meine Änderungen von Heute sauber getestet sind. Hmm, wollen wir nicht vielleicht den nächsten RC erst fertigstellen? Noch eine Zwischenversion, weiß nicht... Und extra eine RC-Nummer dafür zu verbraten fänd ich jetzt auch übertrieben. Eine der typischen und unzureichend abgesicherten Annahmen in XP, denn wenn man in xpglobal.pas neue Strings für die Versionsbezeichnung einträgt und dabei nicht unmittelbar auf die Idee kommt Moment, da war doch in sowieso.pas was mit einer auf 50 Zeichen begrenzten Signatur, dann kommt es zu solchen Folgen. Es ist xp6s.inc wo die Werbe-Signatur und die Tearline gebaut werden. In xp6.pas wird die XP_ID declariert. War mir klar, daß es in der Ecke sein muß. Aber was ich meinte, war: Das sind so typische Routinen, die entstehen, wenn jemand alleine an einem Programm arbeitet. Der hat dann eine relativ gute Chance, daß ihm beim Bauen solcher Strings einfällt Da war doch was Zumal die sich zu Zeiten von v3.12 und davor ja auch nicht ganz so oft in der Gesamtlänge geändert haben. Der Fix wäre: a) Sicherstellen, daß keine Signaturen länger als 48 Zeichen erzeugt werden (oder alternativ die Variable vergrößern), und Also Variable verlängern, da sie sonst immer mal wieder an seine Längengrenze stossen könnte. Jetzt 80 Zeichen + Absicherung nach 78 Zeichen. Ok. 78 Zeichen find ich auch einen sinnvollen Wert. Trotzdem bin ich der Meinung, daß das Halloween an der Stelle gar nix zu suchen hat. b) zusätzlich sicherstellen, daß selbst bei versehentlich längeren Strings auf jeden Fall ein CRLF angehängt wird (z.B. indem man ein 'truncstr(s,sizeof(variable)-3)' davorschaltet). Das sieht dann bei gekürzten Strings zwar unschön aus, führt aber wenigstens zu einer technisch sauberen Nachricht. Ebenfalls geschehen. Gut. Man sollte natürlich zukünftig trotzdem darauf achten, daß die Summe aller für die Signatur verwendeten Variablen (inkl. Leerzeichen) nicht länger als 78 Zeichen wird. Vielleicht wäre ein Kommentar in xpglobal.pas angebracht. Michael FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp [EMAIL PROTECTED] schrieb am 02.02.06 um 13:19: --8-- ## CrossPoint/FreeXP v3.40 RC4 (Halloween) (XMS) K---==_CrossPoint_Next_MIME_Part_==- --8-- Daher findet XP das im Header deklarierte Boundary nicht und kann die einzelnen Teile nicht erkennen. Das hat jetzt aber nix mit mir zu tun, oder? Nein, sondern mit XP natürlich. Klarer Bug. Und das es so bei anderen nicht aufgetretten ist, ist allein die doch eher seltene Konstellation einer Kom-Reg, die den Stringaufbau ein wenig intern ändert, wodurch gewisse kritische Aktionen zufällig unglücklich zusammenkamen, das sich ein Fehler zeigt. Definitiv. Wundert mich nur, weil ich das bei meiner Version nicht reproduzieren kann. Vielleicht auch deshalb, weil nicht dieselben Ranfbedingungen zutreffen. Ja, KomReg gegenüber Standard-Reg ist ein kleiner Unterschied, der einen kleinen Unterschied macht. Normal sollte übrigens sowieso ein String in XP immer ein CRLF bekommen, egal was man sich so zusammenprogrammiert. Es kam aber wohl eine besonders unglückliche Kombination zusammen, die das CRLF irgendwie nicht ans Ende gebracht hat. Hier kann ich auch nicht nachvollziehen, das ein CRLF unvollständig oder fehlend ans Ende gefügt wird. Ich habe es aber jetzt deutlich sicher gestaltet. -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp [EMAIL PROTECTED] schrieb am 02.02.06 um 17:08: Mittlerweile glaube ich, daß die bei mir herrschenden Randbedingungen Grenzwertigkeit in so ziemlich allen Belangen besitzen ;-)) Nicht Grenzwertig, sondern ungewöhnlich. In diesem Fall liegt es nicht an Dir, sondern an XP. Ohne jetzt in den Code geschaut zu haben, kann man an dem beobachteten Verhalten die Ursache des Bugs förmlich riechen: Da wird irgendeine Variable für die Signatur auf 50 Zeichen begrenzt sein. Ja, und zwar XP_ID, was eben genau eben die Werbesignatur trägt. Hab ich jetzt direkt mal auf 80 Zeichen aufgebohrt. Diese Variable wird mittels einer Stringaddition nach dem Prinzip bla + blubb + baeh + #13#10 gefüllt (wobei #13#10 für den Zeilentrenner CRLF stehen). Jepp, stand praktisch exakt so im Code. Jetzt wird erst mal geschaut ob mehr als 78 Zeichen drin sind und wenn ja, nur die ersten 78 Zeichen verwendet und dann CRLF angehängt. Das ist solange gut gegangen, wie die XP-Signatur nie länger als 48 Zeichen war. Was sie durch diverse Umstände bisher praktisch nicht war. Und wenn, dann nur in Versionen, die nicht so breit im Einsatz waren wie die Halloween-Version. Dadurch kommt es zu einer Nachricht ohne abschließendes CRLF, was wiederum dazu führt, daß alle nachfolgenden Strings unmittelbar an das Ende der Signatur angehängt werden (u.a. mit der Folge, daß ein MIME- Boundary nicht mehr erkannt werden kann oder eine nachfolgende Nachricht mit der vorherigen zusammengezogen wird). Ich würde das sogar als einen relativ kapitalen Bug bezeichnen (kleine Ursache, große Wirkung). Also würde ich ein relativ zeitnahes Recompilat der RC4 vorschlagen. Und zwar sobald meine Änderungen von Heute sauber getestet sind. Eine der typischen und unzureichend abgesicherten Annahmen in XP, denn wenn man in xpglobal.pas neue Strings für die Versionsbezeichnung einträgt und dabei nicht unmittelbar auf die Idee kommt Moment, da war doch in sowieso.pas was mit einer auf 50 Zeichen begrenzten Signatur, dann kommt es zu solchen Folgen. Es ist xp6s.inc wo die Werbe-Signatur und die Tearline gebaut werden. In xp6.pas wird die XP_ID declariert. Der Fix wäre: a) Sicherstellen, daß keine Signaturen länger als 48 Zeichen erzeugt werden (oder alternativ die Variable vergrößern), und Also Variable verlängern, da sie sonst immer mal wieder an seine Längengrenze stossen könnte. Jetzt 80 Zeichen + Absicherung nach 78 Zeichen. b) zusätzlich sicherstellen, daß selbst bei versehentlich längeren Strings auf jeden Fall ein CRLF angehängt wird (z.B. indem man ein 'truncstr(s,sizeof(variable)-3)' davorschaltet). Das sieht dann bei gekürzten Strings zwar unschön aus, führt aber wenigstens zu einer technisch sauberen Nachricht. Ebenfalls geschehen. -- Mit freundlichen Gruessen, Martin Wodrich FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Reinhard Irmer [EMAIL PROTECTED] wrote on 02.02.06: hier ein *.out zum Nachvollziehen. Damit kann ich nix nachvollziehen, Du hättest den ZC-Puffer mit N/X als..Puffer aus XP extrahieren müssen und *den* schicken müssen. Du hast doch selbst gesagt, daß Du die Note schon *vor* dem Versand (und damit auch *vor* einer UUZ-Konvertierung) siehst. Warum schickst Du dann eine vom UUZ konvertierte *.OUT, die das fragliche Zeichen gar nicht mehr enthält? Die von Dir angehängte RFC-Nachricht ist bei Dir in zu-Richtung durch den UUZ gelaufen, dann beim Anhängen von XP base64-codiert worden, dann beim Versand des Attachments nochmal durch den UUZ gelaufen, über diverse Clients und Server transportiert worden, hier beim Empfang in uz-Richtung nochmal durch den UUZ gelaufen, anschließend in XP extrahiert und dabei base64-decodiert worden, und das Extrakt ist dann von mir nochmal in uz-Richtung durch den UUZ geschickt worden, um wieder einen ZC-Puffer zu erhalten. Bei diesen vielen Bearbeitungsschritten ist irgendwo das einzelne CR (aka die Note) repariert worden, vermutlich schon bei der allerersten UUZ-Konvertierung auf Deinem System, bevor Du die Nachricht aus dem Spool gefischt und als Attachment verschickt hast. Aber egal, ich glaub's Dir auch so, denn nicht nur die v3.45 hat offenbar ein Problem mit XP-Signaturen, sondern die Halloween-Version ebenfalls. Deine Multipart wurde hier zwar mit M geflagged, aber beim Öffnen kam nicht das MIME-Auswahlmenü, weil XP -- evtl. im Zusammenspiel mit dem UUZ -- die XP-Signatur und das MIME-Boundary zu einer Zeile zusammengezogen hat (lange Zeile, Ctrl-W drücken): --8-- ## CrossPoint/FreeXP v3.40 RC4 (Halloween) (XMS) K---==_CrossPoint_Next_MIME_Part_==- --8-- Daher findet XP das im Header deklarierte Boundary nicht und kann die einzelnen Teile nicht erkennen. Hab's hier händisch repariert und hänge zur Dokumentation die Nachricht aus dem Spool in der Bezugsnachricht nochmal an. Danke für den Hinweis, irgendwas ist im Zusammenhang mit der XP-Signatur in der Tat nicht ganz sauber, und zwar grundsätzlich nicht. Michael FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Bug mit XP-Signatur (was: Note als letztes Zeichen der Sigline in FXP 3.45a)
Michael Heydekamp [EMAIL PROTECTED] wrote on 02.02.06: [...] Daher findet XP das im Header deklarierte Boundary nicht und kann die einzelnen Teile nicht erkennen. Hab's hier händisch repariert und hänge zur Dokumentation die Nachricht aus dem Spool in der Bezugsnachricht nochmal an. Danke für den Hinweis, irgendwas ist im Zusammenhang mit der XP-Signatur in der Tat nicht ganz sauber, und zwar grundsätzlich nicht. Hängt dran. Jetzt muß sich nur noch wer kümmern. ;) Michael N.IN Description: Binary data FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp schrieb: Reinhard Irmer [EMAIL PROTECTED] wrote on 02.02.06: hier ein *.out zum Nachvollziehen. Damit kann ich nix nachvollziehen, was sind denn dann die Zeichen =23 =23 am Ende der Sigzeile? Du hättest den ZC-Puffer mit N/X als..Puffer aus XP extrahieren müssen und *den* schicken müssen. aha und wie soll das gehen? Ich schreibe das posting und sage JA im Sendefenster dann N/U/Z, Balken drauf dann N/X/A/Enter/P und dann??Ich hab danach nur ein *.PP-File im XP-Verzeichnis gefunden, meinst Du das? Du hast doch selbst gesagt, daß Du die Note schon *vor* dem Versand (und damit auch *vor* einer UUZ-Konvertierung) siehst. richtig, bei N/U/Zenter Warum schickst Du dann eine vom UUZ konvertierte *.OUT, die das fragliche Zeichen gar nicht mehr enthält? ob das OUT das Notenzeichen evtl. in anderer Form (=23 ??) enthält, kann ICH nicht beurteilen. Deswegen das posting hierher. Die von Dir angehängte RFC-Nachricht ist bei Dir in zu-Richtung durch den UUZ gelaufen, [...] das war aber auch alles. Das OUT ist nie rausgegangen, sondern abgefangen und as is als attach angehängt worden. [...] Aber egal, ich glaub's Dir auch so, :-) das ist nett, aber ich möchte schon genau wissen, was ich wie tun muß, damit dev-spezialisten was damit anfangen können. Dass mit sccreenshots nix anzufangen ist, hab ich schon mitbekommen ;-) denn nicht nur die v3.45 hat offenbar ein Problem mit XP-Signaturen, sondern die Halloween-Version ebenfalls. wie man an den screenshots sieht ;-] Deine Multipart wurde hier zwar mit M geflagged, aber beim Öffnen kam nicht das MIME-Auswahlmenü, weil XP -- evtl. im Zusammenspiel mit dem UUZ -- die XP-Signatur und das MIME-Boundary zu einer Zeile zusammengezogen hat (lange Zeile, Ctrl-W drücken): --8-- ## CrossPoint/FreeXP v3.40 RC4 (Halloween) (XMS) K---==_CrossPoint_Next_MIME_Part_==- --8-- Daher findet XP das im Header deklarierte Boundary nicht und kann die einzelnen Teile nicht erkennen. Das hat jetzt aber nix mit mir zu tun, oder? [...] Danke für den Hinweis, irgendwas ist im Zusammenhang mit der XP-Signatur in der Tat nicht ganz sauber, und zwar grundsätzlich nicht. naja, dann hat mein Rumgemurkse doch wieder etwas Sinn gemacht ;-) -- gruss Reinhard FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Reinhard Irmer [EMAIL PROTECTED] wrote on 02.02.06: Michael Heydekamp schrieb: Reinhard Irmer [EMAIL PROTECTED] wrote on 02.02.06: hier ein *.out zum Nachvollziehen. Damit kann ich nix nachvollziehen, was sind denn dann die Zeichen =23 =23 am Ende der Sigzeile? ## Das Ende der Signatur halt. Du hättest den ZC-Puffer mit N/X als..Puffer aus XP extrahieren müssen und *den* schicken müssen. aha und wie soll das gehen? Wie man einen Puffer extrahiert? Mit N/X/N halt und vor dem letzten N dafür sorgen, daß Als..Puffer eingestellt ist. Dann im Eingabefeld Nachricht extrahieren einen Dateinamen angeben und die Datei irgendwo temporär speichern. Dann das Bugmeldeposting erstellen und daran die eben gespeicherte Datei als Attachment anhängen (genauso, wie Du die Datei aus dem Spool angehängt hast). Danach kannst Du die Datei löschen. Ich schreibe das posting und sage JA im Sendefenster dann N/U/Z, Balken drauf dann N/X/A/Enter/P und dann?? Siehe oben: N :-) Ich hab danach nur ein *.PP-File im XP-Verzeichnis gefunden, meinst Du das? Das hättest Du alternativ auch schicken können, wenn es keine weiteren Nachrichten enthält, die uns möglicherweise nix angehen. ;) Warum schickst Du dann eine vom UUZ konvertierte *.OUT, die das fragliche Zeichen gar nicht mehr enthält? ob das OUT das Notenzeichen evtl. in anderer Form (=23 ??) enthält, kann ICH nicht beurteilen. Deswegen das posting hierher. Das Notenzeichen ist wie gesagt ein alleinstehendes CR (also die erste Hälfte eines CRLF-Zeilentrenners), ergo 0Dh bzw. 13d. In nahezu jeder Zeichentabelle sind auch die Hexwerte angegeben (oft sogar eher als die Dezimalwerte). Guckst Du z.B. hier: http://www.microsoft.com/globaldev/reference/oem/437.mspx Da findest Du unter 23h dann auch den Gartenzaun #. Die von Dir angehängte RFC-Nachricht ist bei Dir in zu-Richtung durch den UUZ gelaufen, [...] das war aber auch alles. Aber das ist das Entscheidende. Ich hatte Dir ja kürzlich schon mal per Mail erklärt, daß der UUZ in zu-Richtung aus DOS-Zeilentrennern (CRLF) Unix-Zeilentrenner (LF) macht. D.h., er liest jede Zeile bis zu einem CR und/oder LF, schreibt den Inhalt der Zeile und hängt ein LF an. Dadurch wird so ein alleinstehendes CR dann eben repariert, weil in uz-Richtung das Umgekehrte passiert: Aus jedem LF (Unix) wird ein CRLF (DOS) = sollte es alleinstehende CRs gegeben haben, sind sie jetzt zu sauberen CRLFs mutiert und Du siehst im Lister keine Note mehr. Das OUT ist nie rausgegangen, Das spielt in dem Zusammenhang keine Rolle. Deine Multipart wurde hier zwar mit M geflagged, aber beim Öffnen kam nicht das MIME-Auswahlmenü, weil XP -- evtl. im Zusammenspiel mit dem UUZ -- die XP-Signatur und das MIME-Boundary zu einer Zeile zusammengezogen hat (lange Zeile, Ctrl-W drücken): --8-- ## CrossPoint/FreeXP v3.40 RC4 (Halloween) (XMS) K---==_CrossPoint_Next_MIME_Part_==- --8-- Daher findet XP das im Header deklarierte Boundary nicht und kann die einzelnen Teile nicht erkennen. Das hat jetzt aber nix mit mir zu tun, oder? Nein, sondern mit XP natürlich. Klarer Bug. Danke für den Hinweis, irgendwas ist im Zusammenhang mit der XP-Signatur in der Tat nicht ganz sauber, und zwar grundsätzlich nicht. naja, dann hat mein Rumgemurkse doch wieder etwas Sinn gemacht ;-) Definitiv. Wundert mich nur, weil ich das bei meiner Version nicht reproduzieren kann. Vielleicht auch deshalb, weil nicht dieselben Ranfbedingungen zutreffen. Michael FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Michael Heydekamp schrieb: Reinhard Irmer [EMAIL PROTECTED] wrote on 02.02.06: Michael Heydekamp schrieb: Reinhard Irmer [EMAIL PROTECTED] wrote on 02.02.06: [...] Du hättest den ZC-Puffer mit N/X als..Puffer aus XP extrahieren müssen und *den* schicken müssen. aha und wie soll das gehen? Wie man einen Puffer extrahiert? Mit N/X/N halt und... [...] danke, wieder was gelernt ;-) [...] Das Notenzeichen ist wie gesagt ein alleinstehendes CR (also die erste Hälfte eines CRLF-Zeilentrenners), ergo 0Dh bzw. 13d. In nahezu jeder Zeichentabelle sind auch die Hexwerte angegeben (oft sogar eher als die Dezimalwerte). Guckst Du z.B. hier: http://www.microsoft.com/globaldev/reference/oem/437.mspx Da findest Du unter 23h dann auch den Gartenzaun #. danke; mal sehen, ob ich irgendwo was finde, wo auch das nicht druckbare Notenzeichen angezeigt wird. [...] Dadurch wird so ein alleinstehendes CR dann eben repariert, hätte ich zum Zeitpunkt des ersten postings schon gewußt, daß 1.) =23 dem # entspricht und 2.) =0D dem Notenzeichen dann wäre es garnicht rausgegangen und der Bug wohl erst später irgendwann mal erkannt worden. So gesehen. ;-) [...] naja, dann hat mein Rumgemurkse doch wieder etwas Sinn gemacht ;-) Definitiv. Wundert mich nur, weil ich das bei meiner Version nicht reproduzieren kann. Vielleicht auch deshalb, weil nicht dieselben Ranfbedingungen zutreffen. Mittlerweile glaube ich, daß die bei mir herrschenden Randbedingungen Grenzwertigkeit in so ziemlich allen Belangen besitzen ;-)) -- gruss Reinhard FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: Note als letztes Zeichen der Sigline in FXP 3.45a
Reinhard Irmer [EMAIL PROTECTED] wrote on 02.02.06: Michael Heydekamp schrieb: aha und wie soll das gehen? Wie man einen Puffer extrahiert? Mit N/X/N halt und... [...] danke, wieder was gelernt ;-) Jetzt sag bloß, Du hast noch nie eine Nachricht extrahiert...? naja, dann hat mein Rumgemurkse doch wieder etwas Sinn gemacht ;-) Definitiv. Wundert mich nur, weil ich das bei meiner Version nicht reproduzieren kann. Vielleicht auch deshalb, weil nicht dieselben Ranfbedingungen zutreffen. Mittlerweile glaube ich, daß die bei mir herrschenden Randbedingungen Grenzwertigkeit in so ziemlich allen Belangen besitzen ;-)) In diesem Fall liegt es nicht an Dir, sondern an XP. Ohne jetzt in den Code geschaut zu haben, kann man an dem beobachteten Verhalten die Ursache des Bugs förmlich riechen: Da wird irgendeine Variable für die Signatur auf 50 Zeichen begrenzt sein. Diese Variable wird mittels einer Stringaddition nach dem Prinzip bla + blubb + baeh + #13#10 gefüllt (wobei #13#10 für den Zeilentrenner CRLF stehen). Das ist solange gut gegangen, wie die XP-Signatur nie länger als 48 Zeichen war. Die Signatur ... --8-- ## CrossPoint/FreeXP v3.45 alpha 1 (XMS) Kom-R ## --8-- ... ist aber bereits 49 Zeichen lang, so daß von dem anzuhängenden CRLF nur noch das CR (#13) übrigbleibt, weil das LF (#10) quasi hinten aus dem String rausfällt. Im Lister wird das dann als Note dargestellt. Bei noch längeren Signaturen (siehe Halloween) kann noch nicht mal das CR angehängt werden, und der String wird auf 50 Zeichen gekürzt. Dadurch kommt es zu einer Nachricht ohne abschließendes CRLF, was wiederum dazu führt, daß alle nachfolgenden Strings unmittelbar an das Ende der Signatur angehängt werden (u.a. mit der Folge, daß ein MIME- Boundary nicht mehr erkannt werden kann oder eine nachfolgende Nachricht mit der vorherigen zusammengezogen wird). Ich würde das sogar als einen relativ kapitalen Bug bezeichnen (kleine Ursache, große Wirkung). Eine der typischen und unzureichend abgesicherten Annahmen in XP, denn wenn man in xpglobal.pas neue Strings für die Versionsbezeichnung einträgt und dabei nicht unmittelbar auf die Idee kommt Moment, da war doch in sowieso.pas was mit einer auf 50 Zeichen begrenzten Signatur, dann kommt es zu solchen Folgen. Der Fix wäre: a) Sicherstellen, daß keine Signaturen länger als 48 Zeichen erzeugt werden (oder alternativ die Variable vergrößern), und b) zusätzlich sicherstellen, daß selbst bei versehentlich längeren Strings auf jeden Fall ein CRLF angehängt wird (z.B. indem man ein 'truncstr(s,sizeof(variable)-3)' davorschaltet). Das sieht dann bei gekürzten Strings zwar unschön aus, führt aber wenigstens zu einer technisch sauberen Nachricht. Michael FreeXP Entwickler-Mailingliste Dev-List@freexp.de http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
