Warum kann Windows 9x-Software unter Windows 7 64-Bit ausgeführt werden?

791
Ed999

Ich habe viele Jahre lang (lange nach der Einführung von Windows XP) eine Sammlung alter Windows 9x-Desktop-PCs ausgeführt. Grundsätzlich waren diese Maschinen in ihrer Hardware zu niedrig, um auf XP aufgerüstet zu werden (und hatten eine Menge Geld gekostet). Daher verwendete ich sie weiterhin mit ihrer Originalsoftware: Verschiedene Installationen von Windows 98SE und Windows ME (alle laufen) als 32-Bit-Version).

In dem Fall habe ich nie XP benutzt. Die Win9x-Maschinen waren so zuverlässig, dass sie noch lange nach XP und Vista funktionierten. Irgendwann musste ich jedoch auf Windows 7 64-Bit migrieren.

Ich bin nicht im Begriff, etwas wirklich Dummes zu tun, etwa die Frage, warum ein solches Programm nicht unter Win7 64bit laufen kann! :-)

Ausnahmslos funktionierte die gesamte Software, die ich unter 32-Bit-Windows 98SE ausgeführt hatte, sozusagen auf der NT-64-Bit-Architektur von Win7. Heute verwende ich immer noch eine Vielzahl dieser Software, insbesondere die Textverarbeitungsprogramme und HTML-Editoren, die ich routinemäßig verwende.

Gibt es einen technischen Grund, warum ich nie die Schwierigkeiten hatte, die ich beim Ausführen von Windows 9x-Programmen unter 64-Bit-NT erwartet hatte? Ich wurde über die Einstellungen für die Kompatibilität unter Win7 informiert, habe aber noch nie ein Programm im Kompatibilitätsmodus ausgeführt.

Mir ist bekannt, dass Windows 7 32-Bit- und 64-Bit-Software an unterschiedlichen Orten aufbewahrt und unterschiedlich behandelt: Ich hatte jedoch erwartet, dass dies mit 32-Bit- und 64-Bit-Programmen zusammenhängt, die für Windows 7 geschrieben wurden.

Ich bin überrascht, dass Windows 98 32-Bit-Programme mit den Windows XP / Vista / 7-32-Bit-Programmen vollständig kompatibel zu sein scheinen, und ich würde gerne wissen, warum dies so ist. Gibt es wirklich keinen Unterschied zwischen ihnen?

Auch viele der alten Windows 9x-Programme waren / sind portabel. Ich habe mich angewöhnt, sie auf USB-Sticks oder auf den Windows 7-Desktop zu legen und sie einfach auszuführen. Ich habe keine Probleme erfahren. Obwohl sie nicht aus einem Ordner Programme ausgeführt werden. Ich möchte noch einmal verstehen, warum der Betrieb dies aus technischer Sicht nicht beanstandet.

Mache ich etwas Unsicheres? Das Windows 7 O / S scheint sehr stabil zu sein: Ich würde aber gerne wissen, ob ich es frage, Dinge zu tun, die ich nicht tun sollte.

-1

2 Antworten auf die Frage

3
Community

Sie müssen der erste Benutzer sein, der sich beschwert, weil er keinerlei Probleme hat. ;)

Während die Mainstream-Medien viel Zeit in Anspruch genommen haben, um Windows einen unverdienten Ruf im App-Kompatibilitätsbereich zu verleihen, hat Microsoft sehr viel in die Abwärtskompatibilität investiert und die überwiegende Mehrheit der für Windows 98 geschriebenen Apps ist weiterhin unter Windows 7 einsetzbar. Plus Windows 7 ist das stabilste Betriebssystem, das Microsoft jemals entwickelt hat. Machen Sie keine Fehler, der Unterschied zwischen Windows 7 und Windows 98 ist enorm, aber:

  • Windows 98 nutzte eine reichhaltige Windows-API, die Microsoft nicht einfach umschrieben hat, nur weil! Beispielsweise ist die Oberfläche zum Zeichnen eines Rechtecks ​​auf dem Bildschirm, zum Erstellen eines Fensters oder Anzeigen einer Menüleiste immer noch gleich.
  • Windows 7 hat Maßnahmen implementiert, um die Kompatibilitätsprobleme der Altsoftware zu beheben. Eine davon ist die UAC-Virtualisierung. Windows 98-Apps haben ihre App-Daten in ihren Installationsordner geschrieben. Windows 7 erlaubt das nicht mehr; Bei älteren Apps leitet UAC Virtualization den Datenschreibvorgang jedoch außerhalb des App-Installationsordners um %LOCALAPPDATA%\VirtualStore.

Windows 98-Ära-Apps, die nicht mehr unter Windows 7 funktionieren, umfassen 16-Bit-Apps (die nicht unter 64-Bit-Windows, aber manchmal auch unter 32-Bit-Windows ausgeführt werden) und Apps, die entweder auf Hacks oder geheimnisvollen älteren Betriebssystemdiensten basieren.

tldr: Sie behielten die API- und ABI-Kompatibilität bei;) Journeyman Geek vor 7 Jahren 1
... und implementierte Kompatibilitätsmaßnahmen wie UAC-Virtualisierung vor 7 Jahren 0
@FleetCommand: Ich habe% LOCALAPPDATA% \ VirtualStore geöffnet und der Ordner ist seltsamerweise leer. Das übergeordnete Verzeichnis enthält eine Menge Einträge,% LOCALAPPDATA%, aber zilch in \ VirtualStore. Übrigens war ich völlig genau, als ich auf die Verwendung der 32-Bit-Win9x-Software verwies. Ich habe längst alle verbliebenen 16-Bit-Programme aufgegeben. Ed999 vor 7 Jahren 0
Die fehlende 16-Bit-Unterstützung hat mit der Entscheidung von Intel zu tun, wie der lange Modus funktioniert und wie die Unterstützung für die Anweisungen deaktiviert wird, die 16-Bit-Anwendungen benötigen, wenn der lange Modus aktiviert ist. Was mir klar ist, ist eine zufällige Tatsache Ramhound vor 7 Jahren 1
@ Ed999: Auch dies kann nur gut sein! Sie haben zivilisierte Apps, wie sie sind. Natürlich haben Sie erwähnt, dass "viele der alten Windows 9x-Programme portabel sind" und "sie werden nicht aus einem Ordner" Programme "ausgeführt". Also keine UAC-Virtualisierung für das Dateisystem. (Wir haben auch eine UAC-Virtualisierung für die Registrierung.) vor 7 Jahren 1
2
CBHacking

Sie stellen hier eine Menge Fragen, einige sind ziemlich komplex, aber die grundlegende Antwort lautet: "Microsoft ist sehr bemüht, die Abwärtskompatibilität aufrechtzuerhalten". Ehrlich gesagt könnte eine bessere Frage "Warum funktioniert es nicht?", Da sowohl Win9x als auch NT (einschließlich Win7) die Win32-API und den x86-Befehlssatz verwenden (die 64-Bit-Erweiterungen von AMD für den x86-Befehlssatz von Intel sind abwärtskompatibel; ein "x64" -Prozessor, der im 64-Bit-Modus ausgeführt wird, kann auch 32-Bit-Programme ausführen.

Der wahrscheinlichste Grund, warum die Dinge nicht funktionieren würden, wäre einfach die Zugriffskontrolle. Win9x unterstützte keinerlei Zugriffskontrollen. Jedes Programm konnte alles, was es wollte. Durch böswillige Eingriffe wurde das Schreiben von Malware sehr einfach. Nicht bösartig, aber träge verwendet, bedeutet dies, dass viele Entwickler ihre Programme so geschrieben haben, dass die Programme Daten in ihre Installationsordner schreiben. Dies ist aus verschiedenen Gründen eine schlechte Idee, nicht zuletzt aus Sicherheitsgründen. Unter einem "echten" Betriebssystem können Nicht-Administratoren aufgrund des Standardverzeichnisses, in dem Dateien installiert werden, nicht in Dateien schreiben, und Sie sollten als Nicht-Administrator ausgeführt werden, außer wenn Sie Software installieren / aktualisieren.

Natürlich ist dieses ganze "Schreiben in das Verzeichnis, aus dem Sie laufen", einfach (ich habe gesagt, die Entwickler seien faul ...) und ja, es macht Software auch "tragbar" in dem Sinne, dass Sie es einsetzen können auf einem Flash-Laufwerk (dem normalerweise auch die Zugriffskontrolle völlig fehlt, da sie Varianten des FAT-Dateisystems verwenden und FAT keine Dateiberechtigungen unterstützt). Das Ausführen von Software auf diese Weise ist weniger sicher als die Installation in einem Bereich mit Zugangsbeschränkung und die Ausführung von dort aus (als Benutzer ohne Administratorrechte). Dies ist jedoch wahrscheinlich in Ordnung, solange Sie den Computer nicht mit anderen Personen teilen.

Warum das OS nichts dagegen hat ... warum sollte man es erwarten? Program FilesEs ist in keiner Weise ein spezieller Ordner, es ist nur der Ort, an dem Sie per Konvention Programme installieren. (Dies ist eigentlich eine wirklich blöde Konvention, weil einige Software - Pausen, wenn Sie es mit Leerzeichen in seinem Weg zu einem Ort installieren, aber vielleicht MS wollten Entwickler nicht ganz, um sicherzustellen, wurde die faul ...) Die einzig Besonderes an Program Filesist Auf 64-Bit-Systemen werden 32-Bit-Prozesse, die nach dem Program Files (x86)Ordner "Programme" fragen, tatsächlich in den Ordner geleitet. Darüber hinaus können Sie mit dem Betriebssystem Programme von überall ausführen, auf die Sie als Benutzer Zugriff haben. Einige Programme werden absichtlich in Ihrem Benutzerprofil oder in einem eigenen Ordner im Stammverzeichnis des Laufwerks installiert (C:\Python27ist ein allgemeiner Ordner, der auf einem Entwicklercomputer angezeigt wird). Diese Programme funktionieren gut.

Ich bin nicht einverstanden mit Ihrem Klopfen auf "Entwicklerlässigkeit" - die Sicherheitskonzepte waren zu dieser Zeit unbekannt oder nicht erforderlich, und ein Entwickler darf normalerweise nicht viele Stunden für etwas aufwenden, das als irrelevant erachtet wird. Was Sie tun, ist, als würden Sie den Menschen im 17. Jahrhundert die Schuld dafür geben, dass die Straßen nicht groß genug für Autos sind. Ansonsten gute Antwort. Aganju vor 7 Jahren 0
@Aganju: "Unbekannt" nur, wenn Sie nichts über die Computerwelt wussten. In diesem Fall waren Sie wahrscheinlich kein Entwickler. Die Grundprinzipien der Sicherheit eines Mehrbenutzer-Betriebssystems gehen auf Multics zurück, das 1969 veröffentlicht wurde. Unix, ein einfacherer (aber dennoch sicherer) Spross der Sprache, wurde 1973 veröffentlicht und war Ende der 70er Jahre weit verbreitet. Microsoft selbst verkaufte Unix (Xenix) ab 1980. Die Windows NT-Familie, die Unix (einschließlich der Sicherheit) sehr schuldet, wurde 1993 veröffentlicht (Linux, BSD und viele andere * nix-Betriebssysteme existierten bis dahin alle). 1998 gab es keine Entschuldigung für Unwissenheit. CBHacking vor 7 Jahren 1
Ich habe mich seit den 70er Jahren entwickelt, aber die Leute, die die Rechnungen bezahlen, würden nicht gerne einen Cent für Sicherheit ausgeben. Ich sehe diese Veränderung erst seit ~ 2005 Aganju vor 7 Jahren 0
@Aganju: Was "nicht erforderlich" angeht, ist das völlig falsch. Es war so, wie es damals war, und es ist sehr notwendig. Win98 (oder sogar 95 mit einigen Upgrades nach der Veröffentlichung) war angeblich ein Mehrbenutzersystem, obwohl es keinen Mechanismus für die Durchsetzung der Sicherheit zwischen Benutzern gab. Es gab keinen Schutz gegen schädliche Software (und es gab * Tonnen * von schädlicher Software). Unternehmen (und einige Häuser) verwendeten jedoch NT, das diese Funktionen hatte. Wie für "viele Stunden", ähm, nein. Es ist nicht gerade schwer, nach "% APPDATA% \ ProgramName \ Filename" zu schreiben, anstatt nur nach "Dateiname"! Faulheit pur. CBHacking vor 7 Jahren 1

Verwandte Probleme