?
Solved

Is a compiler OS dependent

Posted on 2003-03-06
6
Medium Priority
?
1,432 Views
Last Modified: 2013-12-06
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?
0
Comment
Question by:dssrrjy
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
6 Comments
 
LVL 3

Accepted Solution

by:
bjorndahlen earned 200 total points
ID: 8082105
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.
0
 
LVL 49

Expert Comment

by:dbrunton
ID: 8082286
>>> 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.
0
 
LVL 24

Expert Comment

by:SunBow
ID: 8084257
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.
0
 
LVL 3

Expert Comment

by:bjorndahlen
ID: 8091853
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.  
0
 
LVL 12

Expert Comment

by:paullamhkg
ID: 9229632
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
0

Featured Post

Get real performance insights from real users

Key features:
- Total Pages Views and Load times
- Top Pages Viewed and Load Times
- Real Time Site Page Build Performance
- Users’ Browser and Platform Performance
- Geographic User Breakdown
- And more

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Why Shell Scripting? Shell scripting is a powerful method of accessing UNIX systems and it is very flexible. Shell scripts are required when we want to execute a sequence of commands in Unix flavored operating systems. “Shell” is the command line i…
I don't know if many of you have made the great mistake of using the Cisco Thin Client model with the management software VXC. If you have then you are probably more then familiar with the incredibly clunky interface, the numerous work arounds, and …
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
This video shows how to set up a shell script to accept a positional parameter when called, pass that to a SQL script, accept the output from the statement back and then manipulate it in the Shell.
Suggested Courses

752 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question