Since I enjoy using this toolchain myself let me add some more info that might be useful.
While it's true that those are the typical libraries you need to link with with your program, there are actually several versions of it. e.g. multithreaded vs single-threaded, dynamic runtime vs statically linked runtime, wide-chars vs byte chars.
The trick is to realized that bcc32 already knows which runtime libraries are needed when you're building your program. Thusly, instead of calling ilink32 directly by C::B just have it call bcc32 for the linking process as well. This idea is actually used by gcc toolchain too. Linker for gcc is never actually invoked directly by C::B but is invoked indirectly by calling one of the 'frontend' command lines like gcc-c++.
This will simplify somethings by not having to remember which lib files to include. Instead you just specify what kind of program you're compiling by supplying the proper options. bcc32 will take care of the rest by telling ilink32 which lib files it should include.
Just for reference here's a quick list of options that you'll want to pass to bcc32 depending on what your building:
-tW Windows GUI program
-tWC win32 Console program
-tWM Multi threaded program
-tWD build as DLL shared library
-tWR Dynamically link the runtime to program
As an example, let say you want to compile your program as a console multithreaded application and you want dynamically runtime linkage to make your executable smaller1. The commandline you want C::B to invoke should look something like this:
For each C/C++ source in your project compile as:
bcc32 -tWM -c -Iyour include directories -oyourobjfile.obj -c yoursrcfilename.cpp
Link all compiled translation units together like this:
bcc32 -tWC -tWM -tWR -Lyour library directories -eexecutablename.exe srcobjfile1.obj srcobjfile2.obj srcobjfileN.obj extra library files
Supply import library files in the extra library files section. If your program, for example, depends on or uses 3rd party API like say wxwidgets or SDL, this is where you would include it2.
All in all, this is a really nice toolchain. Sure it may be old but it doesn't mean it isn't functional. I particularly like how fast it's able to compile code. Just to compare, I was able to build the SDL API from source in just ~5seconds w/o using parallel-build. This 5 seconds includes:
- compiling all the SDL source
- linking objects together to produce SDL.dll
- compiling SDLmain.lib
- compiling and linking of all the test demo programs supplied.
MSVC9 compiler took ~8seconds to do the same thing. Now the really fun part is if I enable 4 parallel builds then that entire process gets reduced down to just 2 seconds!
1. Note that your program will need the cc32xx.dll runtime if you do link it dynamically.
2. Note that bcc32 already supplies the needed runtime cw.lib and import32.lib files to the linker. So you do not need to include it here.
It's true compiled resources can't be passed to the linker in this fashion. The method of using #pragma works perfectly fine as far as I could tell and that's the method I use whenever I need to link resources into my program. I found it to be the most straight forward way of doing it.
What I have done is put the #pragma resource line in the resource.h header file. It doesn't seem like the linker minds having multiple reference to link the same resource file:
//resource.h
#ifndef __RESOURCE_H__
#define __RESOURCE_H__
#define APPICON 1
#pragma resource "resource.res"
#endif
//resource.rc
#include "resource.h"
APPICON ICON "sample.ico"
//main.cpp
#include "resource.h"
using namespace std;
//or WinMain if it's windows GUI app
int main()
{
//code that does something useful goes here
return 0;
}
Hope that helps