Thread replies: 7
Thread images: 1
Thread images: 1
File: 1458466405546.gif (3MB, 240x320px) Image search:
[Google]
3MB, 240x320px
So what makes Windows Executables unable to run on Linux? Aren't the instructions x86 for both of the oses? What would need to be modified in Linux to make windows executables work? I assume it's more than just copying over the dlls from Windows, but what specifically is stopping someone from making a distro that can run exes?
>>
Different binary formats. Different ABI: calling conventions, incompatible syscalls. Does the caller or called clean up the stack? How many arguments are passed through registers?
Even if they had the same syscall convention: NT syscall 0x60 is NtAcceptConnectPort, Linux syscall 0x60 is gettimeofday.
Regardless, Wine doesn't need to change the kernel to achieve good compatibility (better than newer Windows in some cases).
>>
>>55261061
So what's stopping some cool /g/uy from changing the Linux source code to be compatible with what exe's need? A FOSS OS that runs windows exe's seems like it's be a pretty cool thing
>>
>>55261290
Wine basically does that and without changing Linux.
>>
m8 it's called Wine
If you want a OS, look for ReactOS
>>
>>55261370
Doesn't WINE have compatibility issues/lag with things like gaymes and more intensive programs? Either way an OS solution would be faster and more stable I'd imagine...
>>
Linux uses ELF, Windows uses PE. Linux does not, by default, know how to open a PE file. If you try to run an exec syscall on it, the kernel will say it's not an executable file, and toss it away. Fortunately, third party programs like Wine can open the file, and map the appropriate sections to allocated memory that has been given appropriate memory protections.
Windows programs all do system level shit by means of a couple of DLLs that use incompatible syscalls compared to Linux. Fortunately, Windows NT syscalls are rather undocumented (and allowed to change at any time!), so Windows programs have to call functions inside of DLLs, rather than making syscalls themselves. This is why Wine can work, at least half decently, rather than being completely broken. Rather than copying the Kernel32.dll and other relevant files from Windows, they implement the functions themselves so that, for example, when a program executes the WriteConsole() function in the DLL, it will actually use the write() syscall in Linux, rather than whatever Windows is using. Since no program is going to use the syscall instruction on its own, there's at least some possibility for compatibility.
That said, Wine is imperfect, and D3D is a bitch to implement, so you're still going to have some compatibility issues no matter what.
Thread posts: 7
Thread images: 1
Thread images: 1