[Windows 7] Windows 64 Bit Programme - warum brauch ich die? - u.a. Photoshop 7/CS6

[F.L.X]

Hi,

ich hab mal ne doofe Frage:

Ich hab nun Win 7 64 Bit installiert. [8 GB RAM aber nur ne 250 GB Platte drin und Office und Delphi und Visual2010Epress = Partition schon voller]
Photoshop 7 bekomm ich nicht mehr zum Laufen.
Früehr unter 32 Bit war das kein Problem.

Office 64 Bit soll auch Probleme machen - darum wird sogar von MS und CHip.de empfohlen lieber nur die 32er zu nehmen und (OK, das macht Sinn - nur in Ausnahmefällen, wegen großer Dateien die 64er [Excel Pivot tabellen usw.])

Überhaupt frag ich mich - wozu brauch ich die 64er Versionen unbedingt?!

und - Warum brauch ich von z.B Nirsoft.net die 64 Bit Varianten des Programmes?
OK, SmartSniff das ist systemnah, aber warum braucht man für ebenso systemnahe wie openwithviewoder, mylastSearch - und da sind noch welche - keine 64Bit Version?

daran anknüpfend:
Wenn ich Photoshop CS6 installieren möchte ([legal geliehen] der zwar viel mehr Platz als die 7er beansprucht) - kann ich zwar die 64er alleine, - aber die 32er unter Win64 nur NEBEN/zusätzlich der 64erBit auswählen, aber nicht ohne die 64er.
OK, wer große Bilder bearbeiten möchte, wird auch 64Bit benötigen, damit mehr als 4 GB RAM verwendet werden können - leuchtet mir ein.
64 Bit Version - 500 GB
32 Bit Version wäre ebenfalls nur 500 GB, kann aber nur mit der 64er installiert werden, was dann zusammen schon wieder 1,2 GB ausmacht. WOZU DANN DIE 32er, wenn man die nicht alleine installieren kann? WTF!
Aber wer das nicht braucht - und mit der 32er zufrieden wäre ...?
was soll das? ist das Adobe intene Logik, oder hat das mit 64 Bit generell zu tun.

Zahlreiche 32Bit Programme laufen ja tadellos unter Win64. Selbst 17 Jahre alte Programmschätzchen, wie Paintshop 7 oder 5.

Zugegeben Photoshop 7 hätt ich auch gern weitergenutzt.
Aber nicht mal in den Adobe/Photoshop Foren konnte man mir konkret sagen, woran das liegt, daß der weder installiert, noch falls eine "Portable" Version gestartet werden kann.

Wenn mir da einer weiterhelfen könnte, der davon Ahnung hat [Admins/Programmierer], wäre ich sehr dankbar.

 

[alter_Bekannter]

Sowohl in der Theorie als auch inder Praxis macht es einige Programme erheblich schneller
(ich kenne ein Beispiel von ca 20%) nur dadurch das sie für 64Bit kompiliert wurden.
+Addressraum und Addressen sind halt größer.

Die inkompatiblitäteten von denen du spriuchst komemn zum größten Teil vermutlich nicht mal
daher sondern einfach von Schlampigkeit der Entwickler oder deinem vermurksten System. So
sehen meine Erfahrungen aus der Praxis aus, allerdings kenne ich deine konkrete Situation halt
nicht. Dafür halt bealstbarere Zahlen aus Benchmarks und Supportfällen.

Der einzige konret immer anfallende Nachteil von 64 zu 32 Bit ist die höhere Größe. Die verliert
allerdings wiederum ständig an Relevanz. Ob das Programm jetzt 100 oder 200Kb groß ist juckt
doch heute keinen mehr. Fällt doch neben den gängigen Grafiken im GB Bereich eh keinem mehr auf.

Die reine Executable größe liegt auch heute noch idR bei maximal wenigen MB, der Rest ist Grafik ud Soundgedöns, nicht nur bei Spielen.

Da bleibst halt ganz simpel Executable wird vielleicht paar hundert kb größer = juckt keine Sau
wird dafür aber aber inder Regel auch 10-30% schneller, das widerum interessiert bei neuen lahmen mobil ultra low voltage Dingern.

 

[The_Emperor]

Ich hoffe ich kann das Thema simpel erklären. Also zuerst die Einschränkungen von 32-Bit Software die auf einem 64-Bit (Windows) System ausgeführt wird.

Um eine Software überhaupt auf einem System starten zu können deren Bitness sich vom System unterscheidet braucht man zuerst einen Emulator der 64-Bit Befehle in 32-Bit übersetzen kann. Unter Windows ist dafür der Dienst "Windows on Windows", bzw. durch sein Working Directory besser als SysWOW bekannt zuständig. Alleine durch diese Softwareemulation kommt es schon zu dem ersten Performanceverlust. Zusätzlich dazu kommen noch technische Einschränkungen durch die Emulation was zu einer Begrenzung von 2GB RAM pro Prozess und Unmöglichkeit zur Multicoreskalierung führt. Im Klartext: 32-Bit Software kann auf einem 64-Bit System maximal einen einzigen CPU-Kern und 2GB RAM verwenden.

Dass 64-Bit Software manchmal schlechter auf 64-Bit Systemen funktioniert oder instabil wird hat einen peinlichen Grund der insbesonders bei Microsoft Office x64 zum Vorschein kommt: 64-Bit Software hat andere APIs als 32-Bit Software. Dritthersteller müssen daher ihre veralteten 32-Bit APIs durch aktuelle 64-Bit APIs ersetzen, dann steht einem stabilen System in einer homogenen 64-Bit Umgebung nichts im Wege. Solange dieser Murks aus 32 und 64-Bit Software, bzw. 64-Bit Software mit 32-Bit APIs nicht vollkommen aus dem Markt gedrängt wurde wird sich daran nichts ändern. Hauptschuldige an diesem Dilemma sind Firmen die trotz der Jahreszahl 2015 immer noch an der veralteten 32-Bit Architektur hängen oder sie nicht aufgeben wollen (mein Programm braucht nicht mehr als 4GB RAM...).

Was mich an diesem Thema noch belustigt ist die weit verbreitete Meinung dass man mit 32-Bit Software mehr Leistung hat weil die Programme angeblich doppelt so viel Speicher benötigen. Das mag zwar am Papier stimmen, aber wer sich ansieht wie sich die Cachegrößen der Prozessoren seit dem Durchsetzen von 64-Bit entwickelt haben wird schnell merken wie lächerlich diese Meinung im Angesicht des technischen Fortschrittes der Hardware ist.

 

[CroneKorkN]

Wobei sich nur die Adressdaten verdoppeln, nicht die eigentlichen Nutzdaten. Der Speicherverbrauch ist folglich in der Praxis bei weitem nicht doppelt so hoch.

was soll das? ist das Adobe intene Logik, oder hat das mit 64 Bit generell zu tun.

Also nein, ist kein strukturelles Problem, sondern Ignoranz der Softwarehersteller.

 

[alter_Bekannter]

Fragt sich nur wie viel % der schuld bei wem liegen.

Viele Entwickler haben nohc das Problem das viele Kunden sich noch heftig an Systeme
klammern für die es längst von Herstellerseite keinen Support mehr gibt oder der Hersteller
einfach so nichts mehr tut.

In anderen Worten:
Wer noch Windows XP oder älter benutz ist Teil des Problems.

Dazu kommt dann noch die Verwaltung von Softwareabhängigkeiten unter Windows:
Jeder bringt alle seine Bibliotheken zack Durchrotz Paket mit und kümmert sich einen
Scheiss um Kompatiblität oder Versionierung. Was dazu führt das zusätzlich auch
keine Sau mehr weiss was jetzt mit was noch kompatibel ist, was noch weiter dafür
sorgt das jeder mehr Scheisse dabei packt und sich nur an seinem Stand der Bibliotheken orientiert.

Ein Teufelskreis aus Workarounds und Deadlines => das Kernproblem kommerzieller Softwareentwicklung

 

[The_Emperor]

Das Problem mit den verschiedenen Bibliotheken hat Microsoft den Softwareherstellern schon abgenommen, siehe WinSXS. Auch wieder ein Problem das durch die Inkompetenz der Softwarehersteller verursacht wurde und von Microsoft gelöst wurde.

 

[alter_Bekannter]

In wie fern löst das irgendwelche Probleme mit Abhängigkeiten?

"Stable" Patches werden außerdem generell erst mit Windows 10 eingeführt. Bislang ist das gesamte Updateverhalten mehr
so eine Art Open Beta. Erklär mir mal wie das mit der Unfähigkeit der Entwickler zu tun hat. Erst recht bei so Dinger wie "macht
bekanntermaßen Probleme mit allen AMD Karten" Frage ich mich was da bei Microsoft schiefgelaufen ist. Die sollten jawohl ein
AMD System zum testen haben so klein sind die nicht.

Gerade IE und WMP sind riesige Problemherde.

 

[The_Emperor]

Abhängigkeiten von bestimmten Dateiversionen werden unter Windows durch SideBySide umgangen. Wenn drei verschiedene Programme von der gleichen Runtime drei verschiedene Versionen benötigen kann Windows diese gleichzeitig anbieten.

 

[kaliva]

also ich hab auch relativ häufig das Problem, daß 32 Bit Programme, v.a auch 16 Bit DOS Programme unter Win64 nicht mehr laufen.

Echt ne Seuche. Die hätten den 16 Bit Emulator ruhig noch weinter drinlassen können.

 

[The_Emperor]

Abwärtskompatibilität zu veralteten Programmen ist eines der Hauptprobleme von Windows und deshalb wird Windows nie wegweisend sein was moderne Betriebssysteme anbelangt. Hat mich im negativen Sinne überrascht dass von Windows 8 überhaupt noch eine 32-Bit Version auf den Markt kommt. Firmen die es bis heute nicht in das Jahr 2015 geschafft haben sollten sich intensiv mit Virtualisierung auseinandersetzen.

 

[musv]

Hat mich im negativen Sinne überrascht dass von Windows 8 überhaupt noch eine 32-Bit Version auf den Markt kommt. Firmen die es bis heute nicht in das Jahr 2015 geschafft haben sollten sich intensiv mit Virtualisierung auseinandersetzen.

Ich arbeite in einer Softwarefirma. Das Produkt hier ist eine über 20 Jahre alte Software. Entsprechend chaotisch ist die Code-Struktur. Ein paar Komponenten davon sind:

• C/C++ 64bit
• C/C++ 32bit
• C# / .NET
• VB Classic

Natürlich könnte/sollte/müsste das mal alles in Ordnung gebracht werden. Immerhin hat mein Chef schon mal akzeptiert, dass das VB-Classic-Zeug nur noch Probleme macht.

Aber dann kommt wieder die Entscheidungsfrage, ob halt jetzt ein ganz tolles neues Feature eingebaut werden soll, oder ob … Nee, eigentlich kommt nur die Entscheidungsfrage, welches neue tolle Feature eingebaut werden soll. Und damit bleiben dann sogar auch noch die Codeteile, die für die Unterscheidung zwischen 16bit- und 32bit-Windows zuständig sind/waren, im Code enthalten.

Der nächste Punkt ist aber auch, dass alter Code getestet ist. Baut man jetzt alten Code um, um den z.B. auf 64bit, andere Libs, in wartbare Strukturen umzuwandeln, muss der auch wieder von Anfang an getestet werden.

Bei Open Source funktioniert das. Bei Closed-Source-Herstellern ist das jedoch Aufwand, dem kein Einkommen gegenüber steht. Und entsprechend werden dafür auch keine Ressourcen geopfert. Das geht dann zwangsläufig so weit, dass irgendwann mal bestimmte Teile einfach nur noch unwartbar werden. Und wenn halt eine verwendete Komponente so unwartbar geworden ist, dass niemand mehr damit was anfangen kann, wird halt ein Spezialist teuer eingekauft, der es doch kann. Nicht umsonst werden Cobol- und Fortran-Entwickler gesucht, die weit überdurchschnittlich bezahlt werden (müssen).