Dean,

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

I kind of like the idea of a macro that appears in the main module of
an application,  and I think that would work fine for me. I'm actually
not too worried about eliminating main(), just hiding it. I want to get
the "percieved" main() function into my class lib,  for a lot of
reasons, one being that there's no main() in a windoze program, and I'd
like to have these program's i'm writing be as "cross-platform" as
possible, in the event I ever decide to port them to a windoze platform
(honestly can't see it in my future at this point).

DR> 
DR> One fishy thing is the _main(), which means that what it is
DR> looking for is not the main() that you are providing. 

Yes, the linker was actually complaining about a _main() function, and
not main(). what actually happened was, I have 2 versions of this class
lib, one that works (and requires a main() in the program), and one
that doesn't (has the classlib::main()). They both have the same name,
but are in different directories, and i had specified the wrong one to
link to. After fixing that, the program compiled, but crashed on
startup, but because of another thing I'm experimenting with. I stepped
through the 2 lines of code in the classlib::main() function with a
debugger, and I suppose the fact that it actually made it to that
function says it worked. So, i'm happy with that. However, the problem
you mentioned with the IBM compiler bothers me, so I'm thinking about
the macro approach now.

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

It sounds like a pretty educated one, I must say.

___
 X KWQ/2 1.2g NR X If at first you don't succeed, put out another version (KWQ 1.2g)

--- Maximus/2 2.01wb