Is a compiler OS dependent

Is a compiler OS dependent? what is an exe file.
if compiler is not OS dependent, why an exe file
generated on Windows platform is not executing
on unix? Can i use a same compiler on different
Operating systems?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Compilers translate source code such as C and Pascal into
an executable image. In addition to generating machine
instructions, the executable must contain prolog and
epilog code that deals with aquiring and releasing memory,
saving/restoring state and so forth.
In addition to this, the compiled
executable generally contains calls to other OS-dependent
run-time facilities.
Memory management for instance,
is highly OS dependent and thus an executable generated for Windows 98 is note going to work in say Linux even if the hardware is the same. Also, some OS'es require the applications
to participate in the thread management, e.g. the application may be required to give up the processor explicitly (not fully pre-emptive multi-tasking).
And so on..
Windows support several different executable formats.
The oldest is the .com which has it's roots in cp/m.
This is a pretty raw binary, with little other information,
no relocation info is present and so on.
a Windows .exe file contains a combination of instructions,
data, and resources. In addition to this, it has headers
primarily containing information for the loader.

OK, if you're still with me :-) , here is the short version:
executables generally contain information intended for
the OS responsible for loading it and requires services
provided by that particular OS.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
>>> OK, if you're still with me :-) , here is the short version:
            executables generally contain information intended for
            the OS responsible for loading it and requires services
            provided by that particular OS.

bjorndahlen's answer above.

This means that compilers are OS dependent.
And you (generally - minor exceptions) cannot use a compiler on different OS systems.

Give bjorndahlen the points.
hmm I while I usually agree with dbrunton, not so here, those are MickeySoft Greenie_answers.

A compiler is indeed platform dependent, but it has no inherent dependency on any OS, Unix or MS or VMS or MVS, what it has to do with is the actual hardware being used, essentially, the CPU.  In this sense, Linux is slightly closer to MS OS since both need to convert to Intel machine code.

I ask you: What is basic function of compiler?

*** It takes your high level language and converts it to machine code, for code specific to cpu. Thus any x86 compiler will never produce code that can execute on either Motorola or any other chips used in Apple HW.

Now if you purchase a 'compiler' that does not produce machine code, but merely makes calls to existing OS, coincidentally produced by same company, well, that is neither my problem now the question.

> why an exe file generated on Windows platform is not executing on unix?

You cannot simply move executables from one unix to another either. It is not about the OS. It is about the CPU. You also cannot move between Sun's Sparc and Linux. Linus is x86 so it is HW issue, not (necessarily) the OS.

Now, OS does become a factor for when programmers care about such things as other files on an existing system. To get at the file, the compiler needs to know filesystem, and that is indeed OS dependent. To make a compiler more friendly to use, it is easier to make it both aware and compatible with some filesystem, so it may well be true that you need to also match compiler with OS at compile time. But runtime is another matter.

One example that may be more known is when borland provided compiler options to run on either 16 bit or 32, and still develop for either 16 or 32. Thus, for same x86 cpu, the developer could run in a Windows OS, but still develop for DOS. I believe the reverse was true as well, that developer could boot to DOS, but still develop application that could be compiled for Windows. So you see it is not the OS itself, but it may indeed be relevant to the filesystem employed by OS. Even that not necessary, you can boot a diskette that runs small compiler. It can place result on another diskette. No OS needed. I think not a few of the DOS alternatives employed schemes like that to be remaining independent of MS.
I'm not going to argue the strict definition provided by SunBow.

However, most compilers available do not adhere to this strict definition.

A typical simple compiler may go thru the following steps
(or something similar):

Preprocessing -> get rid of comments, substitute for
 preprocessor statements

Lexical analysis > build a token tree

Parsing -> check for syntactic correctness, and generate
 an intermediate code representation.

These first steps (the front-end) are apart from character representations highly machine (and OS) independent.

Code generation -> generate an object module

Linkedit -> linking with external libraries,
 create an executable (load module) by resolving addresses.
The last two steps (the back-end) are hardware and generally OS dependent. (Even worse - the obj files
even for the same target environment produced by one
 vendor's compiler are generally incompatible
 with another vendors .obj files, thus requiring
 converters, or use of a vendor specific linker.)

Some compilers will do all of these steps and generate an
 executable directly, others will require a separate
 linkedit step, and others again will produce assembler
 source, to be assembled and linkedited separately.

There are many compilers that will allow you to specify
 memory model, 16bit or 32 bit or even a different
 architecture for the target environment

If your programming language allows for dynamic memory
 allocation, this dynamic memory is generally requested
 from the specific OS running on the target machine.
 This dynamic (automatic) memory request may either be
 explicit through a malloc (or some similar function)
 or implicit to house variables in reentrant programs.
The latter is what I was refering to when mentioning
 prolog and epilog code generated by a compiler.

The same holds true for I/O functions, exception handling,
 and other OS dependent functions, etc.  

Most compilers targeting the Windows (read win32)
 environment will produce a .obj file including references
 to external functions (such as DLL's).

Other compilers running on a S390 platform may be able to
 produce code that will run under MVS or VSE, the code
 generated dependent on a compiler directive, or
 handled by OS specific sets of include libraries.  

The fact that you can create a bootable floppy, and do
 some things by addressing the hardware directly through
 the BIOS, has in my opinion very little to do whether
 (most) compilers are OS dependent or not.  

On a x86 platform, even executable with the same extension
 may in fact be different formats:

One .exe file may only have a simple DOS exe header,
 and run under DOS or possibly in a DOS virtual machine.

Other .exe files may be PE files which includes
 information of the intended target operating system,
 references to DLL's, etc.

Linux, on the other hand may use elf executables, which are
incompatible with .exe files.

So is the strict definition:
>> "It takes your high level language and converts it to machine code, for code specific to cpu" useful ?
I believe it is, in particular if you are are involved in
compiler development, or education.

Is it relevant with regard to commercially available
 compilers and when explaining why the executables
 targeted for windows will not run on Linux ?

I think not.  
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is to:

Accept bjorndahlen's Comments as answer

Please leave any comments here within the next seven days.


EE Cleanup Volunteer
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.