Related Question:
Why won't windows exe's work on Linux?

Can a Windows .exe file be run on Linux?

If the same architecture is used will it be possible? Like if both programs run on X86 architecture, will it be possible to run a Windows .exe on Linux?


The exe file will either execute under Linux or Windows, but not both.

Executes Under Windows

If the file is a windows file, it will not run under Linux on it's own. So if that's the case, you could try running it under a Windows compatibility layer (Wine). If it's not compatible with wine, then you won't be able to execute it under Linux.

Before you can start, you will need to install Wine. The steps you need to install Wine will vary with the Linux platform you are on. You can probably Google "Ubuntu install wine", if for example, you're installing Ubuntu.

Once you have wine installed, then you'd be able to execute these commands.

wine xxx.exe

Execute Under Linux

If you know this file to run under linux, then you'll want to execute these commands:

You'll want to change permissions to allow all users to execute this file (a+x). you could also allow just the user to execute (u+x)

chmod a+x xxx.exe

Launch the program, the ./ tells the command line to look in the current path for the file to execute (if the 'current' directory isn't in the $PATH environment variable.


The operating system (Windows or Linux) provides services to applications. For example, Windows and Linux will have functions that the application can call to access files, to access the network, to display things on the screen, etc.

The different operating systems provide different ways of doing those things, so an application that does it the Windows way won't work on Linux, and vice versa, even though the CPU architecture is the same.

  • 2
    This answer is correct. It's not the only reason (the different loaders and executable formats are also key), but it's one of them. Nov 30 '10 at 9:49
  • 2
    It's one of the main reasons you can't have the same executable run natively on different operating systems.
    – Angus
    Nov 30 '10 at 9:49
  • 1
    @Let_Me_Be: Actually your comment is not correct.
    – 0xA3
    Nov 30 '10 at 9:51
  • 1
    @0xA3 If you are accessing platform specific API, then yes. But for the most part, that's actually not true. Reimplementing C or C++ standard library is actually very simple, you just need to re-implement the bugs and redirect calls. What takes a lot of work is different file format (and platform specific API's since they have to be reimplemented from scratch). Nov 30 '10 at 9:59
  • 2
    @Let, I never said you should. I was pointing out that you said "for the most part", programs don't use platform-specific APIs; in fact, most do. Even programs using cross-platform libraries like GTK are still using platform-specific APIs indirectly. Nov 30 '10 at 10:08

No, different Operating Systems use different formats (ie. Windows uses PE while linux uses ELF). Also, when compiled, your program makes calls to native OS methods. As mentioned, you can look into using WINE. It provides most functionality to run Windows binries on Linux.


There are three major reasons why .exe files won't directly run on Linux and why a Linux executable won't directly run on Windows.

  1. The first is System calls. System calls are, almost by definition, platform specific. However, not all system calls are made the same. There are portable system calls (e.g. defined by the C/C++ standard library) and non-portable system calls (e.g. defined by POSIX or Microsoft). Applications that are statically linked at compile time with the system libraries would find that the part of the code that is statically included would probably have no chance of executing correctly in the target platform due to the vastly different design of the platform. Applications that are dynamically linked at runtime do have a chance of running with a few condition: if it's portable system calls, there is a translation table between the original binaries' system calls to the target platform's system calls; if it's non-portable system call, there must be a compatibility layer that receive system calls of the original platform and find an equivalent translation in the target platform (which may not always be possible1, different platforms have different set of features, and some feature does not make sense in the other platform2).

    Solution: For running Windows program in Linux, Wine provides an implementation of Windows System Calls and Windows System Libraries, it also recognizes PE format; Wine can run Windows program in Linux without recompiling. For the Linux program in Windows, Cygwin provides an implementation of POSIX System calls in Windows, and it allows program written for Linux to be recompiled using Cygwin GCC to run on Windows system with no source-code changes. Because of the open source nature of most Linux program, it is easier to recompile rather than going the Wine's way of providing binary-compatible layer. It is not impossible to provide wine-like compatibility layer, however Cygwin's way is more robust and there is just not much drive to allow non-open-source Linux program to be easily ported to Windows.

  2. The other is Executable Format. Windows uses PE (Portable Executable) format and Linux uses ELF (Executable and Linkable Format). The executable format contains metadata, and defines how the executable is to be loaded and executed by the platform.

    Solution: It is entirely possible to write a PE -> ELF or ELF -> PE converter; and it probably should not be too hard to do so (warning: I'm not familiar with the actual format of either one). Another way is to write an executable loader that can understand PE files (e.g. Wine provides one) or executable loader that can understand ELF file (I believe the design of Windows limits the possibility of a double-clickable file running natively as an executable)

  3. System calls calling convention. Linux and Windows does not only have a different set of available system calls, it also have a very different system call calling convention. In Linux, to make a system call you pass the syscall number in eax/rax register and arguments in the rest of registers, and then you make 0x80 interrupt request. In DOS, you also pass arguments in the register, however there is a different interrupt request number for each system service so you don't pass system call number in eax/rax. Windows NT is more similar to Linux, however instead of 0x80 you raise 0x2E interrupt request, however the system call number still differs (so you need a syscall number translation table and possibly a compatibility layer).

    Solution: Even when you don't have a self-modifying code or trying to execute data as code or do other tricky codes, it is still very hard (as hard as solving the Halting Problem) to analyze an executable, search for all system calls interrupt requests, and translate them to the target platform's system calls. An easier way is to provide a runtime service that handle the program's interrupts requests and redirect them to the target platform's system calls3.

There are various other reasons, but I believe these three are the big stumbling blocks.

1 filesystem security comes to mind, there is no way to translate between Linux's security bits and Windows' NTFS ACL.

2 Windows cannot fork a process; CreateProcess can somewhat be used to emulate fork however it loses the copy-on-write semantic. There is no way to do a create copy-on-write process in Windows.

3 I believe Wine does this


It is possible lookup wine

  • paul@ i dont want wine...i am talking about programming...after i get an executable after compilation. can that executable run on both window and linux
    – Manu
    Nov 30 '10 at 9:45
  • 1
    The wikipedia article gives high level details of why WINE is required. Nov 30 '10 at 9:46

Only if it is a .Net .exe file. I made an app in VS and compiled under Windows then I run it on Linux

mono myapp.exe

I know this is not exactly what you are looking for, yet the answer is you can run some exe files on Linux.


The only way to run executables on Win, Linux (or even Mac)is having some kind of "virtual layer" between the assembly and OS directives, lukas' option of running it under Mono is one way to go, just like building an Java file (or even an Adobe Air).

Building binaries that run that, as is, to run on several architectures is no possible because machine code is highly binded to the OS and even the hardware, you may have to perfom several builds for each system/OS.