JDBP>MD>
    >  >   Ok, first of all, the OS2STUB.EXE is VERY easy to take care of.
    >MD>

JDBP>  Borland C++ TLINK doesn't require an OS2STUB.EXE, as it provides a
    >  built in default.  This is the cause of the problem.
JDBP>  Having said that, I don't get a STUB statement in my DEF file
    >  anyway.

You don't get one when you are using Guidelines?  I think you do.

JDBP>MD>
    >  > I, too, have been getting the unable to resolve externals with Borland
    >  > C++ v1.5.  It seems we bought into a compiler that can't do jack.
    >MD>
JDBP>  No, you have hit one of the nastiest portability problems in C++.

JDBP>  String literals in Borland C++ are not unsigned char *, nor are they
    >  signed char *.  They are simply char *.  And it appears that the -K
    >  compiler switch doesn't affect string literals.

JDBP>  This is ISO-conforming behaviour unfortunately, because the handling
    >  of the signedness of char is left to the individual compiler
    >  implementators.

JDBP>  The only reason that Borland C++ makes you notice this is because it
    >  is the only OS/2 compiler where char is signed rather than unsigned by
    >  default.  Most people who code for CSet++ and then port to BC++OS2
    >  encounter this problem.

By what you're saying, it sounds like Borland has always worked this
way.  Strange since v1.0 and v1.01 worked fine.


JDBP>MD>
    >  >   Run a test with the IDE, compile a function to an OBJ format.  Then
    >  > compile a project with the OBJ file included in the project to an EXE.
    >  > It should give you the same problem with unresolved externals as well 
    >  > the problem with "Bad field list in debug information in module
    >  > MODULE.OBJ".  Borland has done it again!
    >MD>
JDBP>  Use a LIB file.

Uhm...  When you use an OBJ file, you don't need (nor can one be used) a
LIB file.  Linking with an OBJ is a form of STATIC linking, not DYNAMIC
like a DLL with a LIB.
___
 .Mike's Mail Internet:   MICHAEL.DOUGLASS{at}LCHANCE.SAT.TX.US

--- Maximus/2 2.01wb