Printable View
In Web development, we have browser/feature detection libraries as a last resort for cross-browser applications. Is there any equivalent library, or at least an algorithm, for detecting the OS at runtime? Or must we compile cross-platform applications with slightly different sources for each platform?
You might be able to detect variants at runtime, but you can't detect the OS since you've already done that by compiling a binary for a given platform.Quote:
Originally Posted by Jesdisciple
You can't have a single binary that could actually load and run on both Linux and Windows, for instance. You already know you're on some variant of Windows by virtue of the fact that you compiled a Windows executable. The most you can determine is possibly what variant of Windows (9x, NT, 2k, XP, Vista, etc).
This probably depends what your actual question is.
You will have to compile a program separately for any given platform, since Windows exectuables != *nix executables != etc. So if you have platform-specific code, you might as well do it at compile-time as anything else.
I know a different compiler must be used, but I don't want to maintain divergent sources, each one for a different compiler. I want the same source to work with all the compilers, and all the OSes (within reason).
But I'm not just looking for source-compatibility; I also want to determine what the hard drive is called ( / on *nix, C:\ on Windows, no idea on Macintosh) and where the user's personal information is stored.
I take it that NSPR would grant the source-compatibility; do I need to build my own detection algorithms (based on env vars, I guess) on top of that?
Thanks for all the replies.
Use pre-defined macros?
http://predef.sourceforge.net/preos.html
I'm a bit lost with the macros... I expected it to be something like _COMPILER being defined as "GCC" or _OS being defined as "Windows". How do you use macros with platform-specific identifiers to determine a platform?
etcCode:#ifdef _WIN32
#define OS WINDOWS
#else
#ifdef linux
#define OS LINUX
#else
#ifdef __APPLE__ & __MACH__
#define OS MAC_OSX
#endif
Does that work? I thought you need to do this to check if they're both defined:Quote:
Originally Posted by cyberfish
or is that code doing something else?Code:#if defined( __APPLE__ ) && defined( __MACH__ )
Ah yes, I just copy and pasted it from the page.
I don't find any such macros in the Standards section.Quote:
Originally Posted by http://predef.sourceforge.net/preos.html#sec33
What does all that mean in practice? Is Compaq's compiler DEC? Do Unix-like systems (Solaris, Linux, Mac) also identify as Unix? If so, does the preprocessor support ! (Boolean inversion)?Quote:
Originally Posted by http://predef.sourceforge.net/prestd.html#sec6
Also, what can I do for Mac OS <9?
The existence of the _WIN64 macro introduces another complication... What is the difference between 32-bit and 64-bit programs? How can I detect the bit-width of relevant hardware, including the CPU?
I appreciate this enormously.
> I don't find any such macros in the Standards section.
That's because there aren't any.
Standard C and C++ don't give a hoot about your OS or processor or ...
At best, all you'll be able to manage to say is
"This code can be compiled with gcc on Linux, and compiled with Microsoft Visual C++ or Borland on Windows".
Download something like zlib, which will compile for quite a wide range of compilers. But the code is a mess in places in order to achieve this.
Set realistic goals for the subset of operating systems and compilers you're willing to support and go from there.
32/64-bit detection is easy.
Code:printf("%d-bit", sizeof(int *)*8);
Sure, but you could just as well just #define it, since you know what you're compiling for. The more interesting question is how to determine, if you are a 32-bit app, whether you are running on a 64-bit processor.Quote:
Originally Posted by cyberfish
Salem, the quote was talking not about standard C/C++ but about standard UNIX. Do "POSIX or X/Open" require any macros for identification of compatible systems? If not, what am I missing? Is SF just wrong?
How would you #define it if the same source is preprocessed and compiled for both 32-bit and 64-bit?Quote:
Originally Posted by brewbuck
But what is a 32-bit app? What makes a program compatible with each bit-width?Quote:
Originally Posted by brewbuck
And why wouldn't cyberfish's detection work for that?
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.Quote:
But what is a 32-bit app? What makes a program compatible with each bit-width?
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
Then in the code you have the BITS macro already defined.Code:#for 32-bit
gcc -DBITS=32 xxx.c
#for 64-bit
gcc -DBITS=64 xxx.c
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?
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
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).Quote:
Originally Posted by cyberfish
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/.
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.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?
brewbuck was just suggesting that there is an easier way (define macros yourself).
What do you mean by compiled as written?Quote:
Should the program even care whether it was 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.
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:
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?
To eliminate the use of compiler switches, you will have to deal with those ugly platform-dependent macros on the SF page.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).
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.
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
Thanks; that's what I was hoping.Quote:
Originally Posted by cyberfish
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
True, but that approach must be repeated for each program, and thus a library would be useful.Quote:
Originally Posted by cyberfish
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.
What about z/OS? No-case/upper-case, 8 char dataset names, '.' separator, EBCDIC... ;)Quote:
Originally Posted by cyberfish
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!