Platform Detection Library?

Quote:

---

But what is a 32-bit app? What makes a program compatible with each bit-width?

---

Different registers are available (64-bit registers aren't available in 32-bit mode), different size of pointers, different instruction sets, probably many other things.

In short, you won't be able to make a binary that will run on both 64-bit (as 64-bit binary) and 32-bit systems, at least not for x86.

Another option is to define things in the call to the compiler.

For example, for gcc

Code:

---

#for 32-bit
gcc -DBITS=32 xxx.c

#for 64-bit
gcc -DBITS=64 xxx.c

---

Then in the code you have the BITS macro already defined.

Not sure how one would do that with VS.

Old questions that I don't want to lose in the page jump:

• Do "POSIX or X/Open" require any macros for identification of compatible systems? If not, what am I missing? Is SF just wrong?
• Why wouldn't cyberfish's detection inform a 64-bit binary compiled from a source written on a 32-bit system that it's 64-bit?
• Should the program even care whether it was compiled as written?

Quote:

---

Originally Posted by cyberfish

Different registers are available (64-bit registers aren't available in 32-bit mode), different size of pointers, different instruction sets, probably many other things.

In short, you won't be able to make a binary that will run on both 64-bit (as 64-bit binary) and 32-bit systems, at least not for x86.

---

So the 32-bit or 64-bit nature is a property of the binary (and compiler) but not the source? And a set of sources written on a 32-bit system will require no changes to be compiled and run on a 64-bit system?

Quote:

---

Originally Posted by cyberfish

Another option is to define things in the call to the compiler.

For example, for gcc

Code:

---

#for 32-bit
gcc -DBITS=32 xxx.c

#for 64-bit
gcc -DBITS=64 xxx.c

---

Then in the code you have the BITS macro already defined.

Not sure how one would do that with VS.

---

That's certainly an improvement, and a nice last resort for *nix and emulators; the divergent sources become shell scripts which are naturally modular. But I still wish the sources could be perfectly portable, especially across such an important difference as 32-bit (incumbent) and 64-bit (strong challenger).

This is somewhat similar to this other technique which I don't fully understand. What's an instruction set and how would it be mapped to a macro? And that would need to be worked into the compiler itself, right?

As for working the first solution in Visual Studio, it might be possible but someone who can actually run it would have to investigate. The possibility is explained at the bottom of http://www.devsource.com/c/a/Using-V...ommand-Line/1/.

Quote:

---

Why wouldn't cyberfish's detection inform a 64-bit binary compiled from a source written on a 32-bit system that it's 64-bit?

---

It would, as long as the binary is indeed compiled as a 64-bit binary (64-bit systems can run 32-bit binaries). Assuming we are only dealing with x86 here.

brewbuck was just suggesting that there is an easier way (define macros yourself).

Quote:

---

Should the program even care whether it was compiled as written?

---

What do you mean by compiled as written?

Compilers are allowed to do whatever they want with the source (re-order instructions, unroll loops, combine constant expressions...) as long as the resulting binary works as the source specifies.

Quote:

---

So the 32-bit or 64-bit nature is a property of the binary (and compiler) but not the source? And a set of sources written on a 32-bit system will require no changes to be compiled and run on a 64-bit system?

---

Yes, if you write in standard and portable C/C++, and don't make assumptions like pointers to be of certain length (always use sizeof()).

Quote:

---

That's certainly an improvement, and a nice last resort for *nix and emulators; the divergent sources become shell scripts which are naturally modular. But I still wish the sources could be perfectly portable, especially across such an important difference as 32-bit (incumbent) and 64-bit (strong challenger).

---

To eliminate the use of compiler switches, you will have to deal with those ugly platform-dependent macros on the SF page.

How many platforms are you intending to support?

An easier approach would be to just support 1 or 2 platforms that you KNOW your code will be used on, but write your code portably, so it can be easily modified to be compatible with other platforms should the need arises.

Quote:

---

Originally Posted by cyberfish

What do you mean by compiled as written?

---

That was actually a restatement of the question just below it; I typed the later one first, then thought I typed it before that post and added the earlier one.

Quote:

---

Originally Posted by cyberfish

Yes, if you write in standard and portable C/C++, and don't make assumptions like pointers to be of certain length (always use sizeof()).

---

Thanks; that's what I was hoping.

Quote:

---

Originally Posted by cyberfish

How many platforms are you intending to support?

---

The application that prompted this search only needs to run on Linux, and maybe Windows. But I want a library of macro (and variable) definitions to let any application immediately know "where" it is with reliability. I think it's silly that no standard is in place to provide such detection via the same identifier(s) on all systems.

Quote:

---

Originally Posted by cyberfish

An easier approach would be to just support 1 or 2 platforms that you KNOW your code will be used on, but write your code portably, so it can be easily modified to be compatible with other platforms should the need arises.

---

True, but that approach must be repeated for each program, and thus a library would be useful.

I just realized that I've somehow been overlooking the standard macros on that page... They are all in <unistd.h>, but that won't be available on Windows. So here is my current solution, which doesn't yet use the UNIX macros because I'm not sure which operating systems they apply to. I'm not sure whether anything else should be defined via macro, especially since all Windows paths depend on the drive's letter which can only be found via substring.

Code:

---

#if defined( _WIN32 ) || defined( __WIN32__ ) || defined( __TOS_WIN__ ) || defined( __WINDOWS__ ) || defined( _WIN64 )
    #define OS_NAME "Windows"
    #define SLASH '\\'
#else
    #include <unistd.h>
   
    #define SLASH '/'
   
    #if defined( Macintosh ) || defined( macintosh )
        #define OS_NAME "Mac OS 9"
    #endif
   
    #if defined( __APPLE__ ) && defined( __MACH__ )
        #define OS_NAME "Mac OS X"
    #endif
   
    #if defined( linux ) || defined( __linux )
        #define OS_NAME "Linux"
    #endif
   
    #if defined( sun ) || defined( __sun )
        #define OS_NAME "Solaris"
    #endif
#endif

---

Unless you are doing very platform-specific stuff, it's usually sufficient to just support 2 categories - Windows and the "rest of the world", since Mac/Linux/Unix/BSD/Solaris... all behave similarly. Windows just likes to be different - case insensitivity, forward slashes, multi-root (whatever the proper name is), strange headers..., so we make a special case for it.

For the rare instances where a function is defined on a platform but not on another (or defined differently), I would just make a wrapper function for it, and hide all the nasty platform-detection stuff inside.

Quote:

---

Originally Posted by cyberfish

Unless you are doing very platform-specific stuff, it's usually sufficient to just support 2 categories - Windows and the "rest of the world", since Mac/Linux/Unix/BSD/Solaris... all behave similarly. Windows just likes to be different - case insensitivity, forward slashes, multi-root (whatever the proper name is), strange headers..., so we make a special case for it.

For the rare instances where a function is defined on a platform but not on another (or defined differently), I would just make a wrapper function for it, and hide all the nasty platform-detection stuff inside.

---

What about z/OS? No-case/upper-case, 8 char dataset names, '.' separator, EBCDIC... ;)

Also, keep in mind that you can determine a lot of these platform-specific parameters by simply examining your environment variables, eg: getenv( ), or even main:

Code:

---

int main( int, char**, char** envp )
{
        while( *envp )
                puts( *envp++ );
}

---

Oh... I thought the *nixen had significant differences other than compilation algorithms.

Now I wonder what the difference is between %USERPROFILE% and %HOMEPATH%... Just a pair of aliases?

I tried to find something else to ask, but I think everything (except the above mild curiosity) has been answered. Thanks!