• Forwarder DLLs

    From Andrew Belov@2:5020/181.2 to All on Thu Feb 22 15:20:08 2001
    Hello All!

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

    1. Create a custom DOSCALL1.DLL and reuse imports from the genuine DOSCALL1.DLL
    for all APIs. This is quite complex since not every API is documented and there
    are specific 16-bit entry points/etc. which are hard to reproduce.

    2. Make a DLL of my own (like the one in OS2TRACE) and hack certain executables
    to use it, the one of special importance are EMX and IBM LIBC, I guess. However, there is a multitude of executables that need to be patched this way.

    The question is, how can be the method (1) be utilized? Does anyone have any experience on substituting DOSCALL1.DLL, or this is a very specific task which can't be accompished without a major reverse engineering job?

    Sincerely yours - Andrew

    ---
    * Origin: Conea Software Mail system - Moscow, Russia (2:5020/181.2)
  • From Vitus Jensen@2:2474/424.1 to Andrew Belov on Fri Mar 2 14:22:16 2001
    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)

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

    There are two approaches here, as I see:

    1. Create a custom DOSCALL1.DLL and reuse imports from the genuine DOSCALL1.DLL for all APIs. This is quite complex since not every API
    is documented and there are specific 16-bit entry points/etc. which
    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.

    2. Make a DLL of my own (like the one in OS2TRACE) and hack certain executables to use it, the one of special importance are EMX and IBM
    LIBC, I guess. However, there is a multitude of executables that need
    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:

    IMPORTS
    DOSCWAIT =DOSCALLS.2
    DOSENTERCRITSEC =DOSCALLS.3
    ...
    EXPORTS
    DOSCWAIT @2
    DOSENTERCRITSEC @3


    The question is, how can be the method (1) be utilized? Does anyone
    have any experience on substituting DOSCALL1.DLL, or this is a very specific task which can't be accompished without a major reverse 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)
  • From David Noon@2:257/609.5 to Vitus Jensen on Mon Mar 5 13:31:30 2001
    Hi Vitus,

    Replying to a message of Vitus Jensen to Andrew Belov:

    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)

    It was slow. Andrew posted his message on 22nd February [as above] and I didn't
    receive it until the night of 1st March. I replied on 2nd March. So the message
    took a week to get from Russia to England.

    Regards

    Dave
    <Team PL/I>

    --- FleetStreet 1.25.1
    * Origin: My other computer is an IBM S/390 (2:257/609.5)
  • From David Noon@2:257/609.5 to Andrew Belov on Fri Mar 2 13:22:58 2001
    Hi Andrew,

    Replying to a message of Andrew Belov to All:

    Hello All!

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

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

    There are two approaches here, as I see:

    1. Create a custom DOSCALL1.DLL and reuse imports from the genuine DOSCALL1.DLL for all APIs. This is quite complex since not every API
    is documented and there are specific 16-bit entry points/etc. which
    are hard to reproduce.

    2. Make a DLL of my own (like the one in OS2TRACE) and hack certain executables to use it, the one of special importance are EMX and IBM
    LIBC, I guess. However, there is a multitude of executables that need
    to be patched this way.

    The question is, how can be the method (1) be utilized? Does anyone
    have any experience on substituting DOSCALL1.DLL, or this is a very specific task which can't be accompished without a major reverse 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)
  • From Andrew Belov@2:5020/181.2 to David Noon on Thu Mar 15 11:08:37 2001
    Hello David!

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

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

    Why not just use TVFS, which supports links in its virtual file
    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.

    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.

    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)
  • From Andrew Belov@2:5020/181.2 to Vitus Jensen on Wed Mar 7 14:50:44 2001
    Hello Vitus!

    02 Mar 01 22:22, Vitus Jensen wrote to Andrew Belov:

    There are two approaches here, as I see:

    1. Create a custom DOSCALL1.DLL and reuse imports from the
    genuine DOSCALL1.DLL for all APIs. This is quite complex since
    not every API is documented and there are specific 16-bit entry
    points/etc. which 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?

    Exactly. This seems to be the best solution (although it will require some sort
    of automation to fix any and all DOSCALL1.DLL regardless of their export table).

    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.

    Hmmm, it looks like no code is required for the API forwarders. Shame I didn't know it until now.

    The question is, how can be the method (1) be utilized? Does
    anyone have any experience on substituting DOSCALL1.DLL, or this
    is a very specific task which can't be accompished without a
    major reverse 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.

    There are too many ones to patch, unfortunately. Not so many people use LIBC*.DLL or EMXLIBC*.DLL, so almost every executable has its own reference to DosOpen()... and there are zillions of C libraries as well: LIBC*.DLL, MMPMCRTS.DLL, REXXCRT.DLL, EMXLIBC*.DLL, ACROCRT.DLL, GUICRT.DLL, ...

    And it will continue to work after applying a fixpak even if there
    are entries added to DOSCALL1.DLL!

    The only problem is that it has to be automated somehow. The manual intervention is not a problem since I already accumulated a rich set of patches
    (fixing palette in Cirrus driver, resurrecting the Merlin hibernation feature, and so on). Have to think twice before I install a new CSD.

    Sincerely yours - Andrew

    ---
    * Origin: Conea Software Mail system - Moscow, Russia (2:5020/181.2)
  • From David Noon@2:257/609.5 to Andrew Belov on Tue Mar 20 15:05:42 2001
    Hi Andrew,

    Replying to a message of Andrew Belov to David Noon:

    [snip]
    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)?

    I just tried it out using VAC++ 3.0 and it works. ILINK.EXE gives a warning about creating a forwarder when it links the "middle" DLL, but everything works. The .EXE I wrote called 2 routines, ostensibly from the same DLL, but one was actually in another DLL; both DLL's were loaded correctly and both routines were called correctly.

    So, just import in one part of your .DEF file and export in another. Only supply code for the specific routines you want to hack.

    Regards

    Dave
    <Team PL/I>

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