OSDev.org

Hai


1.why windows executable files or not compatabile with other os (linux)and vice versa?


i have learned that all programs whether it is windows or any other os, is converted in to machine language and executed by the processor. i am having windows and linux on i686(p4) processor, both operating systems convert their program in to machine language which is common for i686 processor, then y there is a incompatability between the programs from various operating system.

Linux /could/ support the windows format but the programs all have dependicies of their own. (eg. DLLs). This would most likely need a full windows-like API from scratch because loads of programs use windows API (eg BitBlt, and PlaySoundA). This requires 2 things: standard GUI, and windows CORE files.

It should be mentioned that indeed Wine does implement Win32 API on Linux so with Wine installed Linux does support Windows programs, at least up to the completeness of Wine's implementation, which isn't perfect yet, but allows one to run a lot of stuff anyway.

There are other such implementations than Wine too, Cedega (former WineX, a fork of Wine) and Crossover Office some to mind at least.

Mystran is right.

I'm gonna make a correction to myself:
standard GUI. this can be omitted for DOS programs.

Cheers, DH.

PS. Hope this helps.

It would be possible to load them if you wrote the Windows API from scratch (such as ReactOS does I think) . I really don't think it's worth that sort of trouble though.

If anything write a program to work like WINE

The executables are incompatible primarily because Linux and Windows programs use different means of interacting with the operating system (the syscall mechanism).

For example: Moving arguments into particular registers and trying to perform "int $0x80" to make a system call on Windows will cause an exception and the program will be terminated. That is not how you call the operating system in Windows. It is in other operating systems. Likewise, using the Windows system call mechanism will probably fail in other operating systems (unless this is taken care of, like, as mentioned, with Wine).

Second, the linker formats used are often different as well. The format of an EXE executable is different than that of an ELF or a.out executable (but since you could simply set up a loader for it, this is not as significant an issue as the first).

samjkd wrote: why windows executable files or not compatabile with other os (linux)and vice versa?

As always, I can't resist but attempt to give an even better explanation.

1) When you compile source code to object code, the format of the object code differs. On Linux, object code is rendered in ELF (Executable and Linker Format), Windows prefers PE (Portable Executable) format.

2) When you link object code, startup code is linked into the resulting executable. This startup code is OS specific, as there are differencies in how each OS sets up a process. These differencies are (of course) also reflected when you start an executable. Where is the code loaded? Where is the stack set up? Which memory area is reserved for the kernel functions? How are e.g. C++ exceptions supported? What is the default priority, which priorities are available?

i have learned that all programs whether it is windows or any other os, is converted in to machine language and executed by the processor.

An executable is loaded into memory, prepared for running, and executed under control of the OS. The OS is, in turn, loaded / prepared / executed by the bootloader. The bootloader is likewise handled by the BIOS. Effectively, only bootloaders enjoy the benefit of all starting on an equal footing. Anything after that is dependent on whatever does the loading / preparing / executing.

i am having windows and linux on i686(p4) processor, both operating systems convert their program in to machine language which is common for i686 processor, then y there is a incompatability between the programs from various operating system.

One thing I haven't even mentioned is the API. When you code a program using OS-specific functions - like, DirectX - those functions are not compiled into the program, but rather the executable receives a table of unresolved references to the libraries containing the (DirectX) functions. Even while ignoring the fact that each OS has its own way of resolving those references, a Linux box just doesn't have a DirectX library...

Hope that helps.

Slightly off-topic but still in scope, but what about device drivers? Personally, I'd love my kernel to eventually be able to load windows drivers. Reasons be that a good portion of all devices have specialized drivers written for windows.

Better yet; what about a standardized device driver format that could be convertable from and to? Personally I believe this would be worth looking at.

Cheers, DH.

Drivers suffers from the same problems as programs, but at another level. There have been attemps to uniformize (e.g. Uniform Driver Interface) device drivers programming, but without support from Linux or Windows, it has lead to a dead end.

It is difficult to offer a virtual environment for a driver without having to add half of the 'ordinary target' system to the host system, unfortunately ...

Well..... I'm gonna try ;P
Thanks!

Warrior wrote: It would be possible to load them if you wrote the Windows API from scratch (such as ReactOS does I think) . I really don't think it's worth that sort of trouble though.

If anything write a program to work like WINE

In fact, ReactOS and Wine share code about as much as possible. ReactOS is kind like a "next step" from Wine: start with Wine implementation of Win32, and build an NT-like kernel under it. So... basicly...one should expect about the same amount of compability from ReactOS and Wine, except that ReactOS has the potential of supporting even Windows drivers.

That is, if I've understood correctly.