Subj : Forwarder DLLs
To   : David Noon
From : Andrew Belov
Date : Thu Mar 15 2001 11:08 am

Hello David!

02 Mar 01 21:22, David Noon wrote to Andrew Belov:

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

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

Two problems arise with TVFS:

1. The files of interest reside in applications' home directories. This will 
require the applications to move to TVFS as well. I can't just make links to 
configuration files from CVS working directory, I think it's more reliable to 
set up the symlinks vice-versa. A complex TVFS structure is a time bomb by 
itself, moreover, it's not so flexible, e.g. unreachable from CONFIG.SYS.

2. TVFS conflicts with that little-known "hibernation" feature (HYBERNAT.EXE) 
of OS/2 v 4.x. The IBM Austin team acknowledges problems with hibernation but 
refuses to fix them, what led me to a long path of kernel-patching and stealing 
files from TCO branches of OS/2... I managed to make it work even in OS/2 v 
4.50 (!) but anyway, TVFS screws up after the system is restored.

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

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

That is the problem I'll have to investigate. Do I need to supply code for all 
and any ordinal being forwarded, or there is an easier approach (e.g. by 
duplicating the name both in IMPORTS section and in EXPORTS)? Anyway, thanks 
for the information, I'll hack with it later.

                                        Sincerely yours - Andrew

---
 * Origin: Conea Software Mail system - Moscow, Russia (2:5020/181.2)

.