mp3DirectCut 2.12 mit Vista/7

[mpesch3]

Mag mal jemand testen, ob sich die nächste Version von mp3DirectCut unter Windows Vista bzw. 7 korrekt verhält? Möglichst jemand, dem die Struktur des Appdata-Ordners geläufig ist.

Knackpunkt ist der Speicherort der Ini-Datei: Wenn das Programm als Administrator installiert aber mit eingeschränkten Rechten benutzt wird, landet die Ini bei den bisherigen Versionen im Ordner "VirtualStore", weil Vista dem Programm vorenthalten hat, dass es keine Schreibrechte im Programmordner hat. mp3DC 2.12 hat jetzt das "Vista-Manifest", mit dem das wieder funktionieren sollte - die Ini landet dann im Ordner "Roaming" unter Appdata. (Die Ordner sind übrigens in der Regel versteckt.)

Mehr noch: mit einem Button unter Settings/Misc sollten sich die Settings aus dem VirtualStore-Verzeichnis importieren und der mp3DC-Ordner unter VirtualStore löschen lassen. Das kann ich aber nicht testen, weil ich XP habe. (Das VirtualStore-Thema wurde auch im Nachbar-Thread für 1by1 schon abgehandelt, nur gibt es für 1by1 diesen Import- und lösch-Button nicht)

Die anderen Neuheiten:
- Unicode support (enable under Settings/Misc)
- Stupid hang on language selection fixed
- Unselectable record base name problem fixed
- Optional slim button layout
- Batch function corrections

[Edit] Release unter http://mpesch3.de1.cc/mp3dc.html

[_db_]

Hi, ich habe es unter Win 7 HP 64 Bit ausprobiert (Admin mit UAC).

Die Ini-datei wird im Roaming-Ordner abgelegt. Der Aufruf des Konfig-Ordners aus den Programmoptionen klappt auch.

Der Import aus dem VirtualStore-Ordner klappte nicht, da der Pfad nicht gefunden wurde.

Vermutlich ein 64-Bit Problem, da der Ordner hier
C:\Users\db\AppData\Local\VirtualStore\Program Files (x86)\mp3DirectCut
heisst.

MP3DC sucht aber C:\Users\db\AppData\Local\VirtualStore\mp3DirectCut

[mpesch3]

Ah, danke. Mit x64 sollte es aber nix zu tun haben, eher damit, dass mp3DC den Programmpfad nicht richtig ausgelesen hat.

Hab oben das Update von heute eingehängt. Jetzt wird der Programmpfad per GetModuleFileName abgefragt. D.h. ob es in "c:\Program Files (x86)" oder "c:\Program Files" steht, müsste egal sein.

[_db_]

Jetzt stimmt der Pfad. Es ist jedoch darauf zu achten, dass mp3DC in einen Ordner "mp3DirectCut " installiert wird. Ich hatte den Ordner "mp3dc212a" genannt und dann sucht das Programm beim Import der Konfiguration aus dem VirtualStore den Ordner ....\Local\VirtualStore\Program Files (x86)\mp3dc212a, den es natürlich nicht gibt.

[mpesch3]

Ja, das ist natürlich ungünstig, wenn das neue Programm in einem anderen Verzeichnis installiert wird. Da weiß ich dann auch keine Lösung. Naja, der Button ist da, und der gute Wille zählt.

[mpesch3]

So, ich habs jetzt nochmal geändert. Der User muss den Virtualstore-Ordner beim Importieren jetzt selber auswählen. Das programm führt ihn nur zum VirtualStore hin - was hoffentlich klappt. Update ist oben.

[mpesch3]

Ok, Final ist draußen. Wenn die sagenhafte Virtualstoreimportierungsundordnerlöschfunktion in den Settings jetzt nicht richtig geht, wirds halt in 2.13 korrigiert.

[WinnieW]

Ich habe mir die neueste Version mal heruntergeladen und wollte diese installieren. Allerdings gab es da ein paar kleine Probleme.

Ich habe die deutsche 64 Bit Version von Windows 7 auf meinem Rechner laufen.
Der Installer möchte das Programm in den Pfad "C:\Program Files (x86)\mp3DirectCut" installieren. Den Pfad "\Program Files (x86)" gibt es bei der deutschen Version von Windows 7 allerdings nicht, in dieser Version lautet der Pfad "\Programme (x86)". Der Installer bricht an dieser Stelle auch die Installation ab wenn ich die Standardvorgaben übernehmen will.

Wenn ich den Pfad manuell ansteuere dann wird das Programm installiert, aber ich habe plötzlich zwei(?) Ordner mit dem Namen "Programme (x86)" auf dem Rechner. Das Programm selber funktioniert, ich finde das trotzdem merkwürdig.

[mpesch3]

Soweit ich weiß, heißt der Programm-Ordner immer "Program Files" - auch wenn in der deutschen Version "Programme" da steht. Der echte Name wird nur per Lokalisierung im Explorer nur überdeckt.

Wenn man also beim Installieren einen echten Ordner "Programme" anlegt, hat man im Explorer zwei. Der Installer hätte mit seinem ersten Vorschlag demnach das richtige Verzeichnis angewählt... Ja, das ist ein hartes Erwachen für Vista-User: die Software liegt in Wirklichkeit in "Program Files".

MS hat es aber dadurch einfacher, weil der Ordner auf der ganzen Welt "Program Files" heißt und nur die Sprachdateien geändert werden müssen - das spart Kosten. Das geht zwar zu Lasten der Transparenz und der Benutzbarkeit, aber der User kann sich wenigstens damit trösten, dass er mit dem Ertragen der zusätzlichen Komplikationen einen Beitrag dazu leistet, dass ein bedeutendes Unternehmen sein Gewinnmanagement noch ein Stückchen weiter optimiert hat.

[_db_]

Richtig, "Programme" ist nur (noch) ein Alias-Name, anders als unter XP und davor. Führe den Installer mit dem Kontextmenü (rechte Maustaste) und "als Administrator ausführen" aus.
Dann geht es. Die Sicherheitsfunktionen in Win7/Vista verhindern je nach System das Anlegen des Programmordners in "Program Files (x86)".

Ich habe es unter Win 7 32Bit/64Bit ohne Probleme laufen.

[WinnieW]

Danke für die Hilfe und Erklärungen.
Das ist der erst Programminstaller - seit ich Windows 7 kenne - der nicht von sich aus nach Administratorechten fragt. Deswegen wohl meine Verwirrung.
Aber nun ist mir die Sache klar.

[Schweini]

Wieso schiebt das Setup nicht UAC an? Dann ists doch klar, dass es mangels Zugriffsrechten nicht in C:\Program Files (x86) zu installieren geht. ME sollte das aber Aufgabe von UAC sein, hier nach Erlaubniss zu fragen.

Kannst Du in dem Setup nicht hier "als Admin ausführen" setzen? Dann müsste es klappen.

[mpesch3]

Der Installer fragt ganz bewusst nicht nach Adminrechten. Grund: mp3DirectCut ist grundsätzlich portable - was sollen da Adminrechte?

Wer das Programm bei Program Files haben möchte, startet es als Admin. Damit verhält sich das ganze exakt wie unter XP. Man kann natürlich dieses requestedExecutionLevel-Ding statt "asInvoker" auf Admin setzen. Aber ich will nicht, dass der Installer Adminrechte einfordert. Software, die das macht, rühre ich persönlich gar nicht an.

Damit bleibt es die Entscheidung des Benutzers, ob er das Program als Admin installieren will oder nicht. Was soll daran falsch sein?

[WinnieW]

[mpesch3]

Stimmt, der Standardpfad und der fehlende Admin-Request passen nicht so ganz zusammen. Ich frage mich nur, warum das bei XP jahrelang funktioniert hat und sich keiner beschwert hat? Haben die alle mit Adminrechten gearbeitet?

Normalerweise ist es doch so: man weiß, dass man als Benutzer mit eingeschränkten Rechten nicht alles darf. Wenn dann ein Installer meldet: "Zugriff verweigert", dann weiß man: aha, da muss man wohl mit Adminrechten ran. Bzw.: wenn man was ins Standard-Programmverzeichnis stellen will, startet man den Installer gleich mit Adminrechten. Microsoft ist es offenbar nicht gelungen, den Usern den Unterschied zwischen Admin und Benutzer klar zu machen. Stattdessen haben die UAC eingeführt.

Einen Hinweis habe ich tatsächlich eben auf die Webseite gestellt. In der nächsten Version könnte auch ein Hinweis in den Begrüßungstext des Installers. Oder ich nehme das "asInvoker" wieder raus. Aber dann beschweren sich die Leute, die kein UAC wollen. Mir erscheint die Invoker-Variante immer noch die sauberere.