Windows Vista

[binchen72]

Nun, mit neuem Rechner kam auch neues Vista. Nachdem ich das erstmal wieder auf ein reines Betriebssystem reduziert hatte, stellen sich mir 2 Fragen:

Wie werde ich diesen merkwürdigen lokaliserten Dateinnamenmurks wieder los?

Und wie sieht das denn nun mit W7 aus? Kriege ich da eine reine Vollversion, oder ist das nur ein Update von Vista auf W7? Dann würde ich mir die 20 Euro nämlich sparen, im Fall des Falles will ich ja nicht wieder von der OEM DVD ein verseuchtes Vista installieren, um dann daraus ein W7 zu machen.

[Anthea]

Normaler lässt sich doch seit WinXP ein "Update" auch separat installieren, sofern man nachweist (z.B. durch vorhandene DVD), dass man Updateberechtigt ist.

[binchen72]

Stellt sich dann weiter die Frage, 32 oder 64 bit? Kann die 32 bit Version nun 4GB nutzen oder nicht? XP kann von 4 GB ja nur etwas mehr als 3 GB nutzen.

[Anthea]

Ach ja, auf der Microsoft-Seite zu Win7:
http://store.microsoft.com/microsoft/Wi ... ature_win7

* Currently running Windows Vista
* Customers with Windows Vista can purchase Windows 7 Upgrade versions. You can do a clean install (back up your files, clean install, and then reinstall your applications) or an in-place upgrade (Windows 7 installs over Windows Vista).

Die 32Bit-Variante hat wohl angeblich immer noch die 4GB-Beschränkung, aber außer bei der Win7Home-Basic Variante ist ja überall 32 und 64 Bit dabei. Und die 64Bit-Variante hat halt, wie Vista auch, gewisse Probleme mit der Treibervielfalt, Du kriegst eben noch nicht für alle Hardware den passenden 64Bit-Treiber. Und 32Bit-Programme, die ja nach wie vor die Mehrheit der Programme bilden, laufen halt unter 64Bit nur in der Emulation und somit etwas langsamer (aber Du hast ja einen schnelleren Rechner )

[binchen72]

Hmm bei der Upgradebestellung muss ich auswählen ob ich ein 32er oder ein 64er W7 haben möchte. Die einzige Hardware die ich an die Kiste dran hängen will sind eine DV Kamera und ein Scanner. Naja, der Scanner hat auch einen Drucker eingebaut.

Vielleicht sollte ich mir doch ein 32/64 W7 Homebasic kaufen, mehr Geld als das kostet wollte ich aber nicht ausgeben.

[Stefan Heße]

Hallo

Folgende Antworten habe ich auf Deine Fragen:

1. Wie werde ich diesen merkwürdigen lokaliserten Dateinnamenmurks wieder los?
Gar nicht, da er bedingt durch die Sprachneutralität mit Windows Vista erst eingeführt wurde. Die Ordner sind jetzt eben nicht mehr lokalisiert wie früher (z.B. Programme anstatt Program Files), sondern werden in der GUI nur so angezeigt. Ich empfinde das als Verbesserung und nicht als "Murks". Was stört Dich daran?

2. Clean Install bei Update DVD
Diese Frage wurde Dir schon von Anthea beantwortet.

3. 32 oder 64 Bit
Eine Erklärung, warum ein 32 Bit Betriebssystem nicht mehr als ca. 3GB Arbeitsspeicher nutzen kann findest Du hier. Das hat also nix mit XP, Vista oder Windows 7 zu tun, sondern ist eine Limitierung der PC-Architektur. Wenn Du also 4GB oder mehr Speicher in Deinem Rechner hast (was ich bei einer DV-Kamera und dem sicherlich von Dir betriebenen Videoschnitt auch empfehlen würde), dann kommst Du wohl um 64 Bit nicht drum herum.
Inzwischen haben jedoch fast alle Hersteller auch 64 Bit Treiber im Angebot. Topfield ist da leider eine der wenigen Ausnahmen.
Auch die langsam laufenden 32 Bit Applikationen sind ein Mythos. Das galt nur für die damals unter dem Itanium laufende Emulation. Bei einem modernen x64 Prozessor merkst Du keinen Unterschied.
Falls Du ganz sicher gehen willst und testen willst, ob mit dem 64 Bit Windows 7 bei Dir alles läuft kannst Du Dir unter der Adresse http://technet.microsoft.com/de-de/eval ... ID=wtcfeed eine Testversion herunterladen, die 90 Tage gültig ist.
Die angebotene Windows 7 Enterprise Testversion ist die RTM.

Gruß,
Stefan

[Anthea]

Bei Win7 sollte die Emulation aber abhängig von der Version sein. In der Pro-Version ist ja die "Inline-Virtualisierung" mit drin, auch extra für XP, die angeblich deutlich höhere Stabilität, Geschwindigkeit und Kompatibilität zu älteren Programmen mit sich bringt. In der Home-Version läuft angeblich noch der alte Emulator.

[Stefan Heße]

Wenn Du mit "Emulation" den Windows XP-Mode meinst, der ist bei den Varianten Professional, Enterprise und Ultimate mit "dabei". In Wirklichkeit muss man den nachinstallieren, aber er läuft halt aus Lizenzgründen nur unter den 3 "großen" Lizenzen. Windows Virtual PC läuft meines Wissens auch unter Home Premium. Siehe http://windows.microsoft.com/de-DE/wind ... e-editions bzw. http://windows.microsoft.com/de-DE/wind ... ws-xp-mode.
Der Virtual PC ist aber eigentlich nicht dazu gedacht, um 32 Bit Applikationen laufen zu lassen, sondern um Applikationen laufen zu lassen, die nicht unter Windows 7 laufen, weil sie falsch programmiert wurden. Der Klassiker ist z.B. eine Setup-Routine, die abfragt, ob sie unter Windows XP aufgerufen wurde und nicht korrekterweise, ob Sie unter einer Version mindestens Windows XP oder neuer aufgrufen wurde. Solche Apps kann man dann entweder mit Shims austricksen (so würde es der Profi machen) oder man kann sie auch in der virtuellen XP Umgebung laufen lassen.
32 Bit Anwendungen laufen auch ohne Virtual PC auf einem 64 Bit Betriebssystem wie Windows Vista oder 7 x64.
Nur uralte 16 Bit Applikationen (also alle DOS-Anwendungen) laufen nicht mehr unter 64 Bit.

Gruß,
Stefan

[binchen72]

Hallo Stefan,

danke für deine Antworten. Zu den lokalisierten Dateinamen: Anscheinend haben da einige Applikationen eigene Dateidialoge, wo dann die Dateinamen angezeigt werden. Im Explorer sehe ich aber die lokalisierten Dateinamen. Das hat mit zu Anfang schon etwas Kopfzerbrechen bereitet.

Was ist denn dran an dem Einwand, das man eine Datei names Virus.exe über den Mechanismus der lokalisierten Dateinamen den Namen eines JPG Bildes überstülpen kann, sprich, es wird nicht nur der Name, sondern auch die Extension "lokalisert". Wenn ich mir das richtig angelesen habe, geht das nicht nur auf Ebene der Ressourcen IDs, sondern auch über ganz beliebige Konstanten in der Desktop.ini.

Code: Alles auswählen

[LocalizedFileNames]
virus.exe=Urlaub in Marbella.jpg

Ist da was dran?

Und ehrlich gesagt habe ich euch beide bzgl des Upgrades noch immer nicht verstanden. Gibt es nun eine W7 Version, die ich *nur* auf eine bestehende Vista Version installieren kann oder kann ich Vista platt machen und W7 ganz von vorne installieren. Das wäre mir nämlich am liebsten.

Da ich mich beim Upgradeprozess aber eh entscheiden muss ob ich eine 32bit Version oder 64bit Version haben möchte, werde ich wohl doch die 32/64er Version kaufen. Ich dachte, Vista32 würde von 4 GB mehr nutzen können als XP, der Processmonitor von Sysinternals zeigt zumindest 4 GB an.

[Anthea]

Hey, ich find bestimmt noch irgendwo nen 16-Bit-Windows-3.0-Programm Das ist nur beinahe DOS...

Ich dachte, die VPC-Lösung würde auch für die verbesserte 32-Bit-Kompatibilität eingesetzt, irgend ein Papier hatte ich so verstanden, aber ausprobiert hab ich das Win7 trotzdem noch nicht (MSDN machts möglich), da der Win7-Treiber für unsere eigene Hardware noch nicht 100% stabil läuft. Vista hatten wir ignoriert, und unsere Kunden auch, daher war das bisher kein Problem

[Anthea]

Und ehrlich gesagt habe ich euch beide bzgl des Upgrades noch immer nicht verstanden. Gibt es nun eine W7 Version, die ich *nur* auf eine bestehende Vista Version installieren kann oder kann ich Vista platt machen und W7 ganz von vorne installieren. Das wäre mir nämlich am liebsten.

Also noch mal deutlicher was ich schon schreibselte:

Ach ja, auf der Microsoft-Seite zu Win7:
http://store.microsoft.com/microsoft/Wi ... ature_win7

* Currently running Windows Vista
* Customers with Windows Vista can purchase Windows 7 Upgrade versions. You can do a clean install (back up your files, clean install, and then reinstall your applications) or an in-place upgrade (Windows 7 installs over Windows Vista).

Oder auch: Egal was Du für ein Upgrade kaufst, Du hast beim Wechsel von Vista die Wahl, ob Du drüberinstallierst oder alles plättest und neu installierst. Beim Wechsel von XP hingegen muss man komplett neu installieren.

[Stefan Heße]

Und noch einmal in meinen Worten:

1. Inplace-Update ("Drüberinstallieren") geht nur von Vista SP1 oder SP2 auf Windows 7, nur innerhalb der Prozessorarchitektur, also x86 --> x86 und x64 --> x64 und nur auf eine gleiche oder größere Version (also z.B. nicht von Vista Ultimate auf 7 Home Premium).
2. Update von Windows XP auf Windows 7, von einer Prozessorarchitektur auf die andere und auf eine kleinere Version geht nur über den Easy Transfer Agent und komplette Neuinstallation.
3. Du kannst einen Windows 7 Update-Datenträger auch für eine Neuinstallation nutzen.
4. Eine Sicherheitslücke mit dem angegebenen [LocalizedFileNames] Parameter kenne ich nicht. Ich konnte das Problem eben bei mir auf meinem Windows 7 x64 nicht reproduzieren.

Gruß,
Stefan

[binchen72]

3 war das was ich wissen wollte, merci

4 klingt wieder interessant, ob da jemand Unisnn erzählt hat was sich nun ohne Überprüfung wieder durchs Netz frisst? Ich fand das ziemlich hanebüchen und wäre schon erstaunt gewesen, wenn dem wirklich so wäre...

[hagge]

1. Wie werde ich diesen merkwürdigen lokaliserten Dateinnamenmurks wieder los?
Gar nicht, da er bedingt durch die Sprachneutralität mit Windows Vista erst eingeführt wurde. Die Ordner sind jetzt eben nicht mehr lokalisiert wie früher (z.B. Programme anstatt Program Files), sondern werden in der GUI nur so angezeigt. Ich empfinde das als Verbesserung und nicht als "Murks". Was stört Dich daran?

Hier kann ich mich nicht bremsen und muss mal wieder loswerden, dass das eigentlich kompletter Blödsinn ist. Eine Datei heißt so, wie die Datei heißt. Da gibt es keinen, aber auch wirklich keinen Grund, die anders erscheinen zu lassen, als sie auf der Platte heißt. Alles andere verwirrt nur, weil mal der eine und mal der andere Name auftaucht. Ich hasse es schon, wenn die Extension unterdrückt wird und schalte deren Anzeige sofort auf jedem Windows-Rechner ein, an den ich komme.

Was ich zum Beispiel regelmäßig sehe: Ein Installer fragt mich, wohin ich das Programm installieren möchte und schlägt mir "Program Files" vor. Ich bin entsetzt, waren das doch die Fehler der Installer zu den alten Win95-Zeiten, als die amerikanischen Softwareentwickler noch nichts von lokalisierten Verzeichnissen in anderen Ländern gehört hatten. Also klicke ich schnell auf den Button daneben, es geht ein Fileselector auf und da finde ich den Ordner "Programme". Genau dahin will ich installieren, also wähle ich diesen aus und schließe den Fileselector. Aber anschließend steht wieder "Program Files" im Installer. Das ist doch komplett irritierend. Das kann mir keiner weismachen, dass das nun schlüssiger ist als früher in XP, wo in beiden Fällen eben "Programme" da stand.

Welchen Vorteil hat es denn, dass der Name intern als "Program Files" geführt wird? Doch eigentlich gar keinen.

Ich sehe an diesem Beispiel nur neue Verwirrung und die Tatsache, dass ein an sich völlig einfacher Sachverhalt (eine Datei hat einen eindeutigen Namen) mal wieder komplizierter als notwendig gemacht wird (eine Datei hat auf einmal mehrere Namen).

Das mit dem Unterjubeln von anscheinend harmlosen Namen ist gar nicht so weit hergeholt. Denn die "Lokalisierung" läuft über einen Mechanismus, der es sehr wohl erlaubt, z.B. eine exe-Datei als ein JPG-Bild erscheinen zu lassen. Wird dieses angeklickt, dann wird eben die Malware ausgeführt. Das ist auch alles andere als sicher.

Gruß,

Hagge

[binchen72]

Welchen Vorteil hat es denn, dass der Name intern als "Program Files" geführt wird? Doch eigentlich gar keinen.

Doch, schon. Die Separierung der Texte von den Objekten erleichetert bei der Programmerstellung einiges.

Der Grossteil der deutschen Anwender kann mit Pictures nichts anfangen, da sollte also schon Bilder stehen. Wenn man nun das Objekt vom Text abkoppelt kann man die Lokalisierung getrennt bearbeiten und ruckzuck auch neue erstellen.

Wenn du bei 3PG schaust, da hast du im Quellcode auch nur noch textobjekte mit Ziffern dran, die durch eine Lokalisierungsroutine die eigentlichen Texte aus den lng Dateien holt. So könnte man zB auch ruckzuck eine hessisch babbelende 3PG Version erstellen, ohne das man den Quellcode von 3PG bräuchte.

Was mich daran stört, das es jetzt noch immer Programme gibt, die den Dateinamen nicht durch GetLocalize( ) (oder wie das auch immer heissen mag) jagen und ich deswegen die eigentlichen Texte sehe.

Auch die Implementierung seitens Microsoft, das ganze in der Desktop.ini anzulegen halte ich nicht für sinnvoll. Evtl lösche ich die alle und schau mal was passiert

Das ganze wird sich bei mir aber eh in Luft auflösen, da ich mit win7 eh alles in Englisch installiere und gut ist. Dann wird nur noch mein Acronis deutsch sprechen weil Acronis leider nicht multilanguagefähig ist.

Die Idee an sich ist ja soweit gut, leider habe ich aber doch Bauchschmerzen mit der Implementierung.

Das ganze Prozedere läßt sich hier nachlesen, da habe ich das auch mit dem Urlaubsbild her. Ich werde das am Wochenende mal ausprobieren, ob man eine Exe namentlich als JPG File erscheinen lassen kann.

[hagge]

Doch, schon. Die Separierung der Texte von den Objekten erleichetert bei der Programmerstellung einiges.

Der Grossteil der deutschen Anwender kann mit Pictures nichts anfangen, da sollte also schon Bilder stehen. Wenn man nun das Objekt vom Text abkoppelt kann man die Lokalisierung getrennt bearbeiten und ruckzuck auch neue erstellen.

Da sage ich ja auch gar nichts dagegen. Aber es spricht doch auch nichts dagegen, über die GetLocalize()-Funktion den lokalen Namen zu erfragen und diesen dann als Filename zu benutzen. Diese Abfrage mache ich ein einziges Mal am Anfang des Programms und muss dann nur noch mit diesem einen String arbeiten. Wenn ich aber sowohl den internen Namen für die Datei als auch den sichtbaren Namen für die Textausgaben mitführen muss, dann sind das immer zwei Objekte, die ich habe. Also doppelter Programmieraufwand.

*Und* man hat das Problem der Inkonsistenzen, dass eben doch hier und da die Datei mit ihrem Originalnamen zu sehen ist. Denn spätestens in einem Diskeditor oder File-Recovery-Programm habe ich es dann doch wieder mit den ursprünglichen Namen auf der Platte zu tun. Oder wenn ich von einem ganz anderen System, wie z.B. Linux auf so eine Platte zugreifen will, wo diese ganze Namensumsetzung völlig unbekannt ist.

Es liegt einfach in der Natur der Sache, dass es Inkonsistenzen gibt, wenn ich für ein und dieselbe Sache zwei Namen habe. Ein Name ist schon laut Definition eine "eindeutige Kennung". Und genau hiergegen verstößt Microsoft nun, indem es nämlich mehrere Kennungen für das gleiche Objekt gibt, je nach Sprache nämlich eine.

Das muss einem doch intuitiv klar sein, dass ein Name einer Datei ein Primärschlüssel für die Suche in der Datenbank "Filesystem" ist und den kann man nicht einfach durch etwas anderes ersetzen, ohne Inkonsistenzen zu erzeugen. Das geht immer schief! An irgendeiner Stelle will ich *immer* den Originalnamen haben. Denn wenn ich nirgendwo den Originalnamen bräuchte, dann -- nun dann bräuchte man ihn eben nicht und könnte "Program Files" folglich sowieso komplett weglassen. Ist diesem Gedankengang zu folgen?

Wenn du bei 3PG schaust, da hast du im Quellcode auch nur noch textobjekte mit Ziffern dran, die durch eine Lokalisierungsroutine die eigentlichen Texte aus den lng Dateien holt.

Das widerspricht meiner Auffassung in keinster Weise. Nur läuft auch hier die Umsetzung Nummer nach Name im Programm und nicht mal automatisch (wie beim Aufruf des Fileselectors oder im Windows Explorer) und mal nicht (wie bei der Ausgabe als Text). Auch hier ist das Schema bei Microsoft völlig inkonsistent. Ich verstehe durchaus, was Lokalisierung ist und habe es nun schon auf verschiedenen System gesehen. Aber kein anderes System (Linux, Mac, etc.) hat das so dämlich gelöst wie Microsoft. (Sorry, wenn ich das so krass ausdrücke, aber als genau das empfinde ich diese Umsetzung.)

Gruß,

Hagge

[binchen72]

[quote="hagge"]...Umsetzung...[/quote]

Sag ich doch. Aber es hat ja nicht nur M$ schuld, es gibt ja noch immer genügend Programmierer, die mit fest verdrahtenteten Verzeichnisse arbeiten und noch immer Programmierer, die Programmdaten im Program Files Verzeichnis ablegen (wollen).

[hagge]

Aber es hat ja nicht nur M$ schuld

Hmm, eigentlich doch. Denn es war ein völlig funktionierendes System. Wer hier noch in das falsche Verzeichnis geschrieben hat, war ein ewig gestriger, der Seit Win3.11 nichts mehr dazu gelernt hat. Aber ansonsten war das völlig OK in WinXP: ein Verzeichnis hatte einen Namen, und diesen (lokalisierten) Namen konnte man über Systemfunktionen erfragen und er war eindeutig. Mit Vista hat hier aber Microsoft völlig unnötigerweise ein System eingeführt, das nun zu lauter Inkonsistenzen führt und mehr verwirrt als nützt. Also ist Microsoft schuld.

es gibt ja noch immer genügend Programmierer, die mit fest verdrahtenteten Verzeichnisse arbeiten und noch immer Programmierer, die Programmdaten im Program Files Verzeichnis ablegen (wollen).

Und ich wette, seit Vista gibt es hier wieder deutlich mehr...

Hagge

[binchen72]

Zudem durch die Virtualisierung auch kein Druck mehr zur Änderung besteht, Schreibzugriffe auf program Files werden ja IMHO irgendwo hin umgeleitet und virtualisiert, so dass es nur so aussieht, als ob die Dateien dort liegen.

Nevertheless, wir werden es nicht ändern, meine beiden Hauptapplikationen gibt es in dem von mir gewünschtem Umfang nur für Windows.