Thread: How to detect the operating system at runtime?

Originally Posted by matsp

This is obviously said in jest, since how do you find out which OS it is BEFORE you call the OS-specific function.

Well, technically, it IS possible to just try to find and load some system dlls and scout for the proper function inside them (dynamic dll loading). That way it MIGHT be possible to find out what platform it is. I'll give no guarantees to making it work, though.

Originally Posted by Elysia

Well, technically, it IS possible to just try to find and load some system dlls and scout for the proper function inside them (dynamic dll loading). That way it MIGHT be possible to find out what platform it is. I'll give no guarantees to making it work, though.

But how do you load a DLL without knowing whether you should call LoadLibrary, loadlibrary or some other function? LoadLibrary is not a user-mode function, so it will perform some operation to try to get into the kernel code. This will not work.

Try adding

Code:

asm { mov eax, 20; int 0x80 }

to your windows app, and it will definitely crash [No, I haven't actually tried it - but I do know that interrupt vector 0x80 is not used by Windows]. Do the corresponding on a Linux system and you get the current process ID. No, I don't know what the eax value for loadlibrary is...

And I obviously gave up a bit early searching for the bootlace code - I gave it a few more minutes and found this bit:

Code:

	.byte	0x7F, 0x45, 0x4C, 0x46	# ELF magic number
					// 7F 45 = jg dos_entry_point
					// 4C = decw %sp
					// 46 = incw %si
... // further down
.ascii	"\r\nError: Unsupported DOS. The DOS exec function call(int21/AX=4B00) did not\r\ntransfer flags of GREATER-THAN to this program. Report this problem to the\r\nmaintainers of GRUB FOR DOS.\r\n\r\n\0"

So like I said, it's expecting the JG instruction to be taken to jump to dos_entry_point


Another piece of code does:

Code:

	movzbl	ABS(read_only), %eax
	movb	$0x3d, %ah	// open file for read/write
	movl	%edi, %edx	// DS:DX points to ASCIZ filename
	int	$0x21
	jnc	1f
	negl	%eax		/* EAX < 0 */

So it is using DOS system calls to read files. Basicly, there are two versions of the same program for the DOS and Linux version (you can read DOS files in Windows too if you write it in 16-bit code).

And yes, it's fairly complicated.
--
Mats

Originally Posted by robwhit

Linux might not have a disk.

Neither might Windows - although it is probably harder to achieve that in general.

But more importantly, to read the disk you either need kernel code - which is kind of difficult to achieve without knowing what OS it is to load the driver into the kernle - or you need to know the system calls to read from the filesystem. In which case we're back to "knowing how to do system calls in the OS".

It is a catch-22 situation: Paraphrazing Joseph Heller: "If you aren't crazy, you want to get out, so if you want to get out, you'r obviusly not crazy - so why should you be sent home"

--
Mats

If you're writing code in a compiled language like C or C++, you basically have to compile the program separately for different platforms. It's just the way things work.

Of course, if you write portable code, you can just distribute the source code and have everyone compile it for themselves.

Originally Posted by cpjust

But wouldn't it still have a / root directory and some files required to boot (even if they are all read-only)?

There is a root directory somewhere, but it's not a DISK necessarily. But the BIG problem is still that there is no way you can GET to the disk without knowing which OS it is - because you can't read/write the hardware directly [assuming you even know that it's an IDE disk or whatever].

I did think yesterday that there may be a way that you can do it:
A .com file like the bootlace. Then we could examine some common registers such as FS/GS [assuming the processor is at least a 386]. The FS/GS registers usually have some sensible/detectable values in Linux, but not in DOS. Looking at general registers, stack value, and such things would also be a possibilty. But I'm sure it would be pretty difficult to determine without relying on versions of the OS's.

--
Mats

But some filesystem functions are OS independent, like fopen(), fread(), and all of the stuff in <stdio.h>

Originally Posted by cpjust

But some filesystem functions are OS independent, like fopen(), fread(), and all of the stuff in <stdio.h>

Yes. But do you think that fopen in Linux is implemented without calling open(), which in Linux is a direct system call. Equally, the Windows C library uses CreateFile() - which is calling into the OS directly. Without knowing which OS it is, you don't know if you should call open(), DOS int 21 function 0x3D (or possibly 0x3C to CREATE a file), or Windows CreateFile. One of those is the right one, the other two are wrong and will absolutely crash the system. And don't say "But I can install a signal handler to catch the crash", because you can't - that also requires a system call, and you can't do that one either.

--
Mats

Originally Posted by matsp

Yes. But do you think that fopen in Linux is implemented without calling open(), which in Linux is a direct system call. Equally, the Windows C library uses CreateFile() - which is calling into the OS directly. Without knowing which OS it is, you don't know if you should call open(), DOS int 21 function 0x3D (or possibly 0x3C to CREATE a file), or Windows CreateFile. One of those is the right one, the other two are wrong and will absolutely crash the system. And don't say "But I can install a signal handler to catch the crash", because you can't - that also requires a system call, and you can't do that one either.

--
Mats

Oh yeah, because you need to link with a clib.lib that calls the correct OS API... OK, nevermind.