#### Archived

This topic is now archived and is closed to further replies.

# Operating System Independence

This topic is 5704 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

If I compile code on a non OS-independent compiler, will it still be OS-independent if I didn''t use any system APIs? I really need to know. Thanks in advance. void Signature(void* Pointer) { PObject(Pointer)->ShowMessage("Why do we need so many pointers?"); };

##### Share on other sites
In theory: yes.

In reality: maybe. It depends. If you don't make any system specific calls (i.e. you don't use conio.h or something like it). For example, the following simple prog should work for any (to my knowledge) OS:

        #include <iostream>int main(void){   std::cout << "Press enter key to exit...";   std::cin.get();   return(0);}

However, if you do something like:

       #include <iostream>#include <conio.h>  // DOS specificint main(void){   std::cout << "Press enter key to exit...";   while(!kbhit());  // also DOS specific   return(0);}

In general, as long as you avoid OS specific code, you should be ok.

[EDIT] I'll get it right here in second...

/*=========================================*/
/* Chem0sh */
/* Lead Software Engineer & Tech Support */
/* http://www.eFaces.biz */
/*=========================================*/

[edited by - Chem0sh on June 8, 2002 8:17:16 PM]

[edited by - Chem0sh on June 8, 2002 8:17:51 PM]

[edited by - Chem0sh on June 8, 2002 8:18:40 PM]

##### Share on other sites
Yep. And the reason is simple: YOu do use OS speficic code.

Even when using the non-os-specific libraries, at one point this has to map to functionaltiy in the OS. This is normally deep down in the accompanying .lib files. but these get statically linked into the executable.

And the executable itself will be OS specific - the internal organisation of a windows exe file is different than from it''s Linux or BSD counterpart.

Anyhow, just recompiling is not that complex. BUT you need to keep build environments for everything around. ESPECIALLY because if you talk about a game, there is more than the exe.

That said, STILL stay as far away from things like GCC if you want performing code.

THONA

##### Share on other sites
quote:
Original post by Eli Gottlieb
If I compile code on a non OS-independent compiler

?

##### Share on other sites
quote:
Original post by thona
...Stay as far away from things like GCC if you want performing code.

Excuse you? And use what instead, MSVC? Using GCC makes a lot of sense if you want to develop on multiple platforms, because you''re virtually guaranteed to find GCC for them all (and for free at that), eliminating compiler issues such as standards compliance discrepancies, etc.

I suspect you''re simply ignorant of the -O2 flag.

##### Share on other sites
A OS-independent compiler is one that can compile for multiple platforms. Also, what is GCC? And I don't have to worry about EXE formats, I know where to find code to parse executable files. OK, here's what an example of what I'm trying to implement. I built a fairly large library in C++ and I compile it into OBJ files without any system calls. Then I write an OBJ file parsing program and use it to link the OBJ files to an application and use them as a library. According to what's been posted here so far, I could compile once and use on any OS where I have a parser becuase there's a standard format for OBJ files. Am I understanding this correctly?

void Signature(void* Pointer)
{
PObject(Pointer)->ShowMessage("Why do we need so many pointers?");
};

[edited by - Eli Gottlieb on June 9, 2002 1:24:25 PM]

##### Share on other sites
The object code - IIRC - is composed of opcodes. While there''s some similarities between code sets across processors, they''re not all the same. So builing an executable for 80x86 or Pentium will not be able to run on the Motorola (Mac) processors.

Along with that, you''ve got to deal with things like big-endian vs. little-endian... as people have said, the source code would be theoretically fine, but the object code (and therefore the exectuable) would need rebuilding.

OS-Independant compiler: you mean a cross-development system (i.e. developing for Mac on a PC)? As long as the compiler outputs the correct opcodes for the destination processor, it should work fine.

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

##### Share on other sites
quote:
Original post by thona
That said, STILL stay as far away from things like GCC if you want performing code.

I have to agree with Oluseyi on this one. GCC does just fine when you enable optimizations, especially if you hand tune to switches passed to it (or just use -O3 and possibly -funroll-loops).

##### Share on other sites
quote:
Original post by Null and Void
(or just use -O3 and possibly -funroll-loops).

## Optimizations# -------------GENERIC_OPT     = -O3 -funroll-loopsMIPS_OPT        = $(GENERIC_OPT) -INLINE:=ON:all:dfe=ON: -mips4\ -IPA:alias=ON:addressing=ON:aggr_cprop=ON:cgi=ON\-LNO:auto_dist=ON:non_blocking_loads=ON:gather_scatter=2:ou_further=3:‍Pf1=ON:‍Pf2=ON:‍Pf3=ON:‍Pf4=ONSPARC_OPT =$(GENERIC_OPT)X86_OPT         = \$(GENERIC_OPT)

[edited by - Fruny on June 9, 2002 2:48:40 PM]

##### Share on other sites
lib files are NOT usable across different OSs. even calls that are non system api calls in the "standard" library are implemented different on different OSs. obj files will link to OS specific code no matter what you do. recompiling on each OS is not difficult and should be as simple as just running the compiler.

here is an example of OS independet code, but requires OS dependent libraries.
int *a = new int();
delete int();

each compiler handles allocation differently. so that right there modifies how the code is generated. ussually new used on a struct call malloc() then the ctor which inits everything in the object. delete calls the dtor then free().

malloc is implemneted different on different systems, heck some OSs use different calling conventions (ie pass parms on teh stack, pass them using registers, caller should clean up parms, the function deals with cleaning up the parms, etc), as well as simply handling memory allocation differently. there is VERY little code that you can write that is truly 100% not relient on the OS.

there is no such thing as an OS independent compiler as you think. since the compiler compiles whatever it is given using the libraries it has avialible which are OS dependent. you can change the libraies and even the target platform (ie cpu) with some compilers.

question. does your OBJ file contain ANY OS code (ie use printf, basically an io call) or use anything that deals with memory? if so the opcodes compiled into the OBJ file will not run since it will fail to find the functions (ie not linked with the libraries, and different OSs handle dynamic libraries differently if they are even supported) or they are linked staticly in which you have OS specific code with in your OBJ file (the actually asm code to create blocks of memory is different in each OS, since OSs can map interrupt functions in any way they wish). dont try this. do things correctly and cross compile your code using proper dlls/o or libs/a. dont hack things using OBJ files. you will find its MUCH more work to ensure yoru code will run correctly and even more work to get arounf the limitations you will face because of yoru choices.

compiling ocde is not so difficult that it requires such a difficult workaround.

Eli Gottlieb, you say you found code to "parse" exe files. i assume this is only fo the pe format (ie win32). linux and other OSs use different mehods of storage AND initilization of exes.

what are you trying to create? a math library that works in linux and windows? you seem to be confised on some things. try explaining better what your are trying to do. i think you really just want to compile the code on a single platform, but have it work on mulitple platforms. this can work, it requires installing mulitple compilers and libraries for the platforms you wish to use, and compiling your binary for each platform.

##### Share on other sites
In all the performance test I''ve looked at, MSVC was often about twice as fast as gcc. The price of portability?

##### Share on other sites
Were these tests using the optimisations that everyone was talking about earlier, and in what context are you talking about here? Graphics programming, general etc. Very vague statement.

quote:
Original post by Magmai Kai Holmlor
In all the performance test I''ve looked at, MSVC was often about twice as fast as gcc. The price of portability?

##### Share on other sites
quote:
Original post by Magmai Kai Holmlor
In all the performance test I''ve looked at, MSVC was often about twice as fast as gcc.

Can you show us some of these tests you are refering to? In this article (which was primarily meant to compare Java and C/C++), (an old version of) GCC outperforms MSVC (MSVC 6 Enterprise) in 3 out of 5 tests, so I don''t think that they are so unequal as what you claim.

##### Share on other sites
quote:
Original post by Magmai Kai Holmlor
In all the performance test I''ve looked at, MSVC was often about twice as fast as gcc.

..and Intel C/C++ Compiler twice as fast as MSVC.

##### Share on other sites
Thanks everyone. To clarify, I needed to create a math library to be used in CAD software that''s run on an inter-OS network. I''m hearing that the only way to do this would be to compile once for each system or compile using a muli-platform compiler. Either way, I end up with one copy of the library for each platform. So I''m going to just encode the library''s source code and distribute in a record-based binary file. Then I write a program for each platform to decode the source and invoke the installed compiler to generate linkable OBJ files. By the way a person, there IS a standard for binary-module format. You ever hear of COFF? Well I checked, and most systems support some version of it, even if they add "extentions", so that will be the format of my math library''s encoded source file. Again everyone, thanks for all the help!

void Signature(void* Pointer)
{
PObject(Pointer)->ShowMessage("Why do we need so many pointers?");
};

##### Share on other sites
quote:
Original post by Null and Void
In this article (which was primarily meant to compare Java and C/C++), (an old version of) GCC outperforms MSVC (MSVC 6 Enterprise) in 3 out of 5 tests, so I don''t think that they are so unequal as what you claim.

And by all accounts, the new GCC 3.1 produces even better code still. (At the expense of slower compile times, however.)

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]

##### Share on other sites
quote:
Original post by Kylotan
And by all accounts, the new GCC 3.1 produces even better code still. (At the expense of slower compile times, however.)

That''s been my experience with GCC 3.x . That''s why I made sure to add "an old version" to that post.

##### Share on other sites
Looking at that Java/C comparison article, the setups aren''t really comparable. The GCC setup is set to do a lot more aggressive optimization...The MSVC setup, for example, is generally isn''t biasing its optimizations towards Pentium Pro and above as it would if one used the /G6 option... The gcc setup, on the other hand, clearly is set up to bias towards ppro and above.

Anyway, gcc isn''t that bad. Not bad enough that you have to worry too much about its performance, especially as you can use it for free, which is a big plus. However, in my experience, having used both quite extensively (up to their current release versions) MSVC++ (especially V7/.Net, but V6 too) produces consistently faster code when it comes to real world C++. As far as straight C goes, they might be closer and gcc might even beat it in some cases..Dunno, haven''t programmed straight C code in years. But for C++ code using templates and other langage features, I''d pick MSVC++ over gcc any day (though they both still have problem areas when it comes to the dark corners of the C++ standard).

In any case, if performance is what you care about over price, you''ll want the Intel compiler (mentioned previously) which is even better yet, or Codeplay''s vectorizing compiler (doesn''t support C++ under Windows yet though...supposed to have a version that would in May but its delayed). Both of those beat MSVC++, but if you value your sanity you''ll still buy a copy of VC++ for the slick IDE and debugger (debug builds in MSVC++ so you get the edit & continue and other rather nice debug functionality, release builds in the performance compiler of your choice...the two mentioned both support Visual Studio IDE integration).

##### Share on other sites
quote:
Original post by gmcbay
Looking at that Java/C comparison article, the setups aren''t really comparable. The GCC setup is set to do a lot more aggressive optimization...The MSVC setup, for example, is generally isn''t biasing its optimizations towards Pentium Pro and above as it would if one used the /G6 option... The gcc setup, on the other hand, clearly is set up to bias towards ppro and above.

Yes, I''d like to see the test done again with every compiler set to optimize for the current system. If anyone would like to come up with some code to duplicate the tests run under than article, maybe that could be done (I don''t see any download link for the source code in the article).
quote:
Original post by gmcbay
Both of those beat MSVC++, but if you value your sanity you''ll still buy a copy of VC++ for the slick IDE and debugger...

When it comes to my sanity, I''d have to say that MSVC (6, at least, the only version I own) has caused me many more problems when it comes to standard compliance than Borland (5.5) or GCC (any version that I''ve used) .