dssrrjy
asked on
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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
(cross-compilers).
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)
request,
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.
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
(cross-compilers).
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)
request,
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.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Paul
EE Cleanup Volunteer
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.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Paul
EE Cleanup Volunteer
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.