Vitus Jensen wrote to all on 10-03-1999

VJ> Hi all,
VJ> 
VJ> I'm implementing some DLLs to allow third party 
VJ> applications to control machines via serial lines.  The 
VJ> DLLs use CRT routines (malloc,free) and are currently 
VJ> statically linked to their own version of CRTs.
VJ> I'm wondering whether those statically linked CRTs are the 
VJ> correct way to do it or may even cause errors (in fact 
VJ> there is currently a hang situation reported).

Well, static linking is a good way to use LOTS of memory.  Since you
are using several DLL's you could save a lot of space by dynamic
linking.  I use it in one big app I work on and the RTL (re-named per
IBM rules) is bigger than any of the 'functional DLL's.

VJ> Could someone explain the use of the subsystem library (compile
VJ> switch /Rn)  and whether it's use would be better in my case.  And 
VJ> please remember that I have a thread hidden inside the DLLs 
VJ> (currently started via _beginthread but /Rn doesn't support  it,
VJ> DosStartThread plus some magic code required?).

I use _beginthread() liberally.  Most of my threads deal with comm
links - network and serial - so it only makes sense to spin them off
that way.  There are some slicker ways to instantiate the threads but
they all seem to deny me some important tweeking.  A couple of the
threads I run will need from 28k to 4 meg for stack/heap and
_beginthread() allows me the flexibility to allocate enough that the
thread can then commit whatever it really needs.  BTW, all these
threads are launched from DLL code and use semaphores and a message
queue for control and process-related communications.  Just be VERY
careful of where you put your waits and be extra meticulous about
cleanup on thread exit.  The biggest trap the programmers I work with
fall into is misuse of shared memory - they just can't seem to clean
up after themselves.  I think it's a carryover from using multiple
processes rather than true threads.  Just to ease your mind a little,
one comm job that gets done has been known to run over 100 threads in an
iterative challenge-reply communications exchange and I've always been
able to kill the process cleanly at any stage.  Also, don't be fooled
by the IOC propaganda - the base API's like _beginthread()\_endthread()
are still quite available.
 
Will Honea 
--- Maximus/2 2.02