OSDev.org

1. 1. Ability to boot directly from network (via PXE/BOOTP)
   2. Can create bootable CDROM images in both "No Emulation" and "1.44 Emulation" modes.
   3. Can make bootable USB sticks (then just copy your executable to the root directory and it boots!)
   4. Better executable compression and updated C and ASM examples for MinGW/gcc, fasm, tcc, and msvc compilers.

#include <stdio.h>
#include <stdlib.h>

#ifdef __MINGW32__
void debug(void){asm("int $1");}	void __stdcall DllMainCRTStartup(int a, int b, int c)
#else //__MSVC__
void debug(void){__asm {int 1};}	void mainCRTStartup(int a)
#endif
{
	char *p = "Hello World";
	char *v = (char*)(0xB8000+0x6c7);

	if( (int)&a < (int)v )		// if stack < 640k - it is not Win32
	{
		for(;v++,*v++=*p++;);	// write directly to the video memory
		debug(); 					// invoke debug monitor built into the stub
	}
	else // Win32
	{
		printf(p);
		exit(0);
	}
}

   C:\test>cl hello.c /link /fixed:no /subsystem:console /nodefaultlib msvcrt.lib
   C:\test>c:\mingw\bin\gcc -s -shared -nostdlib hello.c -o hello.exe -lmsvcrt
   tux$ i586-mingw32msvc-gcc -s -shared -nostdlib hello.c -o hello.exe -lmsvcrt

   pe2boot.exe -s pe_stub.bin  -i hello.exe -o hello.exe     <- compress PE

   pe2boot.exe -b boot_fat.bin -i hello.exe -CD0 hello.iso   <- No emulation
   pe2boot.exe -b boot_fat.bin -i hello.exe -CD2 hello.iso   <- 1.44 emulation
   pe2boot.exe -b boot_fat.bin -i hello.exe -FLP hello.flp   <- 1.44 floppy
   pe2boot.exe -b boot_fat.bin -L "HELLO   EXE" -FAT \\.\U:  <- USB drive
   copy hello.exe u:\	 <- if you boot from USB drive it will load hello.exe

  hello.exe            							<- "Hello World" Win32/Linux
  qemu -fda hello.flp  							<- "Hello World" boot floppy
  qemu -cdrom hello.iso							<- "Hello World" boot cdrom
  qemu -tftp . -bootp hello.exe -boot n  	<- Direct boot with BOOTP

bluemoon wrote:Sound like your're working on an binary compatibility layer (For example, Linux Binary Compatibility).
I'm surprised you do it on bare-bone, since most people would implement it last when the OS has richer functionality.

Anyway, I'm interested on how many functions you provide in the bulit-in runtime, since it affect the usability on the whole environment.

• Win32 executable to run on Windows 9x, XP, Vista, 7 (or their server siblings)
  ELF executable to run on Linux, FreeBSD, etc...
  DOS executable with some sort of 32-bit extender for FreeDOS, MS-DOS, etc...
  Bare hardware version of the executable packaged onto
  • Bootable CDROM image
    Bootable Floppy/USB image
    Image for network boot using PXE/BOOTP
    Boot from HD partition, CHS/LBA, MBR/EFI, large sector size headaches...

Merlin wrote:Very cool stuff. Barring Windows support, could the same thing be made with ELF files?

technik3k wrote:When run on Windows it simply lets you call Win32 functions that you normally import from various DLLs.

When Linux loader sees PE32 signature it calls Wine loader, which handles any Win32 calls. In the hello.c example those are printf() and exit() normally found in MSVCRT.dll just as it would happen on Windows. In addition to Win32 functions, you can also call Linux syscalls via "int 80h" (unless it is blocked by security policy).

When you run on DOS or bare hardware, the runtime will detect available memory, and switch CPU into protected mode and call your app. Your interface to the outside world is int86(regs,regs) function and any port I/O, if you like so.

bluemoon wrote: I'm a bit confused, although the resulting binary is a single file, you still have to write different code segments for different target platform and branch internally? What will happen if I called winapi in the code and the program loaded on bare-bone? do it fail to resolve symbols or just call a stub function and result fail? How about I use in86() and run the program under windows?

What's the advantage over the following environment detection stub + zip/concat solution?
binary layout:
stub
[executable map]
PE executable for Windows, with MZ stub for DOS
executable for Linux

• MZ header
  -> BOOTP entry point
  ...
  PE32 Header
  -> DOS entry point
  ...
  BOOTP magic
  -> BIOS CDROM/USB/HD boot entry point
  ...
  commonBOOTP_DOS_BIOS:
  • Detect memory, A20, XMS
    Initialize GDT, IDT, IRQ handles
    Switch CPU to 32-bit protected mode
  jmp common32
  -> Win32 entry point
  common32:
  • Decompress and rebase executable
    if Win32 foreach DLL { LoadLibrary(); GetProcAddresses(); }
    jmp app entry point
  (compressed payload app)

When Linux loader sees PE32 signature it calls Wine loader, which handles any Win32 calls. In the hello.c example those are printf() and exit() normally found in MSVCRT.dll just as it would happen on Windows. In addition to Win32 functions, you can also call Linux syscalls via "int 80h" (unless it is blocked by security policy).

When you run on DOS or bare hardware, the runtime will detect available memory, and switch CPU into protected mode and call your app. Your interface to the outside world is int86(regs,regs) function and any port I/O, if you like so.

mooseman wrote:Looks very cool!
Just wondering..... what license is the code released under? There seems to be no license info in the download, and none in the source files that I looked at.
- m

Combuster wrote:So you still need to write two applications. Plus that any attempt to use printf or anything like it fails because it will either give a linking conflict if you provide your own (something you need to do for bare metal support) or you use windows' and you will most likely crash on bare metal.

In other words, welcome to Jurassic Park. Why aren't the raptors in their enclosure?

technik3k wrote:So what would be your suggestion? If you intend to have a utility running on multiple platforms you have to deal with multiple backends anyway.