Deskicon.rsc gesucht

[ari.tao]

Seufz. Dann zeig mir doch mal eine korrekte RSC-Datei wo das nicht der Fall ist.

Bittäh sährr: Die .RSC im Anhang hat eine Rsc-Länge von 11062B., aber eine DateiLänge von 11111B. Wird vom TOS ebenso wie von diversen RCSs problemlos eingelesen und korrekt verarbeitet (aber nicht von jedem RCS wieder genauso abgespeichert). Inhalt sind übrigens die Dir schon bekannten 3p-Icons - ist ja nicht das erste mal, daß Du Dir durch unnötige Annahmen die Sicht verbaust. Wäre immer ResourceLänge = DateiLänge, so bräuchte es den Wert rsh_rssize im Rsc-Header gar nicht, der heißt ja auch nicht etwa rsh_rsfsize.
Was den Sinn angeht: Der fällt nicht vom Himmel, sondern man muß ihn setzen. Als Kreativer habe ich kein Problem damit, genau das zu tun; zB. könnte da ein CopyRight-Vermerk angehängt sein, oder eine Vers.Nr. oder eine Serien-Nr. oder sonst irgendetwas nützliches...

PS1: Kreativität ist die Fähigkeit, in einem Regelwerk Freiräume zu erkennen und zu nutzen.
PS2: Mengenlehre ist doch Kinder-leicht. Warum fällt Logik manchen so schwer? Es muß einen tieferen psychologischen Grund dafür geben... Das sind doch isomorphe Boolsche Algebren!

[Thorsten Otto]

Bittäh sährr: Die .RSC im Anhang hat eine Rsc-Länge von 11062B., aber eine DateiLänge von 11111B.

Keine Ahnung wo du da 11062 siehst:

Code: [Auswählen]

rsh_vrsn:      $0004
rsh_object:    $0028
rsh_tedinfo:   $0100
rsh_iconblk:   $0100
rsh_bitblk:    $0100
rsh_frstr:     $0100
rsh_string:    $0100
rsh_imdata:    $0100
rsh_frimg:     $0100
rsh_trindex:   $0024
rsh_nobs:      $0009 (9)
rsh_ntree:     $0001 (1)
rsh_nted:      $0000 (0)
rsh_nib:       $0000 (0)
rsh_nbb:       $0000 (0)
rsh_nstring:   $0000 (0)
rsh_nimages:   $0000 (0)
rsh_rssize:    $0100
filesize:      $00002b67

Ganz abgesehen davon enthält sie 9 color-icons, also schlechtes Beispiel.

Wird vom TOS ebenso wie von diversen RCSs problemlos eingelesen und korrekt verarbeitet

Ja, wie gesagt, aus Platzmangel führt TOS so gut wie keine Überprüfungen durch. Nur weil sie problemlos geladen wird, heisst also nicht viel.

aber nicht von jedem RCS wieder genauso abgespeichert

Auch das ist normal. Fast jedes RCS speichert die einzelnen Teile in anderer Reihenfolge ab, wodurch man nach laden/speichern selten die binär identische Datei erhält.

ist ja nicht das erste mal, daß Du Dir durch unnötige Annahmen die Sicht verbaust.

Da muss ich jetzt glaube ich nichts zu sagen.

Wäre immer ResourceLänge = DateiLänge, so bräuchte es den Wert rsh_rssize im Rsc-Header gar nicht, der heißt ja auch nicht etwa rsh_rsfsize.

Dann schau dir doch mal zB. andere Formate von diversen Bild-Formaten an. Es gibt fast immer ein Feld im Header das, in der einen oder anderen Form, die Dateigrösse angibt. Sowas nennt sich Redundanz, und dient normalweise zur Überprüfung ob die Datei i.O. ist.

Was den Sinn angeht: Der fällt nicht vom Himmel, sondern man muß ihn setzen. Als Kreativer habe ich kein Problem damit, genau das zu tun

Witzig. Ich könnte ja auch mal kreativ werden und meine JPEG-Dateien anders komprimieren als üblich. Das Resultat ist deswegen noch lange nicht JPEG-konform.

[ari.tao]

Warum kannst Du nicht einmal beim Thema bleiben und mußt die Sache immer noch weiter auf Abwege in´s OT führen? Weder Color noch extended Format noch JPEG oder andere Bildformate haben hier eine Berechtigung, iZshg. mit meiner kurzen Bem. in #13 überhaupt erwähnt zu werden. Und mit etwaig fehlenden Überprüfungen durch TOS hat das auch nix zu tun.
Diese Resource habe ich zur Demonstration gewählt, weil Dir die Resource mit ihrer Länge von 11062B. ja schon von früher bekannt war (und ich habe NICHT rsh_rssize = 11062 geschrieben!!). Wir hatten uns doch schon verständigt, daß Color keine Rolle spielt?! Also sehr gutes Beispiel, und TOS-konform! Ich hätte durchaus auch eine andere .RSC nehmen können (zB. auch ohne Icons, nur mit Formularen oder Strings).

ist ja nicht das erste mal, daß Du Dir durch unnötige Annahmen die Sicht verbaust.

Da muss ich jetzt glaube ich nichts zu sagen.

Oh si tacuisses...

PS: Auch in Bezug auf Redundanz liegst Du falsch.

[Atariosimus]

Meine Inf Datei ist unter 4Kb groß und die Resource ist unter 64Kb groß. Jetzt hab ich den Effekt, dass
die Icons nach Änderung beim Neustart wieder weg sind.

Wo liegt da der Fehler?

[Thorsten Otto]

Warum kannst Du nicht einmal beim Thema bleiben und mußt die Sache immer noch weiter auf Abwege in´s OT führen?

Wer hat denn diese unsinnige Diskussion angefangen?

Und mit etwaig fehlenden Überprüfungen durch TOS hat das auch nix zu tun.

Natürlich hat das was damit zu tun. Enfach irgendwelchen Müll an die Datei zu hängen

Code: [Auswählen]

00002B30: 00 00 00 00  00 01 20 20  20 20 20 20  20 20 75 6E   "......        un"
00002B40: 67 65 72 61  64 65 20 44  61 74 65 69  20 66 81 72   "gerade Datei f.r"
00002B50: 20 67 65 72  61 64 65 20  52 65 73 6F  75 72 63 65   " gerade Resource"
00002B60: 21 20 84 74  73 63 68                                "! .tsch"

und dann zu behaupten daß das immer noch ein gültige RSC Datei ist, nur weil TOS beim laden nicht abstürzt, hat nur was damit zu tun daß eben keine Überprüfung statfindet.

Also sehr gutes Beispiel, und TOS-konform!

Eben nicht. Um mal aus dem Compendium zu zitieren:

Code: [Auswählen]

17
rsh_rssize
Size of the resource file (in bytes). Note
that this is the size of the old format
resource file. If the newer format file is
being used then this value can be used
as an offset to the extension array.

Und für das neuere Format, das aber erst bei TOS 4 unterstützt wird:

Code: [Auswählen]

The Extension Array
Immediately following the old resource data (using rsh_rssize as an offset) an extension array is
added. The first entry in this array is a LONG containing the true size of the RSC file.
Da das bei der von dir manipulierten Datei nicht zutrifft, ist es demzufolge keine gültige RSC Datei.

Aus der Tatsache, daß rsh_rssize als offset für das Extension-Array benutzt wird, dieses Array aus LONG-Werten besteht, und diese von einem 68000 nur von geraden Addressen gelesen werden können, folgt implizit daß dieser Wert immer gerade sein wird, auch wenn das nirgendwo explizit erwähnt wird.

Ich hätte durchaus auch eine andere .RSC nehmen können (zB. auch ohne Icons, nur mit Formularen oder Strings).

Ja, hast du aber nicht. Stattdessen eine Datei manuell manipuliert nur um unbedingt Recht zu behalten.

Natürlich kann man, durch manuelle Manipulation, RSC Dateien erzeugen bei denen meine Behauptung nicht mehr zutrifft, und die immer noch der Format-Beschreibung entsprechen. Allerdings wird kein Editor eine solche Datei erzeugen, und demzufolge wird es in der Praxis solche Dateien nicht geben. Nichts anderes hab ich ursprünglich gesagt.

[Thorsten Otto]

Meine Inf Datei ist unter 4Kb groß und die Resource ist unter 64Kb groß. Jetzt hab ich den Effekt, dass
die Icons nach Änderung beim Neustart wieder weg sind.

Wo liegt da der Fehler?

die von dir angehängte Datei scheint die defekte zu sein? Und eine INF Datei seh ich da auch nicht.

[Atariosimus]

Vielleicht klappt es so. Es ist als ob sich Newdesk.inf nicht mehr beschreiben läßt.

[ari.tao]

Deine .INF ist fehlerhaft, mindestens diese Zeilen:

Code: [Auswählen]

#d
#Z 01 @                       
#K 4F 53 4C 0#Z 01 @
#K 4F 53 4C 00 00 00 00 00 F0 30 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 @
Ich hatte mal eine Beschreibung der NewDesk.INF irgendwo gepostet - mußte mal nach suchen (hieß wohl newDTop.LEO.txt oder so ähnlich).

[ari.tao]

Wer hat denn diese unsinnige Diskussion angefangen?

Das warst _DU_! Als Reaktion auf meine winzige Klarstellung in #13. Und mit Argumenten, die hier nicht her gehörten. Du warst ja nicht mal bereit, an Pos. $100 hinzuschauen, was da steht, nämlich $00002B36 = 11062. Diese Zahl als DateiLänge zu interpretieren anstatt als ResourceLänge halte ich schlicht für einen Fehler, sogar wenn das im Kompendium steht. Es ist imho nicht verboten, hinter den extended Array noch mehr zu schreiben, und ob das Müll ist oder von Wert, das entscheidet allein der, der´s ´reinschreibt und benutzt. Das _muß_ man nicht manuell machen (auch wenn ich es zur Demonstration so tat).
Ich hoffe doch wohl, daß Du weißt, wie zB. die Funktion RscLoad funzt: Zuerst wird per GEMDOS der ganze File eingesogen, dann der Anfang als Header interpretiert, usw. Da kann man also auch ganz eigene Strukturen noch hinten hineinpacken, denn eine abermalige Erweiterung durch Atari steht ja nicht mehr an... Das bleibt also für ewig TOS-kompatibel!
Ist das jetzt der Dank für meine Mühe, daß ich Dir den Nachweis geliefert habe: Daß Du _mir_ Rechthaberei vorwirfst?! Das fällt auf Dich zurück!

Natürlich kann man ... RSC Dateien erzeugen bei denen meine Behauptung nicht mehr zutrifft, und die immer noch der Format-Beschreibung entsprechen.

Allerdings. Und jetzt klinke ich mich aus diesem Jahrmarkt der Eitelkeit mal wieder aus.

[Thorsten Otto]

Ich hatte mal eine Beschreibung der NewDesk.INF irgendwo gepostet - mußte mal nach suchen.

Gibt auch einen Hypertext dafür, ursprünglich von Dirk Hagedorn.

Die NEWDESK.INF sieht jedenfalls wirklich merkwürdig aus. Hast du die manuell geändert?

[Thorsten Otto]

Diese Zahl als DateiLänge zu interpretieren anstatt als ResourceLänge halte ich schlicht für einen Fehler, sogar wenn das im Kompendium steht.

Ohne Worte. Kompendium hat Unrecht, alle RSC-Editoren sind fehlerhaft, nur du hast Recht.

Es ist imho nicht verboten, hinter den extended Array noch mehr zu schreiben

Doch, ist es, wenn nirgendwo definiert ist was da du gedenkst anzuhängen.

und ob das Müll ist oder von Wert, das entscheidet allein der, der´s ´reinschreibt und benutzt.

Nein, das entscheidet der, der's lesen muss. XaAES würde so eine Datei. z.B nicht laden.

denn eine abermalige Erweiterung durch Atari steht ja nicht mehr an... Das bleibt also für ewig TOS-kompatibel!

Abgesehen davon daß es schon Erweiterungen gibt, die nicht im Compendium beschrieben sind, aber als Quasi-Standard von allen RSC Editoren verwendet werden, z.B. die Farb-Tabelle die zur Erstellung der Color-Icons benutzt wurde.

[Atariosimus]

Super, ich hab die Zeilen korrigiert und dann gings 

[ari.tao]

Mein newDTop.LEO enthält iirc mehr Info als das .HYP (das ich erst im Nachhinein kennenlernte). Es basiert auf dem (alten!) ProfiBuch plus eigenen Recherchen.

Edit:
Den DownLoad gibt´s hier:
   https://forum.atari-home.de/index.php?topic=13724.msg222906#msg222906

[ari.tao]

Diese Zahl als DateiLänge zu interpretieren anstatt als ResourceLänge halte ich schlicht für einen Fehler, sogar wenn das im Kompendium steht.

Ohne Worte. Kompendium hat Unrecht, alle RSC-Editoren sind fehlerhaft, nur du hast Recht.

Du willst also nicht aufhören zu ätzen? Na denn, mit Worten:
Atari hat Unrecht, nur T.Otto hat Recht. Da kann man ja gleich L.Otto spielen...
Kennst Du wirklich _alle_ RCSs? Meines kennst Du nicht. Wie schon bemerkt, läßt sich Odd_Dat.RSC problemlos in die RCSs laden, die sonst noch in meinem Besitz sind (ORCS habe ich nicht probiert), und das sind einige.

XaAES würde so eine Datei. z.B nicht laden.

Dann ist XaAES in diesem Punkt nicht kompatibel zum AES des TOS und sollte entsprechend korrigiert werden. Mit NAES2, MAGX & Geneva7 klappt´s.

... Erweiterungen ..., die nicht im Compendium beschrieben sind, aber als Quasi-Standard von allen RSC Editoren verwendet werden, z.B. die Farb-Tabelle ...

Ach, da gab´s also schon andere, die etwas hinter den extended Array gepackt haben? Warum hast Du dann geleugnet, daß das geht?! Wo sind diese Erweiterungen dokumentiert? Und nochmal: _von_allen_? zB. auch GEM_RCS3 von DRI ? (Das war afaik das letzte offizielle).

PS: Es ist imho durchaus fragwürdig, ob man Icons durch eine beigepackte Palette ´lokalisieren´ sollte (habe gerade wieder mit MyAES eine fehlerhafte Paletten-Anwendung erlebt, siehe anderer Thread). Von DRI war die Palette ursprünglich nur global vorgesehen - das wurde schon sehr früh mißverstanden und führte zu bekannten Darstellungs-Fehlern. Davon mal abgesehen, könnte man die Palette ja auch zu den FarbIcons _in_ das extended Array packen anstatt dahinter.

[Thorsten Otto]

Kennst Du wirklich _alle_ RCSs?

Ich denke zumindest alle, die Color-Icons verarbeiten können.

Meines kennst Du nicht.

Nö, Sehe hier auch nirgendwo einen Hinweis daß du sowas mal veröffentlich hättest.

ORCS habe ich nicht probiert

ORCS läd die Datei auch, nach einem Hinweis daß da möglichweise was nicht stimmt.

Dann ist XaAES in diesem Punkt nicht kompatibel zum AES des TOS und sollte entsprechend korrigiert werden.

Genau. Und am besten auch gleich den ganzen Multi-Tasking Quatsch rausschmeissen, weils inkompatibel zu TOS ist.

Ach, da gab´s also schon andere, die etwas hinter den extended Array gepackt haben?

Die habens aber nicht einfach nur dahinter gepackt.

Wo sind diese Erweiterungen dokumentiert?

Ich dachte du hast einen RSC-Editor geschrieben? Und kennst diese Erweiterung nicht?

Und nochmal: _von_allen_? zB. auch GEM_RCS3 von DRI ? (Das war afaik das letzte offizielle).

Kann das Color-Icons? Wohl kaum, die wurden erst sehr viel später eingeführt.

Es ist imho durchaus fragwürdig, ob man Icons durch eine beigepackte Palette ´lokalisieren´ sollte

Die ist genausowenig fragwürdig wie sie bei Palette-Orientierten Bild-Formaten vorhanden ist.

könnte man die Palette ja auch zu den FarbIcons _in_ das extended Array packen anstatt dahinter.

Hast Du dir das Format dieser Erweiterungen überhaupt mal angeschaut?

[ari.tao]

Willst Du jetzt diesen Thread bloß noch mit Polemik & heißer Luft zumüllen anstatt seriös zu diskutieren und Information zu bieten?

Color Icons, cicon_blk -> Atari_Compendium p.6.22 sowie InterfaceRCS-HandBuch S.127
.RSC-FileFormat -> Atari_Compendium Anhänge C9 - C11
Deine heimlichen Extensions kenne ich nicht.

... enthält sie 9 color-icons ...

Nicht einmal korrekt zählen kannst Du. Es sind genau acht.

PS: Mein (textuelles) RCS wird nicht veröffentlicht. Seit ich Interface besitze benutze ich es nur noch zur Einbettung von Resourcen in eigenen M2-Programmen, ansonsten ist es obsolet, denn Interface konnte ja aus dem iNet frei ´runtergeladen werden.

[Thorsten Otto]

Color Icons, cicon_blk -> Atari_Compendium p.6.22 sowie InterfaceRCS-HandBuch S.127
.RSC-FileFormat -> Atari_Compendium Anhänge C9 - C11

Dann schau halt in xrsrc.c von Interface nach, wenn du's nicht glaubst. Oder leg einfach eine Datei mit Coloricons in Interface an, und schau sie dir an.
Kann sein, daß es im Handbuch nicht dokumentiert ist, habe ich jetzt gerade nicht zur Hand. Wurde aber soviel ich weiss von Interface eingeführt, logisch daß das im Kompendium nicht dokumentiert ist.

Deine heimlichen Extensions kenne ich nicht.

Da ist überhaupt nix heimliches dran. Sowohl Interface als auch RSM benutzen das genauso. Daß es nicht "offiziell" dokumentiert ist, iiegt wohl nur daran daß es keine neuere Version vom Kompendium gibt. Das "lange" Resource-Format (also das, daß auch normale RSC-Dateien >64K erlaubt), ist ja auch nicht offiziell dokumentiert, trotzdem wird es zumindest von XaAes, und von allen Programm die darauf angewiesen sind, unterstützt.

Mein (textuelles) RCS wird nicht veröffentlicht

Woher soll ich es dann kennen?

Interface konnte ja aus dem iNet frei ´runtergeladen werden.

Naja, genauso "frei" wie es überall TOS ROMs zu finden  gibt.

[Atariosimus]

Die Newdesk.inf scheint etwas empfindlich zu sein.   
Ab und zu vereisst es die obere Zeile wenn man viel mit Xboot probiert oder neue Icons testet. Dann geht der Link nicht mehr.

Ist etwas mühselig. Befürchte auch, dass das mit dem Sprengen der
normalen Speichergrenze noch unangenehmer werden kann. Ich bleib deshalb drunter.
Wer weiß was da noch alles für Programme ausser Xboot die Datei manipulieren.
Theoretisch ist das alles sehr schön, doch ich habe es jetzt schon mehrmals geschafft
das Teil zu verhunzen. 

[ari.tao]

^^--Wenn Du mit einem Text-Editor die NewDesk.?NF veränderst, dann mußt Du Dich hochnotpeinlich genau an das Format halten, da gibt´s nur wenig Spielraum. Ibs. die Trailing Blanks müssen erhalten bleiben, ganz besonders für #c ! Steht ja alles in meinem Leo. Kann durchaus sein, daß Dein BootSelektor da noch empfindlicher ist als das TOS. Ich bin kein Freund von BootSelektoren, weil sie gleich zu Anfang Schreibzugriffe machen. Das kann mitunter fatal enden!

-------

Interface RCS:
   http://www.atari-home.de/2000/12/interface-23-gfa-interpreter-35-zum-download/
Leider hält GH alias Hadley das Teil inzwischen nicht mehr bereit auf seiner HomePage.
Vielleicht ist es noch in der belgischen Kurobox?

ORCS läd die Datei auch, nach einem Hinweis daß da möglichweise was nicht stimmt.

Aha, auch Du hattest also schon die Idee, daß der File länger sein könnte als die Resource - und wir beide waren sicherlich nicht die einzigen... Warum also nimmst Du Anstoß an meiner Bem. in #13 und plagst mich?!

... Extensions ... Da ist überhaupt nix heimliches dran.

Dann nenne doch mal die anderen anstatt FarbIcons und Paletten.

[Nervengift]

Die Newdesk.inf scheint etwas empfindlich zu sein.   
Ab und zu vereisst es die obere Zeile wenn man viel mit Xboot probiert oder neue Icons testet. Dann geht der Link nicht mehr.

Hm ... ich hätte da spontan folgende Idee: Eine Sicherheitskopie von NEWDESK.INF machen und dann einen drauf Schreibschutz setzen. Ist natürlich schwierig, wenn XBOOT mit verschiedenen NEWDESK.INF-Dateien arbeiten soll.