Diskussion:Microsoft Windows 95

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Automatische Archivierung
Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 180 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte. Die Archivübersicht befindet sich unter Archiv.

Technische Neuerungen[Quelltext bearbeiten]

Die komplexe Zusammenarbeit von 16-Bit- und 32-Bit-Codekomponenten zeigt sich auch beim Bootvorgang, in dem der Prozessor vom Real Mode in den Protected Mode (Schutzmodus) geschaltet wird.

Inwiefern ist das Schalten vom Real Mode in den Protected Mode ein Beweis für die "komplexe Zusammenarbeit von 16-Bit- und 32-Bit-Codekomponenten"? Das ist ja nun wirklich ein trivialer Schritt. Wahrscheinlich ist da etwas anderes gemeint, dann sollte da "während" und nicht "in dem" stehen. Oder sehe ich da etwas falsch? -- Liliana 23:26, 31. Mai 2013 (CEST)

In Windows 95 funktionieren auch 16-Bit-DOS-Treiber: z.B. für eine Erweiterungskarte, für die es keinen Windows-Treiber gibt. Ein gutes Beispiel sind auch SCSI- oder CD-ROM-Treiber: die Laufwerke können unter Windows 95 trotz DOS-Treiber genutzt werden.
Windows 95 kann auch relativ gut zwischen DOS und Windows (32-Bit) hin- und herschalten. Bei späteren Windows-Versionen war das nicht mehr so einfach möglich, bei NT sogar technisch unmöglich.
Andreas 12:20, 2. Jun. 2013 (CEST)
Nachtrag: Man muss bedenken, dass es bei Erscheinen von Windows 95 nur wenige 16-Bit-Windows-Programme gab, noch weniger 32-Bit-Windows-Programme, aber sehr sehr viele DOS-Programme/-Spiele. ‣Andreas 12:22, 2. Jun. 2013 (CEST)
Das sollte dann aber auch im Artikel erläutert werden, weil so an sich klingt der Satz wirklich merkwürdig. -- Liliana 15:22, 2. Jun. 2013 (CEST)
Ich hab da mal gegoogled:
So einfach wie ich das geschrieben habe ist es dann offenbar doch nicht. Ich weiß jedoch, dass ich mein CD-ROM-Laufwerk unter Windows 95 benutzen konnte, obwohl ich nur einen DOS-Treiber verwendet hatte. Das ganze war dann im 16-Bit-Zugriffsmodus, weil eben kein Windows 95-.vxd dafür vorhanden war, ging aber einwandfrei.
Langer Rede, kurzer Sinn: eine Recherche wäre gut. Leider habe ich gerade jetzt keine Zeit dafür.
Andreas 17:24, 2. Jun. 2013 (CEST)

"erstes 32-Bit-Windows"[Quelltext bearbeiten]

"Es ist das erste Betriebssystem der Windows-Reihe, das den 32-Bit-Betrieb dieser Architektur weitreichend unterstützt [...]"

Ähm, Win3.x hatte die Win32s-Erweiterung, und war auch nur mit deutlich über 1 MB Ram genießbar, gerne z.B. mit 256 MB. Man musste WfW 3.1+ explizit in den 286-Modus prügeln, teilweise ging das gar nicht mehr, sondern ein 386er war zwingend Voraussetzung. Und damit waren natürlich sowohl Win32s- als auch DOS-/Win-16-Bit-Progis ausführbar.

Die Aussage "Win95 war das erste Win-OS ..." ist imo ziemlich wackelig.

--arilou (Diskussion) 15:09, 10. Jun. 2013 (CEST)

Zumal Windows NT einfach totgeschwiegen wird, wie so oft. -- Liliana 21:37, 10. Jun. 2013 (CEST)
Die Einleitung macht immer noch gar keinen Sinn. Meines Wissens nach konnte Windows NT (für Intel) durchaus mit 16-Bit-Windows-Programmen umgehen (zumindest Windows NT 3.51). Man kann allenfalls schreiben, dass es die erste 32-Bit-Windows-Version für den Heimbereich war. --Filzstift  15:07, 1. Dez. 2013 (CET)
Das soll wohl darauf hinweisen, dass NT nur eine schlechte Kompatibilität zu 16-Bit-Programmen hatte, was aber auch nur auf Intel zutrifft (MIPS hatte sogar eine ausgezeichnete 16-Bit-Kompatibilität). So ist das wirklich Schwachsinn und muss raus. -- Liliana 17:02, 1. Dez. 2013 (CET)
Dazu kommt, dass man die angeblich schlechte Kompatibilität zu 16-Bit-Programmen eigentlich belegen sollte. Behaupten kann man ja schliesslich alles. --Filzstift  14:13, 3. Dez. 2013 (CET)
Die 16-Bit-Kompatibilität von NT kann nicht so schlecht sein, wie man vielleicht glaubt. Ich hatte mal ein Programm mit Multimedia-Elementen, das für Win 9x als 32-Bit-Variante und für Win 3.x als 16-Bit-Variante auf CD-Rom erschien. Mit Direct X unter Win 9x lief die 32-Bit-Variante auch tadellos, jedoch auf keinem NT-System. Die 16-Bit-Variante hingegen lief unter NT 3.51 (und Folgeversionen bis einschl. XP) problemlos, inklusive der Filmsequenzen, da es nicht für DX-Unterstützung programmiert wurde und der 16-Bit-Code problemlos unter NT 3.51 ausgeführt wurde. NT 3.51 kam bekanntlich im Mai heraus, Win 95 erst im August. Aber auch noch frühere Win NT-Versionen dürften 16-Bit-Programme ähnlich gut unterstützt haben, denn Win NT entspringt ja einer gemeinsamen Codebasis mit OS/2, und Sinn der Entwicklung damals war damals ja, die schon verbreiteten 16-Bit-Windowsprogramme ausführen zu können. Microsoft Office 4.2 (NT-Version) enthielt Word und Excel „for Windows NT“, PowerPoint dagegen war auch auf der NT-CD nur als 16-Bit-Variante vorhanden (vgl. Microsoft Office#Versionen, Einzelnachweise siehe dort). 16-Bit-Windowsprogramme sind also prinzipiell kein Problem. Lediglich mit DOS wird's schwierig unter diesen NT-Versionen. Richtig dürfte dagegen sein, dass Win 95 das erste System war, das Windowsprogramme (egal ob 16-/32-Bit) bei gleichzeitiger Kompatibilität (d.h. ohne Emulation mit all ihren Einschränkungen) zu alten DOS-Programmen ausführen konnte. Dementsprechend sollte man den Text anpassen. --H7 (Diskussion) 19:58, 1. Dez. 2013 (CET)
Herzlichen Dank, schon viel besser, nur: «stets nur in einer Emulation ausgeführt...»: das trifft auf die Nicht-Intel-NT-Maschinen sicher zu, aber auf Intel-Prozessoren wird virtualisiert, nicht emuliert. Jedenfalls behauptet der Artikel NTVDM, dass dort der Virtual 8086 Mode zum Zuge kommt. --Filzstift  10:22, 3. Dez. 2013 (CET)
Ähm, wenn ich es mir aber recht überlege, ist DOS-Emulator doch nicht ganz falsch (DOS wird schliesslich emuliert). Da da aber nur "Emulator" stand, hat mich das verwirrt (in der Annahme, auch der Prozessor würde emuliert werden). --Filzstift  12:08, 3. Dez. 2013 (CET)
Zum Speicher: 256 MB ist das Maximum, mit dem Windows 3.1x problemlos läuft, aber damals hatte ziemlich sicher kein Desktop-Computer so viel Speicher verbaut, bei den meisten Mainboards war der maximale Ausbau 128MB (4 SIMMs mit je 32MB), tatsächlich ab Werk verbaut hatte aber wohl kaum einer mehr als 32MB (die meisten eher 8MB oder 16MB). Und auch aufgerüstet wurde meist auf maximal 32MB, weil mehr brauchte man damals einfach normalerweise auf einem Desktop nicht (und Speicher war noch teuer). Zum minimal benötigten Speicher: Windows 95 lief mit 4 MB, aber nur sehr schlecht, da lief 3.1x mit Win32s sicher schon besser, natürlich nur wenn das Programm nicht viel mehr als 4MB belegt hat (etwas mehr war kein Problem, da auch Win 3.1x bereits Swapping unterstütze, soviel ich weiß wurde das Swapping erstmals mit Windows/386 eingeführt, daher heißt die Swapfile unter 16-bit-Widnows und windows 9x ja auch standardmäßig WIN386.SWP). 16MB düften damals aber für fast alle zwecke ausreichend gewesen sein (auch wenn man ev. mit 32MB die Performance durch Swapping-Reduktion noch etwas steigern konnte). --MrBurns (Diskussion) 18:37, 3. Apr. 2014 (CEST)

Defekte Weblinks[Quelltext bearbeiten]

GiftBot (Diskussion) 20:51, 22. Nov. 2015 (CET)

Vollständig vs. Kernkomponente[Quelltext bearbeiten]

Was ist eine Kernkomponente eines OS, und was nicht?

Bzgl. diesem Edit +vorausgehende.

Eindeutiger Fall: Bei Win9x war/ist ein Mediaplayer mit dabei. Ganz eindeutig keine Kernkomponente des OS, es läuft hervorragend auch ohne dieses Programm.

Streitfall: Scandisk

Bei Win9x mitgeliefert. Benutzer:MrBurns sieht es als "Kernkomponente", die in 32 bit hätte vorliegen müssen, um das OS als "vollständig 32 bittig" beschreiben zu dürfen.

Ich sehe Scandisk als (Wartungs-)Anwendungsprogramm. Imo beschränken sich 'Kernkomponenten' auf Dinge wie Kernel, Speicherverwaltung, Scheduler, Dateisystem, Treibermodell/-Verwaltung, Rechteverwaltung, Ressourcenhandling, Oberfläche. (Vielleicht noch 2-3 Dinge mehr, aber eben keine "Zusatz- und Hilfstools": ScanDisk, RegEdit, FontManager, Systemsteuerung, ...) Imo ist ein OS "vollständig 32 bittig", wenn diese Komponenten 32-bittig sind.

Scandisk/Defrag u.ä. wurden lange Zeit bei MS-Betriebssystemen nicht mitgeliefert (DOS 5?), der Benutzer konnte sie (von Drittfirmen) zukaufen (z.B. Norton System Utilities). Oder es bleiben lassen.

Ich plädiere dafür, Win95 wieder als "vollständig 32-bittiges OS" zu bezeichnen, auch wenn einige Hilfsprogramme noch 16-bit waren.

--arilou (Diskussion) 13:39, 15. Mär. 2016 (CET)

Die Frage ist, ob Scandisk etc. auch zum OS gehört. Wobei Scandisk unter Windows 95 glaub ich schon auch als 32bit-Anwendung integriert war, einige anderen Programme aber nicht. Genauer gesagt war Scandiskm eine 16/32-bit Anwendung in einer .exe-Datei, vgl. Portable Executable, unter DOS lief der 16bit-Teil, unter Windows der 32bit-Teil, eigentlich ist das jeder 32bit-Anweundung nur ist der 16bit-Teil üblicherweise nur ein sehr simples Programm, das nichts macht außer eine Zeile wie "This Programm cannot be run in DOS mode" auszugeben, während bei Scandisk der 16bit-Teil eben eine "richtige" DOS-Anwendung ist. Ob jetzt diese notwendigen Dienstprogramme, die eben noch teilweise uaschließlich in 16 Bit vorlagen, zum OS gehören, ist ein altes Streitthema, ich hab dazu keine fixe Einstellung. --MrBurns (Diskussion) 13:50, 15. Mär. 2016 (CET) PS: noch genauer dürfte es bei Scandisk so gewesen sein, dass der 32-bit-Teil der scandisk.exe nur ein Verweis auf die 32-bit-Anwendung scandskw.exe war, warum auch immer. Jedenfalls gabs ein 32-bit-Scandisk. --MrBurns (Diskussion) 14:01, 15. Mär. 2016 (CET)
Dass das Microsoft natürlich gerne so sieht wie das arilou hier vertritt, Der Artikel Betriebssystem beginnt so: "Ein Betriebssystem ist eine Zusammenstellung von Computerprogrammen, die die Systemressourcen eines Computers wie Arbeitsspeicher, Festplatten, Ein- und Ausgabegeräte verwaltet und diese Anwendungsprogrammen zur Verfügung stellt." Da ist sowas wie Scandisk oder einzelne 16-Bit-Treiber erkennbar mit eingeschlossen, denn ohne Scandisk können manche Fehler der Festplatte nicht repariert werden und Fremdprogramme versagen eventuell ihren Dienst bzw. Dateien können von ihnen nicht mehr verwendet werden. Wenn das keine Kernkomponente ist, dann beschränkt sich das wohl nur auf Kernel und Treiber? Das ist doch Unsinn! Natürlich sind Festplatten-Dienstprogramme Kernkomponenten! Einfach, weil es - im Gegensatz zum Media Player - zur vernünftigen Verwendung des Betriebssystems einfach dazugehört. Außerdem müssen wir dem Leser schon selbst überlassen, was er von einem Betriebsystem erwartet, ohne ihn in die Irre zu führen. Und genau das tut man, wenn im System 16-Bit-Software mitgeliefert wird und wir behaupten, es sei "vollständig 32-bittig". Übrigens: Wenn Scandisk sogar unter Win98 noch ein 16-Bit-Programm war (Beleg, dann glaubt doch keiner, dass der im vorherigen Windows 32-Bit gewesen sein soll. (Im Übrigen gibt es auch 32-Bit-Programme, die nicht unter der grafischen Oberfläche laufen, sondern in der CMD-Shell als echte 32-Bit-Anwendung, d.h. der Vergleich ist hier vermutlich nicht zielführend.) --H7 (Diskussion) 17:18, 15. Mär. 2016 (CET)
Das ist mitnichten "Unsinn". Nicht jedes Wartungs- oder Fehlerdiagnose-Tool ist "OS-Komponente".
Beispiel-Tools, die auch heute nicht Bestandteil des OS sind, also nicht mitgeliefert werden:
  • SMART-Diagnose
  • Reparatur beschädigter Partitionen
  • Datenrettung
  • teilweise Diagnose und Reparatur von Registry-Problemen
  • EFI-/Bootmanager
Übrigens war MS hierbei jahrzehntelang eher "Vorreiter" und hat häufig Tools mitgeliefert, als Konkurrenz-Systeme noch extrem "nackt" geliefert wurden. Speziell im Großrechnerbereich (Unix, VMS, ...) war ein OS ohne (extra zu kaufende) Zusatzpakete praktisch unbedienbar; das "Kernsystem" kam z.B. ohne Kommandozeilenprogramme wie "cd" oder "copy" - die wurden in einem gesonderten Paket verkauft.
["erkennbar mit eingeschlossen"] - ähm, nein. Ram, Hdd, Ressourcen zu verwalten ist etwas anderes, als deren Fehler zu beheben, ggf. sogar auch nur zu erkennen. Um Festplattenplatz zu verwalten, genügt ein simples Dateisystem. Ganz ohne chkdsk, scandisk, Partition repair, ...
--arilou (Diskussion) 09:28, 16. Mär. 2016 (CET)
Alles, was du schreibst, ist eigentlich doch mitgeliefert – hängt aber vom jeweiligen OS ab. Mac OS X 10.4 konnte z.B. schon den S.M.A.R.T.-Status angeben, und das war 2005. Jedes Betriebssystem bietet zudem so etwas wie Datenrettung, und sei es nur ein archaisches Sicherungsprogramm, das im Notfall die Daten dadurch rettet, indem es sie vorher gesichert hat. Soetwas wie Schattenkopien und Sicherungspunkte zählen ja wohl auch dazu. Auch einen Bootmanager bietet Windows schon seit den frühen Tagen von Windows NT.
OS-Komponente ist wohl das, was beim OS dabei ist. Obwohl es Kernkomponenten gibt, ohne die das OS gar nicht läuft. Die Trennlinie ist aber wohl eher fließend, wie der Internet-Explorer-Fall zeigte, wo argumentiert wurde, dass Windows ohne den IE gar nicht läuft – was wohl auch zutreffend war, aber das war dennoch auch Absicht und Kalkül.
Andreas 18:32, 16. Mär. 2016 (CET)
?!?
Ein "Datenrettungs-Tool" ist etwas völlig anderes als ein "Backup-Tool". Ein Tool zum Reparieren von Partitionen/-Tabellen ist etwas völlig anderes als ein Backup-Tool, das Images einer Partition erstellen und zurückspielen kann. Das Verwalten (Ändern, Umsortieren, De-/Neu-Installieren) von Booteinträgen - auch für andere OSe - ist etwas anderes, als überhaupt einen Bootmanager zu installieren/besitzen.
Ein OS teilt sich auf in "Kernkomponenten" und (mitgelieferte) "Zusatzkomponenten".
Ja, der Übergang ist fließend. Aber: ganz sicher ist "mitgeliefert" nicht das maßgebende Kriterium für "ist Kernkomponente" vs. "ist Zusatzprogramm" (des OS).
--arilou (Diskussion) 10:38, 17. Mär. 2016 (CET)
PS: Etwas, das OS-Kernkomponente ist, muss bei jedem OS dabei sein - sonst ist es ziemlich sicher keine Kern-Komponente, wenn es bei einem OS einfach weggelassen werden kann.
Wenn behauptet wird, ein OS sei "vollständig" 32-bittig, dann würde ich als Kunde allerdings keinen Unterschied zwischen Kernkomponenten und Zusatzprogrammen machen, und die Diskussion hier zeigt ja auch, dass es nicht sinnvoll ist, hier zu unterschieden, weil die Grenze fließen (d.h. strittig) ist. Stattdessen würde ich (und wohl auch die meisten anderen Windowsnutzer) erwarten, dass das, was der Hersteller liefert, eben auch vollständig der Behautptung entspricht. Und das ist offensichtlich nicht der Fall, denn nicht mal Microsoft behauptet das, sondern gibt stattdessen einen Eigenbeleg für Scandisk als 16-Bit-Programm, neutrale zitierfähige Quellen für die Behauptung gibt es anscheinend auch nicht. --H7 (Diskussion) 10:49, 17. Mär. 2016 (CET)
Ich denke nicht, dass es so einfach ist. Ein OS muss gar nichts, es muss nur laufen und für andere Programme eine Plattform bieten. Selbst ein Betriebssystem vollkommen ohne Treiber ist denkbar, warum auch nicht. Es muss nicht mal Grafikmodus bieten. DOS ist auch ein Betriebssystem, das hat aber weder Multitasking-/Multithreading-Fähigkeit noch bietet es standardiesierte Treiber. Auch das Speichermanagement reduziert sich auf ein Minimum: denn das gibt es nicht ohne Zusatzprogramme, die zwar vielleicht mitgeliefert werden, aber keinesfalls Kernkomponenten sind, denn das Betriebssystem selbst läuft ja auch ohne diese.
Die Trennung von Kernkomponente und Zusatzkomponente wird NICHT gelingen. Das ist deshalb unmöglich, weil es nicht klar definiert ist – und niemals klar definiert sein wird – was nun ein Betriebssystem können MUSS.
Wenn der Kernel allerdings 32-bittig ist, und dieser auch 32-bittige Treiber unterstützt, so kann man wohl von einem echten 32-Bit-Betriebssystem sprechen, auch wenn einige der mitgelieferten Programme noch 16-Bit-Programme sind. Das ist nämlich egal.
Im Falle von Windows 95-Me würde ich allerdings von einem Hybrid sprechen, da sowohl 16-Bit- als auch 32-Bit-Treiber möglich sind, und da das Betriebssystem selbst anfangs im 16-Bit-Modus läuft, bevor der 32-Bit-Kernel geladen wird. Dieser 16-Bit-Modus ist selbständig auch lauffähig, da es sich um MS-DOS handelt. In diesem Modus kann dann auch ein 16-Bit-CHKDSK laufen (muss es sogar, weil ein 32-Bit-CHKDSK ja nicht laufen könnte).
Andreas 18:38, 17. Mär. 2016 (CET)


Treiber[Quelltext bearbeiten]

Zu der Frage Win95 ein vollständiges 32-bit-OS war gehört auch die Frage, ob alle Standardtreiber 32 bit hatten. Windows 95 unterstützte jedenfalls auch 16-bit-Treiber und ich denke auch, dass es auf 16-bit-treiber angewiesen war. Meines Wissens hatte erste Windows 98 alle Standardtreiber in 32 bit. --MrBurns (Diskussion) 14:04, 15. Mär. 2016 (CET)

Nein, darauf angewiesen war es sicher nicht. Die meiste Standard-Hardware wurde von Microsoft von Haus aus unterstützt, sodass keine 16-Bit-Treiber notwendig waren. Wer sehr exotische Hardware einsetzte, für die nur 16-Bit-Windows- oder -DOS-Treiber vorhanden waren, konnte diese unter Windows 95 nutzen, obwohl dies einen nicht unwesentlich negativen Effekt auf das Gesamtsystem hatte.
Andreas 18:27, 16. Mär. 2016 (CET)

Im Artikel Microsoft Windows 98 findet sich diese Aussage: "Windows 98 ist das erste DOS-basierte (größtenteils) 32-Bit Betriebssystem, das im Gegensatz zu Windows 95 nicht mehr einzelne Hintergrundprogramme im 16-Bit-Modus ausführt. Aber selbst hier kommen immer noch einzelne Dienstprogramme im 16-Bit-Modus zum Einsatz." Also muss es doch irgendwelche Kernkomponenten von Windows 95 geben, welche nur 16-bittig sind. -- Liliana 18:41, 17. Mär. 2016 (CET)

Dieses PDF ist leider auf Englisch, auf Seite 3 heißt es darin allerdings: Windows 95 is a 32-bit preemptive multitasking operating system that implements some 16-bit code to provide compatibility with existing applications. In general, 32-bit code us provided in Windows 95 to maximize the performance of the system, while 16-bit code balances the requirements for reducing the size of the system and maintaining compatibility with existing applications and drivers.
The design of Windows 95 deploys 32-bit code wherever it significantly improves performance without sacrificing application compatibility. Existing 16-bit code is retained where it is required to maintain compatibility, or where 32-bit code would increase memory requirements without significantly improving performance. All of the I/O subsystems and device drivers in Windows 95, such as networking and file systems, are fully 32-bit, as are all the memory management and scheduling components (the kernel and virtual memory manager).
Andreas 21:13, 17. Mär. 2016 (CET)

Lemma[Quelltext bearbeiten]

Es geht um das Lemma aller Windows-Artikel. Diskussion bitte dort, nicht hier. Danke. ‣Andreas 17:34, 23. Jan. 2017 (CET)