Printable View
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