DT> The loader will automaticly do a DosLoadModule (and fixup) for any 
 DT> modules referenced in the header of the executable. I call this "load
 DT> time" linking vs "run time" linking done with an explicit
 DT> DosLoadModule and DosQueryProcAddr from within the app.  I don't like
 DT> to use the terms "static" or "dynamic" linking
here, they can have
 DT> slightly different connotations in the context of a  compiler and
 DT> it's run time libraries.. 

Me neither.

From what I can gather, by the way, only the module for the main EXE and
for DOSCALL1 are loaded by the parent process.  All other referenced DLLs
are loaded by a special user-mode function in DOSCALL1 that is where the
first thread in the process first starts executing.  

But this brings up a further question: What happens when a DLL cannot be
found ?  This should be, and *is*, reported in the pObjName buffer for
DosExecPgm.  I can see how this would be easy to implement if it were the
*parent* process that resolved all of the import module references and
built the initial user address space of the child.  But how does this
happen if the loading is occurring as part of the execution of user-mode
code in the child process ?  Don't tell me that there's a back door in OS/2
Warp for user-mode code in one process to write to the user address space
of another process!

 ¯ JdeBP ®

--- FleetStreet 1.19 NR