How to detect the operating system at runtime?

This is a discussion on How to detect the operating system at runtime? within the C Programming forums, part of the General Programming Boards category; Originally Posted by matsp This is obviously said in jest, since how do you find out which OS it is ...

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    Quote Originally Posted by matsp View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Registered User
    Join Date
    Jul 2007
    Posts
    88
    Quote Originally Posted by matsp View Post
    I can't find the source
    I am glad that you are interested.
    http://download.gna.org/grub4dos/
    for source grub4dos-0.4.4-2008-08-08-src.zip, for binary grub4dos-0.4.4-2008-08-08.zip.

    Quote Originally Posted by matsp View Post
    But this is not your average programming type things - it's tricky stuff to solve particularly tricky situations.
    The source looks complicated, some assembler. If there is no guide or whatever I lack the knowledge to apply this to my applications.

    If you say it's to complicated, then it is to complicated for now for me.

  3. #18
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Elysia View Post
    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.
    I guess you could also interrogate the filesystem and look for some land-markers that would suggest what OS you're dealing with, i.e. look for a Windows directory or a /boot/vmlinuz...

  4. #19
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Linux might not have a disk.

  5. #20
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #21
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by robwhit View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #22
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  8. #23
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by robwhit View Post
    Linux might not have a disk.
    But wouldn't it still have a / root directory and some files required to boot (even if they are all read-only)?

  9. #24
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by cpjust View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #25
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    But some filesystem functions are OS independent, like fopen(), fread(), and all of the stuff in <stdio.h>
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  11. #26
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by cpjust View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #27
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by matsp View Post
    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.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. What is a Microsoft Operating System Like?
    By Troll_King in forum A Brief History of Cprogramming.com
    Replies: 35
    Last Post: 10-21-2002, 08:36 AM
  2. Operating system
    By sopranosomega in forum C Programming
    Replies: 6
    Last Post: 10-07-2002, 07:12 AM
  3. What operating system are YOU useing?
    By RoD in forum A Brief History of Cprogramming.com
    Replies: 36
    Last Post: 09-14-2002, 11:02 AM
  4. My favourite operating system
    By techie in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 07-19-2002, 07:29 AM
  5. A New Operating System
    By commanderrulz in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 01-24-2002, 01:36 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21