KB> -------
 KB> Q #1) What is the most thorough source of information 
 KB> regarding programming considerations of DLL's?  (I 
 KB> have access to Compuserve,Internet (ftp), and am 
 KB> willing to buy books.)

In the 32bit OS/2 world,  there are very few things you have to worry about
when writing/using a dll.  The DLL simply becomes part of your EXE's
process -- same address space and everything.  If you can compile the code
into a *.LIB,  then a flick of a switch is all you should need to make a
*.DLL instead.

I think the docs that come with IBM's Cset++ compiler explain DLL's just fine.


 KB> I wrote an application that does interprocess 
 KB> communication via pipes, queues, or sockets.  I have 
 KB> linked IBM's TCP/IP .lib's that allow me to use their 
 KB> so32dll.dll and tcp32dll.dll at runtime.

 KB> I tried to test this program on a machine that did not 
 KB> have TCP/IP installed and (of course) OS/2 failed to 
 KB> load the program, informing me that it could not find 
 KB> the DLL's:

 KB> SYS1804: The system cannot find the file TCP32DLL.

 KB> -------
 KB> Q #2) What would you recommend to get around this problem?

This makes your code kinda of ugly.  You want to use DosLoadModule() to see
if the optional dll is present,  and if so,  use DosQueryProcAddr(),on each
function you wish to use,  to get a function pointer.  You will then have
to call each optional (ie: tcpip) function though the function pointer --
this means not using ibm's "tcpip.h" or linking with the tcp/ip
libs.



 KB> I thought I'd be bright and create a dummy copy of 
 KB> each of those DLL's, with all the functions I could 
 KB> find defined in the header files.  I made them return 
 KB> 0's or -1's accordingly to indicate an error to the 
 KB> caller.  The following message came out to greet me:

This will work,  but you will have to export the functions with their
proper ordinal number as well.  Use the EXEHDR utility to get the ordinals
(here's a short example):

  Exports:
  ord obj  offset    name
   12   1  00000f68  GETHOSTBYADDR exported, shared data
   11   1  00000e38  GETHOSTBYNAME exported, shared data
    8   1  00000608  INET_MAKEADDR exported, shared data
   24   1  00002004  GETSERVBYNAME exported, shared data


So in your fake-dll's *.def file,  you would have

    EXPORTS
         GETHOSTBYADDR {at}12
         GETHOSTBYNAME {at}11
         INET_MAKEADDR {at}8
         GETSERVBYNAME {at}24

NOTE:  I find it extremely distasteful to put in a dummy dll like this;it
is bound to cause problems for the end user down the road when they install
the real dll.


 KB> -------
 KB> Q #3) Is the way *I* can trap the error too, so I can 
 KB> just disable the socket portion of the program at 
 KB> runtime but continue to use the other transport 
 KB> methods?
 KB> -------

don't reference the dll at load time (ie: you have to use
DosLoadModule() and the function pointers).


 KB> -------
 KB> Q #4) Is there a way I can have the TCP/IP DLL's *not* 
 KB> load on startup, but rather use DosLoadModule() 
 KB> instead, when I've determined that I want to use 
 KB> sockets?  Or is that determined by the LOADONCALL in 
 KB> the DLL's .DEF file?

LOADONCALL is the default (and is the oposite of PRELOAD).  All this means
is the code pages will not be loaded until used -- but the system still
checks to see that they are there when the program loads (and if they
aren't,  you get the error message you got in question #1).



--- Maximus/2 2.01