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?
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)
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?
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?
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.
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.
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!
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)?
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,028 |
Nodes: | 17 (1 / 16) |
Uptime: | 182:00:24 |
Calls: | 503,706 |
Calls today: | 9 |
Files: | 158,907 |
D/L today: |
14,657 files (4,686M bytes) |
Messages: | 444,363 |
Posted today: | 2 |