Subj : Forwarder DLLs
To   : Andrew Belov
From : Vitus Jensen
Date : Fri Mar 02 2001 02:22 pm

Moin Andrew!

22.02.2001, Andrew Belov wrote a message to All:

(more than a week old and no answer, OS2PROG is getting slow and/or unreliable)

 AB> Is there any chance to create a forwarder DLL for DOSCALL1.DLL (like
 AB> one in the OS2TRACE). I'm thinking to create a quick-and-dirty
 AB> symbolic link support for certain programs I use to let them pick
 AB> configuration files from %ETC% as if they were actually stored in the
 AB> programs' home directory. Or, vice versa, to reference files in the
 AB> home directories from %ETC% (for backup with CVS). 

The official way for such an approach would the use of the DosSearchPath() API. 
 But I guess you don't have source code for those programs, right?

 AB> There are two approaches here, as I see:

 AB> 1. Create a custom DOSCALL1.DLL and reuse imports from the genuine
 AB> DOSCALL1.DLL for all APIs. This is quite complex since not every API
 AB> is documented and there are specific 16-bit entry points/etc. which
 AB> are hard to reproduce.

ren DOSCALL1.DLL OLDCALL1.DLL (don't forget the internal DLL name)
run your own DOSCALL1.DLL which imports from OLDCALL1.DLL?

Whever you are not interested in modifying the way a particular API works you 
can simple let the loader use the entry from OLDCALL1.DLL.  There is a sample 
how to do it from Peter Fitzsimmons: look for inifix.zip.  All you need are 
import definitions in you .def file.

 AB> 2. Make a DLL of my own (like the one in OS2TRACE) and hack certain
 AB> executables to use it, the one of special importance are EMX and IBM
 AB> LIBC, I guess. However, there is a multitude of executables that need
 AB> to be patched this way.

That's the approach which Peter uses: he applies dllrname.exe to a single DLL 
(PMMERGE.DLL) to use his NEWCALLS.DLL, imports all entries from DOSCALL1.DLL, 
runs his own DosOpen() and exports all entries:

IMPORTS
 DOSCWAIT                       =DOSCALLS.2
 DOSENTERCRITSEC                =DOSCALLS.3
....
EXPORTS
 DOSCWAIT                       @2
 DOSENTERCRITSEC                @3


 AB> The question is, how can be the method (1) be utilized? Does anyone
 AB> have any experience on substituting DOSCALL1.DLL, or this is a very
 AB> specific task which can't be accompished without a major reverse
 AB> engineering job?

There is no need for reverse engineering, just code you own version of 
DosOpen().  But I would use method (1): if you make an error just the patched 
apps are affected.  And it will continue to work after applying a fixpak even 
if there are entries added to DOSCALL1.DLL!

Bye,
   Vitus

---
 * Origin: Windows isn't crippleware: it's "Fuctionally Challeng (2:2474/424.1)

.