mboost-dp1
Valve
De kunne starte med at lave et SteamOS der nemt lader brugerne køre spil fra alle kilder, ikke kun Steam?
De kunne sørge for at alt der smager af forbedring af spille muligheder på linux var en del af det OS og at det var nemt at opdatere OS plus drivere samt sørge for at der var adgang til repos med rigelig af software og spil både commerciel og open source...
plus en rigtig god hjælpe funktionalitet
selv manjaro har åbenbart en masse trin man skal igennem efter det er installeret...
selv om jeg må erkende at manjaro ikke var skyld i de problemer med havde med min ryzen maskine
De kunne sørge for at alt der smager af forbedring af spille muligheder på linux var en del af det OS og at det var nemt at opdatere OS plus drivere samt sørge for at der var adgang til repos med rigelig af software og spil både commerciel og open source...
plus en rigtig god hjælpe funktionalitet
selv manjaro har åbenbart en masse trin man skal igennem efter det er installeret...
selv om jeg må erkende at manjaro ikke var skyld i de problemer med havde med min ryzen maskine
Jeg forstaar ikke rigtig pointen. Vavle burde jo udemaerket vide at nu om dage er der saa faa gamere paa Linux at det ikke er oekonomisk rentabelt at udvikle spil til Linux.
Det maa vaere en slags PR stunt...
Det maa vaere en slags PR stunt...
#2 Ja, det er underligt, men det kan jo tænkes det er fordi de håber på at kunne udvikle en Steam konsol på et tidspunkt. En som er standalone og sådan... og jeg tænker at deres logik er solid nok at der faktisk kan hentes en hel del performance ved at skifte til Linux og undgå alt det Windows bloat man skal have for at spille på Windows 10.
Men har du ikke set den udvikling der allerede er sket for Steam på Linux? Det smarte er jo at spillene ikke længere behøves at være udviklet til Linux. DX12 er jo sådan set den primære grund til at spil køre bedre med Windows, men de har allerede gjort det så at Steam på Linux kan lave et form for DX12 API til Vulkan. Det er jo to åbne APIer. Ved ikke hvor meget Steam egentlig har været bag den udvikling men de har støttet det og fået lavet en samlet løsning.
Så spillene behøves ikke at være lavet til Linux, de kan (for det meste) køre fint på Linux ved hjælp af Wine og dette DX12 til Vulkan trick.
Men har du ikke set den udvikling der allerede er sket for Steam på Linux? Det smarte er jo at spillene ikke længere behøves at være udviklet til Linux. DX12 er jo sådan set den primære grund til at spil køre bedre med Windows, men de har allerede gjort det så at Steam på Linux kan lave et form for DX12 API til Vulkan. Det er jo to åbne APIer. Ved ikke hvor meget Steam egentlig har været bag den udvikling men de har støttet det og fået lavet en samlet løsning.
Så spillene behøves ikke at være lavet til Linux, de kan (for det meste) køre fint på Linux ved hjælp af Wine og dette DX12 til Vulkan trick.
#2 måske er det fordi Valve udviklerne er en bunke nørder der er trætte af at udvikle på Windows og sukker efter Linux. Spotify til Linux kom mig bekendt til verden på den måde. Lille marked, javist, men motiverede udviklere...
Tror nu også at #3 er inde på noget. Hvis de vil lave en konsol er det bekvemt ikke at skulle betale for Windows.
Tror nu også at #3 er inde på noget. Hvis de vil lave en konsol er det bekvemt ikke at skulle betale for Windows.
Man kunne forestille sig at Valve er bange for at Windows Store kommer og tager markedsandele fra dem. Jeg tror ikke det er smart for Valve at være for afhængig af en leverandør. Der har jo været en del spekulanter der har snakket om at systemer bør begrænses til kun at kunne installere software igennem officielle App stores, så man sikre brugerne fra ondsindet software og skaber en bedre brugeroplevelse.
Det kommer sikkert ikke til at ske, lige foreløbig. Men Valve sikre bare deres røv.
Det kommer sikkert ikke til at ske, lige foreløbig. Men Valve sikre bare deres røv.
#5:
jeg tror ikke der skal herske tvivl om at Microsoft sigter efter 2 ting med Windows...
1) at bevæge sig mod en abbonementsløsning og
2) at sikre sig man kun kan installere software der er købt i deres Windows Store
udover den 3 ting de allerede har gjrot i lang tid nu... at indsamle oplysninger
jeg tror ikke der skal herske tvivl om at Microsoft sigter efter 2 ting med Windows...
1) at bevæge sig mod en abbonementsløsning og
2) at sikre sig man kun kan installere software der er købt i deres Windows Store
udover den 3 ting de allerede har gjrot i lang tid nu... at indsamle oplysninger
#6
Det er ikke saa meget Windows, som det er DirectX. Og det kraever millioner og atter millioner af dollars at udvikle noget ala. DirectX.
OpenGL blev jo aldrig en success. Selv Apple droppede OpenGL for deres egen standard, Metal.
Og spiludviklere som har mange Mac kunder bliver ogsaa Metal nu om dage istedet for OpenGL.
Saa Linux kan kun blive emulering i fremtiden. Og emulering er kun til userieoese gamere.
Det er ikke saa meget Windows, som det er DirectX. Og det kraever millioner og atter millioner af dollars at udvikle noget ala. DirectX.
OpenGL blev jo aldrig en success. Selv Apple droppede OpenGL for deres egen standard, Metal.
Og spiludviklere som har mange Mac kunder bliver ogsaa Metal nu om dage istedet for OpenGL.
Saa Linux kan kun blive emulering i fremtiden. Og emulering er kun til userieoese gamere.
#8 Som jeg skrev i min post, så har Steam allerede en løsning på det. En løsning der ikke bruger emulering, men er lidt i still med Wine. Det er et API der tager imod DX12 kaldene og laver dem om til Vulkan. Så jeg tror det er lidt over et års tid nu, at man har kunne spille DX12 Windows spil på Steam med Linux.
CBM (6) skrev:#5:
jeg tror ikke der skal herske tvivl om at Microsoft sigter efter 2 ting med Windows...
1) at bevæge sig mod en abbonementsløsning og
Ja.
Det er vel en observerbar kendsgerning.
CBM (6) skrev:
2) at sikre sig man kun kan installere software der er købt i deres Windows Store
Nogen hos MS ville nok gerne.
Men jeg tror at det vil være et selvmål.
Hvorfor vælger folk Windows idag?
Mit bedste gæt: de sætter pris på al det software de kan få til Windows.
Fjerne den fordel, så er der ligesom åbnet op for alternativer.
De foreslåede ændringer inkluderer en erstatning af esync, hvilket skulle forbedre multitrådede spil og andre spil og programmer, der er krævende for CPU’en.
Undrer jeg mig over.
Nu har vi i årevis hørt at spil ikke kan udnytte alle (virtuelle) cores.
Og nu skal en optimering af trådhåndteringen give en markant forbedring af spil-performance?
#11 Jeg vil tro at de fleste nyere spil kører multithreaded i en eller anden forstand.
En hurtig søgning gav:
Det lyder som om de mutexer, semaphorer, queues osv Wine tilbyder performer skidt og esync retter op på det.
En hurtig søgning gav:
What is Esync?
Esync removes wineserver overhead for synchronization objects
Det lyder som om de mutexer, semaphorer, queues osv Wine tilbyder performer skidt og esync retter op på det.
Ja, MS sagde for nogle år siden at de ville til at sikre deres brugere ved kun at lade dem intallere via Windows store. Til det sagde Gabe (Valve), at det ville blive for dyrt og for besværligt for services som Valve, at konkurere med, da MS ville tage en del af kagen for salg, så MS selv, ville kunne sælge spil til en mere favorabel pris. Det modsatte Valve sig, og begyndte at lave deres SteamOS, som, hvis jeg husker ret, først var baseret på Ubuntu, men da de valgte at udvikle MIR, i stedet for at lægge ressourcer i Wayland, blev der oprør blandt en masse Linux gamere, og Valve valgte at rebase til Debian.
Ubuntu og Debian, er vel også blandt de bedst supporterede Linux distros for privatbrugere. Jeg ved ikke om det var den respons fra Valve alene, der fik MS til at trække i land igen, men jeg synes ikke at have hørt noget om at MS vil tvinge deres brugere til at installere gennem MS store mere.
Hvad gaming ydelse angår, var Valve ret hurtige til at optimere hvad de havde brug for, for at få flere FPS på DOTA2 (hvis jeg husker ret), end på Windows. I deres arbejde på OpenGL delen i Linux, fik de samtidigt optimeret den i Windows, så brugen af OpenGL outperformede DirectX.
DirectX, Wine, Vulkan:
Der er flere tiltag, der arbejder på at basere DX9, DX10, DX11,og DX12, fra OpenGL, til Vulkan.
Der er ikke voldsomt meget fokus på Linux, nej, men det viser sig at det performer ganske framragende, når spillene under udvikling bliver sktevet med ordentlig support for Linux, og når driverne også bliver ordentligt udviklede.
DX12, Vulkan, Metal:
AMD startede med at udvikle Vulkan, da de ville have mindre overhead. Det var fra starten udviklet som et API der på sigt ville blive åbnet, og de holdte deres løfte og gav det til det consortium der stod for OpenGL. AMD er dog sjældent særligt hurtige når det kommer til software, så jeg tror at Apple blev trætte af at vente, eller ogsã tænkte de "API revolution, og mulighed for at fange kunder, hvis vi er hurtige" og udviklede relativt hurtigt. Det var klar nogen tid før Vulkan. Microsoft var vel interesserede i at holde deres monopol, så DX12 har også mere low level funktioner for at mindske overhead.
Som med DX, arbejdes der også på et Metal til Vulkan abstraction layer.
Med alt det, vil Linux have support for DX9-12, Vulkan, og Metal. Fordelen ved Wine, her, og den brede support for API'er, betyder at du kan køre gamle spil, der efterhånden ikke kan køres på Windows længere.
Generel ydelse, og support i Linux, bliver også bedre og bedre, der er betydeligt mindre overhead (idle Linux (afhængigt af DE, ligger mellem 200 og 500MB RAM. standard Windows 10, æder hurtigt 700MB. Og jeg ved ikke hvordan Windows regner deres forbrug af RAM, men hvis du har 4GB, er computeren sløv, selv om mansjældent kmer over 3GB i brug (iflg task manager), så man kan nemt mærke forskel fra 4 til 8GB, uden at stresse Windows ret meget, og hvis man gamer store spil, kan man også nemt mærke forskel fra 8 til 16GB. Jeg synes slet ikke man mærker det i samme grad på Linux baserede systemer (igen - afhængigt af DE, og kvalitet af drivere) så det meste af hvad der holder Linux nede, er manglen på software. Hvis f.eks. MS office kunne køre fejlfrit i Linux, med alle funktioner tilgængelige, tror jeg at der ville være mange der gladeligt ville flytte over. Og hvad gaming angår, tror jeg de fleste udviklere bare konsekvent udvikler til Vulkan nu. Det kan understøttes af alle systemer der vil understøtte det, så hvis de optimerer til Vulkan, er det meste af cross platform support allerede sikret, og så er det da lidt dumt at støtte MS's monopol.
Det korte af det lange er, at havde der været mere support til/mere fokus på Linux, ville det kunne outperforme Windows. Det gør det f.eks. på mange områder på serversiden, og det har meget kraftigere CLI værktøjer/kommandoer, som MS er i fuld gang med at stjæle. Man kan nok også vende den om og sige, at hvis der havde været flere brugere, ville der nok være større efterspørgsel, mere fokus, mere udvikling, bedre support, og dermed flere og bedre programmer.
Ubuntu og Debian, er vel også blandt de bedst supporterede Linux distros for privatbrugere. Jeg ved ikke om det var den respons fra Valve alene, der fik MS til at trække i land igen, men jeg synes ikke at have hørt noget om at MS vil tvinge deres brugere til at installere gennem MS store mere.
Hvad gaming ydelse angår, var Valve ret hurtige til at optimere hvad de havde brug for, for at få flere FPS på DOTA2 (hvis jeg husker ret), end på Windows. I deres arbejde på OpenGL delen i Linux, fik de samtidigt optimeret den i Windows, så brugen af OpenGL outperformede DirectX.
DirectX, Wine, Vulkan:
Der er flere tiltag, der arbejder på at basere DX9, DX10, DX11,og DX12, fra OpenGL, til Vulkan.
Der er ikke voldsomt meget fokus på Linux, nej, men det viser sig at det performer ganske framragende, når spillene under udvikling bliver sktevet med ordentlig support for Linux, og når driverne også bliver ordentligt udviklede.
DX12, Vulkan, Metal:
AMD startede med at udvikle Vulkan, da de ville have mindre overhead. Det var fra starten udviklet som et API der på sigt ville blive åbnet, og de holdte deres løfte og gav det til det consortium der stod for OpenGL. AMD er dog sjældent særligt hurtige når det kommer til software, så jeg tror at Apple blev trætte af at vente, eller ogsã tænkte de "API revolution, og mulighed for at fange kunder, hvis vi er hurtige" og udviklede relativt hurtigt. Det var klar nogen tid før Vulkan. Microsoft var vel interesserede i at holde deres monopol, så DX12 har også mere low level funktioner for at mindske overhead.
Som med DX, arbejdes der også på et Metal til Vulkan abstraction layer.
Med alt det, vil Linux have support for DX9-12, Vulkan, og Metal. Fordelen ved Wine, her, og den brede support for API'er, betyder at du kan køre gamle spil, der efterhånden ikke kan køres på Windows længere.
Generel ydelse, og support i Linux, bliver også bedre og bedre, der er betydeligt mindre overhead (idle Linux (afhængigt af DE, ligger mellem 200 og 500MB RAM. standard Windows 10, æder hurtigt 700MB. Og jeg ved ikke hvordan Windows regner deres forbrug af RAM, men hvis du har 4GB, er computeren sløv, selv om mansjældent kmer over 3GB i brug (iflg task manager), så man kan nemt mærke forskel fra 4 til 8GB, uden at stresse Windows ret meget, og hvis man gamer store spil, kan man også nemt mærke forskel fra 8 til 16GB. Jeg synes slet ikke man mærker det i samme grad på Linux baserede systemer (igen - afhængigt af DE, og kvalitet af drivere) så det meste af hvad der holder Linux nede, er manglen på software. Hvis f.eks. MS office kunne køre fejlfrit i Linux, med alle funktioner tilgængelige, tror jeg at der ville være mange der gladeligt ville flytte over. Og hvad gaming angår, tror jeg de fleste udviklere bare konsekvent udvikler til Vulkan nu. Det kan understøttes af alle systemer der vil understøtte det, så hvis de optimerer til Vulkan, er det meste af cross platform support allerede sikret, og så er det da lidt dumt at støtte MS's monopol.
Det korte af det lange er, at havde der været mere support til/mere fokus på Linux, ville det kunne outperforme Windows. Det gør det f.eks. på mange områder på serversiden, og det har meget kraftigere CLI værktøjer/kommandoer, som MS er i fuld gang med at stjæle. Man kan nok også vende den om og sige, at hvis der havde været flere brugere, ville der nok være større efterspørgsel, mere fokus, mere udvikling, bedre support, og dermed flere og bedre programmer.
CBM (1) skrev:De kunne starte med at lave et SteamOS der nemt lader brugerne køre spil fra alle kilder, ikke kun Steam?
De kunne sørge for at alt der smager af forbedring af spille muligheder på linux var en del af det OS og at det var nemt at opdatere OS plus drivere samt sørge for at der var adgang til repos med rigelig af software og spil både commerciel og open source...
plus en rigtig god hjælpe funktionalitet
Nu er det lang tid siden jeg har prøvet SteamOS, men den gang var det da nemt nok at komme ud på skrivebordet, og få fuld adgang til alt fra Debians repositories, inkl. Wine og alt hvad det giver af muligheder.
God hjælpe funktionalitet burde godt nok også at være en del af SteamOS, men det er ikke nemt for Valve at lave hjælpe funktionalitet til alle de millioner af kombinationer af software og drivere dit system består af.
Det skal iøvrigt lige tilføjes at OpenGL var aldrig et dårligt API. MS svinede det bare til, og havde en helvedes masse penge til at promovere funktioner de tilføjede i DX, som ellers allerede eksisterede i OpenGL. Det blev vidst også lidt rodet på et tidspunkt, og ikke alle driverne fulgte protokollerne 100% så det blev svært at skulle udvikle til AMD, som fulgte dem, og seperat til nVidia, som ikke gjorde, og så blev nVidia defakto, så alt blev udviklet for at det kunne fungere der, og så fungerede det ikke særligt godt på AMD's hardware, og så videre. Så OpenGL har haft noget tumult, men det er i høj grad MS der er skyld i at det er et lidt overset API. Og derfor er der så mange spil der kun kører på Windows, men hvis man udvikler til Vulkan/OpenGL (Vulkan er så vidt jeg ved ikke ment som en erstatning for OpenGL, men det giver dig muligheden for at kode performance kritiske dele i lavere level API, og kode resten i OpenGL, hvis man vil, men der er selv sagt ingen der stopper dig i at kode alt i Vulkan. Af samme grund udvikles der stadigvæk på OpenGL), og SDL2 (SimpleDirectmediaLayer, hvis jeg husker ret), så har du alt du har i DX (det ved i sikkert alle sammen alt om, men DirectX er en samling af ting der gør dit spil kompatibelt med alle enheder der understøtter det (så alt der kører windows, med DX installeret). Du har håndtering af lyd/grafik/video etc. i forskellige dele af DX. Men så kan man vælge at kode grafik i Vulkan(/OpenGL), og resten i SDL2, og dermed kunne køre dine spil på alt der har support for SDL2, hvilket så vidt jeg husker, er Linux, iOS, Windows, Android, og sikkert flere, og så er det da lidt tosset at begrændse sig til en enkel platform, når der ikke er mere arbejde i at supportere mange (med mindre MS kaster penge efter dig for at bruge DX).
#12
https://github.com/zfigura/wine/blob/esync/README....
har en lidt grundigere forklaring.
Hvis jeg har forstået det rigtigt så:
uden esync => synkronisering er IPC med wineserver
med esync => synkronisering er user mode kode med shared memory
Og det kan sikkert godt gøre en forskel i nogle tilfælde.
https://github.com/zfigura/wine/blob/esync/README....
har en lidt grundigere forklaring.
Hvis jeg har forstået det rigtigt så:
uden esync => synkronisering er IPC med wineserver
med esync => synkronisering er user mode kode med shared memory
Og det kan sikkert godt gøre en forskel i nogle tilfælde.
Claus Jørgensen (8) skrev:#6
Det er ikke saa meget Windows, som det er DirectX. Og det kraever millioner og atter millioner af dollars at udvikle noget ala. DirectX.
OpenGL blev jo aldrig en success. Selv Apple droppede OpenGL for deres egen standard, Metal.
Og spiludviklere som har mange Mac kunder bliver ogsaa Metal nu om dage istedet for OpenGL.
Saa Linux kan kun blive emulering i fremtiden. Og emulering er kun til userieoese gamere.
WINE: Wine Is Not an Emulator
Desuden er Vulkan cross platform, og det samme med SDL2. De kan totalt erstatte hele DirectX pakken, og WINE har bedre kompatibilitet for gammelt Windows software, end Windows. Det ville være at skyde sig selv i foden, ikke at bruge Vulkan(/OpenGL), og SDL2
Tak for skrivet Linos, interessant læsning.
Haha, cool hvis Linux + WINE ender med også at blive den mest kompatible retro Windows 3D gaming platform.
Dosbox er allerede den mest kompatible DOS maskine man kan lave til DOS spil. I Linux findes der fede frontends til at starte Dosbox og andre emulatorer. Jeg har personlig scriptet mig ud af at starte spillene med den konfiguration jeg ønsker. Jeg ved ikke hvordan jeg skulle gøre det på en Windows.
... så vi er ved at være der hvor Linux er en bedre platform til spil, inklusiv Dos/Windows spil, end Windows selv (hvis man undtager de nyeste AAA titler).
linos (19) skrev:WINE: Wine Is Not an Emulator
Desuden er Vulkan cross platform, og det samme med SDL2. De kan totalt erstatte hele DirectX pakken, og WINE har bedre kompatibilitet for gammelt Windows software, end Windows. Det ville være at skyde sig selv i foden, ikke at bruge Vulkan(/OpenGL), og SDL2
Haha, cool hvis Linux + WINE ender med også at blive den mest kompatible retro Windows 3D gaming platform.
Dosbox er allerede den mest kompatible DOS maskine man kan lave til DOS spil. I Linux findes der fede frontends til at starte Dosbox og andre emulatorer. Jeg har personlig scriptet mig ud af at starte spillene med den konfiguration jeg ønsker. Jeg ved ikke hvordan jeg skulle gøre det på en Windows.
... så vi er ved at være der hvor Linux er en bedre platform til spil, inklusiv Dos/Windows spil, end Windows selv (hvis man undtager de nyeste AAA titler).
arne_v (21) skrev:linos (19) skrev:
WINE: Wine Is Not an Emulator
Det siger de.
Men i realiteten er WINE vel en OS emulator.
Mon ikke det går på at instruktionerne kører native og ufortolket på CPU.
Eller gør de? Jeg har altid været imponeret over at WINE kan lade sig gøre i det hele taget
@arne: ja det må immervæk være billigere at konvertere API kald end at skulle emulere et helt system på den måde som en emulator ville gøre
Ja, at WINE ikke er en emulator er grunden til at jeg også nævnte det som et svar på at "Linux kan kun emulere"... for det er netop ikke emulation. Ligesom det de gør med DX12, så prøver de ikke at emulere DX12, de laver sådan set et alternativ i stedet. At mappe DX12 API kald til Vulkan kald er ret nice en løsning til at komme uden om MS.
Det er nemlig langt mere effektivt. Man kunne jo potentielt gøre dette for at portere Windows til ARM og det har man måske også allerede gjort. De bedste løsninger jeg har prøvet for at køre x86 ting på ARM... udover DOSBox mener jeg har været WINE baseret.
Det kunne potentielt blive stort at Microsoft snakkede om at integrere den Windows Store, for det vil ret sikkert ikke kun være Steam det kunne få til at reagere. WINE ville være en af de ting der nok hurtigt ville kunne få en del støtte og Linux udvikling går allerede ret hurtigt, så hvis pludselig der skete et skift i mentalitet og at en del virksomheder ville væk fra Windows og få flere brugere til Linux, tror jeg egentlig hurtigt der kunne komme meget stærke alternativer.
Lidt ligesom når nu USA (eller Trump i hvert fald) vælger at lave sanktioner imod Huawei, så kan det potentielt føre til at der ville komme en del alternativer til store systemer som Android i dag, simpelthen fordi de tvinger det til at ske. Jeg tror godt Google og sådan ser hvor stort et potentielt problem det kunne blive for dem hvis der kom stærke alternativer til Android.
Det er nemlig langt mere effektivt. Man kunne jo potentielt gøre dette for at portere Windows til ARM og det har man måske også allerede gjort. De bedste løsninger jeg har prøvet for at køre x86 ting på ARM... udover DOSBox mener jeg har været WINE baseret.
Det kunne potentielt blive stort at Microsoft snakkede om at integrere den Windows Store, for det vil ret sikkert ikke kun være Steam det kunne få til at reagere. WINE ville være en af de ting der nok hurtigt ville kunne få en del støtte og Linux udvikling går allerede ret hurtigt, så hvis pludselig der skete et skift i mentalitet og at en del virksomheder ville væk fra Windows og få flere brugere til Linux, tror jeg egentlig hurtigt der kunne komme meget stærke alternativer.
Lidt ligesom når nu USA (eller Trump i hvert fald) vælger at lave sanktioner imod Huawei, så kan det potentielt føre til at der ville komme en del alternativer til store systemer som Android i dag, simpelthen fordi de tvinger det til at ske. Jeg tror godt Google og sådan ser hvor stort et potentielt problem det kunne blive for dem hvis der kom stærke alternativer til Android.
@kblood: men det ville være et kæmpe win for os som forbrugere hvis der kom et kinesisk alternativ til amerikanske operativ systemer fra hhv. Apple, Google og Microsoft!
Ideen med en mikrokernel er genial og effektiv! Bare ikke hvis det kommer fra Google (Fuchsia)
Det smerter mig at jeg som forbruger skal vælge mellem pest eller kolera når det handler om operativ systemer til hhv computere og mobile enheder
Ideen med en mikrokernel er genial og effektiv! Bare ikke hvis det kommer fra Google (Fuchsia)
Det smerter mig at jeg som forbruger skal vælge mellem pest eller kolera når det handler om operativ systemer til hhv computere og mobile enheder
kblood (27) skrev:Ja, at WINE ikke er en emulator er grunden til at jeg også nævnte det som et svar på at "Linux kan kun emulere"... for det er netop ikke emulation.
Ja. Men executables i Linux følger elf formatet og "exe" filer i Windows følger et helt andet format. Og dynamisk linking af libraries er anderledes i Windows og Linux. "dll" filer er anderledes i Linux. Det jo helt forskellige OS'er der ikke er binært kompatible på nogen måde. Man kan ikke bare køre en "exe" fil på Linux.
Jeg tænker det virker ved at Wine går ind først og oversætter exe filen til noget der er spiseligt for Linux. I den proces kan man også rette dynamisk linking til så de ønskede libraries bliver kaldt på den måde det skal gøres i Linux. Men det er altså ikke noget man bare lige gør. Derfor min beundering over at det overhovedet kan lade sig gøre at lave et program som Wine så godt som det allerede er.
#29 Ja, det er det som WINE gør... Windows har jo selv et system hvor at når der er en EXE fil, så ved den hvad den skal gøre med den og så tager EXE filen måske og anmoder om forskellige dele af Windows eller prøver at bruge DLL filer.
Du kender SCUMMVM? Grunden til at det kan køre på så mange systemer så godt, er netop fordi det ikke prøver at emulere noget som helst. De genskaber hver enkelt engine i SCUMMVM så de rent faktisk laver en port af spillet til alle de systemer som SCUMMVM er portet til.
WINE gør det samme... som jeg forstår det... laver lidt sin egen version af Windows der har nogle libraries og sådan ligesom Windows der kan få disse EXE filer til at eksekvere og så kan få den respons fra systemet som de forventer.
Det er jo sådan set ret smart. Jeg mener endda det er open source? Lidt underligt at det ikke er mere udbredt, for det fungere jo på ARM og kan gøre det muligt at køre Windows på telefoner og Raspberry Pis.... selvom det så måske ikke altid køre så godt.
Du kender SCUMMVM? Grunden til at det kan køre på så mange systemer så godt, er netop fordi det ikke prøver at emulere noget som helst. De genskaber hver enkelt engine i SCUMMVM så de rent faktisk laver en port af spillet til alle de systemer som SCUMMVM er portet til.
WINE gør det samme... som jeg forstår det... laver lidt sin egen version af Windows der har nogle libraries og sådan ligesom Windows der kan få disse EXE filer til at eksekvere og så kan få den respons fra systemet som de forventer.
Det er jo sådan set ret smart. Jeg mener endda det er open source? Lidt underligt at det ikke er mere udbredt, for det fungere jo på ARM og kan gøre det muligt at køre Windows på telefoner og Raspberry Pis.... selvom det så måske ikke altid køre så godt.
#29
Det er ikke nødvendigt at oversætte noget.
Linux bruger ELF format og Windows bruger PE format, men x86-64 instruktioner er x86-64 instruklioner uanset hvad.
[følgende er lidt forsimplet, men ...]
Hvad sker der når et executable program starter op?
Noget activerings kode:
* loader readonly data op i memory
* loader readwrite data op i memory
* loader eksekverbar kode op i memory
* hopper til start af eksekverbare kode
ELF og PE er formater aom definerer hvordan man finder readonly data, readwrite data, kode og start adresse i executable.
Linux ved hvordan man læser ELF format.
Windows ved hvordan man læser PE format.
Wine er nødt til at forstå PE format.
Men når Wine har loadet memory sektioner og hopper til koden, så er det rene x86-64 instruktioner.
Det er ikke nødvendigt at oversætte noget.
Linux bruger ELF format og Windows bruger PE format, men x86-64 instruktioner er x86-64 instruklioner uanset hvad.
[følgende er lidt forsimplet, men ...]
Hvad sker der når et executable program starter op?
Noget activerings kode:
* loader readonly data op i memory
* loader readwrite data op i memory
* loader eksekverbar kode op i memory
* hopper til start af eksekverbare kode
ELF og PE er formater aom definerer hvordan man finder readonly data, readwrite data, kode og start adresse i executable.
Linux ved hvordan man læser ELF format.
Windows ved hvordan man læser PE format.
Wine er nødt til at forstå PE format.
Men når Wine har loadet memory sektioner og hopper til koden, så er det rene x86-64 instruktioner.
#30
Så vidt jeg kan læse mig til så:
- kører Wine x86-64 programmer beregnet til Windows x86-64
- kører Wine ARM programmer beregnet til Windows ARM (Windows CE, Windows RT)
Sådan er det nødt til at være for at undgå ISA emulering.
Men det reducerer nytten af Wine ARM en del.
Så vidt jeg kan læse mig til så:
- kører Wine x86-64 programmer beregnet til Windows x86-64
- kører Wine ARM programmer beregnet til Windows ARM (Windows CE, Windows RT)
Sådan er det nødt til at være for at undgå ISA emulering.
Men det reducerer nytten af Wine ARM en del.
arne_v (31) skrev:Linux ved hvordan man læser ELF format.
Windows ved hvordan man læser PE format.
Wine er nødt til at forstå PE format.
Men når Wine har loadet memory sektioner og hopper til koden, så er det rene x86-64 instruktioner.
Det giver mening. Men normalt når man eksekverer en ELF binary sker load processen i kernel space med execve(...) hvor man stikker den en path til en binary: https://lwn.net/Articles/630727/ Wine er tilsyneladende i stand til at lave en custom load process i user space. Tja, hvorfor skal det egentlig ikke kunne lade sig gøre.
Men hvad med dynamisk linkning? Hvordan får Wine systemkald og interfacing til libraries til at virke?
#33
Med .dll/.so sker der lidt mere ved aktivering.
Aktiveringskoden finder i executable (ELF eller PE) referancer til .dll/.so, loader disse ind i memory og opdaterer referancerne til dem.
På VMS loades images med to kald:
SYS$IMGACT
SYS$IMGFIX
---
Med hensyn til hvad Wine gør så lad mig kopiere fra #24:
FooBar applikation---Windows libraries---[Windows API]Windows
FooBar applikation---Windows libraries---[Windows API]Wine API converter---[Linux API]Linux
Noget Windows kode kalder CreateDirectory funktionen.
På Windows er den i kernel32.dll, med Wine på Linux er den i Wine som kalder Linux kernel mkdir.
Med .dll/.so sker der lidt mere ved aktivering.
Aktiveringskoden finder i executable (ELF eller PE) referancer til .dll/.so, loader disse ind i memory og opdaterer referancerne til dem.
På VMS loades images med to kald:
SYS$IMGACT
SYS$IMGFIX
---
Med hensyn til hvad Wine gør så lad mig kopiere fra #24:
FooBar applikation---Windows libraries---[Windows API]Windows
FooBar applikation---Windows libraries---[Windows API]Wine API converter---[Linux API]Linux
Noget Windows kode kalder CreateDirectory funktionen.
På Windows er den i kernel32.dll, med Wine på Linux er den i Wine som kalder Linux kernel mkdir.
Jeg fik installeret Ubuntu og Steam og det virker da ret godt må jeg sige. Stort set plug and play... var lidt problematisk at få Nvidia driveren installeret, men mest fordi den første guide jeg fandt var forældet eller sådan noget.
Har kun lige prøvet No Mans Sky og Maldita Castilla og NMS får nu bedre framerates på PC, men kørte mere stabilt på Linux... men jeg kunne sådan set mærke at spillet kørte langsommere så problemet var nok mere end bare en lav framerate.
Men vil prøve nogle flere spil og se om der ikke er nogen der kører godt eller måske endda bedre på Linux selvom det er lavet til Windows.
Har kun lige prøvet No Mans Sky og Maldita Castilla og NMS får nu bedre framerates på PC, men kørte mere stabilt på Linux... men jeg kunne sådan set mærke at spillet kørte langsommere så problemet var nok mere end bare en lav framerate.
Men vil prøve nogle flere spil og se om der ikke er nogen der kører godt eller måske endda bedre på Linux selvom det er lavet til Windows.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund