Is it possible to run the COFF executable files on UNIX or the ELF executable files on Windows? And what would be the steps to be able to run either file type on Windows and UNIX. I'm just curious.
To answer your question properly, it is relevant to review what ELF, COFF, and PE are. These binary formats are essentially just containers that give directions to the operating system about how to execute the raw CPU instructions contained in the file. They are very much like audio/video containers like MKV, WMV, and OGG. Support for the executable format is either in the operating system or not. Microsoft Windows has consistently not given any support for COFF or ELF, until recently. With Windows 10, Microsoft has provided indirect support for ELF by building into the Windows kernel UserMode-Linux compatible system routines. A UserMode Linux kernel runs on top of the Windows kernel and runs all ELF binary formats almost as if it were running independent of MS Windows.
The alternative to using the UserMode-Linux (sub-kernel) being for Microsoft to rewrite the majority of the Linux API in a completely compatible format, their choice solves one other compatibility issue: The API. "A" stands for Application and "I" for Interface, however the API as an interface is mainly just a set of executable routines and environment assumptions. Access to the filesystem and most basic system routines is provided by the Windows kernel, while everything else is provided in the UserMode Linux kernel. This way not only can Windows run ELF formatted executables, but in can run the most popular ELF executables that are already made to run on the Linux API.
The reverse, the other half of the question, running PE (most Microsoft Windows executables) on Linux is possible as well. There are two runtime wrapping libraries that can run MSIL (virtual machine application) and Win32 (normal CPU application). Because the Linux kernel is extendable to recognize a certain byte format, then run an appropriate wrapper program, in effect the kernel supports PE and potentially more executable container formats. Therefore, Linux can run some PE programs either in the mono runtime (.NET/C# applications) or in the WINE runtime (Win32 C/C++).
To install the UserMode-Linux environment you can follow instructions provided on Microsoft's Development Network. To summarize:
Turn on Developer Mode: Settings | Update & Security | For Developers | Check the Developer Mode radio button
From the start menu, open “Turn Windows Features on or off”
Scroll down and check the “Windows Subsystem for Linux (Beta)” feature
Hit okay and reboot (required step)
Once rebooted, open a PowerShell/command prompt and run “Bash” and follow the simple prompts to accept Canonical’s license and kick-off the download of the Ubuntu image
After download has completed, you’ll be able to start “Bash on Ubuntu on Windows” from the Start menu
Be aware this method only works on Windows 10 and is still limited to text-mode console and a Win32 port of Xorg like vcXsrv for anything graphical. Cygwin or MSYS2 systems are not able to run ELF binaries, but make it possible to port and run the same applications that are normally ELF binaries on a Linux system.
To actually run executables and have them do useful stuff, you need to worry about the API, not just the executable file format. On a Linux machine with WINE installed, you can run Windows .EXE files from the command line and they do the same thing that they do on Windows.
The other way around is not really possible, however if you install CYGWIN on a Windows machine, and then rebuild the application from source with CYGWIN compilers, you will get an executable that runs on Windows and does the same thing that the Linux executable does on Linux. Lots of standard Linux tools are already ported and in the CYGWIN repository including stuff like X-Windows and GIMP.
http://lbw.sourceforge.net/ works better than line.
low was another project for doing the same thing, but that was the less working.
EDIT: http://atratus.org/ seems to do the same as well, without the need to have Interix/SFU.
COFF was originally introduced by UNIX (around System V or thereabouts) so yes, some UNIX probably still supports COFF format. It's been deprecated by Linux at least for a while, and presumably most other Unices have also deprecated or outright dropped support.
Windows ELF support is a bit more iffy - almost certainly not there without some deep trickery. You should be more specific about what you're trying to do here...
Related
I am currently taking a class on Assembly Language and Computer Architecture. We're programming in MASM for x86 processors. I have a Macbook Air, so of course I have to run Windows on a virtual machine to program in MASM for our assignments.
What I'm confused about: We're learning about, and programming for x86 architecture. When I looked up my Macbook Air's processor, it seemed to be in the x86 family. Considering that, why doesn't MASM work with Mac OS X?
Furthermore, if assembly language communicates directly w/ hardware, why does merely installing the Windows OS (or running it through a VM) on Apple Hardware suddenly allow me to program in MASM?
Thanks,
Ian
[EDIT for clarification: My understanding -- please tell me if i'm wrong -- is that Assembly Language is as "low as you can go." I.e. it's pre-operating system, and provides instructions directly to the hardware itself. Thus, I don't understand why an assembly language for x86 architecture doesn't work on ALL x86 machines, regardless of OS]
Programs are made up of more than just the raw machine code. The executable needs to have a special format that the OS can understand, so it can load and run the code. Also, the code expects a certain environment, such as libraries and system calls (along with the appropriate calling conventions).
To compile and run your assembly program you need to assemble it first, that is run it through MASM in this case. However, MASM itself is a windows executable. It is in the executable format for windows, and it uses libraries and operating system functions accordingly. As such, you can't run it directly on mac os. Afterwards, you typically also need to link your code, which has the same issues. The next problem is with the program itself. MASM (and the rest of the toolchain) is by default also targeting windows (or dos) and so the created program has the appropriate format.
You can theoretically create a program intended to run on mac os using windows and masm. This is called cross-compiling in general. If your toolchain does not support the required mac format, you will need to create everything by hand. You obviously also need to write your program such that it expects the mac environment. For example, you can't use dos interrupts or windows libraries.
Since the architecture is the same, you don't need to virtualize the cpu. You can get away with emulating just the environment. An example for this is the windows emulator, wine, or cygwin emulating unix on windows.
A very rough analogy: there are human languages that use the same alphabet, but you still need to translate. There are also languages that do not even use the same alphabet, or don't even have letters. You will need to do more work in these cases.
I deployed a matlab script to an executable file which runs on linux platform.
let's say file :
$./run_test.sh
As it is created on linux, it cannot be executed on the powerPC CPU.
Is there any way to translate the binary file to a PPC readable file?
Thanks
You're mixing OS & CPU issues: the problem isn't that it was created on linux (there are versions of linux that run on PPC); the problem is that it is for a different CPU (x86, most likely). And other than running an emulator/simulator for that processor on you PPC box (which, if it works, would likely be quite slow), or getting a hold of the source to re-compile it, I believe you are out of luck.
...unless of course this really is a script, and while executable is not binary, in which case your solution may be as simple as changing the line endings. This is likely the case if you can open it in a text editor & you can read it (that is, it isn't full of funky symbols).
Complementing Scott's answer. If you have the source code of the application, you can use Software Development Toolkit for Linux on Power to help you in the migration.
The IBM Software Development Kit for Linux on Power (SDK) is a free, Eclipse-based Integrated Development Environment (IDE). The SDK integrates C/C++ source development with the Advance Toolchain, Post-Link Optimization, and classic Linux performance analysis tools, including Oprofile, Perf and Valgrind.
Forgive my ignorance: I need to use a library that requires a UNIX system (LIBSHORTTEXT). Do I need to install a virtual machine with Unix or is Cygwin enough? (I've read quite a few articles about the difference between them but I don't really understand the practical difference for this specific use). Thanks!
Edit: The documentation that said that the library needs UNIX is here
That really depends on what makes the library "require UNIX". Looking at it briefly, it appears to be ANSI C and Python, both of which should either compile or be fairly easy to port on a Windows development system. In your case I'd go with Cygwin if you don't already have a development suite running, as it is likely to allow you to just get things running.
A Virtual Machine is a bit more compartmentalized, so much less connection between Windows and the running software. Unless you are planning to use the operating system in the Virtual Machine as a target for your program, it is a bit of overkill in this case, IMHO.
Hope this helps.
Normally I would say Cygwin will do, but it depens on how you use the library. And when you say that the library requires a UNIX system what do you mean? Are you building a python or c++ program?
The main difference between working in cygwin and a VM is that cygwin is still working in a windows environment with windows directories and hardware drivers, whereas a VM have all this emulated as if it actually was a UNIX machine.
I have seen this question asked for a Linux host system but not for Windows.
I have a Windows 7 64-bit host system. I am running into a 32 bit issue I think and I see this vague phrase in the Code Sourcery documentation.
"Therefore, even when running on a 64-bit host system, Sourcery CodeBench requires 32-bit host libraries. Consult your operating system documentation for more information about obtaining these libraries."
I can't find any documentation because I don't know what "these" libraries are.
Thanks,
Seth M King
That sentence is really only for Linux users; a lot of Linux distributions don't include the basic system libraries (the equivalent of the stuff in c:\Windows\System) needed to run 32-bit applications.
Windows includes everything that's needed as far as this is concerned.
I'm developing a network redirector using RDBSS.
In our network redirector volume, a executable file which is packed from Inno Setup(Open source packer) can not be run.
When we do double-click the file in Windows Explorer, the Explorer shows this messagebox.
It works well on 32bit Windows. Only 64bit Windows is problem.
I guess it is related with npdll or MUP.
We have implemented npdll, and I thought it doesn't have any bug now. - Of course we also have npdll 64bit version.
Other executable files and any files work well for both 32 and 64OS.
If we run this file in 64bit Windows SMB volume, it runs fine.
So, I'm pretty sure some our codes have a bug.(npdll or redirector driver)
Could you guess anything about this?
P.S Is there a good document describing how MUP works? If you know, let me know please.
Thanks.
The other executables which work, are they 64-bit or 32-bit?
If only 32-bit processes (like InnoSetup) fail, could it be that you need to install both the 64- and 32-bit versions of your DLL on x64 systems? That's required for some DLL types (e.g. video codecs) if you want their functionality to be available to all programs, but I'm not familiar with RDBSS and thus don't know if it applies in this case.