Missing startup code in main program?

[Paul K. McKneely]

I am using OWC 1.9 on Win32 to produce 32-bit console programs.
When I compile a program that contains a main function
using the compiler I am writing and try to link it (using wlink)
with other modules written in assembler or modules compiled with
Open Watcom C compiler or library files, I get the following
error:

E:\WC\p\g>wlink OPTION QUIET system nt debug all option map
file hello library E:\WC\lib\std.lib library C:\Watcom\LIB386\NT\clib3s.lib
Warning! W1023: no starting address found, using 00401000

Of course the program crashes when I run it.

I can compile/assemble source files and link them just fine to programs
where the main function is in a C file. I am presuming that my compiler
is not adding one or more necessary things to indicate to the Windows
OS that the entry point into the program is the main function. Can anyone
tell me what I need to add to the main module that isn't normally there
in other modules? I also presume that there is other startup code that
initializes some runtime things that isn't being done.

Here is the batch file I am using to link:

wlink OPTION QUIET system nt debug all option map file %1 library
%ROOT%\lib\std.lib library C:\Watcom\LIB386\NT\clib3s.lib

It works fine if the file containing the main function is written in C and
compiled with the Open Watcom C compiler even when I link to
modules compiled with my compiler.

When I disassemble a C module containing main using wdis there is
nothing apparent that it lists that would be startup code besides a call
to __CHK. If I put this into the assembly file that is produced by my
compiler I get the same error. I need to specify the entry point some
how. Once that is done I may need to call some startup code.

[Mat Nieuwenhoven]

Does our compiler use the same calling convention as you are using with OW?
The calling conventions have influence on function names. I see you're
linking against clib3s, so I guess you're using __cdecl as calling
convention. The object file of the module containing main() should show the
'decorated' name.

Mat Nieuwenhoven

[Paul K. McKneely]

> Does our compiler use the same calling convention as you are using with
> OW?
> The calling conventions have influence on function names. I see you're
> linking against clib3s, so I guess you're using __cdecl as calling
> convention. The object file of the module containing main() should show
> the
> 'decorated' name.
>
> Mat Nieuwenhoven

Calling conventions are not the issue. As I said earlier, I can call
functions
compiled with my compiler from a program where the "main" function is in
a C module compiled with OWC. I can also call C functions from a function
in a module I compile with my compiler. They call each other just fine. They
link and run just fine. I've written literally hundreds of assembly programs
and
I know how the calling convention works. Everything works fine as long as
the function "main" is in a C module compiled with wcc. But I want to put
the "main" function in a module that is compiled with my compiler. My
compiler
generates assembly code that is then assembled with wasm. If there was a
name incompatibility issue then the program wouldn't link. But it does. And
it runs correctly.

The problem is when I write the "main" program and compile it with the
compiler I am writing. It doesn't do anything special if a function happens
to be
called "main" so the linker complains that there is no entry point for the
program.
What do I put into the module that has a "main" function to tell the linker
that
"main" is the entry point into the executable that is produced with wlink?
The
reason it crashes is that the Windows loader doesn't know where to start
execution when my program is loaded. The linker says that it uses some
arbitrary value to assume that it is the entry point. Do you understand?

In other words, I need to know what assembly language I need to add to
an assembly language file that contains the "main" function so that the
linker
will know that "main" is the entry point to the program.

[Frank]

Am 06.01.2012 05:09, schrieb Paul K. McKneely:
> I am using OWC 1.9 on Win32 to produce 32-bit console programs.
> When I compile a program that contains a main function
> using the compiler I am writing and try to link it (using wlink)
> with other modules written in assembler or modules compiled with
> Open Watcom C compiler or library files, I get the following
> error:
>
> E:\WC\p\g>wlink OPTION QUIET system nt debug all option map
> file hello library E:\WC\lib\std.lib library C:\Watcom\LIB386\NT\clib3s.lib
> Warning! W1023: no starting address found, using 00401000
>
> Of course the program crashes when I run it.

Probably your compiler does not generate some records in the objfile
which are needed by the linker.
Compare the output from running 'dmpobj hello.obj'.

CU
Frank

[Frank Beythien]

Am 06.01.2012 05:09, schrieb Paul K. McKneely:

> I am using OWC 1.9 on Win32 to produce 32-bit console programs.
> When I compile a program that contains a main function
> using the compiler I am writing and try to link it (using wlink)
> with other modules written in assembler or modules compiled with
> Open Watcom C compiler or library files, I get the following
> error:
>
> E:\WC\p\g>wlink OPTION QUIET system nt debug all option map
> file hello library E:\WC\lib\std.lib library C:\Watcom\LIB386\NT\clib3s.lib
> Warning! W1023: no starting address found, using 00401000

And of course look at the supplied OW startup code (if installed) in
E:\watcom\src\startup

CU
Frank

[Roald Ribe]

Maybe this sample from jwasm will help?
Seems like the entrypoint for this type of executable is mainCRTStartup,

Roald

;--- Win32 "hello world" console application.
;--- assemble: JWasm Win32_1.ASM
;--- link: WLINK system nt file Win32_1.OBJ

.386
.model FLAT, stdcall
option casemap:none

STD_OUTPUT_HANDLE equ -11

WriteConsoleA proto :dword, :dword, :dword, :dword, :dword
GetStdHandle proto :dword
ExitProcess proto :dword

.const

string db 13,10,"hello, world.",13,10

.code

main proc

local dwWritten:dword
local hConsole:dword

invoke GetStdHandle, STD_OUTPUT_HANDLE
mov hConsole,eax

invoke WriteConsoleA, hConsole, addr string, sizeof string, addr dwWritten, 0

xor eax,eax
ret
main endp

;--- entry

mainCRTStartup proc c

invoke main
invoke ExitProcess, eax

mainCRTStartup endp

end mainCRTStartup

[Hans-Bernhard Bröker]

On 06.01.2012 05:09, Paul K. McKneely wrote:

> I can compile/assemble source files and link them just fine to programs
> where the main function is in a C file. I am presuming that my compiler

> is not adding one or more necessary things to indicate to the byWindows

> OS that the entry point into the program is the main function.

No. What your compiler fails to do is to indicate to the _linker_ that
the C startup code is supposed to be linked in. C code compiled by OW
does that by emitting an explicit reference to a symbol _cstart_
whenever a C source contains the main() function. You can see it if you
run wdis -a against a compiled C main module:

EXTRN _cstart_:BYTE

To satisfy this reference the linker pulls in an object file from the
runtime library. For an NT console app, e.g., that is
lib386/nt\clib3r.lib(cstrtwnt). This module defines a symbol called
mainCRTStartup. That becomes the entry point of the executable.

[Paul K. McKneely]

Hello Hans,

Your info solved the problem. Sounds like this actually does
two things. First it makes sure that the startup initialization
is done and then it jumps to main. Quite an interesting trick.
Your help is much appreciated. Thanks!

Paul

"Hans-Bernhard Bröker" <bro...@physik.rwth-aachen.de> wrote in message
news:je7tn1$p0i$1...@www.openwatcom.org...