16-bit Windowsprogramme unter Win10 64-bit

  • Ja, interessant, die 18 Jahre alte Ausgabe von "Programming Windows" von Charles Petzold enthält unzählige C Source Codes.

    Die sind nicht nur Binärkompatibel sondern auch Sourcecode kompatibel zu jeder Windows Version bis zum WIndows 10!!


    Der Sprung von 16 auf 32 Bit und schließlich der Sprung von 32 auf 64 Bit ohne Nacharbeit!

    Wenn man von Grund auf sauber arbeitet …

  • Muss ich testen, hab letztens versucht einem älteren Nachbarn sein DOS basiertes Ahnenforschungsprogramm unter Win 10 mit DOSBOX zum Laufen zu bringen, funzt aber nicht, DOSBOX schmiert ab. Vielleicht geht das hier ja...? Ansonsten muss ich dem wohl Virtualbox installieren.

    1ST1

  • Ja, interessant, die 18 Jahre alte Ausgabe von "Programming Windows" von Charles Petzold enthält unzählige C Source Codes.

    Die sind nicht nur Binärkompatibel sondern auch Sourcecode kompatibel zu jeder Windows Version bis zum WIndows 10!!


    Der Sprung von 16 auf 32 Bit und schließlich der Sprung von 32 auf 64 Bit ohne Nacharbeit!

    Wenn man von Grund auf sauber arbeitet …

    18 Jahre? Also die 5. Ausgabe von Petzolds "Programming Windows" ist von 1998 und die vierte von 1996 ("Programming Windows 95").

    Evtl. kamen deutsche Übersetzungen später. Aber beide haben die Win32 API beschrieben, also nix mehr 16 Bit.


    Und Win32 ist ja auch schon steinalt. Windows NT 3.x und Win32s auf WfW...


    Hier geht es aber darum mit Wine auch alte 16 Bit Real Mode Programme aus der Windows Steinzeit (also vor NT/95) laufen zu lassen.

    Das (virtual) Real Mode Subsystem wurde mit den x64 Versionen von Windows entfernt, weil ein 16Bit Subsystem im 32 Bit Subsystem wohl

    doch zu aufwendig wurde. Oder keine Entwickler mehr Bock hatten eine leicht aufgebohrte 8Bit ISA zu programmieren.

    Mit Grausamkeiten wie 64KB Segmenten und near und far pointern...


    Dummerweise hat sich auch in der Win32 API noch lange ein Standard Installer gehalten, der 16 bittig war. Oft ist die Software Win32 und tut wunderbar auf neuen x64 Windows, aber der Installer will nicht.


    Andererseite immer noch viel besser als die Radikalinskis von Apple, wo man in iOS 10 mal eben viele User kalt enteignet hat,

    indem man ohne guten Grund nur noch moderne x64 ARMv8 unterstützt und die 32Bit ARMv7 geräte keine Updates bekamen

    und die neuen Geräte alte Apps nicht mehr ausführen konnten.


    64Bit brauchte man ja vorwiegend, um mehr als 4GB Adressraum für datenhungrige Software zu haben. Aber welches Smartphone oder

    Tablet hat mehr als 4GB und welche Apps darauf brauchen mehr ?


    64Bit bei iOS war rein Marketing-Getrieben. ARM wollte mit der 64 bit ISA in den Servermarkt einsteigen und was passiert:

    noch vor ARM macht Apple damit eine CPU für Gadgets, die das gar nicht benötigen. Nur um angeben zu können.

  • 64Bit brauchte man ja vorwiegend, um mehr als 4GB Adressraum für datenhungrige Software zu haben. Aber welches Smartphone oder

    Tablet hat mehr als 4GB und welche Apps darauf brauchen mehr ?

    Klar doch, und wer braucht schon mehr als 640kB?


    https://www.macrumors.com/2018…ipad-pro-1tb-has-6gb-ram/


    Nicht nur die Apps müssen, sondern auch das Betriebssystem muß den Speicher adressieren.


    Vielleicht verwechselt Du da was mit einer 2GB-Dateigrößengrenze, die es irgendwo irgendwann mal gab.

  • Das (virtual) Real Mode Subsystem wurde mit den x64 Versionen von Windows entfernt, weil ein 16Bit Subsystem im 32 Bit Subsystem wohl

    doch zu aufwendig wurde.

    Es liegt wohl auch daran, dass die CPUs im X64 Mode keinen 16 Bit Code mehr ausführen können.

    Ja: der eigentliche "Virtual 86 Mode" wurde von AMD im x64 nicht vorgesehen. Allerdings haben moderne 86er ja die VT-x virtualization extensions, mit denen es kein Problem ist, den 16 Bit Code in einer VM laufen zu lassen. Aber das Interesse ist halt gering.

  • Hab ich behauptet, man bräuchte nie mehr als 640 KB? Hab ich nicht (und Bill Gates wohl auch nicht).

    Ich brauche auch mehr als 4GB RAM für manche Anwendungen. Aber eben nicht auf einem Smartphone oder Tablet.

    Erst recht nicht, wenn der Hersteller seit Jahren keines mit derart viel Speicher anbietet.


    Als Apple den A7 vorstellte, kamen damit das iPad Air und das iPhone 5s mit 1GB RAM raus. Von einem Produkt mit mehr als 4 GB RAM, das 64 Bit notwendig machen würde, war also weit und breit noch keine Spur zu sehen. Erst 5 Jahre später kommt dann also ein iPad Pro mit 6GB in der Maximalausstattung.


    Aber vorher hat man mal eben haufenweise altgediente Apps in die ewigen 32Bit Jagdgründe geschickt, ausreichend gute 32Bit Geräte per Update-Mangel entwertet und die Benutzer so zum Neukauf gedrängelt - um nicht zu sagen: genötigt.


    Ich bleibe dabei: das Ganze war nur Marketing-Geschrei und Geldmacherei unter Mißbrauch der Marktmacht und des vendor-lock-in Effekts, den man mit dem geschlossenen System erzeugt hat.


    Und ich bin mir ziemlich sicher, dass auch ARMv8 Virtualisierungs-Techniken enthält, die es ermöglichen Anwendungen mit 32Bit ARMv7 Code weiterhin in einem 64Bit OS auszuführen. Apple war halt nur nicht daran interessiert, die Investitionen der Nutzer in Hard- und Software zu schützen.

  • Hab ich behauptet, man bräuchte nie mehr als 640 KB? Hab ich nicht (und Bill Gates wohl auch nicht).

    Ich brauche auch mehr als 4GB RAM für manche Anwendungen. Aber eben nicht auf einem Smartphone oder Tablet.

    Erst recht nicht, wenn der Hersteller seit Jahren keines mit derart viel Speicher anbietet.

    Schau über Deinen Tellerrand hinaus. Andere können Adreßbereiche im Mehrfach-GB-Bereich tatsächlich brauchen. Ich finde es auch richtig, daß Apple ein bißchen vorausschaut und die 64 Bit lieber etwas früher als später eingeführt hat. Die Übergangszeit zum Anpassen von Apps war großzügig bemessen, und in der Regel hat das Umlegen eines Schalters und erneutes Compilieren gereicht. War zumindest bei meinen Apps so.

    .

    .

    .

    Und ich bin mir ziemlich sicher, dass auch ARMv8 Virtualisierungs-Techniken enthält, die es ermöglichen Anwendungen mit 32Bit ARMv7 Code weiterhin in einem 64Bit OS auszuführen. Apple war halt nur nicht daran interessiert, die Investitionen der Nutzer in Hard- und Software zu schützen.

    Vielleicht hast Du recht, ich weiß es nicht (Quellen?). Es hätte aber gleichsam das Betriebssystems doppelt mitgeführt und auch weitergepflegt werden müssen. Ich halte das nicht für praktikabel. Oder wird das unter Android oder sonstwo so gemacht?