Turbo C++ and bins

[srg]

Hi

I have a boot sector program that will load in a program that is a bin file and run it (jump to it). I have made programs that will work with this bootsector fine in nasm.

Now I want to make a program in Turbo C++ that will work with this to. I compile and link it as a .COM program. First I modified the boot sector so that it jumps to offset 100h in the segment that the com file is loaded, but when it loads it in trys to jump to it, it hangs. So I put the bootsector back as it was and then removed the PSP from the .COM program. When I tried it again it hung again.

Is there anything that I have missed on trying to get a .COM C Program loading with this bootsector that is designed for bin files.

Or is there anything that I have missed about making a C program that will behave exactly like a simple bin file.

I though that a .COM program was just a bin with a PSP on the front??

Thanks

[Tim]

No, a .COM program is just a bin. No PSP. The PSP is put there by DOS when it loads the .COM file. So offset 100h in your code corresponds to offset 0h within the file on disk: DOS loads the file to offset 100h in the segment and fills in the PSP in front of it.

For an example of a boot sector loading a .COM program written using Turbo C, try the BING bootloader at http://www.execpc.com/~geezer/os/index.htm.

[srg]

hmm According to the readme, it only supports COFF, PE and ELF

[srg]

Right

I Now think I know why it's hanging! Although I have been carefull not to use any of Turbo C++'s standard library, so everything is written by me or calls BIOS services, I have been just looking at a dissassembly of my program and found that it is peppered with Calls to DOS Int 21! In fact instruction number 3 and 4 are a call to dos version!!!

How do I stop Turbo C++ from using anything to do woth DOS, or am I going to have to look for a different compiler!

BTW I Dissassembled it with ndiasm

Thanks

[srg]

Further Update

I have dissassembled each object file and they are clean of DOS Interrupt calls.

So it must be my linker wich is Borland Turbo Link (TLink) Version 3.01. Is there a way to stop TLink from doing this or will I have to use a different linker?

Thanks

[Tom]

I used TC++ and I found out only if you use dos call instructions in the code it calles DOS.

Even when you use "spawnl" & other spawns in process.h it dosn't call DOS.

[srg]

I don't use any of TC++'s library

Only my own routines

none of the object files have dos calls

only after they have been through the linker are there any dos calls, so the linker must be adding them

[Tom]

You can use it's libs just make sure it dosn't call DOS.

It's much easier to use it's libs (not graphics.h or dos.h, though).

If you OS uses the FAT system, you can use TC++'s libs to open files, I belive ( I don't fully know, if your using tc++3 yea ).

[Tom]

( but if you use the libs I don't know if borland lets you in your OS )

[srg]

This program that I'm making is loaded by the boot sector and will be loading the kernel

I specifically didn't use the library so there would not be any DOS calls, but the linker seems to be now adding some. I may have to try a different linker

[Tom]

mabe you can use "JLOC"

[srg]

hmm, well, I do also have DJGPP with LD that I am going to write my Kernel in (havn't got that far yet), I suppose I could try LD, it seem qute complicated to use though

[Tim]

I have dissassembled each object file and they are clean of DOS Interrupt calls.

So it must be my linker wich is Borland Turbo Link (TLink) Version 3.01. Is there a way to stop TLink from doing this or will I have to use a different linker?

This is why I sent you the link to the BING loader. I'm not suggesting that you use it to load your .COM file -- it's not capable of that -- but that you study the code and use similar techniques. The BING source comes with a custom startup routine written in assembly which replaces the Turbo C startup code. The startup code contains the int 21h calls -- it is put there by the compiler, not the linker -- and it is possible to replace it, as BING does. I suggest you look at it again.

[srg]

I have adapted the start asm to load my main() function.

It loads fine in dos (hangs at the end, but that's by design)
also its size had gone from 6.4K or just 2.3K

But when being called by the boot sector, my C code either does nothing or hangs the machine (it even switches the monitor onto standby!!!!)

Here's the startup code:

SEGMENT _TEXT PUBLIC CLASS=CODE

   resb 100h

GLOBAL begin
begin:

..start:
   mov ax,ds         ; zero the BSS
   mov es,ax
   xor ax,ax
   mov di,bdata
   mov cx,edata
   sub cx,di
   rep stosb

EXTERN _main
   call _main         ; call C code

exit:
;%ifdef NODOS
   JMP $
   ;int 19h            ; re-start the boot process
;%else
;   mov ax,4C01h
;   int 21h            ; exit to DOS with errorlevel 1
;%endif

SEGMENT _DATA PUBLIC CLASS=DATA

buffer_e820:
   times 42 db 0

SEGMENT _BSS PUBLIC CLASS=BSS
bdata:

SEGMENT _BSSEND PUBLIC CLASS=BSSEND
edata:

GROUP DGROUP _TEXT _DATA _BSS _BSSEND

[srg]

SUCCESS!!!!!!!

Here is my final method:

1. First compile and assemble all module seperately

the startup code asm file is:
SEGMENT _TEXT PUBLIC CLASS=CODE

GLOBAL begin
begin:

..start:
   mov ax, cs
   mov ds, ax
   mov es, ax

EXTERN _main
   call _main         ; call C code

exit:
   JMP $ ; Program should never get to here


SEGMENT _DATA PUBLIC CLASS=DATA

GROUP DGROUP _TEXT _DATA

2. Link all the files with the startup asm file being the first in the list. Link it as a *TINY MODEL DOS EXE*.

3. Run exe2bin (comes with Windows XP BTW) to turn exe into a flat binary file.

4. Copy to relevant location and rename if recessary

Worked first time for me (if your wondering, my boot sector sets up the stack)

Thanks for your help

Actually, I find that talking to someone else, often helps people figure things out for their self, interesting.