Der richtige Ort für Daten und Einstellungen

[Cyborg]

Nein, das stimmt so nicht.

Es war früher in der Tat so, daß der Inhalt von ENVARC: einfach komplett nach ENV:, das in der RAM Disk lag, kopiert wurde. Inzwischen stellt aber der env-handler ein virtuelles Dateisystem für ENV: bereit, wo die Dateien erst beim erstmaligen Zugriff in den Speicher geladen und dann dort gehalten werden. Wird auf eine Datei nicht über ENV: zugegriffen, belegt sie auch keinen Arbeitsspeicher (außer ein paar Bytes für die Metadaten). Ist also deutlich weniger schlimm, als noch vor einigen Jahren

[ShawnBaxe]

@Cyborg

Ah okay - danke für die Aufklärung

[Blackbird]

Ja, Danke Cyborg für die klarstellung, war mir gar nicht so bewußt!

[Daytona675x]

Also am ehesten deckt sich meine Meinung mit dem was Goos sagt:

Sry aber, wenn ich eine system library nutze, die für das laden und speichern von prefs Einstellungen von Programmen/Spielen verantwortlich ist und in den autodoc steht, dass diese prefs, per default in ENV: liegen, sehe ich das schon als eine Systemrichtlinie an.

Auch wenn ich momentan nicht die apps-lib benutze, um die Settings zu bunkern, würde ich diesen Satz dennoch unterschreiben.

Ein Nachteil von PROGDIR ist mir eben aufgefallen: unsere Games sind nicht zuletzt dank der ENV(ARC): Nutzung völlig problemfrei direkt von CD spielbar, man muss sie gar nicht "installieren" (bei AceOfHearts steht das sogar hinten auf der Hülle ), Einstellungen und Highscores o.ä. werden dabei dann trotzdem funktionierend behandelt.
Bei PROGDIR sähe das in so einem Fall natürlich etwas anders aus...

Wenn ich mir diesen Nachteil ansehe und dann noch die von Goos m.A.n. korrekt vorgetragene Argumentation anschaue, dann bleibe ich vielleicht doch besser bei ENV(ARC)?!

[Cyborg]

Äh.. als User würde ich ganz sicher nicht erwarten, daß irgendetwas von einer Software auf meiner Platte landet, wenn ich sie von CD aus starte. Das ist meiner Meinung nach unerwartetes Verhalten und somit nicht erwünscht. Persönlich würde ich das sogar als fehlerhaft einstufen. Entweder habe ich eine "Live-CD", dann darf aber auch wirklich rein gar nichts irgendwo anders gespeichert werden oder eben nicht. Dann muß ich das Programm aber auch explizit auf meine Festplatte ziehen.

Und nochmal: Irgendwelche Defaults ersetzen doch das eigene Denken nicht. Unerheblich, ob der Default sinnvoll gesetzt wurde oder nicht (was er nach meiner Meinung nicht wurde), sollte doch jeder Programmierer mal kurz darüber nachdenken, ob das so auch wirklich sinnvoll ist. Und wenn man man nur einen Blick in sein eigenes ENV: wirft, müßte das doch schon genügen, um zumindest erhebliche Zweifel an dieser Praxis aufkommen zu lassen.

Irgendwann wird sich der Default ändern.

[whose]

Sehe ich ähnlich... ich fand es von Anfang an ziemlich daneben, Daten der APPLICATION.library per default nach ENV: zu schüppen (jetzt mal abgesehen von dem XML-Krampf). Es hätte Richtlinie werden sollen, daß die application.library die Daten nach Vorgaben der Applikation ablegt. Sprich, KEIN Default, Fehler bei fehlendem Speicherpfad. Keine große Sache und Applikationsprogrammierer hätten zwar angestrengt, aber auch nur kurz, nachdenken müssen, wo sie das Datengeraffel denn hin haben wollen. Höchstwahrscheinlich wäre im Laufe der Zeit daraus ein Quasi-Default "PROGDIR:" geworden, weil "das haben wir schon immer so gemacht!"

Bei Amijeweled habe ich es so gehalten, daß es Daten speichert, sofern das PROGDIR: schreibbar ist. Es ist keine große Sache, für den Fall des Write-Only-Mediums einen anderen Speicherort zu erfragen, wenn der Spieler denn unbedingt von CD spielen, aber Spielstände speichern will (was im Endeffekt nur SEHR seltsame Leute tun werden). Bei PC-Titeln ist häufig ein DVD-only gar nicht möglich und es wird ein Verzeichnis auf Platte gebastelt, in dem dann auch die Spielstände und Einstellungen landen.

Hat kaum jemanden davon abgehalten, diese Titel zu kaufen