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)
