16-bit .com C program in real mode OS

Question

I've been working on a real mode OS, writing in assembly and compiling to flat .bin executables with NASM.
I would like to write some of the OS in C, and so wrote an experiment program (ctest.c) which I would like to access a string and print the first character:

void test();

int main() { test(); return 0; }

char msg [] = "Hello World!";

void test() {
    _asm
    {
        mov si, word ptr [msg]
        mov al, [si]
        mov ah, 0eh
        int 10h
    }
    for(;;);
}

I compiled this with Open Watcom v1.9 using wcl ctest.c -lr -l=COM . This creates ctest.com. The kernel, which I wrote in NASM assembly, loads this program to 0x2010:0x0000, sets DS and ES to 0x2000:0x0000 and then jumps to 0x2010:0x0000. This is how I have been calling .COM programs written in assembly and compiled with nasm -f bin test.asm -o test.com.
When I test the OS (using Bochs), it successfully loads ctest.com, but prints out a meaningless character that is not part of msg[].
Does anyone have any suggestions about this? I think the string is just being initialized in the wrong place. I would like to keep this as a 16-bit OS.
thanks!

The first 128 bytes of a .com memory image contains operating system data, similar to CP/M. DOS depends on it. The next 128 bytes contain the command line. Execution starts at 0x100. — Hans Passant, Mar 24 '12 at 20:11

Alexey Frunze · Accepted Answer · 2012-03-24T21:17:09.913

You are using wrong addresses.

You either load at 0x2000:0x0100 and jump to 0x2000:0x0100 (don't forget setting DS=ES=SS=0x2000 and SP=0 prior to that) OR you load at 0x2000:0x0000 (equivalent to 0x1FF0:0x0100 because 0x2000*0x10+0x0000 = 0x1FF0*0x10+0x0100 = 0x20000 = physical memory address in real mode) and jump to 0x1FF0:0x0100 (don't forget setting DS=ES=SS=0x1FF0 and SP=0 prior to that).

The reason for all of this is that compiled x86 code is generally not position-independent and if you move it, you have to adjust some data offsets inside of the code. Obviously, you weren't making these adjustments. In simple cases there was nothing to adjust and you got away with wrong addresses.

EDIT:

Actually, there're more problems here:

mov si, word ptr [msg] must change to lea si, byte ptr [msg] because you don't want to load si with what's inside the string, you want to load it with the string's address.
The startup code that's linked to your program by OW is dependent on DOS and calls DOS functions, which you don't have when you boot your program. See how to work around this here.

score 1 · Answer 2 · answered Mar 24 '12 at 19:58

1

Under MS-DOS, COM programs were loaded at offset 0x100. I would guess that Open Watcom makes that assumption. I would suggest loading the COM program at 0x2010:0x0100 and see what that does.

answered Mar 24 '12 at 19:58

David Paxson

553
1
3
8

I just tried that, and it didn't work. By the way, I'm using int 13h ah 2 to read sectors off the virtual floppy disk. – user1112148 Mar 24 '12 at 20:28

16-bit .com C program in real mode OS

2 Answers2