Also nur halb so wild. Ohne diese Einschraenkung sah das sehr nach einer "entfernt FAT Code aus Linux und macht embedded Linux weniger Attraktiv" Stoeraktion aus. Wenns nur die LFNs sind, wird das embedded User weniger stoeren, da die zum Code sparen eh nur 8.3 verwenden (zumindest bei meiner Digicam der Fall IMG_nnnn.JPG).

Nach Heise behauptet MS das FAT auf einer Entwicklung von Bill G. von 1976 beruht, gemacht für das damalige Basic.

Hmm, hat MS je mal ein standalone (= OS-loses) Basic mit Disksupport gemacht? Ich glaub eher MS und BG versuchen da Geschichte zu verdrehen, weil ...

Nun, ich will ja jetzt nicht behaupten eine Autorität auf den Gebiet zu sein

... das ist ein Thema das immer wieder mal auf alt.folklore.computers diskutiert wird. Hier eines der besseren Threads dazu.

FAT war bereits in 86-DOS (oft faelschlich QDOS genannt) Version 0.3, und das sei bevor SCP es an MS verkaufte.

Tim Patterson hatte sich CP/M 2.2 als Vorbild genommen, da er möglichst schnell ein OS fuer das neue S100 8086 Board von SCP schreiben mußte.

Ja. Und scheints weil DRI CP/M-86 zu lange nicht lieferte, und TP seine Firma SCP wollte ihre entwickelten Rechner endlich verkaufen. Klassischer Fall von Second System Syndrome, statt einfach mal nen Prozessor Port zu machen und dann neue Features zu implementieren.

Die Ählichkeit erstreckte sich dabei nicht nur auf die ganzen Systemaufrufe, die sogar meist inklusive der Registerbelegung gleich waren, sondern auch auf das Diskettenformat

Nein. CP/M Filesystem sieht sehr anders aus als FAT.

inklusive des unsägliche Disk-Types

Disk Types? Ich nehm an du meinst die .3 File Extensions. Die gehen auf Systeme vor 1965 auf PDP Rechnern zurueck.

Der Hauptunterschied ist, daß CP/M die Folgeeinträge nicht für den Dateinamen, sondern für die Blockliste der belegten Blocks benötigte.

Jo. Im Gegensatz zu FAT, wo Filebloecke eine gelinkte Liste sind (eben in der File Allocation Table gespeichert) mit der Nummer des ersten Blockes im Directoryeintrag, verwendet CP/M pro File ein fixes Array von Blocknummern (wie ein Unix Inode) kennt aber dann keine indirekt Bloecke, sondern verbraucht weitere Directory Eintraege. Eben sehr anders.

Besonders auffällig dabei ist aber auch das sich solche Lizenzierungen insbesondere auch an Speichermedienhersteller richtet. Irgendwie hatte ich immer geglaubt einer Platte (oder auch einem Flash) ist es voellig egal was für Verwaltungsstrukturen benutzt werden.

Ist dem Medium auch. Aber der heutige ignorante/faule DAU/Konsument erwartet das Disks bereits formatiert daher kommen, sonst schickt er sie als "nicht funktionierend" zurueck. Also muss da bereits ne FAT drauf sein.

Frage ist nur, was machen typische Geraete (und Windows!) wenn man ihnen ein vor-LFN formatiertes Medium gibt? Und wie werden die Medienhersteller die relativen Kosten von Lizenzerpressung vs Kundenreaktion auf non-LFN beurteilen.

Welche Eigenschaft begründet nun die Lizenzzahlungen auf Medien? Das ist ja schlimmer als Rambus.

Tun sie zum Glueck nicht. Sie verlangen nur Lizenz fuer vorformatierte Medien mit LFN Support.
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today

... das FAT auf einer Entwicklung von Bill G. von 1976 beruht, gemacht für das damalige Basic....

Hmm, hat MS je mal ein standalone (= OS-loses) Basic mit Disksupport gemacht? Ich glaub eher MS und BG versuchen da Geschichte zu verdrehen, weil ...

Und ob. Denk daran, MS-Basic war lange Zeit der absolute Standard. vieleicht nicht super, aber gut und brauchbar. das war die Zeit, als MS-Produkte kaufen nicht mit einem Makel behaftet war, sondern man stolz darauf war ein solches zu haben. Von Apple ueber Dragon und Tandy bis Zenith hatte jeder MS-Basic, blos Exoten wie viele englische Rechner nicht :)

Nun, ich will ja jetzt nicht behaupten eine Autorität auf den Gebiet zu sein

... das ist ein Thema das immer wieder mal auf alt.folklore.computers diskutiert wird. Hier eines der besseren Threads dazu.

FAT war bereits in 86-DOS (oft faelschlich QDOS genannt) Version 0.3, und das sei bevor SCP es an MS verkaufte.

Nun, ich bleib mal bei dem was Tim mir selbst erzaehlt hat, und das war Q-DOS (Auch John Draper hat das, von Ihm fuer die Portierung des Apple Writer, auf dem SCP Rechner verwendete DOS, mir gegenueber, als Q-DOS bezeichnet ... aber das ist eine andere Story). Den beiden vertrau ich einfach mal mehr als irgendeinem alt.folk thread.

Nein. CP/M Filesystem sieht sehr anders aus als FAT.

Nun, ausser das er genau gleich anfaengt, die naechsten 4 Bytes, die internen CP/M Werten (und dem Bytecount) entsprachen leer sind, und erst die 2. 16 Byte, welche in CP/M die BLockliste hatten, und strikt von jedem programm ignoriert wurden, fuer alles 'neue' verwendet wurde .... also wenn das kein abschreiben ist :)

Disk Types? Ich nehm an du meinst die .3 File Extensions. Die gehen auf Systeme vor 1965 auf PDP Rechnern zurueck.

Nein, ich mein den Media Descriptor im BPB von DOS, welches eine Erweiterung des DPB von CP/M ist. Eigentlich muss ich mich korregieren, da dies eine Verschlimmbesserung gegenueber CP/M war.

Egal, ich bin wie gesagt kein Experte, aber fuer mich liegen diese Teile auf der Hand.

Gruss
H.

Standard war MS Basic (ich hab ja auch Basic auf so einem gelernt, 1984, Dragon 32). Aber saemtliche mir bekannten Versionen hatten ein OS drunter, welches die Filerei machte. Entweder ein DOS wie CP/M oder MS-DOS, oder etwas wie das kernel ROM im C64er oder den Dragon.

FAT war bereits in 86-DOS (oft faelschlich QDOS genannt) Version 0.3, und das sei bevor SCP es an MS verkaufte. Nun, ich bleib mal bei dem was Tim mir selbst erzaehlt hat, und das war Q-DOS

Oh, wenn Tim das selber so gesagt hat, dann stimmt das definitiv. Vielleicht sehen wir da die Differnz interner/Programmierer Name und externer/Marketing Name, so wie Mozilla vs Netscape benutzt wurden, bevor es mit 5.0 open wurde.

Disk Types? Ich nehm an du meinst die .3 File Extensions. Nein, ich mein den Media Descriptor im BPB von DOS

Ah das Teil. Ja das sollte auch kompatibel sein, das es Teil vom CP/M API ist. Ich wuerd das aber als OS Struktur, und nicht Filesystem Strukur einordnen. Logisch wird ein Teil davon dann auf Disk abgebildet, und damit wird auch ein Teil der Filesystem Struktur gewisse Aehnlichkeiten erben.

Anderseits ist die FAT definitiv was anderes als die mehreren zusammengesammelten Directoryrecords.
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today

ROM Basic war nur in den IBM Originalen drin, von ur-PC bis und mit erste Serie PS/2. Kompatible hatten eben keins drin.

ROM Basic verwendete sicher mal das BIOS ROM, das zwar Disks blockweise kennt, aber kein Filesystem. Aber hatte das in der nur-ROM Version ueberhaupt Disk Support? Oder nur Files auf Kassette? Der 16-64kByte auch-disklos-erhaeltlich ur-PC hatte ja noch nen Kassetten Anschluss auf dem Motherboard, neben dem Tastaturanschluss. Erst beim 64-256k PC/XT der stets mit Disks und fakultativ HD daherkam wuerde das weggelassen.

Und war da nicht noch unter PC-DOS (nicht unter MS-DOS!) laufendes abasic noetig, das einfach das ROM Basic dahinter benutzte (daher braucht MS-DOS gwbasic welches kein ROM benoetigt), aber etwas aufmotze, darunter auch die Files mit Disk Zugriff ausstattete, was dann wieder ueber DOS und das Filesystem darin lief?
--
hardware runs the world, software controls the hardware,
code generates the software, have you coded today