www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - link from a dll to another function in another dll?

reply maarten van damme <maartenvd1994 gmail.com> writes:
Hello everyone, this is my second post in the digitalmars.d newsgroup and I
hope it gets as good support and suggestions as my first post :)

I'm playing around with the d programming language and am trying out some
exotic things you normally would write in c++.
Right now I'm trying to 'intercept' all calls from a program to a dll by
renaming that dll and writing my own in d.
In c++ you would write in the header file:
#pragma comment(linker,
"/export:exportfunction=nameofotherdll.dll.destinationfunction, location")

How could one write this in the d programming language?
Asuming this has to be done with the pragma(lib,...) function but I don't
really know how.

thanks in advance,

Maarten
Apr 17 2011
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 17 Apr 2011 16:09:02 -0400, maarten van damme  
<maartenvd1994 gmail.com> wrote:

 Hello everyone, this is my second post in the digitalmars.d newsgroup  
 and I
 hope it gets as good support and suggestions as my first post :)

 I'm playing around with the d programming language and am trying out some
 exotic things you normally would write in c++.
 Right now I'm trying to 'intercept' all calls from a program to a dll by
 renaming that dll and writing my own in d.
 In c++ you would write in the header file:
 #pragma comment(linker,
 "/export:exportfunction=nameofotherdll.dll.destinationfunction, location")

 How could one write this in the d programming language?
 Asuming this has to be done with the pragma(lib,...) function but I don't
 really know how.

 thanks in advance,

 Maarten
I don't know of an automated way of doing this is D. pragma(lib,...) exists, but it simply loads a specified static library. (i.e. to simplify linking/ project setup, etc). Personally, I'd just export extern(C)/extern(System) functions toa DLL, and link in a manually define the renamed DLL using a .def file and implib.
Apr 17 2011
parent reply maarten van damme <maartenvd1994 gmail.com> writes:
The problem with that aproach would be that the functions are in another
location in the export table.
I've read that the locations need to stay exactly the same.
Am I wrong about this?

2011/4/18 Robert Jacques <sandford jhu.edu>

 On Sun, 17 Apr 2011 16:09:02 -0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  Hello everyone, this is my second post in the digitalmars.d newsgroup and
 I
 hope it gets as good support and suggestions as my first post :)

 I'm playing around with the d programming language and am trying out some
 exotic things you normally would write in c++.
 Right now I'm trying to 'intercept' all calls from a program to a dll by
 renaming that dll and writing my own in d.
 In c++ you would write in the header file:
 #pragma comment(linker,
 "/export:exportfunction=nameofotherdll.dll.destinationfunction, location")

 How could one write this in the d programming language?
 Asuming this has to be done with the pragma(lib,...) function but I don't
 really know how.

 thanks in advance,

 Maarten
I don't know of an automated way of doing this is D. pragma(lib,...) exists, but it simply loads a specified static library. (i.e. to simplify linking/ project setup, etc). Personally, I'd just export extern(C)/extern(System) functions toa DLL, and link in a manually define the renamed DLL using a .def file and implib.
Apr 18 2011
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 18 Apr 2011 04:11:16 -0400, maarten van damme  
<maartenvd1994 gmail.com> wrote:

 The problem with that aproach would be that the functions are in another
 location in the export table.
 I've read that the locations need to stay exactly the same.
 Am I wrong about this?
I don't know for sure, but my gut would say that not knowing the exact layout of the DLL is half the point. In practice, I've used D with DLLs that have drastically added to/changed their layout (according to dumpbin) without a problem.
Apr 18 2011
parent reply maarten van damme <maartenvd1994 gmail.com> writes:
Hello, I'm back (I've been ill, nothing serious)
I woul really like a bit more explanation with that particular approach.
Would declaring the functions I want to keep from the renamed dll in a
extern(c) block and linking that to the renamed dll while also declaring
them as export work?
And the function I want to change I declare myself and write in d?

I haven't really mastered the d language and I'm simply playing around with
it, simply checking if I've understood it.

2011/4/18 Robert Jacques <sandford jhu.edu>

 On Mon, 18 Apr 2011 04:11:16 -0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  The problem with that aproach would be that the functions are in another
 location in the export table.
 I've read that the locations need to stay exactly the same.
 Am I wrong about this?
I don't know for sure, but my gut would say that not knowing the exact layout of the DLL is half the point. In practice, I've used D with DLLs that have drastically added to/changed their layout (according to dumpbin) without a problem.
Apr 21 2011
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 21 Apr 2011 07:49:14 -0400, maarten van damme  
<maartenvd1994 gmail.com> wrote:

 Hello, I'm back (I've been ill, nothing serious)
 I woul really like a bit more explanation with that particular approach.
 Would declaring the functions I want to keep from the renamed dll in a
 extern(c) block and linking that to the renamed dll while also declaring
 them as export work?
 And the function I want to change I declare myself and write in d?

 I haven't really mastered the d language and I'm simply playing around  
 with
 it, simply checking if I've understood it.

 2011/4/18 Robert Jacques <sandford jhu.edu>

 On Mon, 18 Apr 2011 04:11:16 -0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  The problem with that aproach would be that the functions are in  
 another
 location in the export table.
 I've read that the locations need to stay exactly the same.
 Am I wrong about this?
I don't know for sure, but my gut would say that not knowing the exact layout of the DLL is half the point. In practice, I've used D with DLLs that have drastically added to/changed their layout (according to dumpbin) without a problem.
Hmm... It should work, but I've never tried it. Def files allow you to rename DLL functions, so you could rename the single function you want to override something else, or leave it out entirely. The only thing to be careful of is call style and name mangling (i.e. System vs C, etc.)
Apr 21 2011
next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
There is another problem, I don't know the return types of the functions
from that dll, so I gave them the type "void *". I think this is incorrect.
I've tried with the little knowledge I have from d and in the link is my
kernel32.d. I have compiled it succesfully in a .dll but the application
using that dll states that that dll isn't valid.

thank you for taking your time to answer this question :) .


http://dl.dropbox.com/u/15024434/kernel32.d

 2011/4/21 Robert Jacques <sandford jhu.edu>

 On Thu, 21 Apr 2011 07:49:14 -0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  Hello, I'm back (I've been ill, nothing serious)
 I woul really like a bit more explanation with that particular approach.
 Would declaring the functions I want to keep from the renamed dll in a
 extern(c) block and linking that to the renamed dll while also declaring
 them as export work?
 And the function I want to change I declare myself and write in d?

 I haven't really mastered the d language and I'm simply playing around
 with
 it, simply checking if I've understood it.

 2011/4/18 Robert Jacques <sandford jhu.edu>

  On Mon, 18 Apr 2011 04:11:16 -0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  The problem with that aproach would be that the functions are in
 another

 location in the export table.
 I've read that the locations need to stay exactly the same.
 Am I wrong about this?
I don't know for sure, but my gut would say that not knowing the exact layout of the DLL is half the point. In practice, I've used D with DLLs that have drastically added to/changed their layout (according to dumpbin) without a problem.
Hmm... It should work, but I've never tried it. Def files allow you to rename DLL functions, so you could rename the single function you want to override something else, or leave it out entirely. The only thing to be careful of is call style and name mangling (i.e. System vs C, etc.)
Apr 21 2011
prev sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
according to dllexp.exe (a dll examiner) my dll does not export any
functions.
So there is something wrong in my declaration:

pragma(lib,kernel33.lib);
extern(C){
export void * functionfromkernel33.lib () ;
...
}

How can one write this correctly?

2011/4/21 maarten van damme <maartenvd1994 gmail.com>

 There is another problem, I don't know the return types of the functions
 from that dll, so I gave them the type "void *". I think this is incorrect.
 I've tried with the little knowledge I have from d and in the link is my
 kernel32.d. I have compiled it succesfully in a .dll but the application
 using that dll states that that dll isn't valid.

 thank you for taking your time to answer this question :) .


 http://dl.dropbox.com/u/15024434/kernel32.d


 2011/4/21 Robert Jacques <sandford jhu.edu>

 On Thu, 21 Apr 2011 07:49:14 -0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  Hello, I'm back (I've been ill, nothing serious)
 I woul really like a bit more explanation with that particular approach.
 Would declaring the functions I want to keep from the renamed dll in a
 extern(c) block and linking that to the renamed dll while also declaring
 them as export work?
 And the function I want to change I declare myself and write in d?

 I haven't really mastered the d language and I'm simply playing around
 with
 it, simply checking if I've understood it.

 2011/4/18 Robert Jacques <sandford jhu.edu>

  On Mon, 18 Apr 2011 04:11:16 -0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  The problem with that aproach would be that the functions are in
 another

 location in the export table.
 I've read that the locations need to stay exactly the same.
 Am I wrong about this?
I don't know for sure, but my gut would say that not knowing the exact layout of the DLL is half the point. In practice, I've used D with DLLs that have drastically added to/changed their layout (according to dumpbin) without a problem.
Hmm... It should work, but I've never tried it. Def files allow you to rename DLL functions, so you could rename the single function you want to override something else, or leave it out entirely. The only thing to be careful of is call style and name mangling (i.e. System vs C, etc.)
Apr 21 2011
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 21 Apr 2011 12:31:56 -0400, maarten van damme  
<maartenvd1994 gmail.com> wrote:

 according to dllexp.exe (a dll examiner) my dll does not export any
 functions.
 So there is something wrong in my declaration:

 pragma(lib,kernel33.lib);
 extern(C){
 export void * functionfromkernel33.lib () ;
 ...
 }

 How can one write this correctly?
You need a dll main function. Check out the dll example that comes with dmd (i.e. dmd2\samples\d\mydll) for the complete example.
Apr 21 2011
next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
That example was a bit incomplete, preceding was the following code:

import std.c.windows.windows;
import core.dll_helper;

pragma(lib,"kernel33.lib");

__gshared HINSTANCE g_hInst;

extern (Windows)
BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
{
    switch (ulReason)
    {
case DLL_PROCESS_ATTACH:
    g_hInst = hInstance;
    dll_process_attach( hInstance, true );
    break;

case DLL_PROCESS_DETACH:
    dll_process_detach( hInstance, true );
    break;

case DLL_THREAD_ATTACH:
    dll_thread_attach( true, true );
    break;

case DLL_THREAD_DETACH:
    dll_thread_detach( true, true );
    break;
    }
    return true;
}
Apr 22 2011
prev sibling next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
I'm afraid I've been a little unclear.
I've copied kernel32.dll from the windows dir, renamed it to kernel33.dll
and generated a .lib from it using implib.
Then I've created a d file with a correct dllmain(stolen from examples) and
between

system(C){
export void * exportedfunctionfromkernel33.dll();
export void * exportedfunction2fromkernel33.dll();
...
}

But it looks like you can't both declare a function from another lib and
export it at the same time.
Apr 27 2011
prev sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
I've changed this, I think I'm still kinda confused with lib files. They've
told me you can't do something with them without a .di file
So I went ahead and made a kernel33.di file. I now import it in kernel32.d
and my declaration is
System(C){
export void * exportedfunctionblablabal(){
   return exportedfunctionblablablal();
}
...
}

The file in the directory are:
kernel32.d : http://dl.dropbox.com/u/15024434/d/kernel32.d
kernel33.di : http://dl.dropbox.com/u/15024434/d/kernel33.di
kernel33.lib : http://dl.dropbox.com/u/15024434/d/kernel33.lib
kernel33.dll : http://dl.dropbox.com/u/15024434/d/kernel33.dll

I've tried to compile using dmd -d kernel32.d kernel33.di kernel33.lib but
it throws errors like
"Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
I have literally no clue why this is the case, can someone help me out or
look at the files?

2011/4/27 maarten van damme <maartenvd1994 gmail.com>

 I'm afraid I've been a little unclear.
 I've copied kernel32.dll from the windows dir, renamed it to kernel33.dll
 and generated a .lib from it using implib.
 Then I've created a d file with a correct dllmain(stolen from examples) and
 between

 system(C){
 export void * exportedfunctionfromkernel33.dll();
 export void * exportedfunction2fromkernel33.dll();
 ...
 }

 But it looks like you can't both declare a function from another lib and
 export it at the same time.
Apr 30 2011
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme  
<maartenvd1994 gmail.com> wrote:

 I've changed this, I think I'm still kinda confused with lib files.  
 They've
 told me you can't do something with them without a .di file
 So I went ahead and made a kernel33.di file. I now import it in  
 kernel32.d
 and my declaration is
 System(C){
 export void * exportedfunctionblablabal(){
    return exportedfunctionblablablal();
 }
 ...
 }

 The file in the directory are:
 kernel32.d : http://dl.dropbox.com/u/15024434/d/kernel32.d
 kernel33.di : http://dl.dropbox.com/u/15024434/d/kernel33.di
 kernel33.lib : http://dl.dropbox.com/u/15024434/d/kernel33.lib
 kernel33.dll : http://dl.dropbox.com/u/15024434/d/kernel33.dll

 I've tried to compile using dmd -d kernel32.d kernel33.di kernel33.lib  
 but
 it throws errors like
 "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
 I have literally no clue why this is the case, can someone help me out or
 look at the files?

 2011/4/27 maarten van damme <maartenvd1994 gmail.com>

 I'm afraid I've been a little unclear.
 I've copied kernel32.dll from the windows dir, renamed it to  
 kernel33.dll
 and generated a .lib from it using implib.
 Then I've created a d file with a correct dllmain(stolen from examples)  
 and
 between

 system(C){
 export void * exportedfunctionfromkernel33.dll();
 export void * exportedfunction2fromkernel33.dll();
 ...
 }

 But it looks like you can't both declare a function from another lib and
 export it at the same time.
In your kernel33.di, try making it extern (C) export void* _hread(); etc. You functions get D mangling otherwise. I'd also suggest you to start with a less complex example, e.g. export only one function, make sure it works, then add the rest. If you think your .lib files doesn't do its job, try using .def file instead. I find them extremely helpful, and they are a lot easier to edit/extend. Hope that helps.
Apr 30 2011
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
I'm not sure your wrapping will work with kernel32.dll, but in general 
here are a few tips:

- most functions in the windows API use the __stdcall calling convention 
in C/C++, which translates to D as "extern(Windows)"

- this will usually add the number of bytes passed on the stack as a 
" NN" postfix to the function name. This postfix does not exist in 
kernel32.dll, but in the import library kernel32.lib that you find in 
the dmd lib folder. Maybe you can use the standard import library, or 
use the translation shown below.

- as the exported function and the function you want to chain to have 
identical names, you have to change at least one of these and modify 
them in some build step. I'd suggest to do this in the def file:

The symbols in the d-source file containing:

----
extern(Windows) HANDLE imported_GetCurrentProcess();

export extern(Windows) HANDLE internal_GetCurrentProcess()
{
   return imported_GetCurrentProcess();
}
----

can be mapped to other symbols in the def file:

----
EXPORTS
   GetCurrentProcess = internal_GetCurrentProcess

IMPORTS
   imported_GetCurrentProcess = kernel33.GetCurrentProcess
----

- if you don't know the number of arguments, you should not call the 
wrapped function, as this will change the callstack. Instead, you should 
just jump to it:

void internal_hread()
{
   asm
   {
     naked;
     jmp imported_hread;
   }
}

I haven't tried all that, though, so there might be some mistakes...

Rainer


Denis Koroskin wrote:
 On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme 
 <maartenvd1994 gmail.com> wrote:
 
 I've changed this, I think I'm still kinda confused with lib files. 
 They've
 told me you can't do something with them without a .di file
 So I went ahead and made a kernel33.di file. I now import it in 
 kernel32.d
 and my declaration is
 System(C){
 export void * exportedfunctionblablabal(){
    return exportedfunctionblablablal();
 }
 ...
 }

 The file in the directory are:
 kernel32.d : http://dl.dropbox.com/u/15024434/d/kernel32.d
 kernel33.di : http://dl.dropbox.com/u/15024434/d/kernel33.di
 kernel33.lib : http://dl.dropbox.com/u/15024434/d/kernel33.lib
 kernel33.dll : http://dl.dropbox.com/u/15024434/d/kernel33.dll

 I've tried to compile using dmd -d kernel32.d kernel33.di kernel33.lib 
 but
 it throws errors like
 "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
 I have literally no clue why this is the case, can someone help me out or
 look at the files?

 2011/4/27 maarten van damme <maartenvd1994 gmail.com>

 I'm afraid I've been a little unclear.
 I've copied kernel32.dll from the windows dir, renamed it to 
 kernel33.dll
 and generated a .lib from it using implib.
 Then I've created a d file with a correct dllmain(stolen from 
 examples) and
 between

 system(C){
 export void * exportedfunctionfromkernel33.dll();
 export void * exportedfunction2fromkernel33.dll();
 ...
 }

 But it looks like you can't both declare a function from another lib and
 export it at the same time.
In your kernel33.di, try making it extern (C) export void* _hread(); etc. You functions get D mangling otherwise. I'd also suggest you to start with a less complex example, e.g. export only one function, make sure it works, then add the rest. If you think your .lib files doesn't do its job, try using .def file instead. I find them extremely helpful, and they are a lot easier to edit/extend. Hope that helps.
Apr 30 2011
next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
Wow, thanks for the help
The first thing I did was in the .di file adding extern(windows){ ... }
and now compiling doesn't give errors and when examining with dllexp I can
see that it exports the same functions as the real kernel32.dll :D

Now I'm going to implement all other suggested changes, thanks a lot

2011/4/30 Rainer Schuetze <r.sagitario gmx.de>

 I'm not sure your wrapping will work with kernel32.dll, but in general here
 are a few tips:

 - most functions in the windows API use the __stdcall calling convention in
 C/C++, which translates to D as "extern(Windows)"

 - this will usually add the number of bytes passed on the stack as a " NN"
 postfix to the function name. This postfix does not exist in kernel32.dll,
 but in the import library kernel32.lib that you find in the dmd lib folder.
 Maybe you can use the standard import library, or use the translation shown
 below.

 - as the exported function and the function you want to chain to have
 identical names, you have to change at least one of these and modify them in
 some build step. I'd suggest to do this in the def file:

 The symbols in the d-source file containing:

 ----
 extern(Windows) HANDLE imported_GetCurrentProcess();

 export extern(Windows) HANDLE internal_GetCurrentProcess()
 {
  return imported_GetCurrentProcess();
 }
 ----

 can be mapped to other symbols in the def file:

 ----
 EXPORTS
  GetCurrentProcess = internal_GetCurrentProcess

 IMPORTS
  imported_GetCurrentProcess = kernel33.GetCurrentProcess
 ----

 - if you don't know the number of arguments, you should not call the
 wrapped function, as this will change the callstack. Instead, you should
 just jump to it:

 void internal_hread()
 {
  asm
  {
    naked;
    jmp imported_hread;
  }
 }

 I haven't tried all that, though, so there might be some mistakes...

 Rainer



 Denis Koroskin wrote:

 On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  I've changed this, I think I'm still kinda confused with lib files.
 They've
 told me you can't do something with them without a .di file
 So I went ahead and made a kernel33.di file. I now import it in
 kernel32.d
 and my declaration is
 System(C){
 export void * exportedfunctionblablabal(){
   return exportedfunctionblablablal();
 }
 ...
 }

 The file in the directory are:
 kernel32.d : http://dl.dropbox.com/u/15024434/d/kernel32.d
 kernel33.di : http://dl.dropbox.com/u/15024434/d/kernel33.di
 kernel33.lib : http://dl.dropbox.com/u/15024434/d/kernel33.lib
 kernel33.dll : http://dl.dropbox.com/u/15024434/d/kernel33.dll

 I've tried to compile using dmd -d kernel32.d kernel33.di kernel33.lib
 but
 it throws errors like
 "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
 I have literally no clue why this is the case, can someone help me out or
 look at the files?

 2011/4/27 maarten van damme <maartenvd1994 gmail.com>

  I'm afraid I've been a little unclear.
 I've copied kernel32.dll from the windows dir, renamed it to
 kernel33.dll
 and generated a .lib from it using implib.
 Then I've created a d file with a correct dllmain(stolen from examples)
 and
 between

 system(C){
 export void * exportedfunctionfromkernel33.dll();
 export void * exportedfunction2fromkernel33.dll();
 ...
 }

 But it looks like you can't both declare a function from another lib and
 export it at the same time.
In your kernel33.di, try making it extern (C) export void* _hread(); etc. You functions get D mangling otherwise. I'd also suggest you to start with a less complex example, e.g. export only one function, make sure it works, then add the rest. If you think your .lib files doesn't do its job, try using .def file instead. I find them extremely helpful, and they are a lot easier to edit/extend. Hope that helps.
May 01 2011
prev sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
Number overflow?
So I implemented the suggested changes (you can check them out at
http://dl.dropbox.com/u/15024434/version2.zip)
But now I get when I compile it :
"kernel32.def(738) : Error 12: Number Overflow: (strange symbol over here)"

I do agree I should've picked a simpler example but I think the
statisfaction will be even bigger if I were to succeed :p

2011/5/1 maarten van damme <maartenvd1994 gmail.com>

 Wow, thanks for the help
 The first thing I did was in the .di file adding extern(windows){ ... }
 and now compiling doesn't give errors and when examining with dllexp I can
 see that it exports the same functions as the real kernel32.dll :D

 Now I'm going to implement all other suggested changes, thanks a lot


 2011/4/30 Rainer Schuetze <r.sagitario gmx.de>

 I'm not sure your wrapping will work with kernel32.dll, but in general
 here are a few tips:

 - most functions in the windows API use the __stdcall calling convention
 in C/C++, which translates to D as "extern(Windows)"

 - this will usually add the number of bytes passed on the stack as a " NN"
 postfix to the function name. This postfix does not exist in kernel32.dll,
 but in the import library kernel32.lib that you find in the dmd lib folder.
 Maybe you can use the standard import library, or use the translation shown
 below.

 - as the exported function and the function you want to chain to have
 identical names, you have to change at least one of these and modify them in
 some build step. I'd suggest to do this in the def file:

 The symbols in the d-source file containing:

 ----
 extern(Windows) HANDLE imported_GetCurrentProcess();

 export extern(Windows) HANDLE internal_GetCurrentProcess()
 {
  return imported_GetCurrentProcess();
 }
 ----

 can be mapped to other symbols in the def file:

 ----
 EXPORTS
  GetCurrentProcess = internal_GetCurrentProcess

 IMPORTS
  imported_GetCurrentProcess = kernel33.GetCurrentProcess
 ----

 - if you don't know the number of arguments, you should not call the
 wrapped function, as this will change the callstack. Instead, you should
 just jump to it:

 void internal_hread()
 {
  asm
  {
    naked;
    jmp imported_hread;
  }
 }

 I haven't tried all that, though, so there might be some mistakes...

 Rainer



 Denis Koroskin wrote:

 On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme <
 maartenvd1994 gmail.com> wrote:

  I've changed this, I think I'm still kinda confused with lib files.
 They've
 told me you can't do something with them without a .di file
 So I went ahead and made a kernel33.di file. I now import it in
 kernel32.d
 and my declaration is
 System(C){
 export void * exportedfunctionblablabal(){
   return exportedfunctionblablablal();
 }
 ...
 }

 The file in the directory are:
 kernel32.d : http://dl.dropbox.com/u/15024434/d/kernel32.d
 kernel33.di : http://dl.dropbox.com/u/15024434/d/kernel33.di
 kernel33.lib : http://dl.dropbox.com/u/15024434/d/kernel33.lib
 kernel33.dll : http://dl.dropbox.com/u/15024434/d/kernel33.dll

 I've tried to compile using dmd -d kernel32.d kernel33.di kernel33.lib
 but
 it throws errors like
 "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
 I have literally no clue why this is the case, can someone help me out
 or
 look at the files?

 2011/4/27 maarten van damme <maartenvd1994 gmail.com>

  I'm afraid I've been a little unclear.
 I've copied kernel32.dll from the windows dir, renamed it to
 kernel33.dll
 and generated a .lib from it using implib.
 Then I've created a d file with a correct dllmain(stolen from examples)
 and
 between

 system(C){
 export void * exportedfunctionfromkernel33.dll();
 export void * exportedfunction2fromkernel33.dll();
 ...
 }

 But it looks like you can't both declare a function from another lib
 and
 export it at the same time.
In your kernel33.di, try making it extern (C) export void* _hread(); etc. You functions get D mangling otherwise. I'd also suggest you to start with a less complex example, e.g. export only one function, make sure it works, then add the rest. If you think your .lib files doesn't do its job, try using .def file instead. I find them extremely helpful, and they are a lot easier to edit/extend. Hope that helps.
May 01 2011
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
It seems you have hit another of those dreaded optlink bugs.

With less symbols, it works if you declare the imports like this 
(because of the described name mangling):

IMPORTS	
	_imported_hread 0 =  kernel33._hread

2 more notes:
- you don't need to import kernel33.di
- you should not use "SINGLE" in the DATA statement of the def file, it 
will share the memory across processes.



maarten van damme wrote:
 Number overflow?
 So I implemented the suggested changes (you can check them out 
 at http://dl.dropbox.com/u/15024434/version2.zip)
 But now I get when I compile it : 
 "kernel32.def(738) : Error 12: Number Overflow: (strange symbol over here)"
 
 I do agree I should've picked a simpler example but I think the 
 statisfaction will be even bigger if I were to succeed :p
 
 2011/5/1 maarten van damme <maartenvd1994 gmail.com 
 <mailto:maartenvd1994 gmail.com>>
 
     Wow, thanks for the help
     The first thing I did was in the .di file adding extern(windows){ ... }
     and now compiling doesn't give errors and when examining with dllexp
     I can see that it exports the same functions as the real kernel32.dll :D
 
     Now I'm going to implement all other suggested changes, thanks a lot
 
 
     2011/4/30 Rainer Schuetze <r.sagitario gmx.de
     <mailto:r.sagitario gmx.de>>
 
         I'm not sure your wrapping will work with kernel32.dll, but in
         general here are a few tips:
 
         - most functions in the windows API use the __stdcall calling
         convention in C/C++, which translates to D as "extern(Windows)"
 
         - this will usually add the number of bytes passed on the stack
         as a " NN" postfix to the function name. This postfix does not
         exist in kernel32.dll, but in the import library kernel32.lib
         that you find in the dmd lib folder. Maybe you can use the
         standard import library, or use the translation shown below.
 
         - as the exported function and the function you want to chain to
         have identical names, you have to change at least one of these
         and modify them in some build step. I'd suggest to do this in
         the def file:
 
         The symbols in the d-source file containing:
 
         ----
         extern(Windows) HANDLE imported_GetCurrentProcess();
 
         export extern(Windows) HANDLE internal_GetCurrentProcess()
         {
          return imported_GetCurrentProcess();
         }
         ----
 
         can be mapped to other symbols in the def file:
 
         ----
         EXPORTS
          GetCurrentProcess = internal_GetCurrentProcess
 
         IMPORTS
          imported_GetCurrentProcess = kernel33.GetCurrentProcess
         ----
 
         - if you don't know the number of arguments, you should not call
         the wrapped function, as this will change the callstack.
         Instead, you should just jump to it:
 
         void internal_hread()
         {
          asm
          {
            naked;
            jmp imported_hread;
          }
         }
 
         I haven't tried all that, though, so there might be some mistakes...
 
         Rainer
 
 
 
         Denis Koroskin wrote:
 
             On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme
             <maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>>
             wrote:
 
                 I've changed this, I think I'm still kinda confused with
                 lib files. They've
                 told me you can't do something with them without a .di file
                 So I went ahead and made a kernel33.di file. I now
                 import it in kernel32.d
                 and my declaration is
                 System(C){
                 export void * exportedfunctionblablabal(){
                   return exportedfunctionblablablal();
                 }
                 ....
                 }
 
                 The file in the directory are:
                 kernel32.d : http://dl.dropbox.com/u/15024434/d/kernel32.d
                 kernel33.di : http://dl.dropbox.com/u/15024434/d/kernel33.di
                 kernel33.lib :
                 http://dl.dropbox.com/u/15024434/d/kernel33.lib
                 kernel33.dll :
                 http://dl.dropbox.com/u/15024434/d/kernel33.dll
 
                 I've tried to compile using dmd -d kernel32.d
                 kernel33.di kernel33.lib but
                 it throws errors like
                 "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
                 I have literally no clue why this is the case, can
                 someone help me out or
                 look at the files?
 
                 2011/4/27 maarten van damme <maartenvd1994 gmail.com
                 <mailto:maartenvd1994 gmail.com>>
 
                     I'm afraid I've been a little unclear.
                     I've copied kernel32.dll from the windows dir,
                     renamed it to kernel33.dll
                     and generated a .lib from it using implib.
                     Then I've created a d file with a correct
                     dllmain(stolen from examples) and
                     between
 
                     system(C){
                     export void * exportedfunctionfromkernel33.dll();
                     export void * exportedfunction2fromkernel33.dll();
                     ....
                     }
 
                     But it looks like you can't both declare a function
                     from another lib and
                     export it at the same time.
 
 
             In your kernel33.di, try making it extern (C) export void*
             _hread(); etc. You functions get D mangling otherwise.
 
             I'd also suggest you to start with a less complex example,
             e.g. export only one function, make sure it works, then add
             the rest.
 
             If you think your .lib files doesn't do its job, try using
             .def file instead. I find them extremely helpful, and they
             are a lot easier to edit/extend.
 
             Hope that helps.
 
 
 
May 01 2011
parent reply maarten van damme <maartenvd1994 gmail.com> writes:
Great, now the error in kernel32.def is resolved but it gets the same
problem in kernel33.def.
here is the start of the exports from kernel33.def:
EXPORTS
_hread  1334
how can I change this to resolve that?

2011/5/1 Rainer Schuetze <r.sagitario gmx.de>

 It seems you have hit another of those dreaded optlink bugs.

 With less symbols, it works if you declare the imports like this (because
 of the described name mangling):

 IMPORTS
        _imported_hread 0 =  kernel33._hread

 2 more notes:
 - you don't need to import kernel33.di
 - you should not use "SINGLE" in the DATA statement of the def file, it
 will share the memory across processes.



 maarten van damme wrote:

 Number overflow?
 So I implemented the suggested changes (you can check them out at
 http://dl.dropbox.com/u/15024434/version2.zip)

 But now I get when I compile it : "kernel32.def(738) : Error 12: Number
 Overflow: (strange symbol over here)"

 I do agree I should've picked a simpler example but I think the
 statisfaction will be even bigger if I were to succeed :p

 2011/5/1 maarten van damme <maartenvd1994 gmail.com <mailto:
 maartenvd1994 gmail.com>>


    Wow, thanks for the help
    The first thing I did was in the .di file adding extern(windows){ ... }
    and now compiling doesn't give errors and when examining with dllexp
    I can see that it exports the same functions as the real kernel32.dll
 :D

    Now I'm going to implement all other suggested changes, thanks a lot


    2011/4/30 Rainer Schuetze <r.sagitario gmx.de
    <mailto:r.sagitario gmx.de>>


        I'm not sure your wrapping will work with kernel32.dll, but in
        general here are a few tips:

        - most functions in the windows API use the __stdcall calling
        convention in C/C++, which translates to D as "extern(Windows)"

        - this will usually add the number of bytes passed on the stack
        as a " NN" postfix to the function name. This postfix does not
        exist in kernel32.dll, but in the import library kernel32.lib
        that you find in the dmd lib folder. Maybe you can use the
        standard import library, or use the translation shown below.

        - as the exported function and the function you want to chain to
        have identical names, you have to change at least one of these
        and modify them in some build step. I'd suggest to do this in
        the def file:

        The symbols in the d-source file containing:

        ----
        extern(Windows) HANDLE imported_GetCurrentProcess();

        export extern(Windows) HANDLE internal_GetCurrentProcess()
        {
         return imported_GetCurrentProcess();
        }
        ----

        can be mapped to other symbols in the def file:

        ----
        EXPORTS
         GetCurrentProcess = internal_GetCurrentProcess

        IMPORTS
         imported_GetCurrentProcess = kernel33.GetCurrentProcess
        ----

        - if you don't know the number of arguments, you should not call
        the wrapped function, as this will change the callstack.
        Instead, you should just jump to it:

        void internal_hread()
        {
         asm
         {
           naked;
           jmp imported_hread;
         }
        }

        I haven't tried all that, though, so there might be some
 mistakes...

        Rainer



        Denis Koroskin wrote:

            On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme
            <maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>>

            wrote:

                I've changed this, I think I'm still kinda confused with
                lib files. They've
                told me you can't do something with them without a .di file
                So I went ahead and made a kernel33.di file. I now
                import it in kernel32.d
                and my declaration is
                System(C){
                export void * exportedfunctionblablabal(){
                  return exportedfunctionblablablal();
                }
                ....
                }

                The file in the directory are:
                kernel32.d : http://dl.dropbox.com/u/15024434/d/kernel32.d
                kernel33.di :
 http://dl.dropbox.com/u/15024434/d/kernel33.di
                kernel33.lib :
                http://dl.dropbox.com/u/15024434/d/kernel33.lib
                kernel33.dll :
                http://dl.dropbox.com/u/15024434/d/kernel33.dll

                I've tried to compile using dmd -d kernel32.d
                kernel33.di kernel33.lib but
                it throws errors like
                "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
                I have literally no clue why this is the case, can
                someone help me out or
                look at the files?

                2011/4/27 maarten van damme <maartenvd1994 gmail.com
                <mailto:maartenvd1994 gmail.com>>


                    I'm afraid I've been a little unclear.
                    I've copied kernel32.dll from the windows dir,
                    renamed it to kernel33.dll
                    and generated a .lib from it using implib.
                    Then I've created a d file with a correct
                    dllmain(stolen from examples) and
                    between

                    system(C){
                    export void * exportedfunctionfromkernel33.dll();
                    export void * exportedfunction2fromkernel33.dll();
                    ....
                    }

                    But it looks like you can't both declare a function
                    from another lib and
                    export it at the same time.


            In your kernel33.di, try making it extern (C) export void*
            _hread(); etc. You functions get D mangling otherwise.

            I'd also suggest you to start with a less complex example,
            e.g. export only one function, make sure it works, then add
            the rest.

            If you think your .lib files doesn't do its job, try using
            .def file instead. I find them extremely helpful, and they
            are a lot easier to edit/extend.

            Hope that helps.
May 01 2011
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
I must have completely misunderstood what you want to do. What do you 
want to build from kernel33.def? Isn't kernel33.dll the original DLL 
that you want to intercept by replacing it with the compiled DLL?

maarten van damme wrote:
 Great, now the error in kernel32.def is resolved but it gets the same 
 problem in kernel33.def.
 here is the start of the exports from kernel33.def:
 EXPORTS
 _hread  1334
 how can I change this to resolve that?
 
 2011/5/1 Rainer Schuetze <r.sagitario gmx.de <mailto:r.sagitario gmx.de>>
 
     It seems you have hit another of those dreaded optlink bugs.
 
     With less symbols, it works if you declare the imports like this
     (because of the described name mangling):
 
     IMPORTS
            _imported_hread 0 =  kernel33._hread
 
     2 more notes:
     - you don't need to import kernel33.di
     - you should not use "SINGLE" in the DATA statement of the def file,
     it will share the memory across processes.
 
 
 
     maarten van damme wrote:
 
         Number overflow?
         So I implemented the suggested changes (you can check them out
         at http://dl.dropbox.com/u/15024434/version2.zip)
 
         But now I get when I compile it : "kernel32.def(738) : Error 12:
         Number Overflow: (strange symbol over here)"
 
         I do agree I should've picked a simpler example but I think the
         statisfaction will be even bigger if I were to succeed :p
 
         2011/5/1 maarten van damme <maartenvd1994 gmail.com
         <mailto:maartenvd1994 gmail.com> <mailto:maartenvd1994 gmail.com
         <mailto:maartenvd1994 gmail.com>>>
 
 
            Wow, thanks for the help
            The first thing I did was in the .di file adding
         extern(windows){ .... }
            and now compiling doesn't give errors and when examining with
         dllexp
            I can see that it exports the same functions as the real
         kernel32.dll :D
 
            Now I'm going to implement all other suggested changes,
         thanks a lot
 
 
            2011/4/30 Rainer Schuetze <r.sagitario gmx.de
         <mailto:r.sagitario gmx.de>
            <mailto:r.sagitario gmx.de <mailto:r.sagitario gmx.de>>>
 
 
                I'm not sure your wrapping will work with kernel32.dll,
         but in
                general here are a few tips:
 
                - most functions in the windows API use the __stdcall calling
                convention in C/C++, which translates to D as
         "extern(Windows)"
 
                - this will usually add the number of bytes passed on the
         stack
                as a " NN" postfix to the function name. This postfix
         does not
                exist in kernel32.dll, but in the import library kernel32.lib
                that you find in the dmd lib folder. Maybe you can use the
                standard import library, or use the translation shown below..
 
                - as the exported function and the function you want to
         chain to
                have identical names, you have to change at least one of
         these
                and modify them in some build step. I'd suggest to do this in
                the def file:
 
                The symbols in the d-source file containing:
 
                ----
                extern(Windows) HANDLE imported_GetCurrentProcess();
 
                export extern(Windows) HANDLE internal_GetCurrentProcess()
                {
                 return imported_GetCurrentProcess();
                }
                ----
 
                can be mapped to other symbols in the def file:
 
                ----
                EXPORTS
                 GetCurrentProcess = internal_GetCurrentProcess
 
                IMPORTS
                 imported_GetCurrentProcess = kernel33.GetCurrentProcess
                ----
 
                - if you don't know the number of arguments, you should
         not call
                the wrapped function, as this will change the callstack.
                Instead, you should just jump to it:
 
                void internal_hread()
                {
                 asm
                 {
                   naked;
                   jmp imported_hread;
                 }
                }
 
                I haven't tried all that, though, so there might be some
         mistakes...
 
                Rainer
 
 
 
                Denis Koroskin wrote:
 
                    On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme
                    <maartenvd1994 gmail.com
         <mailto:maartenvd1994 gmail.com> <mailto:maartenvd1994 gmail.com
         <mailto:maartenvd1994 gmail.com>>>
 
                    wrote:
 
                        I've changed this, I think I'm still kinda
         confused with
                        lib files. They've
                        told me you can't do something with them without
         a .di file
                        So I went ahead and made a kernel33.di file.. I now
                        import it in kernel32.d
                        and my declaration is
                        System(C){
                        export void * exportedfunctionblablabal(){
                          return exportedfunctionblablablal();
                        }
                        ....
                        }
 
                        The file in the directory are:
                        kernel32.d :
         http://dl.dropbox.com/u/15024434/d/kernel32.d
                        kernel33.di :
         http://dl.dropbox.com/u/15024434/d/kernel33.di
                        kernel33.lib :
                        http://dl.dropbox.com/u/15024434/d/kernel33.lib
                        kernel33.dll :
                        http://dl.dropbox.com/u/15024434/d/kernel33.dll
 
                        I've tried to compile using dmd -d kernel32.d
                        kernel33.di kernel33.lib but
                        it throws errors like
                        "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
                        I have literally no clue why this is the case, can
                        someone help me out or
                        look at the files?
 
                        2011/4/27 maarten van damme
         <maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>
                        <mailto:maartenvd1994 gmail.com
         <mailto:maartenvd1994 gmail.com>>>
 
 
                            I'm afraid I've been a little unclear.
                            I've copied kernel32.dll from the windows dir,
                            renamed it to kernel33.dll
                            and generated a .lib from it using implib.
                            Then I've created a d file with a correct
                            dllmain(stolen from examples) and
                            between
 
                            system(C){
                            export void * exportedfunctionfromkernel33.dll();
                            export void *
         exportedfunction2fromkernel33.dll();
                            ....
                            }
 
                            But it looks like you can't both declare a
         function
                            from another lib and
                            export it at the same time.
 
 
                    In your kernel33.di, try making it extern (C) export
         void*
                    _hread(); etc. You functions get D mangling otherwise.
 
                    I'd also suggest you to start with a less complex
         example,
                    e.g. export only one function, make sure it works,
         then add
                    the rest.
 
                    If you think your .lib files doesn't do its job, try
         using
                    .def file instead. I find them extremely helpful, and
         they
                    are a lot easier to edit/extend.
 
                    Hope that helps.
 
 
 
 
May 01 2011
next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
Yes, and i have a kernel32.def for my .d file and a kernel33.def for the
original kernel dll. Your not confused, I am. I thought i needed kerel33.def
so i could acces the dll from d, isnt this the case?
Op 1-mei-2011 22:10 schreef "Rainer Schuetze" <r.sagitario gmx.de> het
volgende:
 I must have completely misunderstood what you want to do. What do you
 want to build from kernel33.def? Isn't kernel33.dll the original DLL
 that you want to intercept by replacing it with the compiled DLL?

 maarten van damme wrote:
 Great, now the error in kernel32.def is resolved but it gets the same
 problem in kernel33.def.
 here is the start of the exports from kernel33.def:
 EXPORTS
 _hread  1334
 how can I change this to resolve that?

 2011/5/1 Rainer Schuetze <r.sagitario gmx.de <mailto:r.sagitario gmx.de>>

 It seems you have hit another of those dreaded optlink bugs.

 With less symbols, it works if you declare the imports like this
 (because of the described name mangling):

 IMPORTS
 _imported_hread 0 = kernel33._hread

 2 more notes:
 - you don't need to import kernel33.di
 - you should not use "SINGLE" in the DATA statement of the def file,
 it will share the memory across processes.



 maarten van damme wrote:

 Number overflow?
 So I implemented the suggested changes (you can check them out
 at http://dl.dropbox.com/u/15024434/version2.zip)

 But now I get when I compile it : "kernel32.def(738) : Error 12:
 Number Overflow: (strange symbol over here)"

 I do agree I should've picked a simpler example but I think the
 statisfaction will be even bigger if I were to succeed :p

 2011/5/1 maarten van damme <maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com> <mailto:maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com>>>


 Wow, thanks for the help
 The first thing I did was in the .di file adding
 extern(windows){ .... }
 and now compiling doesn't give errors and when examining with
 dllexp
 I can see that it exports the same functions as the real
 kernel32.dll :D

 Now I'm going to implement all other suggested changes,
 thanks a lot


 2011/4/30 Rainer Schuetze <r.sagitario gmx.de
 <mailto:r.sagitario gmx.de>
 <mailto:r.sagitario gmx.de <mailto:r.sagitario gmx.de>>>


 I'm not sure your wrapping will work with kernel32.dll,
 but in
 general here are a few tips:

 - most functions in the windows API use the __stdcall calling
 convention in C/C++, which translates to D as
 "extern(Windows)"

 - this will usually add the number of bytes passed on the
 stack
 as a " NN" postfix to the function name. This postfix
 does not
 exist in kernel32.dll, but in the import library kernel32.lib
 that you find in the dmd lib folder. Maybe you can use the
 standard import library, or use the translation shown below..

 - as the exported function and the function you want to
 chain to
 have identical names, you have to change at least one of
 these
 and modify them in some build step. I'd suggest to do this in
 the def file:

 The symbols in the d-source file containing:

 ----
 extern(Windows) HANDLE imported_GetCurrentProcess();

 export extern(Windows) HANDLE internal_GetCurrentProcess()
 {
 return imported_GetCurrentProcess();
 }
 ----

 can be mapped to other symbols in the def file:

 ----
 EXPORTS
 GetCurrentProcess = internal_GetCurrentProcess

 IMPORTS
 imported_GetCurrentProcess = kernel33.GetCurrentProcess
 ----

 - if you don't know the number of arguments, you should
 not call
 the wrapped function, as this will change the callstack.
 Instead, you should just jump to it:

 void internal_hread()
 {
 asm
 {
 naked;
 jmp imported_hread;
 }
 }

 I haven't tried all that, though, so there might be some
 mistakes...

 Rainer



 Denis Koroskin wrote:

 On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme
 <maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com> <mailto:maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com>>>

 wrote:

 I've changed this, I think I'm still kinda
 confused with
 lib files. They've
 told me you can't do something with them without
 a .di file
 So I went ahead and made a kernel33.di file.. I now
 import it in kernel32.d
 and my declaration is
 System(C){
 export void * exportedfunctionblablabal(){
 return exportedfunctionblablablal();
 }
 ....
 }

 The file in the directory are:
 kernel32.d :
 http://dl.dropbox.com/u/15024434/d/kernel32.d
 kernel33.di :
 http://dl.dropbox.com/u/15024434/d/kernel33.di
 kernel33.lib :
 http://dl.dropbox.com/u/15024434/d/kernel33.lib
 kernel33.dll :
 http://dl.dropbox.com/u/15024434/d/kernel33.dll

 I've tried to compile using dmd -d kernel32.d
 kernel33.di kernel33.lib but
 it throws errors like
 "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
 I have literally no clue why this is the case, can
 someone help me out or
 look at the files?

 2011/4/27 maarten van damme
 <maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>
 <mailto:maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com>>>


 I'm afraid I've been a little unclear.
 I've copied kernel32.dll from the windows dir,
 renamed it to kernel33.dll
 and generated a .lib from it using implib.
 Then I've created a d file with a correct
 dllmain(stolen from examples) and
 between

 system(C){
 export void * exportedfunctionfromkernel33.dll();
 export void *
 exportedfunction2fromkernel33.dll();
 ....
 }

 But it looks like you can't both declare a
 function
 from another lib and
 export it at the same time.


 In your kernel33.di, try making it extern (C) export
 void*
 _hread(); etc. You functions get D mangling otherwise.

 I'd also suggest you to start with a less complex
 example,
 e.g. export only one function, make sure it works,
 then add
 the rest.

 If you think your .lib files doesn't do its job, try
 using
 .def file instead. I find them extremely helpful, and
 they
 are a lot easier to edit/extend.

 Hope that helps.
May 01 2011
prev sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
To avoid any confusing on my end, the files I need are
kernel33.dll (original kernel32.dll)
kernel33.def (So d can acces those functions)
kernel32.def (renaming happens over here, contains a list of all
import-exported functions)
kernel32.d (the code)

kernel33.def can be seen as a substitute for the import libary generated by
implib?
and when you have an import library you also need a .di file to acces the
contents?

the compile commands are
dmd -d kernel32 kernel32.def kernel33.def
dmd -d kernel32.obj kernel32.def

Tomorow I can show the files (can't acces them from this laptop)
and I'll post some snipets from the .def files ?

Can someone correct me? I'm finding d promising as language but some things
seem to be overly complicated to me (I'm a java guy, you have .java for
source, .class compiled and .jar packaged Seems way simpler xd).


really apreciating your info here :D
2011/5/1 maarten van damme <maartenvd1994 gmail.com>

 Yes, and i have a kernel32.def for my .d file and a kernel33.def for the
 original kernel dll. Your not confused, I am. I thought i needed kerel33.def
 so i could acces the dll from d, isnt this the case?
 Op 1-mei-2011 22:10 schreef "Rainer Schuetze" <r.sagitario gmx.de> het
 volgende:

 I must have completely misunderstood what you want to do. What do you
 want to build from kernel33.def? Isn't kernel33.dll the original DLL
 that you want to intercept by replacing it with the compiled DLL?

 maarten van damme wrote:
 Great, now the error in kernel32.def is resolved but it gets the same
 problem in kernel33.def.
 here is the start of the exports from kernel33.def:
 EXPORTS
 _hread  1334
 how can I change this to resolve that?

 2011/5/1 Rainer Schuetze <r.sagitario gmx.de <mailto:r.sagitario gmx.de


 It seems you have hit another of those dreaded optlink bugs.

 With less symbols, it works if you declare the imports like this
 (because of the described name mangling):

 IMPORTS
 _imported_hread 0 = kernel33._hread

 2 more notes:
 - you don't need to import kernel33.di
 - you should not use "SINGLE" in the DATA statement of the def file,
 it will share the memory across processes.



 maarten van damme wrote:

 Number overflow?
 So I implemented the suggested changes (you can check them out
 at http://dl.dropbox.com/u/15024434/version2.zip)

 But now I get when I compile it : "kernel32.def(738) : Error 12:
 Number Overflow: (strange symbol over here)"

 I do agree I should've picked a simpler example but I think the
 statisfaction will be even bigger if I were to succeed :p

 2011/5/1 maarten van damme <maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com> <mailto:maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com>>>


 Wow, thanks for the help
 The first thing I did was in the .di file adding
 extern(windows){ .... }
 and now compiling doesn't give errors and when examining with
 dllexp
 I can see that it exports the same functions as the real
 kernel32.dll :D

 Now I'm going to implement all other suggested changes,
 thanks a lot


 2011/4/30 Rainer Schuetze <r.sagitario gmx.de
 <mailto:r.sagitario gmx.de>
 <mailto:r.sagitario gmx.de <mailto:r.sagitario gmx.de>>>


 I'm not sure your wrapping will work with kernel32.dll,
 but in
 general here are a few tips:

 - most functions in the windows API use the __stdcall calling
 convention in C/C++, which translates to D as
 "extern(Windows)"

 - this will usually add the number of bytes passed on the
 stack
 as a " NN" postfix to the function name. This postfix
 does not
 exist in kernel32.dll, but in the import library kernel32.lib
 that you find in the dmd lib folder. Maybe you can use the
 standard import library, or use the translation shown below..

 - as the exported function and the function you want to
 chain to
 have identical names, you have to change at least one of
 these
 and modify them in some build step. I'd suggest to do this in
 the def file:

 The symbols in the d-source file containing:

 ----
 extern(Windows) HANDLE imported_GetCurrentProcess();

 export extern(Windows) HANDLE internal_GetCurrentProcess()
 {
 return imported_GetCurrentProcess();
 }
 ----

 can be mapped to other symbols in the def file:

 ----
 EXPORTS
 GetCurrentProcess = internal_GetCurrentProcess

 IMPORTS
 imported_GetCurrentProcess = kernel33.GetCurrentProcess
 ----

 - if you don't know the number of arguments, you should
 not call
 the wrapped function, as this will change the callstack.
 Instead, you should just jump to it:

 void internal_hread()
 {
 asm
 {
 naked;
 jmp imported_hread;
 }
 }

 I haven't tried all that, though, so there might be some
 mistakes...

 Rainer



 Denis Koroskin wrote:

 On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme
 <maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com> <mailto:maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com>>>

 wrote:

 I've changed this, I think I'm still kinda
 confused with
 lib files. They've
 told me you can't do something with them without
 a .di file
 So I went ahead and made a kernel33.di file.. I now
 import it in kernel32.d
 and my declaration is
 System(C){
 export void * exportedfunctionblablabal(){
 return exportedfunctionblablablal();
 }
 ....
 }

 The file in the directory are:
 kernel32.d :
 http://dl.dropbox.com/u/15024434/d/kernel32.d
 kernel33.di :
 http://dl.dropbox.com/u/15024434/d/kernel33.di
 kernel33.lib :
 http://dl.dropbox.com/u/15024434/d/kernel33.lib
 kernel33.dll :
 http://dl.dropbox.com/u/15024434/d/kernel33.dll

 I've tried to compile using dmd -d kernel32.d
 kernel33.di kernel33.lib but
 it throws errors like
 "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
 I have literally no clue why this is the case, can
 someone help me out or
 look at the files?

 2011/4/27 maarten van damme
 <maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>
 <mailto:maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com>>>


 I'm afraid I've been a little unclear.
 I've copied kernel32.dll from the windows dir,
 renamed it to kernel33.dll
 and generated a .lib from it using implib.
 Then I've created a d file with a correct
 dllmain(stolen from examples) and
 between

 system(C){
 export void * exportedfunctionfromkernel33.dll();
 export void *
 exportedfunction2fromkernel33.dll();
 ....
 }

 But it looks like you can't both declare a
 function
 from another lib and
 export it at the same time.


 In your kernel33.di, try making it extern (C) export
 void*
 _hread(); etc. You functions get D mangling otherwise.

 I'd also suggest you to start with a less complex
 example,
 e.g. export only one function, make sure it works,
 then add
 the rest.

 If you think your .lib files doesn't do its job, try
 using
 .def file instead. I find them extremely helpful, and
 they
 are a lot easier to edit/extend.

 Hope that helps.
May 01 2011
parent Rainer Schuetze <r.sagitario gmx.de> writes:
If you are coming from java, you are probalby used to the ideal world of 
VM programming, where everything is abstracted away from the actual 
platform you are running on.

What you are trying to do with replacing kernel32.dll pokes around in 
very lowlevel Windows specific implementation details. The complications 
are not introduced by the language, but by the DLL file layout and the 
tools available to deal with it. I have no experience using java, but I 
don't think you'll be able to do something similar with it. Even with 
C/C++, it's almost impossible without inline assembler and similar 
linker support as with D.

Coming back to your wrapper DLL, compilation should work (with symbols 
restricted to those actual needed to avoid the recent bug) with

dmd kernel32.d kernel32.def

The generated kernel32.dll is good enough to replace the original DLL 
(if it has not been loaded from the windows directory before the 
implicite DLL loading takes place). As soon as it is loaded, its' import 
dependencies will automatically load kernel33.dll. No other build steps 
required.


maarten van damme wrote:
 To avoid any confusing on my end, the files I need are
 kernel33.dll (original kernel32.dll)
 kernel33.def (So d can acces those functions)
 kernel32.def (renaming happens over here, contains a list of all 
 import-exported functions)
 kernel32.d (the code)
 
 kernel33.def can be seen as a substitute for the import libary generated 
 by implib?
 and when you have an import library you also need a .di file to acces 
 the contents?
 
 the compile commands are
 dmd -d kernel32 kernel32.def kernel33.def
 dmd -d kernel32.obj kernel32.def
 
 Tomorow I can show the files (can't acces them from this laptop)
 and I'll post some snipets from the .def files ?
 
 Can someone correct me? I'm finding d promising as language but some 
 things seem to be overly complicated to me (I'm a java guy, you have 
 .java for source, .class compiled and .jar packaged Seems way simpler xd).
 
 
 really apreciating your info here :D
 2011/5/1 maarten van damme <maartenvd1994 gmail.com 
 <mailto:maartenvd1994 gmail.com>>
 
     Yes, and i have a kernel32.def for my .d file and a kernel33.def for
     the original kernel dll. Your not confused, I am. I thought i needed
     kerel33.def so i could acces the dll from d, isnt this the case?
 
     Op 1-mei-2011 22:10 schreef "Rainer Schuetze" <r.sagitario gmx.de
     <mailto:r.sagitario gmx.de>> het volgende:
 
      > I must have completely misunderstood what you want to do. What do
     you
      > want to build from kernel33.def? Isn't kernel33.dll the original DLL
      > that you want to intercept by replacing it with the compiled DLL?
      >
      > maarten van damme wrote:
      >> Great, now the error in kernel32.def is resolved but it gets the
     same
      >> problem in kernel33.def.
      >> here is the start of the exports from kernel33.def:
      >> EXPORTS
      >> _hread  1334
      >> how can I change this to resolve that?
      >>
      >> 2011/5/1 Rainer Schuetze <r.sagitario gmx.de
     <mailto:r.sagitario gmx.de> <mailto:r.sagitario gmx.de
     <mailto:r.sagitario gmx.de>>>
      >>
      >> It seems you have hit another of those dreaded optlink bugs.
      >>
      >> With less symbols, it works if you declare the imports like this
      >> (because of the described name mangling):
      >>
      >> IMPORTS
      >> _imported_hread 0 = kernel33._hread
      >>
      >> 2 more notes:
      >> - you don't need to import kernel33.di
      >> - you should not use "SINGLE" in the DATA statement of the def file,
      >> it will share the memory across processes.
      >>
      >>
      >>
      >> maarten van damme wrote:
      >>
      >> Number overflow?
      >> So I implemented the suggested changes (you can check them out
      >> at http://dl.dropbox.com/u/15024434/version2.zip)
      >>
      >> But now I get when I compile it : "kernel32.def(738) : Error 12:
      >> Number Overflow: (strange symbol over here)"
      >>
      >> I do agree I should've picked a simpler example but I think the
      >> statisfaction will be even bigger if I were to succeed :p
      >>
      >> 2011/5/1 maarten van damme <maartenvd1994 gmail.com
     <mailto:maartenvd1994 gmail.com>
      >> <mailto:maartenvd1994 gmail.com
     <mailto:maartenvd1994 gmail.com>> <mailto:maartenvd1994 gmail.com
     <mailto:maartenvd1994 gmail.com>
      >> <mailto:maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>>>>
      >>
      >>
      >> Wow, thanks for the help
      >> The first thing I did was in the .di file adding
      >> extern(windows){ .... }
      >> and now compiling doesn't give errors and when examining with
      >> dllexp
      >> I can see that it exports the same functions as the real
      >> kernel32.dll :D
      >>
      >> Now I'm going to implement all other suggested changes,
      >> thanks a lot
      >>
      >>
      >> 2011/4/30 Rainer Schuetze <r.sagitario gmx.de
     <mailto:r.sagitario gmx.de>
      >> <mailto:r.sagitario gmx.de <mailto:r.sagitario gmx.de>>
      >> <mailto:r.sagitario gmx.de <mailto:r.sagitario gmx.de>
     <mailto:r.sagitario gmx.de <mailto:r.sagitario gmx.de>>>>
      >>
      >>
      >> I'm not sure your wrapping will work with kernel32.dll,
      >> but in
      >> general here are a few tips:
      >>
      >> - most functions in the windows API use the __stdcall calling
      >> convention in C/C++, which translates to D as
      >> "extern(Windows)"
      >>
      >> - this will usually add the number of bytes passed on the
      >> stack
      >> as a " NN" postfix to the function name. This postfix
      >> does not
      >> exist in kernel32.dll, but in the import library kernel32.lib
      >> that you find in the dmd lib folder. Maybe you can use the
      >> standard import library, or use the translation shown below..
      >>
      >> - as the exported function and the function you want to
      >> chain to
      >> have identical names, you have to change at least one of
      >> these
      >> and modify them in some build step. I'd suggest to do this in
      >> the def file:
      >>
      >> The symbols in the d-source file containing:
      >>
      >> ----
      >> extern(Windows) HANDLE imported_GetCurrentProcess();
      >>
      >> export extern(Windows) HANDLE internal_GetCurrentProcess()
      >> {
      >> return imported_GetCurrentProcess();
      >> }
      >> ----
      >>
      >> can be mapped to other symbols in the def file:
      >>
      >> ----
      >> EXPORTS
      >> GetCurrentProcess = internal_GetCurrentProcess
      >>
      >> IMPORTS
      >> imported_GetCurrentProcess = kernel33.GetCurrentProcess
      >> ----
      >>
      >> - if you don't know the number of arguments, you should
      >> not call
      >> the wrapped function, as this will change the callstack.
      >> Instead, you should just jump to it:
      >>
      >> void internal_hread()
      >> {
      >> asm
      >> {
      >> naked;
      >> jmp imported_hread;
      >> }
      >> }
      >>
      >> I haven't tried all that, though, so there might be some
      >> mistakes...
      >>
      >> Rainer
      >>
      >>
      >>
      >> Denis Koroskin wrote:
      >>
      >> On Sat, 30 Apr 2011 13:47:53 +0400, maarten van damme
      >> <maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>
      >> <mailto:maartenvd1994 gmail.com
     <mailto:maartenvd1994 gmail.com>> <mailto:maartenvd1994 gmail.com
     <mailto:maartenvd1994 gmail.com>
      >> <mailto:maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>>>>
      >>
      >> wrote:
      >>
      >> I've changed this, I think I'm still kinda
      >> confused with
      >> lib files.. They've
      >> told me you can't do something with them without
      >> a .di file
      >> So I went ahead and made a kernel33.di file.. I now
      >> import it in kernel32.d
      >> and my declaration is
      >> System(C){
      >> export void * exportedfunctionblablabal(){
      >> return exportedfunctionblablablal();
      >> }
      >> ....
      >> }
      >>
      >> The file in the directory are:
      >> kernel32.d :
      >> http://dl..dropbox.com/u/15024434/d/kernel32.d
     <http://dl.dropbox.com/u/15024434/d/kernel32.d>
      >> kernel33.di :
      >> http://dl.dropbox.com/u/15024434/d/kernel33.di
      >> kernel33.lib :
      >> http://dl.dropbox.com/u/15024434/d/kernel33.lib
      >> kernel33.dll :
      >> http://dl.dropbox.com/u/15024434/d/kernel33.dll
      >>
      >> I've tried to compile using dmd -d kernel32.d
      >> kernel33.di kernel33.lib but
      >> it throws errors like
      >> "Error 42: Symbol undifined _Dkernel1336_hreadfzpV"
      >> I have literally no clue why this is the case, can
      >> someone help me out or
      >> look at the files?
      >>
      >> 2011/4/27 maarten van damme
      >> <maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>
     <mailto:maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>>
      >> <mailto:maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>
      >> <mailto:maartenvd1994 gmail.com <mailto:maartenvd1994 gmail.com>>>>
      >>
      >>
      >> I'm afraid I've been a little unclear.
      >> I've copied kernel32.dll from the windows dir,
      >> renamed it to kernel33.dll
      >> and generated a .lib from it using implib.
      >> Then I've created a d file with a correct
      >> dllmain(stolen from examples) and
      >> between
      >>
      >> system(C){
      >> export void * exportedfunctionfromkernel33.dll();
      >> export void *
      >> exportedfunction2fromkernel33.dll();
      >> ....
      >> }
      >>
      >> But it looks like you can't both declare a
      >> function
      >> from another lib and
      >> export it at the same time.
      >>
      >>
      >> In your kernel33.di, try making it extern (C) export
      >> void*
      >> _hread(); etc. You functions get D mangling otherwise.
      >>
      >> I'd also suggest you to start with a less complex
      >> example,
      >> e.g. export only one function, make sure it works,
      >> then add
      >> the rest.
      >>
      >> If you think your .lib files doesn't do its job, try
      >> using
      >> .def file instead. I find them extremely helpful, and
      >> they
      >> are a lot easier to edit/extend.
      >>
      >> Hope that helps.
      >>
      >>
      >>
      >>
 
 
May 02 2011