C is just not working!

[pcmattman]

I'm trying to write a simple kernel in C for my OS so I don't have to do everything in assembly. My current assembly can load an external COM file and execute it, but it only works if the COM is one I've written in assembly. An attempt to run a COM file made in C fails.

I'm using DJGPP GCC.

[bubach]

Do have have a C compiler that can compile to a 16-bit .COM DOS program? You can just make a simple "Hello world" test and see if it runs as expected in DOS.

[pcmattman]

Hmmm... didn't think of that! Are you able to suggest any compilers? And if so, how do I use them to create the program?

[bubach]

The ones I know about are Turbo C, free from the Borland website, and OpenWatcom, www.openwatcom.org

[pcmattman]

I've tried Watcom but it didn't compile anything, just kept giving me errors. I'll look into Turbo C.

[bubach]

Making a simple Watcom C program for DOS took me like 2min, without any errors. You have to choose to include DOS as a target platform when you install, and then that the project will be a DOS .COM program when you create the project.

[pcmattman]

Oh... I keep getting GPF's when I try it ...

I've now got Turbo C. I'm trying to make a COM file with the following source files:

test.c:

Code: Select all

int main()
{
	kputc(); // currently hard-coded character output, will eventually have argument
	return 0;
}

kputc.asm (NASM):

Code: Select all

global _kputc

_kputc:
	mov al,68h
	mov ah,0x0e
	mov bx,0x0007
	int 10h
	ret

Compiled and linked with the following commands:

Code: Select all

nasmw -f obj -o kputc.obj kputc.asm
tcc -c test.c
tlink test.obj kputc.obj,test.com,, /t

Unfortunately, it doesn't work:

Turbo Link Version 2.0 Copyright (c) 1987, 1988 Borland International
Cannot generate COM file : invalid initial entry point address

Can anyone help? It doesn't even work when I change kputc to use DOS interrupts and make an EXE, that just tells me that there is no stack...

[pcmattman]

Ok, I did a search of this forum and found an old post that addresses the same thing...

It suggested linking in an entry point as an OBJ file (which I have done).

The entry point code I wrote prints out a character before it's 'call _main' instruction. I know that it works properly because whenever I call the COM file from within my OS it prints out the character. However, nothing else runs. I've used ndisasmw to disassemble the COM file and it turns out that it isn't jumping to _main at all, it is just jumping to the next instruction.

This is a problem, as the next instruction is the 'return to shell' instruction my OS requires to get control back.

Note: this is not a bootloader, this is a COM that is run from the shell of my kernel.

Loader code:

Code: Select all

section _TEXT

global begin
extern _main

begin:

start
	mov ax,cs
	mov ds,ax
	mov es,ax

	mov al,0x30
	mov ah,0x0e
	mov bx,0x0007
	int 0x10

	call _main			; call kernel proper

	retf				; return to caller

Disassembler outputs:

Code: Select all

00000000  8CC8              mov ax,cs
00000002  8ED8              mov ds,ax
00000004  8EC0              mov es,ax
00000006  B030              mov al,0x30
00000008  B40E              mov ah,0xe
0000000A  BB0700            mov bx,0x7
0000000D  CD10              int 0x10
0000000F  E80000            call 0x12
00000012  CB                retf
00000013  B068              mov al,0x68
00000015  B40E              mov ah,0xe
00000017  BB0700            mov bx,0x7
0000001A  CD10              int 0x10
0000001C  C3                ret
0000001D  E8F3FF            call 0x13
00000020  C3                ret

The 'call 0x12' should actually be 'call 0x13' but it isn't. Is this a tlink problem?

EDIT: lol, I figured it out seconds after I posted... I removed the 'retf' command and now, all of a sudden everything works!!!