Login
Newsletter
Werbung

Thema: »a.out« unter Linux bald Geschichte

40 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von https://de.wikipedia.org/wiki/ am Fr, 8. März 2019 um 08:40 #

Verwirrenderweise trägt die Ausgabedatei eines Unix Compilers bzw. Assemblers auch dann standardmäßig den Dateinamen a.out, wenn sie nicht im Dateiformat a.out, sondern in einem der neueren Dateiformate erzeugt wird.

[
| Versenden | Drucken ]
  • 1
    Von Gnome-Nutzer am Fr, 8. März 2019 um 10:01 #

    Verwirrend ist das nicht, denn der Dateiname selbst tut nichts zur Sache. Es geht nur um das Dateiformat.

    [
    | Versenden | Drucken ]
    • 1
      Von Nils am Fr, 8. März 2019 um 10:19 #

      Für dich vielleicht nicht.
      Ich dachte auch jahrelang, da würden a.out Dateien rauskommen.

      Wenn jemand sein 1100ccm Touren Motorrad immer Moped nennt, ist man auch erstmal verwirrt, wenn man das Moped dann endlich mal sieht.

      [
      | Versenden | Drucken ]
      • 1
        Von Gnome-Nutzer am Fr, 8. März 2019 um 11:07 #

        Ich finde, dass Mirko Lindner sich korrekt ausgedrückt hat:
        Es geht um »alte binäre Dateien«, die sich bislang noch ausführen lassen.
        Siehe: https://de.wikipedia.org/wiki/A.out

        [
        | Versenden | Drucken ]
        • 1
          Von kamome umidori am Fr, 8. März 2019 um 11:18 #

          Hat er – das hat aber nichts damit zu tun, dass die Benennung der Ausgabedateien als „a.out“ verwirrend ist, wenn kein a.out drin ist ;)

          [
          | Versenden | Drucken ]
          • 1
            Von Gnome-Nutzer am Fr, 8. März 2019 um 13:25 #

            Compilierungen unter SunOS tragen auch den Standardnamen „a.out“, wenn kein anderer angegeben wird. Trotzdem sind sie nicht unter Linux (AMD64/i386) ausführbar.

            Namen sind nichts als Schall und Rauch.

            [
            | Versenden | Drucken ]
            • 1
              Von kamome umidori am Fr, 8. März 2019 um 13:32 #

              > Namen sind nichts als Schall und Rauch.

              Nur, wenn dämlich gewählt!

              [
              | Versenden | Drucken ]
              • 1
                Von Gnome-Nutzer am Fr, 8. März 2019 um 14:14 #

                Die bei den sog. PC-Spezialisten gewählte Bezeichnung «BIOS» für den BIOS-Nachfolger «UEFI» finde ich dämlich gewählt. Ganz besonders dann, wenn die BIOS-Kompatibilität in wenigen Jahren aus UEFI entfernt wird. ;)

                [
                | Versenden | Drucken ]
                • 1
                  Von blablabla233 am Fr, 8. März 2019 um 17:11 #

                  Niemand sagt das UEFI ein Bios ist...aber es hat den CSM (welcher so 2020 sterben soll)

                  [
                  | Versenden | Drucken ]
        1
        Von Heizer am Fr, 8. März 2019 um 20:50 #

        Mopped != Moped.

        [
        | Versenden | Drucken ]
      0
      Von Antiquities am Di, 12. März 2019 um 08:09 #

      völlig zutreffend. Punkt.

      [
      | Versenden | Drucken ]
1
Von Ghul am Fr, 8. März 2019 um 13:10 #

Eines muss man Microsoft zu gute halten, die würden die Abwärtskompatibilität zu alter Software noch gewährleisten und Kompatibilitätsmodi noch bis in die neusten Windowsversionen anbieten.

Diejenigen, die unter Linux alte closed Source Software im a.out Format haben, dürften die Software bald nicht mehr ausführen können, wenn die Unterstützung dafür im Kernel ganz entfernt wird.

Vielleicht ist "Civilization: Call to Power" von der ehemaligen Firma Lokigames so ein Kandidat.

[
| Versenden | Drucken ]
  • 1
    Von Janka am Fr, 8. März 2019 um 13:34 #

    Du kannst in einem aktuellen MS-Windows 16-Bit-Binaries ausführen?

    [
    | Versenden | Drucken ]
    • 1
      Von Ghul am Fr, 8. März 2019 um 15:29 #

      Ja, kann ich, wenn es ein 32 Bit OS ist und die CPU somit im 32 Bit Modus arbeitet.

      Dass der Real Mode unter einem 64 Bit Windows nicht mehr funktioniert liegt nämlich nicht an Windows, sondern an der x64 Architektur. Der Long Mode unterstützt im Compatibility Mode nämlich keine 16 Bit Real Mode Programme.

      Siehe dazu:
      https://de.wikipedia.org/wiki/X64#Betriebsmodi
      und
      https://de.wikipedia.org/wiki/Virtual_DOS_Machine

      [
      | Versenden | Drucken ]
      • 1
        Von blubb am Fr, 8. März 2019 um 22:44 #

        Die Rückwärtskompatiblität unter Windows ist größtenteils grauenvoll. Da kommt es nicht zu selten vor, dass etwas ältere Windows Anwendungen mit Wine besser laufen als unter Windows 7/8/10.

        [
        | Versenden | Drucken ]
        • 1
          Von Andre am Sa, 9. März 2019 um 00:44 #

          >> Die Rückwärtskompatiblität unter Windows ist größtenteils grauenvoll.
          Die Rückwärts- sowie Vorwärtskompatibilität ist unter Windows in den allermeisten Fällen "deutlichst" besser als die Rückwärts- sowie Vorwärtskompatibilität von binär-appliationen unter gnu/linux.

          [
          | Versenden | Drucken ]
          • 1
            Von blubb am Sa, 9. März 2019 um 09:33 #

            Träum weiter ...

            [
            | Versenden | Drucken ]
            • 1
              Von Ghul am Sa, 9. März 2019 um 15:45 #

              Wieso? Er hat doch recht!

              Sobald du es unter Linux mit Programmen zu tun hast, die nur binär ohne Quellcode vorliegen, wird es sehr schwierig, diese über Jahre am Laufen zu halten.

              [
              | Versenden | Drucken ]
              • 1
                Von blubb am So, 10. März 2019 um 11:11 #

                Sobald du es unter Linux mit Programmen zu tun hast, die nur binär ohne Quellcode vorliegen, wird es sehr schwierig, diese über Jahre am Laufen zu halten.
                Das ist nur eine Frage der Libraries. Bei Windows werden diese vorgehalten, bei Linux nicht.
                Was meiner Meinung nach auch gut ist, denn wozu soll ich alten Schrott bereitstellen, den keiner mehr braucht, außer evtl. 0.002% der Nutzer?
                Das ist einfach nur total verschwendete Zeit.

                Die Programme selbst wären ansonsten ziemlich sicher lauffähig, da die Kernelschnittstellen über Jahrzehnte hinweg stabil gehalten werden.
                Ähnliches gilt auch für die glibc.

                Wenn man nun ein älteres Programm zum Laufen bekommen will, dann muss man sich also die Libraries besorgen. Das ist im Gegensatz zu dem was er geschrieben hat aber kein so großes Problem, denn man findet ja selbst für Debian 1.0 und ähnlich alte Distributionen noch die entsprechenden Daten.
                Die in ein aktuelles System einzubinden ist ein bisschen Aufwand, aber wenn einem diese Anwendung so wichtig ist (z.B. für den kommerziellen Einsatz?), dann sollte es auch kein Problem sein diesen Aufwand zu investieren. Man kann nicht immer erwarten, dass andere die Arbeit für einen erledigen.
                Mit den Libraries sollten dann keine bis wenige Probleme mehr auftreten.
                Und genau da unterscheidet es sich von Windows, denn unter Windows steigt dann ein Großteil der Anwendungen aus oder funktioniert nicht mehr richtig, da sie eben doch irgendwas an den Schnittstellen geändert haben.
                Natürlich bringt Windows genau dafür noch die Kompatibilitätsmodi mit, aber ehrlich gesagt habe ich noch nie erlebt, dass diese mal irgendwas geholfen hätten.
                Daher kann ich der Aussage einfach nicht zustimmen.

                [
                | Versenden | Drucken ]
                • 1
                  Von Ghul am So, 10. März 2019 um 17:05 #

                  Natürlich bringt Windows genau dafür noch die Kompatibilitätsmodi mit, aber ehrlich gesagt habe ich noch nie erlebt, dass diese mal irgendwas geholfen hätten.
                  Ich habe eine andere Erfahrung gemacht. Bei mir haben die schon oft geholfen.

                  Wenn du natürlich mit DRM zu kämpfen hast, z.B. StarForce, dann ist das ein ganz anderes Thema, dafür kann Windows aber nichts.
                  Für die reicht auch der Kompatibilitätsmodus logischerweise nicht aus.

                  [
                  | Versenden | Drucken ]
        1
        Von Andre am Sa, 9. März 2019 um 00:40 #

        danke für die ausführung :-)

        [
        | Versenden | Drucken ]
    1
    Von Luca Lindhorst am Fr, 8. März 2019 um 13:37 #

    Das ist nicht wahr. Dos-Executeables lassen sich auch ohne weiteres nicht mehr unter Win 10 ausführen. AFAIK ist z.B. der 16bit executable Support unter Linux auch noch vorhanden.

    Zumal das größte Problem ohnehin meist fehlende oder zu neue Std libs sind. Unter Linux kann man alte nachinstallieren oder ein komplett altes system auf neuem Kernel bauen, das geht bei Windows nicht.

    [
    | Versenden | Drucken ]
    • 1
      Von Ghul am Fr, 8. März 2019 um 15:36 #

      Siehe oben, das liegt an x64, nicht an Windows.


      Unter Windows werden die meisten Systemrelevanten DLLs auch in ihrer alten Majorversionsausführung in Windows mitgeliefert, was auch der Hauptgrund dafür ist, dass jedes Windows fetter ist als der Vorgänger.
      Fehlende libs und Runtimeumgebungen können nachinstalliert werden.
      Ich hatte jedenfalls noch nie ein Problem wegen Executables die zu alte DLLs verlangen.

      [
      | Versenden | Drucken ]
      • 1
        Von CRB am Fr, 8. März 2019 um 16:45 #

        Ich hatte jedenfalls noch nie ein Problem wegen Executables die zu alte DLLs verlangen.

        Ist das so? Gerade bei alten Video-Spielen gibt es gerade deshalb Patches, um diese überhaupt wieder lauffähig zu machen.

        Sowas kommt mir auch außerhalb von Videospielen ab und zu mal unter die Linse. Nur, weil dir es nicht passiert, heißt es nicht, dass es das Problem nicht gibt.

        Und übrigens: ältere Major-Versioinen von Bibliotheken lassen sich auch unter GNU/Linux parallel betreiben, jetzt kein Alleinstellungsmerkmal oder Vorteil von Windows.

        [
        | Versenden | Drucken ]
        • 1
          Von Ghul am Fr, 8. März 2019 um 18:37 #

          Ist das so? Gerade bei alten Video-Spielen gibt es gerade deshalb Patches, um diese überhaupt wieder lauffähig zu machen.
          Die Frage hier ist dann aber eher, was genau gepatched wird.
          Ein Patch, damit das Spiel anstatt auf DLL XY Version 1.0 auch auf DLL XY Version 1.1 läuft ist das eher nicht, denn DLL XY Version 1.1 ist abwärtskompatibel zu DLL XY Version 1.0.
          Und die neue Windows Version schleppt die dann mit, auch wenn diese selbst schon längst bei DLL XY Version 3.0 ist


          Sowas kommt mir auch außerhalb von Videospielen ab und zu mal unter die Linse. Nur, weil dir es nicht passiert, heißt es nicht, dass es das Problem nicht gibt.
          Wie schon gesagt, es kommt darauf an, was da genau gepatched wurde.
          Ich hatte mal ein Spiel, das W2K ready gemacht werden musste. Mit der DLL Version hatte das nichts zu tun.

          Ein anderes Spiel funktionierte nicht mit MutliCore CPUs zufriedenstellend und musste deswegen gepatched werden. Auch das hatte nichts mit der DLL Version zu tun.


          Und übrigens: ältere Major-Versioinen von Bibliotheken lassen sich auch unter GNU/Linux parallel betreiben, jetzt kein Alleinstellungsmerkmal oder Vorteil von Windows.
          Ich habe nicht behauptet, dass es ein Alleinstellungsmerkmal von Windows wäre.
          Natürlich kann man das auch unter Linux machen, aber üblich ist das oft nur dann, wenn es noch viele aktiv benutzte Open Source Software Produkte gibt, die nach einer alten Majorversion einer Lib verlangen.
          Sobald die meisten und wichtigsten aber auf die neue Majorversion umgestellt wurden, wird der Support fallen gelassen und die alte Lib aus dem Repo entfernt.

          Der User kann sie dann nur noch selbst compilieren und installieren oder sie sich über dubiose Drittrepos besorgen.

          qt < = 2.x findet sich bspw. nicht mehr in Debian stable.
          Gleiches gilt für gtk < 2.
          Du findest in Windows aber noch sehr wohl DLLs, die man verwendete, als die Entwickler noch mit Visual Studio 6.0 ihr Projekt compiliert haben.

          [
          | Versenden | Drucken ]
          • 1
            Von blubb am Sa, 9. März 2019 um 09:41 #

            qt < = 2.x findet sich bspw. nicht mehr in Debian stable.
            Gleiches gilt für gtk < 2.
            Du findest in Windows aber noch sehr wohl DLLs, die man verwendete, als die Entwickler noch mit Visual Studio 6.0 ihr Projekt compiliert haben.
            Und? Ist das so ein großes Problem?
            Nimm doch die aus einem älteren Repo oder von einem älteren Installationsmedium.

            Wenn du eine alte Software hast, die unbedingt auf dem neueren Rechner laufen muss, dann kann das mit ein bisschen Aufwand verbunden sein um die richtige Umgebung bereitzustellen, aber das ist unter Windows nicht anders.
            Wenn jemand ältere Software vertreiben will, dann steht es ihm dank GPL zudem auch frei die entsprechenden Bibliotheken gleich mitzuliefern, statisch zu linken o.ä.

            Ich persönlich finde es gut, dass man alten Schrott nicht mehr mit sich rum schleppt, insbesondere, wenn das nicht mehr aktualisiert wird (was sicherlich auch in Windows nicht der Fall ist).
            So werden Nutzer nicht dazu verleitet irgendwelchen alten Schrott zu installieren der voll mit bekannten Sicherheitslücken ist.
            Wozu brauchst du Qt 2.x? Nur um mal für 5min anzuschauen wie toll oder hässlich KDE2 war? Vermutlich irgendwie sowas.

            oh und btw, es gibt VM und darin kann man auch alte Distributionen laufen lassen. Ist nicht wirklich ein großer Aufwand und (genauso wie für ältere Windows Versionen und Software) in den meisten Fällen auch die bessere Variante als zu versuchen es direkt auszuführen.

            [
            | Versenden | Drucken ]
            • 1
              Von Ghul am Sa, 9. März 2019 um 15:55 #

              Und? Ist das so ein großes Problem?

              Bei Closed Source Programmen, bei der du nur Binaries hast, ja.
              Die brauchen nämlich die alten Libs und du kannst sie auch nicht an die neuen anpassen.

              Wenn du eine alte Software hast, die unbedingt auf dem neueren Rechner laufen muss, dann kann das mit ein bisschen Aufwand verbunden sein um die richtige Umgebung bereitzustellen, aber das ist unter Windows nicht anders.
              Doch.
              Bei Windows ist es meist die Regel, dass entweder die Software seine eigenen DLLs mitführt, womit es hier diesbezüglich schon einmal keine Probleme gibt oder Windows führt die alten DLLs mit.

              Ich persönlich finde es gut, dass man alten Schrott nicht mehr mit sich rum schleppt, insbesondere, wenn das nicht mehr aktualisiert wird (was sicherlich auch in Windows nicht der Fall ist).
              Ich bevorzuge es Software, für die ich viel Geld bezahlt habe, auch noch nach vielen Jahren benutzen zu können.
              Mit Windows geht das in den meisten Fällen problemlos, solange kein Kopierschutz mit eigenen Treibern dazwischen funkt.

              So werden Nutzer nicht dazu verleitet irgendwelchen alten Schrott zu installieren der voll mit bekannten Sicherheitslücken ist.
              Sicherheitslücken sind natürlich überall ein Problem, aber Nutzer werden alte Software für die sie Geld ausgegeben haben, trotzdem weiternutzen wollen.
              Für die Sicherheit muss man die dann eben vom Netz abschotten, dann geht das auch.

              Wozu brauchst du Qt 2.x? Nur um mal für 5min anzuschauen wie toll oder hässlich KDE2 war? Vermutlich irgendwie sowas.
              Es gibt ja immerhin schon einmal diese eine 2d CAD Software, die es auch als closed Source Version gibt.
              Ich habe die zwar nicht, aber die wäre so ein Kandidat, die früher Qt 2.x benutzt hat und jemand der so eine alte Version hat, der wird somit Qt 2.x benötigen.

              [
              | Versenden | Drucken ]
              • 1
                Von blubb am So, 10. März 2019 um 11:34 #

                Bei Closed Source Programmen, bei der du nur Binaries hast, ja.
                Die brauchen nämlich die alten Libs und du kannst sie auch nicht an die neuen anpassen.
                Dann installier halt die alten Libs. Sind frei verfügbar. Gerade Debian hat hier noch ein recht großes Archiv und bei Debian kann man ja jetzt nicht unbedingt von "dubiosen" Quellen sprechen, oder? ;)
                http://archive.debian.org/
                Ich bevorzuge es Software, für die ich viel Geld bezahlt habe, auch noch nach vielen Jahren benutzen zu können.
                Mit Windows geht das in den meisten Fällen problemlos, solange kein Kopierschutz mit eigenen Treibern dazwischen funkt.
                Tja, da habe ich andere Erfahrungen gemacht, nicht nur wegen Kopierschutz, sondern weil einfach Windows halt doch nicht wirklich rückwärtskompatibel ist.
                Aber zum Glück ist das in der heutigen Zeit eh kein großes Problem mehr, dank VM.
                Genau aus dem Grund habe ich auch noch Windows XP in einer VM installiert.

                Gerade bei Spielen habe ich aber auch so manches Spiel erneut gekauft, da die Versionen auf gog oder Steam manchmal dann doch noch einige Fixes mitbringen, die ansonsten nicht veröffentlicht wurden. (z.B. für Widescreen oder eben neuere Versionen, vom entfernten Starforce/Securom und ähnlichem Mist ganz zu schweigen)

                Ganz abgesehen davon gibt es für das von dir genannte Szenario auch schlicht keine wirkliche Grundlage.
                Die Software wird nämlich in allen Fällen für ein bestimmtes Betriebssystem verkauft, d.h. da steht dann drauf, dass sie für Windows 98/ME/XP oder was auch immer ist.
                Das ist auch unter Linux so.
                Alles andere darüber hinaus kann man mehr oder weniger als Glück verbuchen, kann laufen, kann aber auch schief gehen. Beides oft genug erlebt.

                Es gibt ja immerhin schon einmal diese eine 2d CAD Software, die es auch als closed Source Version gibt.
                Ich habe die zwar nicht, aber die wäre so ein Kandidat, die früher Qt 2.x benutzt hat und jemand der so eine alte Version hat, der wird somit Qt 2.x benötigen.
                Nun, gibt doch 2 praktikable Lösungen:
                1. Entsprechende Distribution in einer VM installieren (dürfte die einfachste Variante sein)
                2. Libraries aus Debian 2(?) auf neueres System migrieren, sollte dann auch laufen.

                Ich sehe da einfach nicht das große Problem, sorry.
                Und vor allem sehe ich nach wie vor nicht ein, dass für solche Corner Cases dann Menschen völlig unnötig ihre Zeit verschwenden sollen um die alten Pakete zu maintainen.
                Insbesondere, da diese das ja oft in ihrer Freizeit machen.

                [
                | Versenden | Drucken ]
        1
        Von Anon Y. Mouse am Sa, 9. März 2019 um 17:26 #

        Wenns nur an der CPU liegen würde, wie wäre es da möglich das gleiche 16bit Programm unter wine laufen zu lassen? Nota bene ebenfalls auf einem 64bit Kernel?

        [
        | Versenden | Drucken ]
        • 1
          Von Ghul am Sa, 9. März 2019 um 23:16 #

          In dem man die Hardware in Software emuliert und somit die Ausführung von Real-Mode Programmen ermöglicht.

          Wenn ich mich nicht irre, dann macht ReactOS und Wine genau das.

          [
          | Versenden | Drucken ]
          • 1
            Von Ghul am Sa, 9. März 2019 um 23:17 #

            Wenn ich mich nicht irre, dann macht ReactOS und Wine genau das.

            Also bei 16 Bit Real-Mode Programmen. Also nicht generell.

            [
            | Versenden | Drucken ]
            1
            Von Ghul am Sa, 9. März 2019 um 23:23 #

            Hier steht es:

            One thing to note about ReactOS' NTVDM is that unlike Windows' version ReactOS' does not set the CPU into a 16bit emulated mode. This mode in theory reduces overhead compared to the emulation done by ReactOS, but CPUs these days are fast enough that performance should not be an issue. An advantage of ReactOS' approach though is that our NTVDM is usable on 64bit x86 processors and potentially ARM processors as well.
            https://reactos.org/node/794

            Es wird also, wie ich sagte, die Hardware für 16 Bit Programme emuliert, anstatt die echte Hardware in den Compatibility Mode zu schalten.
            Das erklärt dann auch, warum 16 Bit Realmode Programme, die für die x86 Architektur geschrieben wurden unter ReactOS auch auf ARM Prozessoren laufen sollen, gesetzt den Fall, man würde ReactOS nach ARM portieren.

            [
            | Versenden | Drucken ]
            1
            Von Ghul am Sa, 9. März 2019 um 23:30 #

            Noch etwas.
            Ja, man darf sich natürlich fragen, warum Microsoft das nicht aus so macht.

            Dazu gibt es drei mögliche Antworten, die alle gültig sein können:
            1. Die ntvdm von Windows ist historisch gewachsen und das Problem mit Real-Mode Programmen gab es zu Zeiten von 32 Bit Windows Versionen und 32 Bit CPUs noch gar nicht. Die 16 Real Mode Programme liefen also auch so.

            2. Die Emulation in Software kostet mehr Leistung. Das erklärt den historischen Schritt von früher, heute könnte man es auch anders machen, wenn da nicht der dritte Punkt wäre.

            3. Die ISA der x86 Architektur gehört Intel. Würde Microsoft diese in Software emulieren, dann wären Lizenzkosten denkbar.

            [
            | Versenden | Drucken ]
      1
      Von Andre am Sa, 9. März 2019 um 00:50 #

      weenn die kompatbilät so doll wäre wie du behauptest:
      * dann versuch mal xmms1 unter debian10 ans laufen zu bekommen.
      * dann versuch mal kdevelop 5.3 mit unter debian8 ans laufen zu bekommen.
      * dann versuch mal ein aktuelles crossover unter debian8 ans laufen zu bekommen.
      * dann versuch mal ein teuer gekauftes vmware10 unter debian10 ans laufen zu bekommen.

      jeweils stundenlange recherchearbeiten notwendig. mal ganz davon abgesehen das man sich erstmal beibringen darf wie appliukationen compiliert werden, wie das dateisystem aufgebaut ist und und und...

      [
      | Versenden | Drucken ]
      • 1
        Von blablabla233 am So, 10. März 2019 um 11:22 #

        Hihi er hat vmware gekauft :D :D hast du auch WinRar gekauft? ;)

        [
        | Versenden | Drucken ]
        0
        Von 1ras am Sa, 16. März 2019 um 03:45 #

        * dann versuch mal xmms1 unter debian10 ans laufen zu bekommen.

        Simple Aufgabe, wozu gibt es schließlich das Debian Archiv oder die Debian Snapshots:

        echo "deb [trusted=yes] http://archive.debian.org/debian/ etch main contrib" >> /etc/apt/sources.list.d/xmms.list
        apt-get update
        apt-get install xmms

        Und der Rest macht eh keinen Sinn. kdevelop und crossover sind zu neu und nicht zu alt, also das genau Gegenteil um was es bei dieser Diskussion geht. Und vmware10 wird schlicht daran scheitern, dass deren Kernelmodul nicht mehr kompatibel ist. Das ist eine bekannte Krankheit die VMWare seitdem es sie gibt noch nie auf die Reihe bekommen hat, das ist nichts anderes als wenn es auf ebay für Linux-Anweder wieder günstige Hardware gibt, weil Windows mit dem alten Treiber nicht mehr kann und der Hersteller natürlich lieber neue Hardware verkauft.

        [
        | Versenden | Drucken ]
    1
    Von nix_Windoof am Fr, 8. März 2019 um 15:37 #

    Anders als unter Windoof ist es kein Problem, eine neue "a.out" im neuen Format unter einem aktuellen Linux zu kompilieren, sofern der Quellcode vorhanden ist (und die Bibliotheken verfügbar). Open-Source macht das alles sehr einfach. Da kann man heute auch noch ggf. den Quellcode anpassen.

    [
    | Versenden | Drucken ]
    • 1
      Von Ghul am Fr, 8. März 2019 um 15:43 #

      Wenn du den Quellcode hast, dann kannst du so etwas auch unter Windows machen.
      Das Argument zählt also nicht.

      Oder anders gesagt, du brauchst nicht so zu tun, als gäbe es unter Linux keine closed Source Software.

      [
      | Versenden | Drucken ]
mehr Oha
0
Von Leser am Fr, 8. März 2019 um 21:12 #

Korrekturlesen wird überbewertet

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung