Subj : Forwarder DLLs
To   : Andrew Belov
From : David Noon
Date : Fri Mar 02 2001 01:22 pm

Hi Andrew,

Replying to a message of Andrew Belov to All:

 AB> Hello All!

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

Why not just use TVFS, which supports links in its virtual file system?

 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.

 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.

 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?

The person best qualified to answer that is probably Peter Fitzsimmons, who 
used to moderate this echo. I recall he did something similar to reduce the 
overheads of the WPS caching OS2.INI and OS2SYS.INI, and using poor I/O 
techinques to flush the cache back to disk. I think he hooked DosOpen(), or the 
like.

Anyhow, in Pete's absence, here is my suggestion:

One possibility would be to write your own DLL named DOSCALL1.DLL, and use the 
DLLRNAME.EXE supplied with IBM C/C++ to rename the original DOSCALL1.DLL to, 
say, DOSCALL2.DLL. Any entry points you don't want to support you just pass to 
DOSCALL2.DLL directly, and the rest you handle/hack within your own code inside 
your DOSCALL1.DLL. It might be best to do this in assembler, so that you can 
transfer control to DOSCALL2.DLL without altering the state of the stack or 
registers; that way you don't need to know the parameter conventions of 
undocumented API calls.

I would try this on a "spare" boot partition before deploying it on my main 
system. ... :-))

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
 * Origin: My other computer is an IBM S/390 (2:257/609.5)

.