Thread: How to detect the operating system at runtime?

Assuming "OS" here means things like Linux, Windows, MacOS X, etc rather than Windows 98, Windows NT or Linux 2.4 and Linux 2.6, then it's not possible to have ONE executable file for different OS's, since these use different executable file formats [well, I think MacOS and Linux actually use the same format files, but they have different shared libraries and OS interfaces].

So you need to compile your application for the OS (and processor type) that you are wanting to use. Yes, you can make it work with different OS's at runtime if you really want, but they need to be close enough in relation to each other [e.g different versions of Windows or Linux]. For most cases, those different versions are close enough that MOST things can be done the same way anyway, so knowing the difference only matters in some small detail things.

--
Mats

For most cases, those different versions are close enough that MOST things can be done the same way anyway.

... including some sort of API or other method of getting the OS name or type.

Originally Posted by zacs7

... including some sort of API or other method of getting the OS name or type.

Sure, but the point was more that "if the OS is so different that you need to know which one it for anything but very special operating system calls, then it's probable that you need to know before you compile which OS it is".

--
Mats

Sigh, I've been missing the point of your posts all day (don't worry it's me, not you)... sorry

Originally Posted by zacs7

Sigh, I've been missing the point of your posts all day (don't worry it's me, not you)... sorry

Well, maybe I should have been more clear - if you misunderstand it, someone else may also misunderstand it - and I'd rather that you asked for a clarificiation point than that someone else is misunderstanding the point and using that misunderstanding in some way to get even deeper into the world of misunderstanding. Sometimes I read my own posts and think "did I really say that - I should have mentioned <something> to make it clearer".

--
Mats

Well, a windows executable is actually a DOS executable, but it has a special marker in it that tells the OS that it "knows about protected mode". If you start the same application in "real mode", it runs a stub. Applications that can run in both DOS and Windows environments use this stub part to implement their own way to do the same things that Windows does when run in Windows [such as setting up a 32-bit environment]. It is either a complete duplicate of the same applicaiton, or it links together the 32-bit application with the Windows environment.

I'm pretty sure [although it would probably take me a few hours to prove] that the dos extender has it's own little set of compatibility functions that are EITHER Windows 32-bit API or compatible with old-fashioned DOS.

The grub4dos when used with Linux uses kexec, which is not quite the same as "running an executable file in Linux" - becasue kexec really replaces the kernel with the executable file you load. Once grub4dos has been loaded, it's not executing inside the Linux environment, it is executing in it's own environment [A boot loader is such a task that you can't really use any OS anyways, so the boot-loader has to understand some basics in itself, and not rely on the OS to solve those things - grub for example has complete filesystem support to read from the disk in various types of filessystems, such as the more popular Linux and Windows filesystems].

Writing code for either of the above examples is relying on "you either put a layer in to translate, or you make the function yourself", which is not really "working on several OS's" as such.

--
Mats

Originally Posted by sept

Before I thought NT and DOS are pretty much different.

Of course, but they are.
But AFAIK, Windows executables also contain a little stub of DOS code to prevent them from executing from DOS.
The rest of the executable format is totally different from DOS.

If it were possible then everyone would be doing it already. That's all you need to know.

And looking at bootlace.com, it seems to be an ELF executable for Linux. It probably just happens to also have a suitable piece of code to work as a DOS executable - after all, a .com file is just a binary file with no "markings", so ANY file can be made into a .com file - write "aaaaaa" into a text file, rename it to ".com", and you can execute it. It won't do anything meaningful, and it will probably crash, but the OS will accept it as an executable file.

If circumstances are right, then the first "instruction" in bootlace will be executable. In this case, it's 7F 45, which translates to JG (JNLE). I don't know for sure, but I expect that to be true when a .com file starts, so it will jump 41 hex bytes forward. Then it sets up an environment which resembles Linux [sufficiently to do the work of writing one sector to the hard-disk - and it may not even do it in Linux style at all, I can't find the source, but it wouldn't be hard to use BIOS calls from the DOS-side, and use Linux code when running under Linux.

But this is not your average programming type things - it's tricky stuff to solve particularly tricky situations.

As to the executable files for Windows and DOS: You _CAN_ if you like replace the stub with your own executable by /STUB:filename when linking your executable (that is, if you are using MS tools).

--
Mats

Originally Posted by cpjust

Yes, call the appropriate OS API function, which is different on every OS.

This is obviously said in jest, since how do you find out which OS it is BEFORE you call the OS-specific function. There is no way to set up a signal handler to handle the "bad system call" or "invalid instruction" or whatever happens when you try to call a Linux system call on Windows or vice versa. Now, if we use tricks like the bootlace above, it is POSSIBLE to set a flag somewhere in a known good memory location [.com files are modifiable after loading - otherwise you couldn't use initialized arrays], and then from that know whether it was started one way or the other.

Likewise, replacing certain parts of Windows API with your own API is entirely possible - it's hard work, but possible.

--
Mats