- 13.07.26
- 16:43
- Artikel
-
-1
Windows 95: Altes Betriebssystem 'erriet' einfach, ob ein Installer lief
@Alexmitter: NEIN!!! Du schmeisst da ganz viel völlig durcheinander. MS DOS war ein sehr altes Kommandozeilen-basiertes 16 Bit-Betriebssystem. Das wurde mit der technischen Entwicklung immer weiter aufgebohrt, z.B. um mehr Speicher zu addressieren. Irgendwann hat man auch graphische Oberflächen entwickelt, die auf dem MS DOS liefen. Das waren u.a. Windows 3.1, Windows 95 und Windows ME. Überall war ein MS DOS drunter, selbst wenn man es nicht mehr gesehen hat. Parallel wurde aber schon ein völlig neues Betriebssystem entwickelt: Windows NT als 32 Bit-Betriebssystem ohne ein MS DOS darunter. Es erschien 1993 - also vor Windows 95 oder Windows ME. Statt eines monolithischen OS hatte dies eine modulare Architektur. Dies erlaubte es verschiedene Subsystem und APIs zu implementieren. Das Standard-API war das Win32 API für den Zugriff von 32-Bit Anwendungen. Win32 API war KEINE Emulationsschicht für alte Anwendungen!!! Für (alte) 16 Bit-Anwendungen gab es das Win16 API, da natürlich 16 Bit-Anwendungen nativ nicht auf einem 32 Bit-OS laufen können. Unter Windows 95 gab es bereits ein ähnliches API mit dem Namen Win32c. Unter Linux gibt es das Win32 API auch heute noch mit Wine. Später wurde Windows zu einem 64 Bit-Betriebssystem und logisch gab es auch ein Win64 API. Win16 wurde in diesem Zug fallen gelassen. - Der Explorer geht in keinster Weise auf Windows 95 zurück. Das wäre technisch überhaupt nicht möglich. Der Explorer stellt den Mechanismus dar, wie jegliche Anwendung auf Dateien zugreift auf beliebigen Dateisystemen. Er ist daher tief im System verwurzelt. - Bei Dateisystemen hast Du komplett daneben gegriffen. NTFS war bei der Einführung eines der modernsten Journaling-Dateisysteme, hat sich aber natürlich auch weiterentwickelt und ist durchaus vergleichbar mit ext4 (NTFS kann z.B. Verschlüsselung verwalten, ext4 ist etwas performanter, dafür ist NTFS wieder etwas besser bei Sicherheit und bietet deutlich mehr Funktionalität). WinFS war in keinster Weise ein Nachfolger, sondern eine Erweiterung von NTFS. Es war der Versuch eines Datenbank-basierten Filesystems, ist aber nur ein Test gewesen und war nie produktiv. Deine Aussage zu Dateisystem zeigt leider mangelhafte Kenntnisse des Themas. - Schlimmer aber ist die letzte Aussage. Dein Common Object Model gibt es nicht. COM war das Component Object Model von Windows 3.1 im Jahr 1992 (und hatte noch Vorgänger). Es war Basis für OLE in Excel und Word und ActiveX, was inzwischen auch lange Geschichte ist. Das war viele viele viele Jahre bevor das .NET Framework erschien. .NET Framework ist wiederum auch nicht .NET und weder basiert COM auf .NET, noch basiert .NET auf COM. Sorry, Deine Aussage ist fachlich kompletter Unsinn, nicht einmal halbrichtig.
Kommentare
7.165
Kommentare
geschrieben
4.589
Antworten
erhalten
10.013
Likes
erhalten
KI soll gezielt Mitarbeiter in Krankenstand & Elternzeit entlassen haben
@Mitsch79: Du hast recht, so einfach ist es nicht. Es ist ja auch nicht gewollt, dass Kranke wegen ihrer Krankheit gekündigt werden. Aber unmöglich ist es nicht. Ich habe selber so einen Fall gehabt. Aber die Hürden sind wirklich hoch.
Secure Boot war mit bekannten Lücken über Jahre hinweg angreifbar
@DavidXanatos: Nein, Du hast SecureBoot nicht verstanden. Vielleicht hilft Dir das: https://www.systemshardening.com/articles/linux/linux-uefi-secure-boot-db/
Secure Boot war mit bekannten Lücken über Jahre hinweg angreifbar
@c0d3r9: Quatsch! Das ist einfach nur falsch. Secureboot ist Teil von Uefi und war anfangs eine Initiative von Intel, später vom Unified EFI Forum in dem alle namhaften PC- und BIOS-Hersteller sitzen: https://uefi.org/members. Und das mit den Laufwerken ist auch Unsinn. Du hast offensichtlich keine Ahnung was Zertifikate sind. Das sollte eigentlich Grundlagenwissen sein.
KI soll gezielt Mitarbeiter in Krankenstand & Elternzeit entlassen haben
@Mitsch79: Krankheit ist einer der zulässigen Kündigungsgründe. Natürlich darfst Du nicht jedem der krank wird sofort kündigen, aber häufige Krankheit oder negative Prognose erlauben dann irgendwann die Kündigung. Robin hat schon einen Link geschrieben, hier noch ein Link der Gewerkschaft DGB, der pro Arbeitnehmer formuliert ist (aber das gleiche beschreibt).
Secure Boot war mit bekannten Lücken über Jahre hinweg angreifbar
@stf: Korrekt wäre Boatkits: https://boatkits.de/ ;-)
Secure Boot war mit bekannten Lücken über Jahre hinweg angreifbar
@DRMfan^^: NEIN!!!! Die Hardware-Hersteller spielen in der Regel ein Microsoft-Zertifikat auf die Rechner. Machen zumindest die meisten, aber nicht alle. Das ist aber nur ein Zertifikat. Man kann problemlos weitere Zertifikate hinzufügen oder auch das Microsoft-Zertifkat rauswerfen. Microsoft ist NICHT "Herr der Zertifikate", sondern nur Herr von den eigenen Microsoft-Zertifikaten. Mehr nicht.
Secure Boot war mit bekannten Lücken über Jahre hinweg angreifbar
@DRMfan^^: Dir stand es immer frei, Dein System zu härten. Viele glauben, SecureBoot ist ein Microsoft-Ding und viele Linux-Nutzer schalten es ab. Das ist dumm, auf Sicherheit zu verzichten aus Unkenntnis. SecureBoot ist ein (um es weiter so flapsig auszudrücken) ein Hardware-Ding. Da ist erst mal kein Microsoft dran oder drin. Es sichert den Rechner ab, dass keine illegale Software ausgeführt werden kann. Was illegal ist, wird über verschiedene Zertifikatsketten festgelegt. Dazu sind verschiedene Keys hinterlegt. Viele Hardware-Hersteller haben bei Auslieferung erst mal einen Microsoft-Key hinterlegt. Da kommt dann Microsoft als CA ins Spiel. Alle Software, die mit diesem Key signiert ist, kann ausgeführt werden. Da viele Linux-Distributionen das nicht sind, kommen dann die Shim ins Spiel, die es erlauben auch andere Software zu starten. Shim sind nur ein Krücke zum Umgehen der Sicherheit. Und eigentlich wären sie auch nicht nötig. Man kann weitere Keys hinterlegen und wenn man sein System härten und komplett Microsoft-frei machen will, kann man sogar die Microsoft CA ausschließen. Aber das erfordert natürlich entsprechende fachliche Kompetenz der Admins. Secureboot abzuschalten ist für die meisten Systeme unklug, da es die Systeme unsicherer macht. Und immerhin unterstützen alle gängigen Linux-Distributionen inzwischen Secureboot, selbst wenn man nicht so weit geht, Microsoft als CA abzuklemmen.
In Deutschland gescheitert: China-Marke verkauft in 6 Monaten 15 Autos
@Abgeflext: Du hast vermutlich kein Auto, oder? Was Du schreibst ist einfach Unsinn! Lange Wartezeiten bei VW sind völlig normal. Unsere Dienstwagen sind immer mal wieder stillgelegt, weil die Werkstätten zu lange auf sich warten lassen. Gerade letztens wegen eines Scheinwerfers mehrere Werkstätten angerufen. Viele hatten erst mal gar keine zeitnahen Termine. Eine in einer Nachbarstadt meinte dann: Birne oder LED? Birne tauschen wir schnell nebenbei, LED müsste ca. 2-3 Wochen warten.
Windows 95: Altes Betriebssystem 'erriet' einfach, ob ein Installer lief
@Alexmitter: NEIN!!! Du schmeisst da ganz viel völlig durcheinander. MS DOS war ein sehr altes Kommandozeilen-basiertes 16 Bit-Betriebssystem. Das wurde mit der technischen Entwicklung immer weiter aufgebohrt, z.B. um mehr Speicher zu addressieren. Irgendwann hat man auch graphische Oberflächen entwickelt, die auf dem MS DOS liefen. Das waren u.a. Windows 3.1, Windows 95 und Windows ME. Überall war ein MS DOS drunter, selbst wenn man es nicht mehr gesehen hat. Parallel wurde aber schon ein völlig neues Betriebssystem entwickelt: Windows NT als 32 Bit-Betriebssystem ohne ein MS DOS darunter. Es erschien 1993 - also vor Windows 95 oder Windows ME. Statt eines monolithischen OS hatte dies eine modulare Architektur. Dies erlaubte es verschiedene Subsystem und APIs zu implementieren. Das Standard-API war das Win32 API für den Zugriff von 32-Bit Anwendungen. Win32 API war KEINE Emulationsschicht für alte Anwendungen!!! Für (alte) 16 Bit-Anwendungen gab es das Win16 API, da natürlich 16 Bit-Anwendungen nativ nicht auf einem 32 Bit-OS laufen können. Unter Windows 95 gab es bereits ein ähnliches API mit dem Namen Win32c. Unter Linux gibt es das Win32 API auch heute noch mit Wine. Später wurde Windows zu einem 64 Bit-Betriebssystem und logisch gab es auch ein Win64 API. Win16 wurde in diesem Zug fallen gelassen. - Der Explorer geht in keinster Weise auf Windows 95 zurück. Das wäre technisch überhaupt nicht möglich. Der Explorer stellt den Mechanismus dar, wie jegliche Anwendung auf Dateien zugreift auf beliebigen Dateisystemen. Er ist daher tief im System verwurzelt. - Bei Dateisystemen hast Du komplett daneben gegriffen. NTFS war bei der Einführung eines der modernsten Journaling-Dateisysteme, hat sich aber natürlich auch weiterentwickelt und ist durchaus vergleichbar mit ext4 (NTFS kann z.B. Verschlüsselung verwalten, ext4 ist etwas performanter, dafür ist NTFS wieder etwas besser bei Sicherheit und bietet deutlich mehr Funktionalität). WinFS war in keinster Weise ein Nachfolger, sondern eine Erweiterung von NTFS. Es war der Versuch eines Datenbank-basierten Filesystems, ist aber nur ein Test gewesen und war nie produktiv. Deine Aussage zu Dateisystem zeigt leider mangelhafte Kenntnisse des Themas. - Schlimmer aber ist die letzte Aussage. Dein Common Object Model gibt es nicht. COM war das Component Object Model von Windows 3.1 im Jahr 1992 (und hatte noch Vorgänger). Es war Basis für OLE in Excel und Word und ActiveX, was inzwischen auch lange Geschichte ist. Das war viele viele viele Jahre bevor das .NET Framework erschien. .NET Framework ist wiederum auch nicht .NET und weder basiert COM auf .NET, noch basiert .NET auf COM. Sorry, Deine Aussage ist fachlich kompletter Unsinn, nicht einmal halbrichtig.
Desktop-PCs: Kuriose Statistik zeigt Windows-Absturz auf unter 60%
@Gösser: Es wird gemessen, welche Daten die Webbrowser der Nutzer an den Server liefern. Der User Agent wird analysiert, z.B. habe ich jetzt gerade "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0". Nein, ich habe kein Windows 10 auf diesem Rechner, wird aber so gezählt. Mein Handy liefert gerade "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Mobile Safari/537.36" und es ist KEIN Chrome, auch wenn es so identifiziert wird. Einige Browser erlauben es, dass man konfiguriert wie der Browser sich identifizieren soll. Das kann auch zu unknown führen.