Könnten wir bitte zum Thema zurückkehren.

Ich frage mich einfach, warum man bei MS derartig idiotische Entscheidungen triff. Oder bauen die absichtlich "Stolpersteine" ein, um möglichst viele Benutzer zum Upgrade aller möglichen Programme zu zwingen ?

Nach einem Upgrade ist das dann weg?:confused:

Es gibt unzählige 16-bit Software-Lösungen, die seit vielen Jahren problemlos im Einsatz sind.
Vor allem bei Individual-Lösungen sind die Kosten eines Upgrades oft erheblich, das kostet oft viele tausend, wenn nicht gar Zehntausende Euro, alles auf eine neue Version zu bringen.

Ich frage mich nur, warum MS solche Gemeinheiten einbaut, anstatt sich um maximale Kompatibilität zu bemühen.
Damit ist doch MS erst groß geworden, also was solls.
Aber vielleicht ist das als Quasi Monopolist nicht mehr nötig, und da ändert sich dann die Strategie in Richtung "wir bestimmen was gemacht wird".

Sicher, erst wenn du alle Programme auf 64-bit bringst, macht die 64-Bit-Umgebung wirklich Sinn.

die frage ist eher - wer will eine 16bit anwendung ernsthaft native auf einem modernen 64bit desktop betreiben? ich kann deinen bedenken durchaus nachvollziehen. ich selbst betreue noch viele alte 16bit anwendungen. aber das zeug lasse ich gleich auf den alten rechner laufen. auf einem neuen gerät fehlt so ziehmlich alles was so eine alte anwendung manchmal braucht (isa port,..).

die übernahme auf ein aktuelles system wäre das selbe wie wenn ich in ein 60 jahre altes auto einen modernen motor einbauen möchte. gerade hier ist aber eine ssd recht praktisch, da geht dann erst recht die post ab. leider sind entsprechende pata platten sündhaft teuer (300 euro für 2gb, dafür läufts bis 120grad :D )




genau das haben sie ja gemacht? die von dir beschriebenen probleme waren zu xp zeiten noch aktuell und mögen dort auch noch gelten. wie gesagt, such mal nach "virtual store".



warum, du kannst heute ja problemlos mischen? warum sollte ich wegen irgend einem 32bit programm mich heute noch mit lächerlichen begrenzungen herumschlagen?

Letztendlich gehts mir nur darum, daß ich nicht verstehe, warum man solche sinnlosen Komplikationen einbaut.
c:\programs hätte doch auch gereicht ?
Wozu deratige lange Pfade aufbauen ?
Nur damit man zeigen kann, daß mans kann ?

Man hat leider nicht immer die Möglichkeit auf dem alten System zu bleiben, weil man nicht mehrere Rechner auf dem Arbeitsplatz stehen lassen will.
Und manchmal segnen manche Pcs auch einfach das Zeitliche.

1. weil es wurscht ist (siehe oben)
2. eine 16bit anwendung würde den pfad eh nicht finden
3. weil es ~30 andere bezeichnungen für %program files% gibt (zb "programme")

deine "sorgen" sind für das veraltete xp noch gültig, nicht aber bei vista/7. dort ist es egal ob c:\programme, program files, program files (x64),...

die app sieht das was sie sehen "will". also genau die lösung für dein angesprochenes problem.

Weißt du das in diesem Zusammenhang interessant ist ?
Mit Win Vista und Win7 ist man offensichtlich wieder ein bißchen schlauer geworden und hat sich den Unsinn mit der Übersetzung der Pfadnamen in verschiedene Sprachen wieder abgewöhnt.
Dem Benutzer wird zwar z.b. im deutschen Windows Programme angezeigt, aber der reale Pfad heißt dann doch wieder Program Files.
Wenn sie gleich auf Programs gegangen wären, wäre das optimal.
Zumindest ich sehe nicht den Nutzen von unnütz aufgeblasenen Pfaden.

Das ist falsch formuliert. Die Übersetzung hat es bei Windows immer gegeben und wurde erst durch Vista abgeschafft, indem man virtuelle Pfadbezeichnungen einführte. So kann jetzt der eigentliche Name bei allen Sprachversionen gleich bleiben, während ein übersetzter angezeigt wird.


In der englischen Version heißt es seit Windows 95 "Program Files" (und im Verzeichnis eines Programmes gibt es oft viel mehr als nur "Programme", womit "Programs" eine sehr unpräzise Bezeichnung wäre). MS hat also nur Kontinuität gewahrt. Passt auch wieder nicht. Aber wenn sie eine Kleinigkeit ändern, finden sich auch sofort ein paar Meckerer, egal wieviel oder besser wie wenig Einsicht in die Materie sie haben.

:hallo: