Convert EXE code to DLL in Visual c++???
Delali Dzirasa
program. I have routines that I want to call in VB but the current code is
in a executable format. How would I go about changing it. I am not sure
whether to use the DLL app wizzard or a simple DLL project in order to make
the conversion.
I have all of the current source code and am compiling with Visual C++ 6.0.
I have never created a DLL before, so I have no idea where to begin.....I
know the functions that I want included in the DLL, but how to declare them,
I am not sure. I tried starting a new project as a DLL proj, and just
adding all of the current exe code but it would't compile.....any
suggestions would very benificial, as I said I have never done this before,
and am not even sure if I am headed in the correct direction.
Delali
Jonathan Clark
1. Rename filename.exe to filename.dll
2. Finished!
Haha, actually you can just load an EXE directly through LoadLibrary if you
like. Some points to watch out for:
- If you have any global constructors they won't be called.
- Any thread local storage will not work (__declspec(thread))
- I have not tested this on all windows platforms, but there is no technical
reason why it wouldn't work on 95->XP
EXE and DLL use the same file format except their entry procedures are
different. Windows will not call the entry function of an EXE if it's
loaded as a DLL (which is why your global constructors won't be called). To
fix this you need to relink as a DLL and also provide a DllMain.
Jonathan
"Delali Dzirasa" <Delali....@jhuapl.edu> wrote in message
news:aenncl$4b8$1...@houston.jhuapl.edu...
Tim Robinson
| EXE and DLL use the same file format except their entry procedures are
| different. Windows will not call the entry function of an EXE if it's
| loaded as a DLL (which is why your global constructors won't be
| called). To fix this you need to relink as a DLL and also provide a
| DllMain.
You'll have to relocate the EXE or it will crash with the EXE that uses it.
Some linkers omit relocation information for EXEs (making the very
reasonable assumption that they won't clash with anything else in memory),
so relocation will be impossible for these executables. Of the EXEs I found
in my %SystemRoot%\System32 directory, only a few had .reloc sections,
implying that only they could be relocated.
The only difference between EXEs and DLLs is a few bits set in the headers
which determine whether Windows will call the entry point as an EXE
(WinMain) or as a DLL (DllMain).
--
Tim Robinson
http://www.themoebius.org.uk/
Jonathan Clark
Yes, I forgot to mention that an EXE should have a base address that won't
clash with the process that is loading it. It does not necessarily need to
have relocation information but that will definately help. I'd say more
than 50% of EXEs in wild have relocation information, though many shipped
with windows don't. It used to be default on with Visual C++, but now I
believe it is default off. I have run across some EXEs with relocation
information that fail to execute properly when loaded at a different base
address because of bugs in the executable compressor they were compressed
with.
What part of the UK are you in?
Jonathan
http://jonathanclark.com
"Tim Robinson" <timothy.rem...@ic.ac.uk> wrote in message
news:aesprl$9o22v$1...@ID-103400.news.dfncis.de...
Tim Robinson
| Yes, I forgot to mention that an EXE should have a base address that
| won't clash with the process that is loading it. It does not
| necessarily need to have relocation information but that will
| definately help.
How can an image be relocated if it doesn't have a relocation table?
Granted, the absence of a .reloc section doesn't necessarily mean that
relocations aren't there (the linker could have put them in another
section), but without a list of relocations, all the global variable
addresses to which the EXE refers will be wrong. The loader can relocate the
internal structure of the EXE (because all addresses -- RVAs -- are relative
to the base address) but not the code itself.
| I'd say more than 50% of EXEs in wild have
| relocation information, though many shipped with windows don't. It
| used to be default on with Visual C++, but now I believe it is
| default off.
Hmm, I haven't looked too closely, but a random EXE of my own (which uses
default Microsoft linker settings) has relocations in debug mode but not
release mode.
| I have run across some EXEs with relocation information
| that fail to execute properly when loaded at a different base address
| because of bugs in the executable compressor they were compressed
| with.
FWIW, I'd link the compressor to a different base address (say, 0xF00000) to
avoid clashes. Ideally I'd put it just below the other EXE, but this
wouldn't work on Win9x, where the bottom 4MB are mapped strangely.
| What part of the UK are you in?
Currently London, although not for long (I've just finished my degree :) ).
I'll be in Cambridgeshire for the next few months.
Jonathan Clark
> Granted, the absence of a .reloc section doesn't necessarily mean that
> relocations aren't there (the linker could have put them in another
> section), but without a list of relocations, all the global variable
> addresses to which the EXE refers will be wrong. The loader can relocate
the
> internal structure of the EXE (because all addresses -- RVAs -- are
relative
> to the base address) but not the code itself.
You can't relocate without relocation information, but at link time
an image can have any base address you want, default for
LINK.EXE is 0x40000, but you can specify any other address above
that. So you can load 2 EXEs into memory if the memory ranges
they are mapped to don't overlapped. Actually the main EXE has
to have a lower address than the EXE loaded as a library.
> | I have run across some EXEs with relocation information
> | that fail to execute properly when loaded at a different base address
> | because of bugs in the executable compressor they were compressed
> | with.
>
> FWIW, I'd link the compressor to a different base address (say, 0xF00000)
to
> avoid clashes. Ideally I'd put it just below the other EXE, but this
> wouldn't work on Win9x, where the bottom 4MB are mapped strangely.
This is just something I encountered when testing my "OS" on a program
called thumbsplus. So whatever they used, looks like a EXE compressor,
screws up the load when relocated to a different base address.
<0x40000 is reserved on win95 kernels (16 bit application stuff)
<0x10000 is reserved on NT kernels. Not sure why..
Jonathan
Jonathan Clark
http://jonathanclark.com/contact
Tim Robinson
| Tried to send an email, but it failed. My email is at:
|
| http://jonathanclark.com/contact
Mine is at http://mobius.sourceforge.net/documentation/?TimRobinson.
Andy Lutomirski
__declspec(dllexport) or list them in the .def file (if you don't have one,
create one). Then link against the .lib that is produced.
Dynamically linking against EXEs, while _possible_, is generally not a very
good idea. (Big exception: it is often convenient for a plugin DLL specific
to a particular EXE to link back to the EXE for callbacks. That being said,
having the EXE pass the DLL a function pointer table is probably better.)
Andy
"Delali Dzirasa" <Delali....@jhuapl.edu> wrote in message
news:aenncl$4b8$1...@houston.jhuapl.edu...
Delali Dzirasa
and have never compiled/called a DLL before. Could someone please kind of
explain how I would go about step by step...that is if you have the time. I
could send the source code if you would like. Or if you don't do you know
of a good online tutorial for this procedure?
My application is not Dialog based, and the entry point is merely:
int main(int argc, char * argv[])
{
.....
}
so I am not sure were I am supposed to be looking for a WinMain and changing
it to a DLLMain.....
If you could provide some assistance I would really appreciate...I will post
this as well...
Delali
"Andy Lutomirski" <lu...@mailandnews.nospam.com> wrote in message
news:3VqQ8.1401$wD6.3...@news3.news.adelphia.net...
Samuel Bandara
> I wanted to know if anyone had a quick way to convert a EXE
> to a DLL program. I have routines that I want to call in VB
> but the current code is in a executable format. How would I
> go about changing it. I am not sure whether to use the DLL
> app wizzard or a simple DLL project in order to make the
> conversion.
as an alternative to Jonathan's suggestion you can simply
create a "simple DLL project" without anything. Then you
add the files from your EXE project to your DLL project.
Functions you want to export should be redeclared by
a preceding __declspec(dllexport), for example:
__declspec(dllexport) void function(void) { }
Create a file "exports.def" in which you list the functions
you like to export. Do it like this:
LIBRARY DLLNAME
DESCRIPTION "Description"
EXPORTS
FunctionA = FunctionA
FunctionB = FunctionB
FunctionC = FunctionC
...
Erase your winmain function. If you need to do some initia-
lization supply either an init function that you call before
using other functions or you write a DllMain function after
reading the documentation about it.
Samuel
G
initialization/clean up when the process attaches/detaches. The compiler
will add one for you if you don't have one.
-Gary
"Samuel Bandara" <0622475...@t-online.de> wrote in message
news:ah6uf4$en2$02$1...@news.t-online.com...