linux to windows converter....?

[zombieman2080]

how would i go about making something that can read a windows binary executable and output a neutral code that can then be converted into a linux binary executable. like a translator i guess.

i know there are windows emulators for linux and even "non-emulators" but to me unless you can fully run something straight off of linux its still an emulator. i also know that right now linux's weakest link is that there are no games for it. the sad thing is is that its a catch 22 scenario, gamers stay with windows to play games and developers stay with windows to sell to gamers. i believe that if a bin converter could be created catch 22 will be removed as game would be playable on linux, just like quake 4. q4 was released for windows but you can download the bin to operate it fully on linux.

thanks.

[NeoIce]

yeah...

thats not how it works. you should do some reading on things like WINE, system APIs, "the kernel", reverse engineering, compilers, etc.

a lot of reading.

[i92guboj]

how would i go about making something that can read a windows binary executable and output a neutral code that can then be converted into a linux binary executable. like a translator i guess.

Of course, if such a thing was that simple it'd have been done after 17 years of linux existence.

The first thing you need to understand is that windows has a given API, a given way to do the things, and a given set of libraries that are not in linux. Not to speak about system calls and whatnot, which are just plain impossible to do directly on system, and need to be kind of emulated. So, there's no way to just "translate" the things. All the missing pieces would need to be reimplemented (windows api, directx, blah blah blah), besides the "translation" that you mention. That is exactly what the wine project does, so, it's the closest you are going to get to your idea.

If you are really really worried about the "bad" idea of having to write "wine" in front of each windows program to run it, you can as well use this:

Linux.com :: How to launch Windows binaries on Linux directly

Which will allow you to run them by just invoking their name.

The other solution would be to create cross platform object code, i.e. to program all the games using java, which would be a ridiculous idea for many reasons, but there are two main ones:

• Developers would continue to using propietary extensions like directx, which would make the final binary useless on any OS not having directx (any OS that's not windows).
• Java can't perform adequately for games, it's just a resource hog and likes to eat lots of ram, it's not the fastest on cpu either.

All in all, the only real solution is to use cross platform libraries (opengl, openal, sdl, ...) instead of directx, and make programs that can be compiled on many platformst natively with very little extra work. There are programmers that can do that, there are programmers that can't do that or just don't want to bother.

[Cabhan]

Indeed. The problem here comes down to proprietary libraries and system calls.

For instance, let's look at a piece of assembly code:

li $a0, 3
syscall

This bit of MIPS means "Execute the system call corresponding to the ID 3". Control is now handed off to the kernel to actually make this call. Linux works the same way.

The problem here is that the internals of "System Call 3" are unknown. Sure, we know that it means "Tell me the current time", but maybe it also has some side effect that is inadvertently taken advantage of later in the program. This is one of the challenges of the WINE project: not just re-implementing the Win32 API, but also being "bug-compliant", where even undocumented behaviours are duplicated correctly.

And then we have the whole DirectX issue. DirectX basically achieves the same thing as OpenGL, but given a piece of source code, you need to again duplicate everything perfectly. And now we're talking about really esoteric behaviour (graphics are not simple ).

As i92 says, WINE is basically trying to do what you describe: achieve perfect binary compatibility with Windows. That's why they're not an "emulator", but rather a reimplementation. They are reimplementing the Win32 API. If you're interested in some of the issues or in helping out, they're the guys to talk to for sure.