letzter Beitrag von Freddy am
ZitatWindows versucht beides zu sein: Ein MultiuserOS UND ein SpieleOS.
Häh? Wohl eher das sich Programmierer dem anbiedern. Wie gesagt, plausible Gründe dafür gibt es überhaupt nicht. Die Wahl des Betriebsystems spielt da überhaupt keine Rolle. Merkwürdige Antwort. Sollte das in der Tat ein Windows Bashing sein, war das jedenfalls sehr sehr schwach.
ZitatWindows versucht beides zu sein: Ein MultiuserOS UND ein SpieleOS.
Häh? Wohl eher das sich Programmierer dem anbiedern. Wie gesagt, plausible Gründe dafür gibt es überhaupt nicht. Die Wahl des Betriebsystems spielt da überhaupt keine Rolle. Merkwürdige Antwort. Sollte das in der Tat ein Windows Bashing sein, war das jedenfalls sehr sehr schwach.
Ich täte eher sagen, daß die Wahl des Betriebssystems sehr wohl eine Rolle spielt.
Multiuser (mehrere Usern gleichzeitig oder von mir aus auch hinter einander) stellt definitv andere Anforderungen am OS als Singleuser (ein Spieler z.B.).
Will man ein Programm 'portable' haben (auf Stick z.B.) dann muß dieses Programm auf dem Stick auch als solches Konfiguriert werden.
Ist dasselbe Programm aber auf ein Multiuser-System für alle zugänglich, dann gehören naturgemäß auch die verschiedene Konfigurationen separiert, denn Mutti hat lieber einen Lila hintergrund, Sohneman steht eher auf Dark-Temes und startet immer Commando Lybia, Oma braucht größere Schrift, und Daddy startet sein X64 immer mit Geos Autoboot.
Wer das nicht versteht verstehe ich nicht 
Und nochmal: Was hat das mit einem Emulator oder OS zu tun? Davon ab kann ich verschiedene Multi-Einstellungen für verschiedene Vorlieben auch in einer cfg/ini abspeichern, wenn es sein muß in Extra Unterordner der Exe. Das muß nicht zwingend auf der Windows Ebene verschachtelt liegen. Ist rein technisch auch kein Problem. RetroArch z.B. veranstaltet auch nicht so eine Zirkus. 
Das ist auch das Problem, dass ich täglich mit vielen Techies (bin selbst einer) im Alltag erlebe:
Sie schanzen sich zu sehr hinter dogmatischen Grundprinzipien und verkennen völlig was in der realen Welt rund um sie herum, z.B. aus Sicht des Benutzers und des Business passiert und was die täglichen Painpoints und Bedürfnisse der User sind.
Das ist auch das Problem, dass ich immer wieder mit Nutzern erlebe: Sie stossen auf irgendein Problem, schreiben darüber lange Threads im Forum, aber kommen nicht auf die Idee, das mal direkt an die Entwickler heranzutragen.
Kleine Geschichtsstunde: Ursprünglich hat WinVICE die vice.ini immer im Programmverzeichnis abgelegt. Das wurde irgendwann (genauer: Anfang 2017) mal geändert, weil Programmverzeichnisse nicht immer für den aktuellen Benutzer beschreibbar sind. Danach lag die vice.ini in appdata\vice\<versionsnummer>. Zusätzlich(!) wurde aber beim Start geprüft, ob im Programmverzeichnis eine vice.ini liegt und diese verwendet ohne in den Systemverzeichnissen nachzuschauen. Bei der Gtk3-Umstellung ist das wohl rausgeflogen und zu diesem Thread habe ich weder im Bugtracker noch an anderen von mir gelesenen Orten Beschwerden deswegen gesehen.
Aber es hilft ja sicherlich viel mehr, in Foren auf die doofen Entwickler einzuhacken als diese mal nett zu fragen, ob man das verlorengegangene Feature nicht wieder einbauen kann, oder?
ZitatAber es hilft ja sicherlich viel mehr, in Foren auf die doofen Entwickler einzuhacken als diese mal nett zu fragen, ob man das verlorengegangene Feature nicht wieder einbauen kann, oder?
Und kein Entwickler kommt da mal selber auf die Idee und wundert sich, wo jetzt wo wohl die ini abgeblieben ist wenn man das erste mal konfiguiriert hat? Ich meine ja nur, Syshack hat da nicht ganz unrecht.
Und kein Entwickler kommt da mal selber auf die Idee und wundert sich, wo jetzt wo wohl die ini abgeblieben ist wenn man das erste mal konfiguiriert hat?
Nö, warum? Als Entwickler nutzt man eh oft "-default" oder ein explizites "-config bla.ini" als Parameter und das Speichern der Einstellungen am Default-Ort und späteres Laden funktionieren ja prima.
Also doch eher 100% Entwickler orientiertes Denken, so wie Syshack schon erwähnte.
Und nochmal: Was hat das mit einem Emulator oder OS zu tun? Davon ab kann ich verschiedene Multi-Einstellungen für verschiedene Vorlieben auch in einer cfg/ini abspeichern, wenn es sein muß in Extra Unterordner der Exe. Das muß nicht zwingend auf der Windows Ebene verschachtelt liegen. Ist rein technisch auch kein Problem. RetroArch z.B. veranstaltet auch nicht so eine Zirkus.
Das hat insofern damit zu tun, daß dein Emulator nur ein Programm unter 1000e ist, und es hat mit dem OS zu tun, weil DIESES Programm unter DIESES OS laufen will, dann hat das Programm sich auch gefälligst an den gepflogenheiten des OSes zu richten.
Wäre so als wenn alle Engländer in Rest-Europa das recht hätten links zu fahren, gelle?
Merke (von wegen 'Windows Bashing') das ist unabhängig vom OS gemeint. Egal ob Win oder Linux, oder DOS.
Also doch eher 100% Entwickler orientiertes Denken, so wie Syshack schon erwähnte.
Den Kommentar verstehe ich nicht.
Die normale Nutzung des Emulators hat einwandfrei funktioniert. Es wäre natürlich nett, wenn es eine umfangreiche Testsuite gäbe, die auch Sonderfälle wie den einer Configdatei an einem Nicht-Standard-Ort testen würde, aber die gibts nicht und manuell kann man nicht bei jedem Release jeden einzelnen Sonderfall ausprobieren.
ZitatDie normale Nutzung des Emulators hat einwandfrei funktioniert. Es wäre natürlich nett, wenn es eine umfangreiche Testsuite gäbe, die auch Sonderfälle wie den einer Configdatei an einem Nicht-Standard-Ort testen würde, aber die gibts nicht und manuell kann man nicht bei jedem Release jeden einzelnen Sonderfall ausprobieren.
Wieso bei jedem Release? An solchen logistischen Dingen, die nicht mir dem Core oder direkt der GUI zu tun haben, ändert sich doch eher selten was. Einfach in der GUI eine Option mit "Portable Mode aktivieren", und alles ist gut.
Das ist auch das Problem, dass ich immer wieder mit Nutzern erlebe: Sie stossen auf irgendein Problem, schreiben darüber lange Threads im Forum, aber kommen nicht auf die Idee, das mal direkt an die Entwickler heranzutragen.
Und dann? Ich behaupt man, der Entwickler, der das verbockt hat, hat das wissentlich und mit Absicht geändert.
Sorry, aber auf solche Diskussion mit Entwicklern (vor allem, wenn sie von Linux her kommen, wo sowieso nur die "reine Lehre" gilt und nicht das, was der User braucht), habe ich lange aufgegeben.
Ich behaupt man, der Entwickler, der das verbockt hat, hat das wissentlich und mit Absicht geändert.
Ich behaupte mal: Das ist üble Nachrede.
Beim Zusammenführen von ziemlich vielen archdep-Abhängigen Funktionen in jeweils mehreren Varianten kann schonmal versehentlich was unter den Tisch fallen.
Ich behaupt man, der Entwickler, der das verbockt hat, hat das wissentlich und mit Absicht geändert.
Ich behaupte mal: Das ist üble Nachrede.
Beim Zusammenführen von ziemlich vielen archdep-Abhängigen Funktionen in jeweils mehreren Varianten kann schonmal versehentlich was unter den Tisch fallen.
Wieso üble Nachrede? Wenn er das für richtig hält, kann er das doch machen. Ist doch seine Entscheidung.
Ob das dann die User gut finden, ist eine andere Frage.
Das ist auch das Problem, dass ich immer wieder mit Nutzern erlebe: Sie stossen auf irgendein Problem, schreiben darüber lange Threads im Forum, aber kommen nicht auf die Idee, das mal direkt an die Entwickler heranzutragen.
Und dann? Ich behaupt man, der Entwickler, der das verbockt hat, hat das wissentlich und mit Absicht geändert.
Sorry, aber auf solche Diskussion mit Entwicklern (vor allem, wenn sie von Linux her kommen, wo sowieso nur die "reine Lehre" gilt und nicht das, was der User braucht), habe ich lange aufgegeben.
I'm the dev who "screwed that up". And indeed I did so intentionally and for good reason: on a modern OS, even on Windows, not all directories are user-writable, the user's profile dir is writable however and thus the logical place for configuration data.
And as mentioned, if you want a vice.ini inside the VICE bindir, you can use the `-config <file>` switch, or use a batch file, with something like `x64sc -config .\vice.ini` in it.
Meanwhile 'load vice.ini from bindir' has been implemented again, VICE first looks for vice.ini in the same dir as the binary and when not found uses vice.ini in the user's profile directory.
And I agree with Unseen: it's pretty tiring to see these long threads while there's better and preferred way of reporting bugs or requesting features: contacting us directly via our bugtracker. That way you'll make sure we actually see the bug report and more devs can have a look, we don't read all forums and certainly not all threads.
I don't understand why it's so hard for some people to wrap their head around this concept.
Entschuldigt die Einmischung aber als Mac-User muss ich mich auf Multi-User-OS-Seite schlagen. Das Problem wurde hier schon genannt: In modernen Betriebsystemen haben die Nutzer keine Schreibrechte im Applikationsverzeichnis. Daher ist es auch keine gute Idee, dort Konfigurationsinformationen abzulegen. Mac-OS verwaltet Anwendungen als sogenannte Bundles: Das sind Verzeichnisse, die aus Anwendersicht aussehen wie Dateien. Was darin abgelegt ist, ändert sich normalerweise nicht, es ist fester Bestandteil der Software. Daher kann ein Programm wie VICE dort auch keine Konfigurationsdateien ablegen. Daher gibt es globale und anwenderspezifische Konfigurationspfade. Die globalen Einstellungen gelten systemweit, die lokalen nur für den jeweiligen Anwender.
Im Fall von VICE, das ein einzelner Anwender mit verschiedenen Konfigurationen starten will, ist vielleicht der Dokument-Ansatz die beste Lösung: Alle Einstellungen und Statusinformationen werden in einer Datei gespeichert, die mit der Anwendung VICE verknüpft wird, üblicherweise durch die Dateierweiterung. Diese Dateien kann dann jeder so verwalten, wie er es braucht. Also statt vice -config meine-konfiguration.ini lieber vice meine-konfiguration.vice. Die Dateien kann man dann auch gut auf die Anwendung werfen, eventuell sogar auf verschiedene Versionen derselben. In der Datei kann auch stehen, welches System (C64, VC20, PLUS4) emuliert wird. Die Anwendung würde sich dann den richtigen Emulator automatisch heraussuchen.
P.S.: Zum Glück verteilen sich die Einstellungen nicht kreuz und quer in der Windows-Registry. Das wäre weitaus schlimmer.
Unseen : Das war kein Gemotze gegenüber den VICE Entwicklern, obwohl sie sich da sicher auch mal Gedanken gemacht haben dürften.
Es war eher an Mr. Freddy gerichtet, der threadübergreifend IMHO immer wieder mit seiner dogmatischen IT Weltanschauung auffällt und sich eben oft auf OS Bashing/Seitenhiebe einlässt, auch dort wo es überhaupt nicht gefragt wurde bzw. Sinn macht. Hier ging es mir um Pro und Contra eine Applikation portabel zu halten und nicht um Grundsatz Diskussionen was Multiuser vs Singleuser Betriebssysteme sind.
Ich habe meinen eigenen Teil an Applikationen entwickelt - ja unter Windows - und bin mir über die Problematik mit benutzerspezifischen Einstellungen und deren Speicherort bewusst.
Manche bevorzugen die Registry im User-Hive, andere im HKLM Hive - beides meiner Meinung oft nur Murks.
Andere Apps bevorzugen ihre Settings im genannten %USERPROFILE%\AppData\ und dann kann man sich aussuchen uner Local/LocalLow/Roaming jeweils unter andere wiederum z.B. unter %USERPROFILE%\Documents\.
Diese Lösungen haben durchaus Daseinsberechtigung, auch wenn ich persönlich finde für Systeme zuhause wo wenige oder nur ein User das System verwenden ein Nightmare für Backups sind.
Aber bei Portable Software - und dazu zähle ich VICE nunmal - finde ich dieses Verhalten nicht in Ordnung, wenn nicht explizit erwünscht/ausgewählt.
Nun ist das offenbar doch noch möglich wenn man vice.ini manuell lokal ablegt, aber intuitiv ist das ja auch nicht gerade. Aber für mich gut genug.
And as mentioned, if you want a vice.ini inside the VICE bindir, you can use the `-config <file>` switch, or use a batch file, with something like `x64sc -config .\vice.ini` in it.
As as workaround if there wouldn't be a better choice or when explicitely needed, ok, but the previous behaviour was changed and therefore this would be not an adequate replacement.
Meanwhile 'load vice.ini from bindir' has been implemented again, VICE first looks for vice.ini in the same dir as the binary and when not found uses vice.ini in the user's profile directory.
This is great and now that I know, I can use this. Thank you . 
Entschuldigt die Einmischung aber als Mac-User muss ich mich auf Multi-User-OS-Seite schlagen. Das Problem wurde hier schon genannt: In modernen Betriebsystemen haben die Nutzer keine Schreibrechte im Applikationsverzeichnis. Daher ist es auch keine gute Idee, dort Konfigurationsinformationen abzulegen. Mac-OS verwaltet Anwendungen als sogenannte Bundles: Das sind Verzeichnisse, die aus Anwendersicht aussehen wie Dateien. Was darin abgelegt ist, ändert sich normalerweise nicht, es ist fester Bestandteil der Software. Daher kann ein Programm wie VICE dort auch keine Konfigurationsdateien ablegen. Daher gibt es globale und anwenderspezifische Konfigurationspfade. Die globalen Einstellungen gelten systemweit, die lokalen nur für den jeweiligen Anwender.
Im Fall von VICE, das ein einzelner Anwender mit verschiedenen Konfigurationen starten will, ist vielleicht der Dokument-Ansatz die beste Lösung: Alle Einstellungen und Statusinformationen werden in einer Datei gespeichert, die mit der Anwendung VICE verknüpft wird, üblicherweise durch die Dateierweiterung. Diese Dateien kann dann jeder so verwalten, wie er es braucht. Also statt vice -config meine-konfiguration.ini lieber vice meine-konfiguration.vice. Die Dateien kann man dann auch gut auf die Anwendung werfen, eventuell sogar auf verschiedene Versionen derselben. In der Datei kann auch stehen, welches System (C64, VC20, PLUS4) emuliert wird. Die Anwendung würde sich dann den richtigen Emulator automatisch heraussuchen.
P.S.: Zum Glück verteilen sich die Einstellungen nicht kreuz und quer in der Windows-Registry. Das wäre weitaus schlimmer.
Disclaimer: Ich verwende gelegentlich auch mein MacBookPro, insofern darf ich hier eine Meinung haben, auch wenn ich das System sehr unproduktiv für mich finde.
Ich finde auf dem Mac ist das noch schlimmer mit der Verstückelung der Dateien, ich habe mich oft dumm und dämlich gesucht, bis ich irgendwelche Einstellungen gefunden habe, teilweise nur durch Googlen.
Mir war es immer wieder mal zumindest so, dass auch nicht immer einheitlich war. Oft muss man irgendwelche Flags setzen oder Dateien sichtbar machen, damit man den Zugriff darauf bekommt.
Das mit den "Applications" Packages ist mir bewusst und dass man dort die Dateien sichtbar machen kann und tatsächlich fand ich auch dort auch schon Settings Dateien.
Das muss nicht unbedingt mit Multiuser System zu tun haben, sondern generell das MacOSX System Design.
Auf dem Mac will Apple halt das Zeugs von dem Anwender verstecken und oft hat der User keine Ahnung wo seine Dateien sind.
Mir gefällt sowas nicht, ich möchte wissen, wo ich gezielt suchen kann und so auch Backups erstellen kann, ohne das ganze System sichern zu müssen.
Oder auch um Applikationen auf einem anderen Mac migrieren können, in dem ich die Settings Dateien richtig platziere.
syshack Gerade was Backups angeht, gibbet nix besseres als 'home-Verzeichnisse'
Sei es wie bei Unixoiden (configs meistens in dot-files) oder halt %userprofile%/<dingsabums>.
Es ist nun mal ein Unding Konfigurationsdateien in binäre Verzeichnisse ab zu legen. Auch unter Anderem wegen Daten- bzw. Virenschutz.
Reine binäre Verzeichnisse können mit Schreibschutz versehen werden. Da sollte z.B. auch kein Virus in der Lage sein dort hinein zu schreiben (und Trojanern ablegen).
Spätestens seit dem wechsel auf dem NT-Kernel ist Windows ein Multiuser-System. Wird langsam Zeit das die Usern das endlich kapieren, und ihre Single-User-Mentalität ablegen, oder sich halt ein Single-User System anschaffen. Wie AtariTOS, AmigaOS oder halt das gute alte DOS.
Was ich hingegen real feststelle, ist daß dieses DOS-Gehabe (also single-user-denken) teilweise sich auch in der Unix insbesondere Linux-Welt verbreitet.
Und seien wir mal ehrlich: auf Heimkomputern haben eigentlich Multi-User-Systeme selten was zu suchen. Wir müssen leider damit klarkommen mangels Alternativen (die es z.B. mit OS/2 durchaus gab).
Wenn das hinweisen auf 'ungereimtheiten' in Windows-Systeme von dir als 'bashing' betrachtet wird, sei es drum.
Ich werde trotzdem weiterhin meine Linuxe und Windosen (ja ich liebe es es so zu nennen) malträtieren wie's mir gefällt
