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)

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)

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)

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)

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)

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)

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)