Hallo Besucher, der Thread wurde 4,9k mal aufgerufen und enthält 38 Antworten

letzter Beitrag von Freddy am

Wo speichert Vice die Einstellungen?

  • Früher war das unter Windows direkt im gleichen Verzeichnis wie VICE, also wo das EXE gestartet wird.

    Das war gut, so konnte mal mehrere Versionen mit eigenen Einstellungen unabhängig von einander haben.

    Das wurde leider irgendwann mal angepasst und ins %userprofil%\AppData\Roaming\vice verfrachtet und damit de-facto werden die EInstellungen vermatscht, wenn du unterschiedliche Versionen verwendest.

  • Früher war das unter Windows direkt im gleichen Verzeichnis wie VICE, also wo das EXE gestartet wird.

    Das war gut, so konnte mal mehrere Versionen mit eigenen Einstellungen unabhängig von einander haben.

    Das wurde leider irgendwann mal angepasst und ins %userprofil%\AppData\Roaming\vice verfrachtet und damit de-facto werden die EInstellungen vermatscht, wenn du unterschiedliche Versionen verwendest.

    Dann ruf doch VICE mit folgende Parametern auf:


    -config <Dateiname>

    Konfigurationsdateiname definieren


    Kannste doch soviele Configs machen wie und wo du willst.

  • Warum ist sowas nicht einfach in einer INI Datei im EXE Verzeichnis konfigurierbar, wenn schon?

    Ach ja, weil es genau diese INI ist, die im Userprofile abgelegt wird. :facepalm:


    Na gut, bis ich nach ein paar Stunden VICE irgendwie alles herausfinde wie ich die EXE zusammengefrickelt kompiliert habe, ist sicherlich eine "recht einfache" Lösung :D

    Dann eher mit einem Shortcut und dem CMD Parameter, wie oben vorgeschlagen.

  • Tja, es ist nun mal so das cfg-Dateien (ini-dateien) gar nichts in Verzeichnisse von ausführbare Dateien zu suchen haben.

    Das ist eine Unart die noch aus DOS-Zeiten hängengeblieben ist. Remember: DOS = Single-User OS, da gab es keine 'Userprofile'.

    In Multi-User OSes (wie das 'moderne' Windows) gehören nämlich die User Vorlieben (configs) der einzelne Usern nun mal in ein dafür dediziertes cfg-Verzeichnis, denn jeder User hat möglicherweise andere Vorlieben.

    Deswegen werden diese Userprofile auch getrennt, die bei JEDEM user natürlich inneralb 'sein' Datenbereich auf der Platte ist, und das ist nun mal auf Windosen => %userprofil%\AppData\Roaming\vice

  • Das ist mir auch klar fuer Vollrundumalles-Applikationen (ich war ja selbst Entwickler) und ich behaupte trotzdem dass portable Programme, wie eben auch VICE, portabel bleiben sollten.

    Ich kann eine Kopie des VICE Verzeichnis machen, mitnehmen auf USB, oder zippen und per Cloud woanders weiterverwenden.

    Mit solchen Einstellungen ins %userprofile% zu schreiben wird aber genau die Portabilitaet kaputtgemacht.

    Und eben auch die Moeglichkeit, mehere Kopien in unterschiedlichen Verzeichnisses fuer verschiedene Zwecke zu haben.


    Wenn man dann unbedingt ins %userprofile% die Einstellungen pro User haben will, sollte das dann per INI Datei im gleichen Verzeichnis wo die EXE ist, konfigurierbar sein.


  • Es sollte eigentlich auch funktionieren, zumindest in den nativen WinVICE Versionen weiß ich das, wenn man einmal das "vice.ini" File aus Admin/AppData/Roaming/Vice herauskopiert und direkt in den Ordner des Emulators mit hineinpackt. Dann nimmt diese WinVICE Version, vom nächsten Start ab, immer dieses ini-File statt dem unter Admin/AppData/Roaming/Vice. Da ich hier inzwischen vier verschiedene WinVICE V3.2 Versionen am PC draufhabe, nutze ich auch bei allen getrennte "vice.ini" Setting-Files. Ob das auf die Art auch bei den GTK3 und SDL2 VICE Versionen funktioniert, hab ich noch nicht ausprobiert bislang. Da hab ich jeweils nur eine Version hier am PC drauf, deshalb stellte sich das Problem bei mir dort bislang noch nicht.

  • Deswegen werden diese Userprofile auch getrennt, die bei JEDEM user natürlich inneralb 'sein' Datenbereich auf der Platte ist, und das ist nun mal auf Windosen => %userprofil%\AppData\Roaming\vice

    Nein, MS fährt da aktuell selbst zweigleisig. Wenn ich in meinem aktuellen Projekt Konfigurationsdaten einfplege, dann werden die automatisch im Verzeichnis abgelegt wo auch die Exe vom Programm liegt.

  • Mit solchen Einstellungen ins %userprofile% zu schreiben wird aber genau die Portabilitaet kaputtgemacht.

    Ich hatte das vor langer Zeit mal so umgebaut, dass eine vorhandene vice.ini im aktuellen Verzeichnis bei Programmstart verwendet wird und ansonsten das Systemverzeichnis benutzt wird. Ich weiss allerdings spontan nicht, ob das die archdep-Zusammenführung beim Gtk3-Umzug überstanden hat.

  • Für so einen 'Sonderfall' gibt es doch die Möglichkeit mit dem -config Parameter.

    Ich verstehe wirklich nicht wieso man sowas bemängelt.

  • Uebrigen, der Grund wieso mir das hauptsaeachlich auf dem Keks geht, ist dass praktisch jedes Mal wenn ich eine neue VICE Version ausprobiere oder zwischen Versionen hin und her wechsle, diese unsaeglichen Violet-Standardpalette und Bildroehre-Streifen wieder aktiv sind.

    Und jedes Mal muss ich den Mist wieder umkonfigurieren.


    Für so einen 'Sonderfall' gibt es doch die Möglichkeit mit dem -config Parameter.

    Ich verstehe wirklich nicht wieso man sowas bemängelt.

    Fuer mich und vermutlich auch fuer viele andere ist der "Sonderfall": Doppelklick auf die EXE oder ein D64/PRG File (bzw. die D64/PRG Datei per Drag & Drop auf VICE ziehen) und gut ist.

    Das es eine Moeglichkeit gibt, den INI Speicherort zu aendern bemaengle ich ja nicht, nur war vorher der Standardort fuer die INI Datei das VICE Verzeichnis, was auch Portabilitaet bedeutete und genau dieses Verhalten wurde irgendwann mal umgedreht.



    Mit solchen Einstellungen ins %userprofile% zu schreiben wird aber genau die Portabilitaet kaputtgemacht.

    Ich hatte das vor langer Zeit mal so umgebaut, dass eine vorhandene vice.ini im aktuellen Verzeichnis bei Programmstart verwendet wird und ansonsten das Systemverzeichnis benutzt wird. Ich weiss allerdings spontan nicht, ob das die archdep-Zusammenführung beim Gtk3-Umzug überstanden hat.

    Du meinst dass das Vorhandensein von einer lokale INI zuerst geprueft wird, bevor ins %USERPROFILE% geschaut wird?

    Muesste das mal ausprobieren. DAS Verhalten waere ja zumindest sinnvoll.

  • Ich hatte das vor langer Zeit mal so umgebaut, dass eine vorhandene vice.ini im aktuellen Verzeichnis bei Programmstart verwendet wird und ansonsten das Systemverzeichnis benutzt wird. Ich weiss allerdings spontan nicht, ob das die archdep-Zusammenführung beim Gtk3-Umzug überstanden hat.

    Eben spasseshalber mal probiert mit dem letzten GTK3 Testbuild von "dqh_" und scheint damit leider bislang nicht zu klappen, da wird ein ini-File im Ordner dann nicht genommen. Kommt hoffentlich aber auch dort noch, denn das ist die beste Lösung so, weil sie beides ermöglicht, je nach Wunsch des Users.


    Uebrigen, der Grund wieso mir das hauptsaeachlich auf dem Keks geht, ist dass praktisch jedes Mal wenn ich eine neue VICE Version ausprobiere oder zwischen Versionen hin und her wechsle, diese unsaeglichen Violet-Standardpalette und Bildroehre-Streifen wieder aktiv sind.

    Und jedes Mal muss ich den Mist wieder umkonfigurieren.

    Meinst du jetzt die nativen WinVICE Versionen? Bei denen funktionierte es ja schon länger auf die Art, welche ich im Eintrag #8 beschrieben hatte. Einfach nur das ini in den Ordner des Emus mit reinkopieren, dann nimmt er dieses, wie auch "Unseen" schrieb.

  • Deswegen werden diese Userprofile auch getrennt, die bei JEDEM user natürlich inneralb 'sein' Datenbereich auf der Platte ist, und das ist nun mal auf Windosen => %userprofil%\AppData\Roaming\vice

    Nein, MS fährt da aktuell selbst zweigleisig. Wenn ich in meinem aktuellen Projekt Konfigurationsdaten einfplege, dann werden die automatisch im Verzeichnis abgelegt wo auch die Exe vom Programm liegt.

    Das ist doch was ich vorhin sagte: Unart aus DOS-Zeiten.

    Windows wird langsam (viel zu langsam) ein echtes multitasking/multiuser OS.

    Die brauchen noch 'ne Weile bis die das im Griff haben.


    Könnte aber auch sein das DU als Entwickler vergessen hast zu sagen wo du deine Konfiguration haben möchtest.

    Wenn dein Proggy nix sagt, dann kann Windows nur Raten & dann schlägt halt die DOS-Unart zu.

  • Tja, es ist nun mal so das cfg-Dateien (ini-dateien) gar nichts in Verzeichnisse von ausführbare Dateien zu suchen haben.

    Das ist eine Unart die noch aus DOS-Zeiten hängengeblieben ist. Remember: DOS = Single-User OS, da gab es keine 'Userprofile'.

    In Multi-User OSes (wie das 'moderne' Windows) gehören nämlich die User Vorlieben (configs) der einzelne Usern nun mal in ein dafür dediziertes cfg-Verzeichnis, denn jeder User hat möglicherweise andere Vorlieben.

    Deswegen werden diese Userprofile auch getrennt, die bei JEDEM user natürlich inneralb 'sein' Datenbereich auf der Platte ist, und das ist nun mal auf Windosen => %userprofil%\AppData\Roaming\vice

    Klar, weil ja auch 95% der Leute ein Multi-User-System haben wo viele verschiedene User Vice benutzen und natürlich jeder eine andere Konfiguration haben möchte. :D

    In der Praxis ist es doch eher so, dass auf dem System genau ein User arbeitet, dafür aber mit mehreren unterschiedliche Vice-Versioen.


    Die "reine Lehre" geht eben oft an den Bedürfnissen der User vorbei. Man kann da auch einfach mal mit dem gesunden Menschenverstand rangehen und nicht wie unter Linux die User ständig versuchen zu gängeln.

  • Die "reine Lehre" geht eben oft an den Bedürfnissen der User vorbei.

    Exakt. Die tatsächliche "Unart" ist es, Portabilität abzubauen oder zu entfernen. Optionalität, Nützlichkeit und Wunsch des individuellen mündigen Users ist in jedem Fall einer Ideologie der Sorte "das System will es aber so" vorzuziehen. Andere Programme bauen Portabilität auch extra (wieder) ein, VLC z.B. hat nach Veröffentlichung der V3 die Option eingeführt, dass zunächst ein Unterverzeichnis namens "portable" im Programmverzeichnis gesucht wird, dass bei Vorhandensein für alle user files verwendet wird, und wenn nicht dann eben nicht. Sowas ist optimal.

    ch hatte das vor langer Zeit mal so umgebaut, dass eine vorhandene vice.ini im aktuellen Verzeichnis bei Programmstart verwendet wird und ansonsten das Systemverzeichnis benutzt wird. Ich weiss allerdings spontan nicht, ob das die archdep-Zusammenführung beim Gtk3-Umzug überstanden hat.

    Ich fürchte nicht.

  • Sehe ich ähnlich. Solche Tools, wie Emulatoren numal sind, gehören portabel verwaltbar. Für etwas anderes gibt es überhaupt keine plausible Erklärung. Wirklich ein Unart, die leider bei vielen Programmen so vorkommt. Ich meine, wer sucht denn z.B. seine Emulator Save States tief verschachelt in der Windows Ebene? Selbst PC Spiele machen diesen Unsinn.


    Die config ini gehört auch direkt in exe Verzeichnis eines Emulators, zumindestens sollte es auf so konfigurierbar sein.

  • Sehe ich ähnlich. Solche Tools, wie Emulatoren numal sind, gehören portabel verwaltbar. Für etwas anderes gibt es überhaupt keine plausible Erklärung. Wirklich ein Unart, die leider bei vielen Programmen so vorkommt. Ich meine, wer sucht denn z.B. seine Emulator Save States tief verschachelt in der Windows Ebene? Selbst PC Spiele machen diesen Unsinn.


    Die config ini gehört auch direkt in exe Verzeichnis eines Emulators, zumindestens sollte es auf so konfigurierbar sein.

    Das liegt wohl daran daß ihr das Konzept des Multi-Users OS nicht versteht.

    Spielekonsolen dagegen sind Single-User Systeme.

    Windows versucht beides zu sein: Ein MultiuserOS UND ein SpieleOS.

    Und wie das so mit eierlegende Wollmilchsäue so ist: sie können ein bisschen alles, aber nichts davon so richtig wie es sich gehört.

  • Ich muss auch nicht alles verstehen auf dieser Welt, wohl aber den Use-Case aus Benutzersicht, der hier wohl ignoriert wird.

    Das hat für mich ehrlich gesagt auch nichts mit der Wahl des Betriebssystems zu tun, welches Du hier zum Anlass für Seitenhiebe auf Windows nimmst.


    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.