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:
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)
