1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › WSL 2 in Windows 11: Von der…

WINE

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. WINE

    Autor: TarikVaineTree 21.10.21 - 08:54

    WINE spielt inzwischen mehr Programme ab als Windows 10, einfach da es dank alter Windowsversionen auch uralten Kram immer noch prima startbar macht.
    Ich habe mich nie wirklich mit WSL beschäftigt, aber nützt mir das irgendwie was um per WINE sonst nicht startbare Software unter modernen Windowsversionen starten zu können?
    WINE übersetzt ja egtl. nur syscalls von Windows in syscalls für Linux. Macht das mit WSL Sinn?

    Und nein: Der Kompatibilitätsmodus von Windows hilft nicht immer.

  2. Re: WINE

    Autor: hum4n0id3 21.10.21 - 09:13

    TarikVaineTree schrieb:
    --------------------------------------------------------------------------------
    > WINE spielt inzwischen mehr Programme ab als Windows 10, einfach da es dank
    > alter Windowsversionen auch uralten Kram immer noch prima startbar macht.
    > Ich habe mich nie wirklich mit WSL beschäftigt, aber nützt mir das
    > irgendwie was um per WINE sonst nicht startbare Software unter modernen
    > Windowsversionen starten zu können?
    > WINE übersetzt ja egtl. nur syscalls von Windows in syscalls für Linux.
    > Macht das mit WSL Sinn?
    >
    > Und nein: Der Kompatibilitätsmodus von Windows hilft nicht immer.

    WSL ist etwas völlig anders. Hier wird nichts übersetzt, sondern es läuft ein Linux-System neben Windows. Auf dieses Linux kannst du dann unter Windows zugreifen. Meist wird in der Entwicklung dazu Docker installiert um sogenannte Container nutzen zu können. Das sind an sich abgeschottete Prozesse die alle denselben Linux-Kernel nutzen. In den Container kannst du alles reinlegen was du möchtest. Java-Umgebung, LAMPP-Umgebung usw. Die Container bleiben dabei immer so wie sie gebaut wurden.

    So kannst du zum Beispiel mehrere Kunden bedienen. Der eine Kunde hat noch eine Software die läuft noch auf Java 6, oder PHP5. Der andere Kunde aber das neueste vom neustem. Das ist für den Container uninteressant, weil sich alle Abhängigkeiten auch im Container befinden.

    Ein Vergleich zwischen WINE und WSL hinkt also gewaltig.

  3. Re: WINE

    Autor: Tiles 21.10.21 - 09:49

    Der hinkt auch deshalb weil auf Windows alles auf Platin läuft ...

  4. Re: WINE

    Autor: hum4n0id3 21.10.21 - 10:26

    Tiles schrieb:
    --------------------------------------------------------------------------------
    > Der hinkt auch deshalb weil auf Windows alles auf Platin läuft ...

    Weil das völlig unterschiedliche Technologien mit Zielsetzungen darstellen. WSL mit Docker macht etwas völlig anderes als WINE.

  5. Re: WINE

    Autor: TarikVaineTree 21.10.21 - 10:59

    hum4n0id3 schrieb:
    --------------------------------------------------------------------------------
    > TarikVaineTree schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > WINE spielt inzwischen mehr Programme ab als Windows 10, einfach da es
    > dank
    > > alter Windowsversionen auch uralten Kram immer noch prima startbar
    > macht.
    > > Ich habe mich nie wirklich mit WSL beschäftigt, aber nützt mir das
    > > irgendwie was um per WINE sonst nicht startbare Software unter modernen
    > > Windowsversionen starten zu können?
    > > WINE übersetzt ja egtl. nur syscalls von Windows in syscalls für Linux.
    > > Macht das mit WSL Sinn?
    > >
    > > Und nein: Der Kompatibilitätsmodus von Windows hilft nicht immer.
    >
    > WSL ist etwas völlig anders. Hier wird nichts übersetzt, sondern es läuft
    > ein Linux-System neben Windows. Auf dieses Linux kannst du dann unter
    > Windows zugreifen. Meist wird in der Entwicklung dazu Docker installiert um
    > sogenannte Container nutzen zu können. Das sind an sich abgeschottete
    > Prozesse die alle denselben Linux-Kernel nutzen. In den Container kannst du
    > alles reinlegen was du möchtest. Java-Umgebung, LAMPP-Umgebung usw. Die
    > Container bleiben dabei immer so wie sie gebaut wurden.
    >
    > So kannst du zum Beispiel mehrere Kunden bedienen. Der eine Kunde hat noch
    > eine Software die läuft noch auf Java 6, oder PHP5. Der andere Kunde aber
    > das neueste vom neustem. Das ist für den Container uninteressant, weil sich
    > alle Abhängigkeiten auch im Container befinden.
    >
    > Ein Vergleich zwischen WINE und WSL hinkt also gewaltig.

    Augenblick. Docker kann ich doch auch einfach direkt in Windows nutzen um verschiedene PHP-Setups usw. zu haben.
    Ich dachte, mit WSL installiert man quasi eine Distro (z. B. Arch), dann kann ich mit pacman Pakete installieren und Linuxanwendungen (wie im Artikel Firefox) in einem Fenster starten, das sich dann einfach in Windows zu den anderen (nativen) Fenstern gesellt, nur dass es eben die Linux-UI hat, weil es von Linux befeuert wird. Genau das finde ich ja sehr reizvoll. Nicht eine VM in einem Fenster starten, wo ich dann einen kompletten Desktopscreen habe und ein Öffnen einer Anwendung dann quasi ein Fenster in einem Fenster (vom Hostsystem aus betrachtet) öffnet, sondern ich habe direkt in Windows ein natives Windowsfirefoxfenster und daneben (!) z. B. ein Linuxfirefoxfenster, ohne dass dahinter/darum ein kompletter Linuxdesktop angezeigt wird (auch wenn dieser im Hintergrund meinetwegen läuft). Oder habe ich das falsch verstanden?
    Und dann müsste ich doch - wie eben den Linuxfirefox - einfach WINE in meinem WSL Arch Linux nutzen können, sodass ich eine Exe mit WINE innerhalb des Archlinux starte und die Anwendung verhält sich dann so, als hätte ich sie in einer Arch-VM mit WINE gestartet. Oder nicht?

    Tiles schrieb:
    --------------------------------------------------------------------------------
    > Der hinkt auch deshalb weil auf Windows alles auf Platin läuft ...

    Nein, eben nicht. Wie ich schon schrieb. Vor allem ältere Anwendungen laufen öfter mit WINE als mit W10+. Daher meine Frage.
    Der Witz ist nämlich, dass ich in einem aktuellen Linux dank des bemerkenswerten aktuellen Standes von WINE neben all den Linuxvorteilen auch mehr Windowsapps nutzen kann, als in Windows selbst. Es bleiben nur 2 Nachteile wenn man so will, die ich entgegnen würde, wenn du jetzt vorschlagen würdest "Dann bleib doch einfach komplett bei Linux?", die da wären:
    1. Es gibt immer mal wieder 1 - 2 sehr aktuelle Windows-Programme, die man dann doch mal nutzen möchte, die eben noch nicht mit WINE laufen.
    2. Bei aller Liebe und Schönreden: Linux bleibt - vor allem was WINE betrifft - immer etwas frickelig. Ich kann jeden Fehler googlen und kriege die meisten dann beseitigt, also nix Unlösbares oder so, ABER es kostet halt immer mal wieder etwas Zeit, wenn eine Windowsapp ein Update erhielt und WINE damit nicht klar kommt. Und Zeit ist kostbarer je älter man wird, vor allem bei 40h-Woche und Familie.

  6. Re: WINE

    Autor: Tiles 21.10.21 - 11:16

    >Nein, eben nicht. Wie ich schon schrieb. Vor allem ältere Anwendungen laufen öfter mit WINE als mit W10+. Daher meine Frage.

    Das ändert doch aber nichts daran dass 95% der Programme in WINE eben kein Platin sind. Software verwendet man am Besten auf dem System für das sie entwickelt wurden.

  7. Re: WINE

    Autor: tomatentee 21.10.21 - 11:30

    TarikVaineTree schrieb:
    --------------------------------------------------------------------------------
    > hum4n0id3 schrieb:
    > ---------------------------------------------------------------------------

    > > Ein Vergleich zwischen WINE und WSL hinkt also gewaltig.
    >
    > Augenblick. Docker kann ich doch auch einfach direkt in Windows nutzen um
    > verschiedene PHP-Setups usw. zu haben.
    >
    Jein, im Hintergrund startet Docker immer ne Linux-VM. Docker braucht nen Linux-Kernel (es gibt auch Windows-Container, die nutzt aber kein Mensch).


    > Ich dachte, mit WSL installiert man quasi eine Distro (z. B. Arch), dann
    > kann ich mit pacman Pakete installieren und Linuxanwendungen (wie im
    > Artikel Firefox) in einem Fenster starten, das sich dann einfach in Windows
    > zu den anderen (nativen) Fenstern gesellt, nur dass es eben die Linux-UI
    > hat, weil es von Linux befeuert wird. Genau das finde ich ja sehr reizvoll.
    >
    WSL1 war wie WINE eine Linux-Emulation. VSL2 startet Jim Hintergrund ne Linux-VM. Der Unterschied ist nur, dass du keinen Linux-Desktop siehst sondern nur die einzelnen Fenster. Ist im Prinzip das klassische X-Forwarding, geht jetzt aber halt auch unter Windows.

  8. Re: WINE

    Autor: hum4n0id3 21.10.21 - 11:46

    TarikVaineTree schrieb:
    --------------------------------------------------------------------------------
    > Augenblick. Docker kann ich doch auch einfach direkt in Windows nutzen um
    > verschiedene PHP-Setups usw. zu haben.

    Es geht auch um das Deployen von Containern, die später eben auf Linux laufen. Du kannst verschiedene Setups machen und veröffentlichen. Keine Konfiguration etc. mehr notwendig. Man kann unter Windows auch ohne Docker mehrere PHP-Versionen nutzen, dafür muss man dann aber auch Linux-Webserver nachträglich anpassen usw. Mit Docker kann man auf Windows entwickeln und auf Linux laufen lassen. Da ist ungefähr so als wenn man eine CD in den Musik-Player einlegt und es spielt los.

    > Ich dachte, mit WSL installiert man quasi eine Distro (z. B. Arch), dann
    > kann ich mit pacman Pakete installieren und Linuxanwendungen (wie im
    > Artikel Firefox) in einem Fenster starten, das sich dann einfach in Windows
    > zu den anderen (nativen) Fenstern gesellt, nur dass es eben die Linux-UI
    > hat, weil es von Linux befeuert wird. Genau das finde ich ja sehr reizvoll.

    Das ist was neuerdings möglich sein soll. Meines Wissens nach wurde WSL entwickelt um eben die Container-Technologie auch unter Windows für Entwickler verfügbar zu machen.

    > Nicht eine VM in einem Fenster starten, wo ich dann einen kompletten
    > Desktopscreen habe und ein Öffnen einer Anwendung dann quasi ein Fenster in
    > einem Fenster (vom Hostsystem aus betrachtet) öffnet, sondern ich habe
    > direkt in Windows ein natives Windowsfirefoxfenster und daneben (!) z. B.
    > ein Linuxfirefoxfenster, ohne dass dahinter/darum ein kompletter
    > Linuxdesktop angezeigt wird (auch wenn dieser im Hintergrund meinetwegen
    > läuft). Oder habe ich das falsch verstanden?

    Das soll eben jetzt ermöglicht werden.

    > Und dann müsste ich doch - wie eben den Linuxfirefox - einfach WINE in
    > meinem WSL Arch Linux nutzen können, sodass ich eine Exe mit WINE innerhalb
    > des Archlinux starte und die Anwendung verhält sich dann so, als hätte ich
    > sie in einer Arch-VM mit WINE gestartet. Oder nicht?
    >

    Das ist ehrlich gesagt eine sehr Abenteuerliche Konstellation. Meine Frage wäre warum du es so machen willst? Du hast ein vollwertiges Windows und nebenher läuft Linux, wo du dann Wine installieren möchtest um Windows Software zu nutzen. Wine ist hier vollkommen überflüssig weil du deine Windows-Software nativ nutzen kannst.

    > Nein, eben nicht. Wie ich schon schrieb. Vor allem ältere Anwendungen
    > laufen öfter mit WINE als mit W10+. Daher meine Frage.
    > Der Witz ist nämlich, dass ich in einem aktuellen Linux dank des
    > bemerkenswerten aktuellen Standes von WINE neben all den Linuxvorteilen
    > auch mehr Windowsapps nutzen kann, als in Windows selbst. Es bleiben nur 2
    > Nachteile wenn man so will, die ich entgegnen würde, wenn du jetzt
    > vorschlagen würdest "Dann bleib doch einfach komplett bei Linux?", die da
    > wären:
    > 1. Es gibt immer mal wieder 1 - 2 sehr aktuelle Windows-Programme, die man
    > dann doch mal nutzen möchte, die eben noch nicht mit WINE laufen.
    > 2. Bei aller Liebe und Schönreden: Linux bleibt - vor allem was WINE
    > betrifft - immer etwas frickelig. Ich kann jeden Fehler googlen und kriege
    > die meisten dann beseitigt, also nix Unlösbares oder so, ABER es kostet
    > halt immer mal wieder etwas Zeit, wenn eine Windowsapp ein Update erhielt
    > und WINE damit nicht klar kommt. Und Zeit ist kostbarer je älter man wird,
    > vor allem bei 40h-Woche und Familie.

    Ist natürlich deine Sache aber es sieht für mich so aus als ob du das falsche System nutzt.

  9. Re: WINE

    Autor: TarikVaineTree 21.10.21 - 13:15

    tomatentee schrieb:
    --------------------------------------------------------------------------------
    > TarikVaineTree schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > hum4n0id3 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > > Ein Vergleich zwischen WINE und WSL hinkt also gewaltig.
    > >
    > > Augenblick. Docker kann ich doch auch einfach direkt in Windows nutzen
    > um
    > > verschiedene PHP-Setups usw. zu haben.
    > >
    > Jein, im Hintergrund startet Docker immer ne Linux-VM. Docker braucht nen
    > Linux-Kernel (es gibt auch Windows-Container, die nutzt aber kein Mensch).
    Ah gut, war mir nie bewusst, da ich Docker bisher nur in Mac OS und Linux nutzte, aber sah, dass es auch 'ne Windows-Anwendung gibt. Danke für die Aufklärung. Dann macht das mit Docker schon mal Sinn.

    > > Ich dachte, mit WSL installiert man quasi eine Distro (z. B. Arch), dann
    > > kann ich mit pacman Pakete installieren und Linuxanwendungen (wie im
    > > Artikel Firefox) in einem Fenster starten, das sich dann einfach in
    > Windows
    > > zu den anderen (nativen) Fenstern gesellt, nur dass es eben die Linux-UI
    > > hat, weil es von Linux befeuert wird. Genau das finde ich ja sehr
    > reizvoll.
    > >
    > WSL1 war wie WINE eine Linux-Emulation. VSL2 startet Jim Hintergrund ne
    > Linux-VM. Der Unterschied ist nur, dass du keinen Linux-Desktop siehst
    > sondern nur die einzelnen Fenster. Ist im Prinzip das klassische
    > X-Forwarding, geht jetzt aber halt auch unter Windows.

    Fast. WINE war und ist kein Emulator, sondern übersetzt nur Syscalls. Aber wenn das X-Forwarding - wie du es nennst - nun somit auch unter Windows geht, ist das schon mal etwas für mich. :)

    Tiles schrieb:
    --------------------------------------------------------------------------------
    > >Nein, eben nicht. Wie ich schon schrieb. Vor allem ältere Anwendungen
    > laufen öfter mit WINE als mit W10+. Daher meine Frage.
    >
    > Das ändert doch aber nichts daran dass 95% der Programme in WINE eben kein
    > Platin sind. Software verwendet man am Besten auf dem System für das sie
    > entwickelt wurden.

    Sicher tut man das, aber nach der Logik käme man ja nie zu einer Alltagslösung, wo man im OS seiner Wahl alles nutzen kann, was man möchte. Um genau das zu ermöglichen, gibt es Projekte wie WINE ja überhaupt (und nun andersrum ja auch WSL).
    Außerdem, was kümmerts mich, wenn andererseits mind. 95% der Programme, die MIR wichtig sind, in WINE problemlos laufen? Die "Frickelei", die ich weiter oben beschrieb, hat man in der Regel nur mit Anwendungen, die nochmal ein Update erhalten haben und wenn man dieses Update auch unbedingt nutzen möchte, es aber dann mit WINE nicht so 100%ig lief wie vor dem Update der Anwendung. Aber vor allem bei Windows-Spielen, die irgendwann mal als "abgeschlossen" gelten, einfach weil es Nachfolger gibt oder sie schon 5+ Jahre alt sind und der Entwickler die eh nicht mehr anfasst, gilt ja dann: Wenn sie in WINE in ihrer jeweils letzten Patch-Version 1x laufen, tun sie das auch weiterhin und ich brauche mich nicht mehr darum zu scheren. Bestenfalls notiere ich mir die WINE-Version, falls neuere WINE-Updates die Kompatibilität mal breaken (wobei das zum Glück ja schon die Community auf winehq übernimmt).

    Diese Debatte und deine Überzeugungsversuche tun aber letztlich auch gar nichts zur Sache, da es mir hier viel mehr darum ging, einige wenige ganz bestimmte Anwendungen/Spiele mittels WSL+WINE in einem W10/W11 nutzen zu können, die so alt sind, dass sie unter Windows eben nicht mehr laufen, unter WINE in Linux aber schon. Und da ich hier den Weg sah, dass ich solche Apps dann trotzdem normal in einem Fenster in Windows haben kann, ohne dafür erst eine komplette VM zu starten, INNERHALB DERER das Fenster der App dann startet, eröffnete ich diesen Thread, um die bereits erfahrenen Hasen zu fragen, ob das geht.

    hum4n0id3 schrieb:
    --------------------------------------------------------------------------------
    > TarikVaineTree schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Augenblick. Docker kann ich doch auch einfach direkt in Windows nutzen
    > um
    > > verschiedene PHP-Setups usw. zu haben.
    >
    > Es geht auch um das Deployen von Containern, die später eben auf Linux
    > laufen. Du kannst verschiedene Setups machen und veröffentlichen. Keine
    > Konfiguration etc. mehr notwendig. Man kann unter Windows auch ohne Docker
    > mehrere PHP-Versionen nutzen, dafür muss man dann aber auch Linux-Webserver
    > nachträglich anpassen usw. Mit Docker kann man auf Windows entwickeln und
    > auf Linux laufen lassen. Da ist ungefähr so als wenn man eine CD in den
    > Musik-Player einlegt und es spielt los.
    Verstehe.
    > > Ich dachte, mit WSL installiert man quasi eine Distro (z. B. Arch), dann
    > > kann ich mit pacman Pakete installieren und Linuxanwendungen (wie im
    > > Artikel Firefox) in einem Fenster starten, das sich dann einfach in
    > Windows
    > > zu den anderen (nativen) Fenstern gesellt, nur dass es eben die Linux-UI
    > > hat, weil es von Linux befeuert wird. Genau das finde ich ja sehr
    > reizvoll.
    >
    > Das ist was neuerdings möglich sein soll. Meines Wissens nach wurde WSL
    > entwickelt um eben die Container-Technologie auch unter Windows für
    > Entwickler verfügbar zu machen.
    Top.
    > > Nicht eine VM in einem Fenster starten, wo ich dann einen kompletten
    > > Desktopscreen habe und ein Öffnen einer Anwendung dann quasi ein Fenster
    > in
    > > einem Fenster (vom Hostsystem aus betrachtet) öffnet, sondern ich habe
    > > direkt in Windows ein natives Windowsfirefoxfenster und daneben (!) z.
    > B.
    > > ein Linuxfirefoxfenster, ohne dass dahinter/darum ein kompletter
    > > Linuxdesktop angezeigt wird (auch wenn dieser im Hintergrund meinetwegen
    > > läuft). Oder habe ich das falsch verstanden?
    >
    > Das soll eben jetzt ermöglicht werden.
    Immer noch top.
    > > Und dann müsste ich doch - wie eben den Linuxfirefox - einfach WINE in
    > > meinem WSL Arch Linux nutzen können, sodass ich eine Exe mit WINE
    > innerhalb
    > > des Archlinux starte und die Anwendung verhält sich dann so, als hätte
    > ich
    > > sie in einer Arch-VM mit WINE gestartet. Oder nicht?
    > >
    >
    > Das ist ehrlich gesagt eine sehr Abenteuerliche Konstellation. Meine Frage
    > wäre warum du es so machen willst? Du hast ein vollwertiges Windows und
    > nebenher läuft Linux, wo du dann Wine installieren möchtest um Windows
    > Software zu nutzen. Wine ist hier vollkommen überflüssig weil du deine
    > Windows-Software nativ nutzen kannst.
    Ich habe es oben bereits mehrere Male erwähnt: Für Edge Cases -> ältere Windowsprogramme, die eben NICHT mehr unter Windows 10+ laufen.
    > > Nein, eben nicht. Wie ich schon schrieb. Vor allem ältere Anwendungen
    > > laufen öfter mit WINE als mit W10+. Daher meine Frage.
    > > Der Witz ist nämlich, dass ich in einem aktuellen Linux dank des
    > > bemerkenswerten aktuellen Standes von WINE neben all den Linuxvorteilen
    > > auch mehr Windowsapps nutzen kann, als in Windows selbst. Es bleiben nur
    > 2
    > > Nachteile wenn man so will, die ich entgegnen würde, wenn du jetzt
    > > vorschlagen würdest "Dann bleib doch einfach komplett bei Linux?", die
    > da
    > > wären:
    > > 1. Es gibt immer mal wieder 1 - 2 sehr aktuelle Windows-Programme, die
    > man
    > > dann doch mal nutzen möchte, die eben noch nicht mit WINE laufen.
    > > 2. Bei aller Liebe und Schönreden: Linux bleibt - vor allem was WINE
    > > betrifft - immer etwas frickelig. Ich kann jeden Fehler googlen und
    > kriege
    > > die meisten dann beseitigt, also nix Unlösbares oder so, ABER es kostet
    > > halt immer mal wieder etwas Zeit, wenn eine Windowsapp ein Update
    > erhielt
    > > und WINE damit nicht klar kommt. Und Zeit ist kostbarer je älter man
    > wird,
    > > vor allem bei 40h-Woche und Familie.
    >
    > Ist natürlich deine Sache aber es sieht für mich so aus als ob du das
    > falsche System nutzt.


    Ich nutze tatsächlich alle 3 großen Desktop-OS auf verschiedenen Geräten. Gerade darum bin ich auch immer sehr interessiert daran, prinzipiell (!) möglichst "alles", was ich nutzen möchte, auf jedem System nutzen zu können. Dass dieses Ideal vermutlich nie erreicht werden kann, ist klar. Dennoch spricht ja nichts dagegen, danach zu streben.

    Übrigens noch anderthalb gute Gründe für WINE in WSL:
    1. -> Ich kann Windows-Apps in einer Sandbox betreiben oder gar zwei Instanzen ein und der selben App installieren (1x in Windows nativ, 1x in WINE), so ich denn möchte.
    1,5. -> WINE32 unterstützt 16bit-Apps, d.h. damit kann ich ohne DosBox (in dem ich erst Windows installieren müsste) alles ab Windows 3.x direkt in Windows 10+ nutzen. Dies ist nur ein halbes Argument, da WINE32 leider (noch?) nicht von WSL unterstützt wird, sondern nur (Überraschung) WINE64. Ich für meinen Teil würde allein aus nostalgischen Gründen gern das alte Microsoft Entertainment Pack in Windows 10+ installieren, nebst einigen anderen alten 16bit-Spielen (etwa "Mamba").



    1 mal bearbeitet, zuletzt am 21.10.21 13:24 durch TarikVaineTree.

  10. Re: WINE

    Autor: TarikVaineTree 21.10.21 - 13:22

    Interessant dazu noch:
    https://www.youtube.com/watch?v=gq4H21uyWBw

  11. Re: WINE

    Autor: Smaxx 21.10.21 - 15:16

    Falls es dir um klassische 16-Bit-Windowsprogramme geht, guck dir doch mal winevdm an, das ist effektiv ein Fork bzw. eine Nachbildung von Wine, die sich in das bei Windows ohnehin vorhandene Kompatibilitätssystem hängt und so effektiv bei einem 64-Bit-Windows die Unterstützung bzw. Umleitung von Systemaufrufen für 16-Bit-Programme "nachpatched" (also das, was damals beim Umstieg auf 64 Bit rausgeflogen ist).

    Sonstige (32-Bit-)Programme sollten mit den ganzen Emulations-/Kompatibilitätsmitteln von Windows laufen, wenn nicht gerade ein nicht signierter Kopierschutztreiber dazwischengrätscht. In dem Fall wäre dann wohl eher eine richtige Windows-VM ideal.

  12. Re: WINE

    Autor: TarikVaineTree 21.10.21 - 16:39

    Smaxx schrieb:
    --------------------------------------------------------------------------------
    > Falls es dir um klassische 16-Bit-Windowsprogramme geht, guck dir doch mal
    > winevdm an, das ist effektiv ein Fork bzw. eine Nachbildung von Wine, die
    > sich in das bei Windows ohnehin vorhandene Kompatibilitätssystem hängt und
    > so effektiv bei einem 64-Bit-Windows die Unterstützung bzw. Umleitung von
    > Systemaufrufen für 16-Bit-Programme "nachpatched" (also das, was damals
    > beim Umstieg auf 64 Bit rausgeflogen ist).
    >
    > Sonstige (32-Bit-)Programme sollten mit den ganzen
    > Emulations-/Kompatibilitätsmitteln von Windows laufen, wenn nicht gerade
    > ein nicht signierter Kopierschutztreiber dazwischengrätscht. In dem Fall
    > wäre dann wohl eher eine richtige Windows-VM ideal.


    Danke. Darauf stieß ich vorhin auch. Scheint dann doch die bessere Lösung für mich zu sein, als mit Kanonen auf Spatzen zu schießen. Mal sehen, wie es sich in der Praxis schlägt.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Sachbearbeiterinnen / Sachbearbeiter (w/m/d) - Cyber-Sicherheit in Smart Home und Smart Cities
    Bundesamt für Sicherheit in der Informationstechnik, Bonn
  2. Android-Entwickler (m/w/d) - Connected Car
    e.solutions GmbH, Ingolstadt
  3. Technical Account Manager (m/f/d)
    SoSafe GmbH, Köln (Home-Office möglich)
  4. Softwareentwickler C# / .NET (m/w/d)
    IS Software GmbH, Regensburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 29,99€
  2. 12,49€
  3. (u. a. Hades PS5 für 15,99€, Doom Eternal PC inkl. Metal Plate für 14,99€,)
  4. 1.000€ MMOGA-Gutschein gewinnen


Haben wir etwas übersehen?

E-Mail an news@golem.de


Discovery Staffel 4: Star Trek mit viel zu viel Pathos
Discovery Staffel 4
Star Trek mit viel zu viel Pathos

Die ersten beiden Folgen der neuen Staffel von Star Trek Discovery bieten zwar interessante Story-Ansätze, gehen aber in teils unerträglichen Gefühlsduseleien unter. Achtung, Spoiler!
Eine Rezension von Tobias Költzsch

  1. Pluto TV Star Trek Discovery kommt doch schon nach Deutschland
  2. Star Trek Discovery kommt nicht mehr auf Netflix

Energiewende: Akkupreise steigen wegen zu hoher Rohstoffkosten
Energiewende
Akkupreise steigen wegen zu hoher Rohstoffkosten

Die Party ist vorbei. Statt billiger, sollen Akkus durch neue Rekorde beim Lithiumpreis und anderen Rohstoffen im Jahr 2022 sogar teurer werden.
Eine Analyse von Frank Wunderlich-Pfeiffer

  1. Nachhaltigkeit Mehr Haushalte investieren in die Energiewende
  2. P2P-Energiehandel Lieber Nachbar, hätten Sie noch etwas Strom für mich?
  3. Erneuerbare Energien Schottland plant ersten Windpark mit Wasserstoffgewinnung

Koalitionsvertrag: Zeitenwende bei der IT-Sicherheit
Koalitionsvertrag
Zeitenwende bei der IT-Sicherheit

In der Ampelkoalition deuten sich große Veränderungen bei der IT-Sicherheit an. Wir haben uns den Koalitionsvertrag genauer angeschaut.
Eine Analyse von Friedhelm Greis

  1. Security Hacker veröffentlichen Daten nach Angriff auf Stadt Witten
  2. Prosite Anonymous hackt Hildmann-Hoster
  3. Security IT-Angriff legt Stadtverwaltung Witten lahm