Printable View
I ask this because I learned the ability to compile an exe to run on more then one operating system at the same time. Imho it's pretty cool.
Do you know a common way to detect the operating system at runtime (not compile time)?
I know there is no standard C or C++ feature for that. Is there a prefab library available?
Or do I need to implement these checks myself for all supported operating systems myself?
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
... including some sort of API or other method of getting the OS name or type.Quote:
For most cases, those different versions are close enough that MOST things can be done the same way anyway.
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".Quote:
Originally Posted by zacs7
--
Mats
Sigh, I've been missing the point of your posts all day (don't worry it's me, not you)... sorry :confused:
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".Quote:
Originally Posted by zacs7
--
Mats
OS means in my personal association also older OS, not just recent ones. Also more different ones, NT, Linux and DOS. This was also the thing I was talking about.Quote:
Originally Posted by matsp
Indeed, currently I was only testing on i386. No other hardware. Guess this will be really impossible on different hardware to use the same executable (without emulator, patching, runtime environment or other tricks).
Currently my exe can run on:
(from HX DOS Extender, \hx\SAMPLES\OW4\THREADW.EXE)
- WinNT (tested only XP and Vista) (native win32 console, no NTVDM)
- Win9x (tested only Win98)
- DOS (tested only MS-DOS and FreeDOS)
And I know another exe running on:
(from grub4dos, bootlace.com)
- WinNT (tested only XP 32 and Vista 32) (unfortunately only NTVDM)
- Win9x (tested only on Win98)
- DOS (tested only MS-DOS and FreeDOS)
- and finally also on Linux 2.6 (tested only Ubuntu Hardy)
(I am trying to understand and both all two processes and combine them but that's another story.)
Isn't this amazing? Both exe are Open Source if you are interested. It did take me a long time to get aware of this software. It was always my dream to have uber portable software.
Seams I am the first gui here interested in this? :) Probable to solve my original question I need to write this from scratch, try to execute some operating system function while error catching for all operating systems.
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
Before I thought NT and DOS are pretty much different.Quote:
Originally Posted by matsp
The HX website says it has win32 console emulation, no more need to prove it. :)Quote:
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.
After booting Ubuntu I can go to console, join the folder and type .\bootlace.com.Quote:
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.
You mean kexec is installed by default and Ubuntu is automatically starting bootlace.com without typing kexec?
While writing this I started my test Ubuntu and wanted to remove kexec. But it's not even installed. When typing kexec Ubuntu suggest to install the kexec-tools. So kexec can not be the explanation.
I wasn't talking about the bootmanager part. Only about the service tool bootlace.com which is a tool to write the bootcode into MBR AFTER an operating system such as Linux or DOS has been started.Quote:
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].
Well, dunno how to call it. In the end I want an exe with the ability to run on the major operating systems I've mentioned here.Quote:
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.
bootlace.com is a good model because Linux and DOS are very different and it can install the bootcode into MBR with the same tool (very probable that very different system calls are needed).
Of course, but they are.Quote:
Originally Posted by sept
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.
The usual "this program can not be run in DOS mode".Quote:
Originally Posted by Elysia
If it were possible then everyone would be doing it already. That's all you need to know.
It's called Java.Quote:
Originally Posted by sept
Yes, call the appropriate OS API function, which is different on every OS.Quote:
Originally Posted by sept
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
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.Quote:
Originally Posted by cpjust
Likewise, replacing certain parts of Windows API with your own API is entirely possible - it's hard work, but possible.
--
Mats
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 matsp
I am glad that you are interested.Quote:
Originally Posted by matsp
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.
The source looks complicated, some assembler. If there is no guide or whatever I lack the knowledge to apply this to my applications.Quote:
Originally Posted by matsp
If you say it's to complicated, then it is to complicated for now for me. :)
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...Quote:
Originally Posted by Elysia
Linux might not have a disk.
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.Quote:
Originally Posted by Elysia
Try addingto 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...Code:asm { mov eax, 20; int 0x80 }
And I obviously gave up a bit early searching for the bootlace code - I gave it a few more minutes and found this bit:
So like I said, it's expecting the JG instruction to be taken to jump to dos_entry_pointCode:.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"
Another piece of code does:
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).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 */
And yes, it's fairly complicated.
--
Mats
Neither might Windows - although it is probably harder to achieve that in general.Quote:
Originally Posted by robwhit
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. :)
But wouldn't it still have a / root directory and some files required to boot (even if they are all read-only)?Quote:
Originally Posted by robwhit
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].Quote:
Originally Posted by cpjust
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>
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.Quote:
Originally Posted by cpjust
--
Mats
Oh yeah, because you need to link with a clib.lib that calls the correct OS API... OK, nevermind. :pQuote:
Originally Posted by matsp