Software > Alternative Betriebssysteme

EmuTOS 1.1 erschienen

<< < (7/17) > >>

Count:

--- Zitat von: Chocco am Fr 16.07.2021, 00:16:30 ---Ganz schlimm sind Programme, denen anhand ihres eigenen Dateinamen Parameter übergeben werden. Bestes Beispiel ist FOLDERXX.PRG. Da wird die Anzahl der zusätzlichen Ordner im Dateinamen numerisch eingetragen, die dann vom Programm selbst extrahiert und ausgewertet werden müssen! Man fragt sich, was die Entwickler geraucht haben, um sich sowas auszudenken.

Hinzu kommt noch, das der Pfad auf die eigene Programmdatei nicht als argv[0] übergeben wird, sondern das Programm seinen eigenen Namen erst über die Basepage(?) selbst herausfinden muss.
--- Ende Zitat ---

FOLDRXXX.PRG ermittelt den "Parameter" übrigens ganz simpel. Es holt sich mit Fsfirst("\AUTO\FOLDR*.PRG") den ersten Directory-Eintrag und extrahiert daraus die Zahl. Theoretisch kannst du das Programm also zweimal mit unterschiedlichen Werten im AUTO-Ordner stehen haben, aber beide Aufrufe tun das selbe. Auf jeden Fall musst du das Muster FOLDRxxx.PRG beibehalten und kannst es nicht in z.B. ORDNR100.PRG umbenennen, das würde zu einer mit Tastendruck zu bestätigenden Fehlermeldung führen.

goetz @ 3rz:

--- Zitat von: MJaap am Sa 17.07.2021, 00:02:27 ---Das coole ist ja, dass der Quelltext vorliegt. Ich hatte mir mal mit TOSPATCH mein Wunsch-TOS2.0x zusammengestellt (mit Pinguin-Icon). Bei EmuTOS gibt es da ganz andere Möglichkeiten. Müsste eben nur jemand entwickeln und entweder einschicken oder einen Fork erstellen. Dinge wie eine Menüzeilen-Uhr oder RAM-Disk wurden schon diskutiert, aber da gibt es eben schon Dutzende Lösungen im PD-Bereich.

Größeren Visionen setzt eben die Kapazität der ROMs (256/512 KB) Grenzen. Ich persönlich würde es super finden, wenn EmuTOS noch Parität mit TOS 4.92 schafft (TOS 5).

Jedes neue Feature, dass durch Programmierer erst erschlossen werden muss, ist allerdings sinnlos. Ein Blick auf die Startseite von Atariuptodate.de zeigt ja, dass es kaum Aktivität abseits von Demos und gelegentlich einem Spiel gibt :(

--- Ende Zitat ---

Menüzeilen-Uhr, RAM-Disk und Co: klar, kann man machen, aber gibt es doch schon x gute, wozu also nochmals erfinden.

Neue Software: das ist auf anderen Plattformen nicht so viel anders (Acorn RiscOS, Mac 68k mit System 6, 7, A/UX): was soll denn noch erscheinen? Die klassische Produktivsoftware (Textverarbeitung etc.pp.) ist ja noch vorhanden und ist gut. Die könnte man natürlich noch ein bißchen besser machen, aber der Aufwand dafür ist, selbst wenn ein Sourcecode von einer alten Software vorliegt, sehr hoch.

Kleine Tools: sicher, sowas gibt es öfters noch neu.

Spannend wäre heute wohl noch am ehesten Kommunikations- und Netzwerksoftware: da ist meist der Teufel TLS/SSL im Weg, dessen Krypto viel zu dick für 680x0 ist (und selbst auf den StrongARM des RiscPCs brettert das nicht gerade, und die spielen in einer ganz anderen Liga als 68k). Da bräuchte es ein generisches Interface für, auf dem man aufbaut, also quasi „ich döngle mir einen Raspberry Pi (zero) extern an meinen 68k Rechner, und der macht über ein definiertes Interface Krypto für mich“, so wie halt NVDI Vektorfonts bereitstellt, und der Raspberry ist nur ein weiterer der vielen Atari-Coprozessoren (Blitter, FPU, DSP …) für einen speziellen Einsatzzweck.

Es gibt ja kleine Ansätze in die Richtung (@czietz hat ja bspw. die Firmware für ein ESP8266 veröffentlicht, womit ein wget am ST geht), aber bevor nicht eine* heldenhafte Programmierer*in die Ärmel hochkrempelt und Fakten schafft, ist der Weg für viele, die sich einen kleinen Mastodon/Twitter/Instafeed-Client oder Keybase-Messenger oder … bauen wollen, qua Krypto versperrt.

Ich würd’ ja als Interface zum Raspi seriell/RS232 vorschlagen, weil’s das bei jeder Plattform gibt, und man die typischen Datenmengen ganz gut durchkriegt, aber mit dem RaSCSI-Board hätte man noch ganz andere Möglichkeiten: Das Krypto-Layer via SCSI-Protokoll-Erweiterung verpacken, der Raspi ist dann noch gleich Ethernet-Adapter.

goetz @ 3rz:

--- Zitat von: Chocco am Fr 16.07.2021, 00:16:30 ---Wenn meine Erinnerung stimmt: Programme im Auto-Ordner haben zudem mit weiteren Einschränkungen zu kämpfen, denn eigentlich werden sie gestartet bevor das System einen stabilen Zustand besitzt. Die Zeichenausgabe funktioniert zwar bereits über TOS (low level Line-A), aber VDI/AES sind noch nicht initialisiert.

--- Ende Zitat ---

Nö, das ist so nicht richtig. VDI hast du im Auto-Ordner schon. Nur AES nicht. Du kannst also sauber eigene GUIs bauen, wenn du das im Auto-Ordner unbedingt tun willst :)


--- Zitat von: Chocco am Fr 16.07.2021, 00:16:30 ---Ganz schlimm sind Programme, denen anhand ihres eigenen Dateinamen Parameter übergeben werden. Bestes Beispiel ist FOLDERXX.PRG. Da wird die Anzahl der zusätzlichen Ordner im Dateinamen numerisch eingetragen, die dann vom Programm selbst extrahiert und ausgewertet werden müssen! Man fragt sich, was die Entwickler geraucht haben, um sich sowas auszudenken.

--- Ende Zitat ---

Kann man natürlich so beurteilen. Oder sich denken „das spart dann halt eine Datei #:\FOLDR.INF, in der dann nur die Zahl "60" stünde, sonst nix“. Haben aus dem selben Grund ja auch RAM-Disk-Entwickler*innen ähnlich gemacht. Auf einer SH205 unter TOS 1.0 war ich um jede Datei froh, die von einer Software nicht referenziert wurde (und ja, ich habe das lange genau so genutzt).

mfro:

--- Zitat von: Chocco am Fr 16.07.2021, 00:16:30 ---...
Jeder dusselige PC hatte zumindest immer ein BIOS Setup, in dem Datum/Uhrzeit, Bootlaufwerk und andere grundsätzliche Dinge eingestellt werden konnten. In TOS und auch EMUTOS gibt es nichts dergleichen.
...

--- Ende Zitat ---

Tatsächlich ist das "BIOS Setup" vom "dusseligen PC" nichts anderes als das NVRAM bzw. die batteriegepufferte Uhr von TT und Falcon.

Atari hat das am Ende eingebaut, wusste aber anscheinend irgendwie selbst nicht so recht, was man denn da reinschreiben sollte.

Im TT ist die einzige mir bekannte, "offizielle" Nutzung die Einstellung der Bootpräferenz, wenn Atari SYSV4 installiert ist.

Im Falcon kamen dann noch Boot-Videoauflösung und die Sprache dazu (wobei erstere - meine ich - nicht wirklich "offiziell" dokumentiert ist und letztere ja nicht dem Anwender, sondern nur Atari selbst nutzte).

Unterm Strich erzeugt das "Atari-NVRAM" mehr Ärger als Nutzen. Hätten die meinetwegen auch weglassen können.

kernal:

--- Zitat ---...
Jeder dusselige PC hatte zumindest immer ein BIOS Setup, in dem Datum/Uhrzeit, Bootlaufwerk und andere grundsätzliche Dinge eingestellt werden konnten.
...
--- Ende Zitat ---

Die Aussage stimmt nicht ganz. Die Echtzeituhr mit dem NVRAM für das BIOS (RTC/Dallas Chip) wurde auch "erst" 1984 mit dem PC/AT eingeführt.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete