Thanks Kelly for your msg about main(), on 19 09-19-1994

I ran into the same thing. I first used Borland and it was find
there. I use a THREAD class and I want all threads (visible to the
outside world) to be created via THREADs, not by getting ahold of
main(). When I ported to CSet/2++ I ran into the same problem, but
I did not have time then to really deal with it. So I created a
macro in the lowest level header of my class system (which is
always included). If the user defines a CIDLIB_MAINMODULE token,
it causes that macro to include a main() that they never really
see. It in turn calls back into my library who takes over from
there. I will look back into it and see what the deal is now that
I have time. During the initial port, I had way too many fish to
fry to worry about it.

One fishy thing is the _main(), which means that what it is
looking for is not the main() that you are providing. CSet/2++
does not provide underscores to names, so main() would not turn
into _main() as far as I know. So maybe main() is really just a
macro that is expanded by the compiler to include an extra
function named _main(). If so, then I could understand what is
happening. It assumes that this magic method is in the .Exe module
and therefore requires no _Export keyword to export it. If you put
main() in an .Dll and it generates the magic function there, then
it would require an export of the _main() function.

All just a guess at this point though.

___
 X KWQ/2 1.2b X I'm an OS/2 developer...I don't NEED a life!

--- Maximus/2 2.01wb