atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: Atariosimus am Sa 21.04.2018, 14:29:05
-
Hier gibt es eine Deskicon.rsc Datei, die ich nicht zum Laufen bringe. Ist diese etwa defekt?
http://matsp888.no-ip.org/~mats/Text/Computer/Atari/Atari%20ST/Misc/TOS%202.06%20User%20Guide/software/icons/ (http://matsp888.no-ip.org/~mats/Text/Computer/Atari/Atari%20ST/Misc/TOS%202.06%20User%20Guide/software/icons/)
-
Bekomme unter TOS2.06 3Bomben... also defekt.
-
Ich leider auch. Schade :(
Alles ist so gut beschrieben.
-
Wie habt Ihr denn die .RSC ´runtergeladen? Bei mir kommt da nur ein seltsamer Textfile von 738B. (anstatt der angegebenen 26k).
@Atariosimus , schicke mir mal Deine eMail-Adr., dann kriegste von mir einen Satz Mono-Icons mitsamt zugehöriger NewDesk.INF in den nächsten Tagen.
-
Mit Android Tablett einfach anklicken. Größe ist 25.96 KB. Läßt sich mit keinem RSC Editor öffnen.
RSM und Interface hatte ich dafür benutzt. Anbei sowie es bei mir ankommt.
Oh danke Ari.Tao. Schick Dir eine PM.
-
Läßt sich mit keinem RSC Editor öffnen.
RSM und Interface hatte ich dafür benutzt.
Dann wars wohl der falsche Editor ;) lässt sich mit ORCS problemlos öffnen. Sehe da aber jetzt auf den ersten Blick keine Icons die nicht auch in anderen Dateien verfügbar wären.
-
Wirklich mit Orcs? Das muss ich dann mal auch probieren.
Merkwürdig ist allerdings, dass der Rechner beim Booten immer wieder abstürzte wenn ich diese Deskicon.rsc nutzte. Auch Shbuf, Gemram und Winx nützen mir da nichts.
Hast Du denn einen Boot hinbekommen bei einem Mega Ste?
-
Dann wars wohl der falsche Editor ;) lässt sich mit ORCS problemlos öffnen. Sehe da aber jetzt auf den ersten Blick keine Icons die nicht auch in anderen Dateien verfügbar wären.
Oder was anderes. Ich kann den Download auch mit ORCS nicht öffnen, es ergibt einen Fehler nach dem anderen. Interface wirft Bomben, RSM sagt „keine gültige RSC-Datei“.
MD5 (DESKICON.RSC) = be53e6db9f5c2fb4a55964f837429d5d
-
Ich frage mich auch, wie Thorsten die Datei mit Orcs öffnen konnte, sie ist nämlich definitiv kaputt -- und zwar nicht nur die Version hier im Forum sondern auch das Original auf dem Server. (Beide sind identisch.)
Irgendwo in der Vergangenheit wurde diese Datei über irgendein System übertragen, dass sie für eine Textdatei hielt und alle "Carriage Returns" (CR) durch "Carriage Return" + "Line Feed" (CR/LF) ersetzt hat. Das ist beliebter Weg, Binärdateien zu zerstören.
-
Hier übrigens die heile Datei: http://www.atari-forum.com/viewtopic.php?t=21001#p272610
Unbedingt den Download The TOS 2.06 in-depth user guide icons.zip nehmen, weiter oben ist als Hall_rsc_files.zip nämlich nochmals die defekte Version.
> md5sum DESKICON.RSC
01e2b0a76c3cd205643c119e9e1d4a08 *DESKICON.RSC
-
@czietz Super :)...werd ich gleich mal ausprobieren.
Die kaputte Datei ist übrigens identisch, ich hatte sie nur nochmal reingestellt um anderen das Suchen
zu ersparen und um von der gleichen Datei zu reden.
Astrein, habs grade ausgelesen.
Vielen Dank
-
eMail an @Atariosimus abgeschickt.
Wer sonst die Icons haben will: Ihr könnt ja eine Kette bilden... ;)
Edit: Doku-Snaps angehängt.
-
Ich frage mich auch, wie Thorsten die Datei mit Orcs öffnen konnte, sie ist nämlich definitiv kaputt
Ah, mein Fehler. Scheinbar hatte ich in meinem Download-Ordner bereits eine Datei deskicon.rsc, und die neue wurde dann als deskicon(1).rsc gespeichert. Beim testen gestern habe ich dann wohl die alte geöffnet. Habs jetzt nochmal ausprobiert, und die Datei ist definitiv nicht in Ordnung (sieht man auch schon an der ungeraden Datei-Grösse, was bei RSC Dateien gar nicht sein darf). Abstürze gibt es beim laden mit ORCS nicht, allerdings jede Menge Fehlermeldungen, und angezeigt werden kann sie auch nicht.
-
Garbage in => garbage out.
-------
... ungeraden Datei-Grösse, was bei RSC Dateien gar nicht sein darf ...
Die Länge einer Resource muß afaik nicht in jedem Fall mit der Dateilänge übereinstimmen.
-
Die Länge einer Resource muß afaik nicht in jedem Fall mit der Dateilänge übereinstimmen.
Wenn keine Color-Icons enthalten sind, schon. Ausserdem hat das damit nichts zu tun. Egal ob mit oder ohne Color-Icons, sowohl die Länge laut Header als auch die tatsächliche Dateigrösse wird immer gerade sein. Wenn nicht, macht der Editor was falsch (oder, wie wohl in diesem Fall, wurde die Datei beschädigt).
-
Irgendwie zickt die Erweiterung mit Icons bei mir rum. Als ich die inf und rsc Datei drübergespeichert hatte kam er bis zum Bootx und dann 3 Bomben. Darf man keine Farbicons einsetzen oder müssen die Icons alle gleich groß sein?
Habe die Speichergrenze vom rsc nicht überschritten. Ist etwas nervig. Jetzt versuch ich es Schritt für Schritt Icons einzufügen und dann gleich zu testen. Beim Absturz kam icz aus der Nummer nur mit Gemini raus,
dass ich aus dem Bootx von Diskette geladen habe.
-
1) FarbIcons dürfen in der ICONS.RSC für TOS_2.06 NICHT enthalten sein.
(Es gibt aber auch dafür eine Erweiterung).
2) Verschiedene Icon-Größen sind durchaus möglich,
- jedoch verschiedene Icon-Höhen nicht empfehlenswert (die ´tanzen´ dann).
3) Um "aus der Nummer ´rauszukommen" empfiehlt sich eine zweite Boot-Part.
Hast Du mal die Icons genommen, die Du von mir bekommen hast? Die .INF dazu braucht SHBUF (da 15k groß).
-------
Die Länge einer Resource muß afaik nicht in jedem Fall mit der Dateilänge übereinstimmen.
Wenn keine Color-Icons enthalten sind, schon. Ausserdem hat das damit nichts zu tun. Egal ob mit oder ohne Color-Icons, sowohl die Länge laut Header als auch die tatsächliche Dateigrösse wird immer gerade sein. Wenn nicht, macht der Editor was falsch (oder, wie wohl in diesem Fall, wurde die Datei beschädigt).
Hat mit Color gar nix zu tun. Die log. Aussage "ungerade => kaputt" ist schlicht falsch und wird auch nicht dadurch richtiger, daß in diesem Fall die Resource tatsächlich defekt war (ex falso quodlibet). Ich kann nix dafür, wenn Dein Editor keine längeren Files zuläßt als mit der im Header angegebenen Rsc-Länge. Mir ist keine Vorschrift von DRI oder Atari bekannt von der Art "Dateilänge muß gleich Rsc-Länge sein". Und eben deshalb gibt´s da einen Freiraum. TOS bzw. GEM verarbeitet solche .RSCn klaglos & korrekt.
-
Ja, hab Deine Icons genommen und SHBUF sowie Gemram gesetzt. Jetzt hab ich ein Problem, ich kann mich nicht entscheiden welche Icons mir besser gefallen :D
-
Wird schon wieder off-topic hier, trotzdem möchte ch das nicht so stehen lassen.
Hat mit Color gar nix zu tun.
Genau das habe ich gesagt.
Die log. Aussage "ungerade => kaputt" ist schlicht falsch
Seufz. Dann zeig mir doch mal eine korrekte RSC-Datei wo das nicht der Fall ist. Die Offsets im Header geben den Beginn von Strukturen an, und die können nunmal bei 68000 nur auf geraden Addressen beginnen. Was vermutlich auch der Grund ist warum die kaputte Datei 3 Bomben schmeisst.
Ich kann nix dafür, wenn Dein Editor keine längeren Files zuläßt als mit der im Header angegebenen Rsc-Länge.
Das Format ist aber nunmal so definiert. Macht auch überhaupt keinen Sinn grössere Dateien zuzulassen, da die Offsets im Header das garnicht beschreiben könnten.
Länger als die im Header angegebene Grösse können die Dateien nur werden, wenn das sogenannte erweiterte Format benutzt wird, das erst seit MultiTOS definiert ist. Und da die einzige Erweiterung bisher die für Color-Icons ist, kann das bei RSC Dateien ohne Color-Icons nicht passieren.
Mir ist keine Vorschrift von DRI oder Atari bekannt von der Art "Dateilänge muß gleich Rsc-Länge sein".
Ach. Wofür ist denn dann wohl das Feld rsh_rssize im Header?
Und eben deshalb gibt´s da einen Freiraum. TOS bzw. GEM verarbeitet solche .RSCn klaglos & korrekt.
Nur weil das eingebaute AES wenig bis gar keine Sicherheits-checks macht wenn es die Datei läd heisst es noch lange nicht daß die Dateien i.O sind.
-
Ja, hab Deine Icons genommen und SHBUF sowie Gemram gesetzt. Jetzt hab ich ein Problem, ich kann man nicht entscheiden welche Icons mir besser gefallen :D
Schalte mal auf LowRez. Vielleicht fällt Dir dann die Entscheidung leichter. ;)
-
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!
-
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:
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.
-
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.
-
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?
-
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
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:
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:
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.
-
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.
-
Vielleicht klappt es so. Es ist als ob sich Newdesk.inf nicht mehr beschreiben läßt.
-
Deine .INF ist fehlerhaft, mindestens diese Zeilen:
#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).
-
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.
-
Ich hatte mal eine Beschreibung der NewDesk.INF irgendwo gepostet - mußte mal nach suchen.
Gibt auch einen Hypertext (http://tho-otto.de/hypview/hypview.cgi?url=%2Fhyp%2Fnewdesk.hyp&hideimages=0&hidemenu=0&charset=utf8) dafür, ursprünglich von Dirk Hagedorn.
Die NEWDESK.INF sieht jedenfalls wirklich merkwürdig aus. Hast du die manuell geändert?
-
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.
-
Super, ich hab die Zeilen korrigiert und dann gings ;D
-
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
-
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.
-
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?
-
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.
-
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.
-
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. :(
-
^^--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.
-
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.
-
Aha, auch Du hattest also schon die Idee, daß der File länger sein könnte als die Resource
Ja, weil ORCS da sehr viel mehr Prüfungen macht als irgend AES wenn es die Datei läd. Könnte ja sein daß irgendwelche Erweiterungen verwendet wurden die ORCS noch nicht kennt. Ausserdem werden die Daten für die Palette nicht nur einfach an die Datei angehängt, sondern es wird ein neuer Eintrag in das Extension Array gemacht, und auch die Gesamtlänge wird entsprechend angepasst.
Dann nenne doch mal die anderen anstatt FarbIcons und Paletten.
Keine die mir bekannt wären.
-
Eine Sicherheitskopie habe ich gemacht.
Problem ist halt nur, wenn verschiedene Programme aus dem Bootx direkt angesprungen werden sollen, dann ändert Bootx das jeweils entsprechend nach Sprung in Newdesk.inf ab.
Da steckt der Wurm. Ein Schreibschutz läßt diesen Komfort allerdings nicht mehr zu.
-
Mit XBoot macht man das ja auch ganz anders... Man legt sich einen Ordner an, z.b. c:\auto\newdesk (eine andere schöne Variante wäre c:\gemsys\newdesk) und da legt man sich die verschiedenen newdesk.inf Dateien mit sinnvollen Namen (stlow.inf, stmed.inf, sthigh.inf, ttvga.inf, tthigh,inf, scrblstr.inf, network.inf, ...) Die Dateien werden nicht von Xboot bearbeitet, sondern nur kopiert. Man muss sich nur angewöhnen, wenn man tatsächlich mal was an der newdesk.inf was ändert (arbeit sichern), dass man die dann wieder in dem Ordner unter dem Namen kopiert, wie man das in Xboot eingestellt hat. Da,mit hat man dann auch seine Sicherheitskopie.
-
^^--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
Da ist leider nichts mehr zu holen. Das Programm habe ich allerdings zum Glück damals gekauft.
-
... NEWDESK.INF ... Schreibschutz ...
Schon das Umbenennen ist ein Schreib-Vorgang! Ein Ausweg wären Links auf u: - aber die gibt´s ja erst, wenn das OS Links überhaupt kann, also ia. nicht zu Anfang des Boots, wenn der Selektor werkelt. Man kann vielleicht tricky Links setzen, die zunächst verwaist sind und dann mit einem fähigen OS später doch aktiv (habe ich mal so ähnlich gemacht mit MAGX) - aber das ist sicherlich zu kompliziert für Hansi Normaluser und widerspricht der Intention eines Bootselektors.
-------
... Extension ...
Dann nenne doch mal die anderen anstatt FarbIcons und Paletten.
Keine die mir bekannt wären.
Schade, ich hatte gehofft, ich hätte da bloß ´was verschlafen. ;)
Unser Problem mit neuen Extension-Slots ist ja wohl, daß man sie nirgends anmelden kann. Schon die Paletten-Extension war doch ein Wildwuchs? Dafür sowie auch für die MonoIcon-Erweiterung >64k fehlt mir jedenfalls offizielle Doku a la FarbIcons.
-
Es ist ein Unterschied, ob man den Verzeichniseintrag oder den Inhalt der Datei ändert. Beides ist ein Schreibvorgang, aber auf verschiedene Bereiche des Dateisystems. Eine Namensumbennenung ändert den Inhalt nicht... (https://www.smilies.4-user.de/include/Essen/icecream_smiley_223.gif)
-
Es ist ein Unterschied, ob man den Verzeichniseintrag oder den Inhalt der Datei ändert. Beides ist ein Schreibvorgang, aber auf verschiedene Bereiche des Dateisystems.
Theoretisch, ja. Auf unix-Systemen wird das auch so gehandhabt. Bei TOS gibt es allerdings keinen Schreibschutz für Directories. Auch der Schreibschutz für Dateien ist nur halbherzig implementiert. Es wird zwar beim öffnen geprüft, aber du kannst fröhlich eine Datei beschreiben die eigentlich nur zum lesen geöffnet wurde.
-
Unser Problem mit neuen Extension-Slots ist ja wohl, daß man sie nirgends anmelden kann.
Ja, ist halt leider so. Man kann sich nur auf Neuerungen einigen, was aber bei der übriggebliebenen Gemeinde nicht so schwierig sein dürfte. Oder man schafft einfach Tatsachen, wie es MagiC seinerzeit in einigen Bereichen getan hat.
Schon die Paletten-Extension war doch ein Wildwuchs?
Dafür sowie auch für die MonoIcon-Erweiterung >64k fehlt mir jedenfalls offizielle Doku a la FarbIcons.
Irgendwo hatte ich mal was darüber gelesen, weiss aber auch nicht mehr wo. Im Interface-Handbuch ist jedenfalls nichts darüber zu finden.
-
^^-- Hat vielleicht sonst jmd. @alle ebbes dazu?
-------
Wenn man ´von Hand´ einen Directory-Eintrag schreibschützt, dann wird iirc nur der Eintrag geschützt, aber nicht der Inhalt des Dirs.
Einen wirksamen Schreibschutz schafft man, indem eine Datei geöffnet und danach nicht wieder geschlossen wird. Leider gibt es ein paar Kandidaten, die dieses Kunststück im AUTO\ hinkriegen - und dann wundert sich der Benutzer, daß er eine Datei nicht wie üblich vom Desktop aus bearbeiten kann (manchmal hilft Kobold, keine Ahnung, wie er das macht) und daß ihm ein mehr oder weniger großes Stück Speicher fehlt...
-
Wenn man ´von Hand´ einen Directory-Eintrag schreibschützt, dann wird iirc nur der Eintrag geschützt, aber nicht der Inhalt des Dirs.
Das ist ja auch Sinn der Sache, es soll nur der Verzeichniseintrag vor Modifikation geschützt werden. Ist unter Windows heutztage übrigens auch machbar, in dem man z.B. die Vererbung nach unten ausschaltet. Und wenn ich mich recht erinnere, ist es in Linux auch so. Wenn du da ein "chmod 111 <ordnername>" machst, bekommen darin die Dateien nichts davon mit. Erst wenn du es rekursiv machst, ändert sich das.
(https://www.smilies.4-user.de/include/Essen/smiley-essen12.gif)
@Thorsten Otto - Über das Handling des Schreibschutz-Attributes bei Dateien durch den Desktop oder aus Anwendungen heraus gehts hier doch garnicht? Hab ich übrigens unter TOS/MiNT noch nie verwendet, unter DOS/Windows übrigens auch nicht, bei letzterem gehts eh viel effektiver über die Berechtigungen, als über das einfache Schreibschutzhäkchen, das auch jeder, der die Schreib-Berechtigung hat, wieder entfernen kann... Und falls das unter TOS wichtig wäre, sollte man mal BigDOS testen, ob es damit korrekt funktioniert.
-
Neue ExtensionSlots?:
Man kann sich nur auf Neuerungen einigen, was aber bei der übriggebliebenen Gemeinde nicht so schwierig sein dürfte. Oder man schafft einfach Tatsachen, wie es MagiC seinerzeit in einigen Bereichen getan hat.
Wenn Du einen ExtensionSlot für Sounds erfindest und/oder einen für die kleinen AnimationsBildchen, die 1ST1 neuerdings so liebt, dann könnte das den Durchbruch für Dein ORCS bedeuten. Schlecht wäre es allerdings, wenn Dein einziger verbliebener Konkurrent RSM dann etwas anderes inkompatibles macht. Der erste, der eine neue Extension publiziert, der setzt sicherlich den Standard.
(https://www.smilies.4-user.de/include/Fruehling/fruehling-smilies-08.gif)
-
Mit XBoot macht man das ja auch ganz anders. […]
Wollt ihr nicht langsam mal den Betreff ändern? Es geht nicht mehr um gesuchte Icons, sondern wie RSC-Dateien auszulegen sind, und wie man mit NEWDESK.INF umgeht …
-
Guter Vorschlag!
-
In STComputer 10/92 auf Seite 106 steht noch ein interessanter Artikel mit Programm.
Da soll man 255 Icons in 64 KB unterbringen. Ist ein Icon Packer für die Resource Datei.
Das probier ich mal aus wenn ich das Programm zum Download finde. Abtippen ist mir
allerdings zu lang.
Hier das Programm:
http://www.stcarchiv.de/stc1992/10/mehr-icons (http://www.stcarchiv.de/stc1992/10/mehr-icons)
-
^^-- Zunächst mal:
Abtippen mußt Du doch gar nix - kann man doch einfach ´rauskopieren:
http://st-computer.atariuptodate.de/index.php?content=archiv&mag=stc&year=1992
Jedoch bezweifle ich, daß sich die Mühe wirklich lohnt:
Es ist keine gute Idee, daß die Icon-Texte perdü gehen. Der GEM-Desktop benutzt sie zwar nicht - wohl aber moderne Desktöppe wie zB. THING oder JINNEE; die identifizieren nämlich die Icons nicht mehr nach deren fortlaufender Nummer (keine gute Idee, was man merkt, wenn man mal mittendrin Icons löschen oder einfügen will), sondern eben nach deren Namen, ie. dem Icon-Text.
Zum anderen schau Dir einmal im RCS genau die 200 Icons an, die Du von mir hast. Dann wirst Du feststellen, daß nur sehr wenige gleiche Masken haben. Der Grund ist, daß diese Icons nicht bloß zweifarbig sind, sondern gewissermaßen zweiundeinhalb-farbig, denn an einigen Stellen scheint der Untergrund durch, der ebenfalls farbig sein kann (mit einem dazu fähigen Desktop und > 2p). Du wirst dann nur schätzungsweise ein Dutzend zusätzliche Icons einbauen können und alsbald stehst Du wieder vor dem Problem, daß der Platz voll ist.
(Ich habe mehr als 500 Icons. Die mir wichtigsten 200 habe ich nach vorne geholt. Leider weiß ich nicht, welche Desktöppe das .RSX-Format von Interface verarbeiten können...).
PS1: Wenn Du die Vorschau-Funktion benutzt, dann kriegst Du auch das Layout gebacken.
PS2: Warum nicht der Anregung von gh_baden folgen?
PS3: Ah, die von Dir angehängte DeskIcon.RSC scheint wieder verschwunden zu sein. Hatte mich schon gewundert über die neuerdings im Forum herrschende Toleranz...
-
Danke für die Info. Ich hatte die RCS Datei wieder rausgenommen. Der einfache Grund ist, sie war ja nicht fehlerfrei nur um einigen später den Frust zu ersparen defekte Dateien zu kopieren. Inklusiv mich selbst. :)
Danke für den Link. Dann kann ich den Text mit GFA 3.6 umwandeln. :D
"...(mit einem dazu fähigen Desktop und > 2p)". Das versteh ich leider nicht ganz. Was ist 2p?
-
>2p -> mehr als zwei Planes (vier Farben)
-
Einen wirksamen Schreibschutz schafft man, indem eine Datei geöffnet und danach nicht wieder geschlossen wird. Leider gibt es ein paar Kandidaten, die dieses Kunststück im AUTO\ hinkriegen - und dann wundert sich der Benutzer, daß er eine Datei nicht wie üblich vom Desktop aus bearbeiten kann (manchmal hilft Kobold, keine Ahnung, wie er das macht)
Kobold geht im normalen Modus (also nicht im GEMDOS-Modus) am GEMDOS vorbei und manipuliert Sektoren und FAT von Hand. Quasi ein nachprogrammierter Dateisystemtreiber, aber nur in einem Programm enthalten.
-
Mit XBoot macht man das ja auch ganz anders... Man legt sich einen Ordner an, z.b. c:\auto\newdesk (eine andere schöne Variante wäre c:\gemsys\newdesk) und da legt man sich die verschiedenen newdesk.inf Dateien mit sinnvollen Namen (stlow.inf, stmed.inf, sthigh.inf, ttvga.inf, tthigh,inf, scrblstr.inf, network.inf, ...) Die Dateien werden nicht von Xboot bearbeitet, sondern nur kopiert. Man muss sich nur angewöhnen, wenn man tatsächlich mal was an der newdesk.inf was ändert (arbeit sichern), dass man die dann wieder in dem Ordner unter dem Namen kopiert, wie man das in Xboot eingestellt hat. Da,mit hat man dann auch seine Sicherheitskopie.
Das ist eine wirklich gute Idee, Danke
Anbei meine Desktop.rsc und Newdesk.inf
-
^^-- @Atariosimus siehe PM.
-------
Kobold geht im normalen Modus (also nicht im GEMDOS-Modus) am GEMDOS vorbei und manipuliert Sektoren und FAT von Hand. Quasi ein nachprogrammierter Dateisystemtreiber, aber nur in einem Programm enthalten.
Das war schon klar - aber mich wundert, daß das GEMDOS hinterher an der Manipulation keinen Anstoß nimmt. Liegt vielleicht einfach daran, daß die geöffneten Dateien bis zum nächsten Reboot gar nicht mehr benutzt werden? Oder, daß der K. die Dateien schließt?
-
Solche Kopierer gaukeln TOS nach getaner Arbeit einen Medienwechsel vor und sorgen so dafür, dass es sämtliche Verwaltungsinformation für dieses Laufwerk verwirft (und entsprechend beim nächsten Zugriff neu einliest).
Dummerweise gehören offene Dateien und aktuelle Verzeichnisse auch zu diesen Infos, so dass das eigentlich (insbesondere, wenn Multitasking im Spiel ist) nicht als feiner Zug gelten kann.
Dokumentiert ist diese Vorgehensweise erst ab TOS 1.4, mit älteren TOSen kann man damit also u.U. auf die Nase fallen.
-
Ich habe aus dem Grund bei mir auf allen Laufwerken in Kobold normalerweise immer den GEMDOS Modus eingeschaltet, auch wenn es etwas Geschwindgkeit kostet.
-
^^-- Dafür brauchst Du den Kobold nicht. Das kann jeder Dösktep genau so schnell bzw. lahm. Ich würde mir wünschen, der K. könnte auch im schnellen Modus mit FAT32 umgehen.
-
Der Desktop ballert beim Kopieren von Dateien nicht den ganzen Speicher mit gelesenen Dateien zu, um die dann in einem Rutsch zu schreiben. Das ist mit Kobold selbst im Gemdos-Modus noch viel schneller als unter dem Desktop, selbst wenn man Alternativen einsetzt.
-
Bei mir sieht es derzeit so aus mit der Deskicon.rsc. Der Rest oder besser der Anfang ist so wie es Hallvard Tangeraas gemacht hat.