Diskussion:Dateiformat

Ich trau mich nicht einfach so ganze Abschnitte zu löschen aber Historie und Dateiaufbau würde ich beide komplett streichen oder ersetzen. Auch heute noch verwendet so ziemlich jede Anwendung ihr eigenes Dateiformat. Und es gibt auch kein Gremium (Einzahl!?) das Computer*software* spezifiziert. Es gibt zig Gruppen und Einzelpersonen die alle möglichen Dateiformate und Protokolle spezifizieren, an die sich Software dann hält, oder auch nicht, oder einen eigenen ”Standard” definiert, oder einen vorhanden verwendet aber nicht vollständig implementiert oder eigene Erweiterungen/Änderungen daran vornimmt. Und der angeblich typische Dateiaufbau mit Header und Body ist auf dem C64 auch nicht wirklich verbreitet. Die Informationen die angeblich im Header enthalten sind und der Link zu Dateikopf ist auch ein wenig speziell, weil das gerade mal Quelltexte betrifft. Und ich würde das auch nicht als Dateiformat durchgehen lassen, weil das ja nur eine Konvention ist einer Quelltextdatei einen Kommentarblock mit bestimmten Informationen voranzustellen, aber keinesfalls Bestandteil einer Spezifikation die man erfüllen muss, damit das als Quelltextdatei erkannt und verarbeitet werden kann. Dort steht ja auch das der Dateikopf keine praktische Funktion hat. Das ist bei Dateiformaten anders, wenn man dort den Header ändert oder weg lässt, kann man mit der Datei in der Regel nichts mehr anfangen. Bei Bildformaten steht dort zum Beispiel in der Regel das Format, welche Kompression verwendet wurde, wie gross das Bild ist, und so weiter. Informationen ohne die man die Daten nach dem Header gar nicht mehr sinnvoll interpretieren kann.

Die DOS-Dateitypen würde ich vielleicht auch nicht als Dateiformate aufzählen. Denn das eigentliche Format der Daten wird dadurch nicht wirklich festgelegt, mit Ausnahme von REL-Dateien vielleicht. Denn die anderen FormateTypen haben alle keine festgelegte Struktur sondern können alle möglichen Dateiformate aufnehmen. --BlackJack 21:59, 1. Nov. 2014 (CET)

Blackjack hat recht. Die Wikipedia-Artikel helfen hier bei uns wirklich nicht weiter. Ich bleibe bei meinem Vorschlag, einfach einen Artikel zu schreiben, in dem auf alle Dateiformate verlinkt wird, vielleicht eingeteilt in Bild-, Text- und andere Dateiformate. --GoDot 22:14, 1. Nov. 2014 (CET)

Die Grundlagen kann man nicht einfach so neu definieren. Und wenn ja, dann müssten wir die Allgemeinen Grundlagen kurz und die C64/Commodre spezifischen Details dann etwas weiter unten erklären.

Das man ein PRG als SEQ oder REL abspeichern kann, geht auf dem PC mit bestimmten Dateiformaten aber auch. Auch wenn man gerne Dateityp = Dateiformat definiert, sind das anhand der Spezifierung über dem OS zwei verschiedene Sachen. --Jodigi 15:28, 2. Nov. 2014 (CET)

Ich bin mir jetzt nicht so ganz sicher was Du mit dem Kommentar eigentlich sagen möchtest. Nein, Grundlagen kann man nicht einfach so neu definieren, deswegen habe ich ja Probleme mit dem Artikel, weil dort komische Sachen drin stehen.

Auf dem PC gibt es bei den gängigen Betriebs- und Dateisystemen keine Dateitypen wie bei CBM-DOS, da sind alle Dateien gleich: eine Folge von Bytes denen einzig die Anwendung die sie verarbeitet eine Bedeutung/Struktur gibt.

Also normalerweise kennt auch ein DOS den Unterschied zwischen ausführbare .EXE, .COM und .BAT-Dateien und den nicht ausführbaren der Anwendungen wie irgendwelche Text-, Bild-, Video-, Musikdateien.

Der Dateityp kann unter DOS sogesehen definiert werden, d.h. eine Textdatei wie TEXT.TXT könnte ich mit einer entsprechenden anderen Dateitypabkürzung versehen und schon meint ein aktuelles Betriebssystem TEXT.JPG wäre ein Bild und keine Textdatei mehr. Dieses Prinzip der Manipulation kann ich bei einen entsprechenden Umgang und Wissen oder entsprechenden Manipulationsprogramme auch mit Dateien unter CBM-DOS erledigen. Ich könnte eine BASIC-Programm, das normal als SPIEL.PRG abgespeichert wird, auch umbenennen in SPIEL.SEQ, und schon wird der Anwender in die Irre geleitet.

Inwieweit diese Dateien nur aus einfache Texte oder entsprechenden kompilierten oder codierten Daten bestehen, sieht man erst beim direkt oder indirekten Aufruf oder ggf. durch einen Editoraufruf mit entsprechende Hilfsprogramme.

Irgendwie ist es leider auch ein schwieriges Thema...

PS: Nochmal der Hinweis, das ein Wiki ein Gemeinschaftsprojekt ist. Falls etwas falsch ist oder ich es nicht richtig oder schlecht erkläre bzw. beschreibe, solltest Du es entsprechend korrigieren... --Jodigi 19:58, 2. Nov. 2014 (CET)

Hier werden Dateitypen und -formate vermischt/verwechselt. Das ist bei MS-DOS & Co Synonym, aber auf dem C64 nicht. Weil man da bei CBM-DOS einen Unterschied machen muss, taugen allgemeine Wikipediaartikel die diesen Unterschied nicht machen, nicht als Referenz/Definition. Die Dateinamenserweiterungen von MS-DOS und die Dateitypen von CBM-DOS sind grundlegend verschieden. Dateitypen in dem Sinne kennt MS-DOS nicht und auch Windows oder Linux nicht. TXT und JPG sind einfach nur Bestandteile des Namens die keinen Einfluss darauf haben wie das Dateisystem die Daten organisiert und man kann diese Endungen auch beliebig ”erfinden”. Bei CBM-DOS gibt es nur eine beschränkte Anzahl von Dateitypen und eine REL-Datei wird anders auf dem Datenträger organisiert und von Programmen angesprochen als eine PRG- oder SEQ-Datei. Und bei USR-Dateien kann der Benutzer eigentlich machen was er will und zwar auf Dateisystemebene. Das gibt es alles bei MS-DOS beziehungsweise gängigen Dateisystemen für den PC nicht. Da gibt es nur *einen* verbreiteten Dateityp auf Datenträgern: Eine Folge von Bytes auf die man wahlfrei zugreifen kann. TXT und JPG entsprechen auf dem C64 Namenszusätzen wie das MPIC am Ende von OCP Art Studio Bilddateien oder das reverse Pik-Symbol am Anfang von Koala Painter Bilddateien. Und genau wie bei MS-DOS kann man aus dem MPIC ein .FT machen ohne das aus der Datei eine Textdatei für Printfox wird. Bei Dateiformaten, und so heisst der Artiel schliesslich, geht es ja gerade um den Inhalt von Dateien. Wie ist der über die Vorgaben des Dateisystems hinaus definiert. --BlackJack 20:58, 2. Nov. 2014 (CET)

(parallel zu BlackJacks letztem Beitrag, daher tw. überlappend)
Also die Darstellung im Artikel vermischt etliches, das auf unterschiedlichen konzeptuellen Ebenen angesiedelt ist. Da wäre mal die CBM-DOS-Dateitypen. Die Typen sagen nichts über das Dateiformat (die Nutzdaten) aus. Deren Verwendung ist eigentlich nur per Konvention geregelt (z.B. die Startadresse am Anfang von Programmen wir vom Basic-Interpreter so gehandhabt, aber dem Floppy-Disk-Laufwerk ist das egal). Also das Dateiformat mit Dateitypen des CBM-DOS zu vermischen, halte ich eher für verwirrend. Ich sehe da die Ebenen (die jeweils von einer entsprechenden API/Schnittstelle abgegrenzt sind)

• Blockebene (Floppy-Disk, aber auch bei Tape-Formaten Blöcke oder ganze "Streams")
• Dateistrukturen (Linked-Blocks = PRG, SEQ, USR und Indexed-Blocks = REL) z.B. bei CBM-DOS oder das Kassettendateiformat, wie es etwa das CBM-Basic verwendet, wo im Prinzip von einem "Dateinamen" auf die Daten am Datenträger gekommen wird).
• Dateiformate, wie sie Betriebssysteme und Anwendungen verwenden, also der "Inhalt", die Nutzdaten, mit dem bzw. mit denen etwas "gemacht" wird.

Der Missbrauch von Dateitypen ist überhaupt ein von der falschen Seite her aufgezäumtes Pferd. Der Typ legt bestenfalls eine Konvention nahe. Aber jede Nutzung eines Typs bleibt dennoch ein legitimer "Gebrauch", nicht mehr und nicht weniger. Eine Abweichung von der üblichen Konvention als "Missbrauch" zu titulieren, ist schon sehr vorverurteilend. Das nur als ein weiteres Beispiel, was die Durchmischung der Begriffe und Konzepte angeht.

Den Begriff von "ausführbaren Programmen" mit Dateiformaten zu verknüpfen ist auch mehrschichtig. "Ausführbares" hat nur im Kontext eines Betriebssystems einen Sinn. Einem Floppy-Laufwerk ist das herzlich egal. Die Intention des Betriebssystems wird bestenfalls durch den Typ (=Konvention beim Dateinamen) oder Dateiattribute (vgl. Execution-Bit bei unixoiden Betriebssystemen) unterstützt. Ob dann das, was in der Datei steckt etwas Ausführbares ist hängt rein von der Interpretation des Betriebssystems ab. Das ist vielleicht nur ein etwas speziellerer (weil überall zu findender) Sonderfall aus allen bekannten Dateiformaten ...
Eine Klassifizierung mit Header und Body ist da auch schon eine ziemliche spezielle, die als Kriterium zur Klassifizierung selbst nicht wirklich taugt (bestenfalls ein Beispiel gibt).

Die hier dargestellten Details zum CBM-Dateisystem sind hier vielleicht auch ein Doppelgemoppel. Es sollte nur in CBM-Dateisystem beschrieben werden und nicht immer wieder im Wiki verteilt vorkommen (in immer wieder leicht unterschiedlicher Ausprägung). Vor allem wird dann immer wieder die 202 Blöcke ladbare Datei erwähnt, was aber nichts mit dem Dateiformat zusammenhängt (das kann so die ganzen 664 Blöcke einer 1541-Disk aufbrauchen) und wenn der Inhalt geschickt aufgebaut ist und der Ladestart anders gewählt wird, ist auch mehr möglich. Auch die REL-Datei-Beschreibung ist 1541-spezifisch (nicht C64-spezifisch). Andere Laufwerke können mitunter "mehr". Also eher unpassend es an dieser Stelle mit diesen Details zu erwähnen.
JohannKlasek 21:48, 2. Nov. 2014 (CET)

Ja also, was mein Ausgangspunkt eigentlich war: Mir ging es um den Inhalt der Dateien (das Format, in dem die Daten abgelegt sind, die Konvention ihrer Struktur auf Disk, wie viele Bytes dienen welchem Zweck). Alles Dateitypgeklingel hat damit überhaupt nichts zu tun. Daher trifft der Artikel "Dateiformat" in der jetzigen Form nicht den Kern der Sache. Aber schön, dass endlich ein Artikel "CBM-Dateisystem" dabei herausgesprungen ist. Fehlte ja nun irgendwie... --GoDot 22:24, 2. Nov. 2014 (CET)

Der Artikel CBM-Dateisystem wure schon im Sept.2012 geschrieben.

Da ich vorwiegend nach dem Begriff schaue und natürlich nicht das ganze C64-Wiki untersuche, ob schon in irgendeinem Artikel dazu etwas existiert, wurde festgestellt, dass Dateitypen auch im Artikel CBM-Dateisystem beschrieben werden. Er müsste aber wohl noch ausgebaut werden.

Nun gibt es einen entsprechenden REDIRECT auf Dateityp!

Und wie kann man nun den aktuellen Artikel Dateiformat noch verbessern? --Jodigi 02:50, 3. Nov. 2014 (CET)

Eine Unterscheidung zwischen "Dateityp" und "Dateiformat" versteht kein Mensch, macht das besser nicht, das sollte synonym benutzt werden. Das mit der Weiterleitung von Dateityp in den entsprechenden Abschnitt des CBM-Dateisystem-Artikels ist doch gut; auskoppeln würde ich den Teil nicht, denn das zerreißt eben den Zusammenhang. Eher später - wenn denn mal genug Masse dafür da ist - "Dateityp" direkt auf eine Disambiguierungs-Seite laufen lassen, die auf "CBM-Dateisystem#Dateityp" und eben "Dateityp (Anwendungen)" verweist (= die aktuelle "Dateiformat"-Seite). Verbessern kann man "Dateiformat" denke ich, indem man mal die "Kategorie:Dateiformat"-Tags aktualisiert, ich habe das eben mal für VLIR gemacht (wobei VLIR ja auch eher wieder ein Meta-Dateiformat ähnlich REL ist... :-) ). -- 1570 02:25, 6. Nov. 2014 (CET)

Die Unterscheidung ist doch aber gerade wichtig für das Verständnis. Wenn ich ein Verzeichnis aufliste und da der Eintrag 15 "[B] PACMAN TITLE" PRG drin steht und die Frage ist welches Dateiformat hat die Datei dann ist die Antwort Amica Paint, wenn die Frage allerdings ist welchen Typ hat die Datei, dann ist die Antwort PRG. Wenn man Dateityp und -format synonym benutzt, dann wird es verwirrend, weil man die beiden Fragen dann nicht mehr eindeutig beantworten kann. --BlackJack 10:33, 6. Nov. 2014 (CET)

Ich weiß schon, was Du meinst. Ich würde das aber besser "Dateiformate/-typen des CBM-Dateisystems" nennen und "Dateiformate/-typen diverser Anwendungen" statt "Dateitypen" und "Dateiformate", denn letzteres ist keine gängige Konvention. Schau' zum Beispiel mal im 1541-Handbuch nach; auf Seite 26 ist von "Sequential Format" und "Program File Format" die Rede, auf Seite 19 dagegen vom "PRG File Type" und vom "SEQ File Type" - schon da werden die Begriffe also munter durcheinandergeworfen. -- 1570 11:14, 6. Nov. 2014 (CET)