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)
