Operating System Independence

Started by
18 comments, last by Eli Gottlieb 21 years, 10 months ago
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?"); };
void Signature(void* Pointer){PObject(Pointer)->ShowMessage("Why do we need so many pointers?");};
Advertisement
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]
/*=========================================// Chem0sh// Lead Software Engineer & Tech Support// http://www.eFaces.biz=========================================*/
The source code will be ok. The binary will need recompiling, though.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]
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
RegardsThomas TomiczekTHONA Consulting Ltd.(Microsoft MVP C#/.NET)
quote:Original post by Eli Gottlieb
If I compile code on a non OS-independent compiler

?



--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
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.
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]
void Signature(void* Pointer){PObject(Pointer)->ShowMessage("Why do we need so many pointers?");};
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

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

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).

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]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

This topic is closed to new replies.

Advertisement