Hi all,

Is it possible to write BCB com servers without VCL being included/linked in. I have written a simple com in-proc server with VC++ which ended being a 20k dll. I tried the same with BCB and ended with a 400k+ dll. I prefer to work in BCB (been using it for 3+ years now) for all my C++ programming.

Is this possible, and if it is how does one achieve it?

Any help greatly appreciated.
Regards - Adrian.

.a

Hi Alex,

Thanks for your response. I'm actually subscribed to that journal - I'll dig that issue out - thanks a lot.

Adrian.

Hi Alex,

I did check your article and it seemed to be pretty
straightforward. I have followed the steps (using BCB5), without
having to change much from your instructions. The main
difference here was that I had to change all lstrcat or lstrcatA
calls to use global scope (i.e. change lstcat to ::lstrcat) in
atlvcl.h, atlmod.h and atlbase.h. Also the 'extern CComModule
_Module' reference operator seems to have been fixed in BCB5 and
the 'for loop i integer' in atlwin.cpp as well.

Everything compiled ok - but I got the following compiler
warnings (which I'm not too worried about) and linker errors:

[C++ Warning] condefs.h(14): W8017 Redefinition of 'USEUNIT' is not identical
[C++ Warning] condefs.h(17): W8017 Redefinition of 'USEOBJ' is not identical
[C++ Warning] condefs.h(20): W8017 Redefinition of 'USERC' is not identical
[C++ Warning] condefs.h(23): W8017 Redefinition of 'USEASM' is not identical
[C++ Warning] condefs.h(26): W8017 Redefinition of 'USEDEF' is not identical
[C++ Warning] condefs.h(29): W8017 Redefinition of 'USERES' is not identical
[C++ Warning] condefs.h(32): W8017 Redefinition of 'USETLB' is not identical
[C++ Warning] condefs.h(35): W8017 Redefinition of 'USELIB' is not identical
[C++ Warning] condefs.h(38): W8017 Redefinition of 'USEFILE' is not identical
[C++ Warning] condefs.h(41): W8017 Redefinition of 'USEIDL' is not identical
[C++ Warning] condefs.h(44): W8017 Redefinition of 'USE' is not identical

[Linker Error] Unresolved external 'System::__linkproc__ __fastcall LStrClr(System::AnsiString&)' referenced from D:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\DEBUG\VCLE50.LIB|dstring
[Linker Error] Unresolved external 'System::__linkproc__ __fastcall LStrFromPChar(System::AnsiString&, char *)' referenced from D:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\DEBUG\VCLE50.LIB|dstring
[Linker Error] Unresolved external '__fastcall Sysutils::FindCmdLineSwitch(const System::AnsiString, const System::Set<char, 0, 255>&, bool)' referenced from D:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\BCBATL.LIB|bcbatllib
[Linker Error] Unresolved external 'System::__linkproc__ __fastcall VarClear(System::Variant&)' referenced from D:\PROGRAM FILES\BORLAND\CBUILDER5\LIB\DEBUG\VCLE50.LIB|variant

Is there a way one can get round these?

Any help greatly appreciated.

Thanks for your help.
Adrian.

hth,
.a

Hi Alex,

Thanks a lot for your response.

The only way I could get the linker errors to go was by
including dstring.cpp into my project (and commenting out some
code in there which was referencing LStrClr and some other
LStr_Someting function). Then everything was fine; nevertheless
the dll ended up being 149k (release build). This is still a bit
bigger than I would like it to be and I'm not so sure as to the
effects of commenting out that code.

I agree with you that the FindCmdLineSwitch function is to blame.
This function needs the contructor and destructor for AnsiString,
and the Set class (for the TSysCharSet). I did wrap the code in
the TModule<T>::Unlock method in #ifdef _NO_VCL directives, but
that didn't remove the reference. When I used tdump on
bcbatl.lib, the FindCmdLineSwitch symbol appeared in there. So I
am assuming that the bcbatl.lib is the culprit. But I could find
no reference to bcbatl.lib in my project files - so this must be
being included by some atl/vcl header/source files. I did come
across some #pragma comment(lib, "bcbatl.lib) lines in
atlbase.h, atlsnap.h and statreg.h. Do these #pragma's end up
including bcbatl.lib? Is the _ATL_NO_FORCE_LIBS symbol related
this whole matter at all?

Anyway, I will try your suggestion of including bcbatllib.cpp to
my project, but I don't know how I'm gonna achieve removing
bcbatl.lib because I can't find any reference to it in my
project files.

I will let you know how I got on.
Thanks again and best regards.

Adrian.

Hi Alex,

I have followed your instructions regarding including
bcbatllib.cpp in my project and everything works fine now. No
linker errors.

The only thing though is that the size of the resultant dll
(release build, no dynamic rtl, no runtime packages) was 155k.
That's not too bad, so I'm quite happy anyway.

Thanks for all your help.
Adrian.

hth,
.a

Hi Alex,

Yes I'm quite happy with that size. One needs to remember that
any non trivial com server is going to end up much bigger than
155k anyway because more functionality has to be added in.
But thanks to your help, I achieved what I wanted - removing the
VCL from a project where it wasn't needed and where it was just
bloating things up unnecessarily. And best of all, I can stick
to my beloved BCB for writing efficient COM servers without
having to use VC++.

I'll check that product out.

Thanks again and best regards.
Adrian.