G'day all,
I'm using wine in a small control system to run a gui win32 program. I had an idea that I could determine what dll's this program used and only including the wine.dll.so files that were required to run this program.
I started by doing a strings on the .exe file and using that to determine which .dlls it referenced. I thought I could use the same process to determine which dll's were then referenced by the dll's the .exe pulled in. Plus including the core dll's by default.
Am I missing something, or will this work ?
I'm in the process of developing a batch file to do it for me, is there a more accurate way of determining which dll's a dll references than doing a text search for dll names in the binary?
Am I wrong, or are you wanting to run a windows program without wine ? This obviously wont work.
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight Spam ! EuroCauce: http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Sylvain Petreolle wrote:
Am I wrong, or are you wanting to run a windows program without wine ? This obviously wont work.
You misunderstand me. What I'm trying to do is see how many wine.dll.so files I can leave off the flash drive and still have the application fully functional. For example, I'm not using any sound/multimedia for this system, so it would be nice to be able to delete that functionality.
I want to see what dll's my .exe file imports, and only include the required files onto the flash drive. At the moment, I do a full wine install and run with that (Well, I remove all .def files, .exe.so files and strip the libs and executables to get the size down) My current tar-gzipped wine install is down to 3.8MB linked against libc6 and a cut down Xfree 4.2.1. If I can leave out some of the .dll.so files that never get referenced then I can get it down smaller.
On Fri, 14 Mar 2003, Brad Campbell wrote: [...]
Am I missing something, or will this work ?
A better way is to run your application with '--debumsg +loaddll'. This will generate a log enumerating all the libraries that your application loads (and also tell you whether it's using the native or builtin version).
Alternately, you can use 'tools/winedump/winedump dump -j imports' on your executable and recursively on each library. But it's more work (however you can use this method on applications that don't work on Wine yet, not your case I guess).
Francois Gouget wrote:
On Fri, 14 Mar 2003, Brad Campbell wrote: [...]
Am I missing something, or will this work ?
A better way is to run your application with '--debumsg +loaddll'. This will generate a log enumerating all the libraries that your application loads (and also tell you whether it's using the native or builtin version).
Alternately, you can use 'tools/winedump/winedump dump -j imports' on your executable and recursively on each library. But it's more work (however you can use this method on applications that don't work on Wine yet, not your case I guess).
I actually do all my application testing on wine to make sure they work flawlessly on both wine and windows. I'm using Delphi, so building with winelib is not an option for me.
I'm not using any native dll's at all. Winedump produces a nice import table for my exe file, but running winedump on the native wine dll files fails miserably.
I might try the --debugmsg +loaddll but I would prefer a static method. I guess I could look into the source tree and parse the IMPORTS and DELAYIMPORTS from each dll makefile, and build a static list from that.
Thanks for the help :p)
"Brad Campbell" brad@seme.com.au wrote:
I might try the --debugmsg +loaddll but I would prefer a static method. I guess I could look into the source tree and parse the IMPORTS and DELAYIMPORTS from each dll makefile, and build a static list from that.
If nothing else helps try www.dependencywalker.com then...
On Fri, 14 Mar 2003, Brad Campbell wrote: [...]
I actually do all my application testing on wine to make sure they work flawlessly on both wine and windows. I'm using Delphi, so building with winelib is not an option for me.
You don't need to build Winelib applications for any of the methods I proposed. Here is how to find out which dlls winword loads:
wine --debugmsg +loaddll winword.exe
If you prefer to do static analysis then winedump will do what you want. But loaddll will give you more accurate results because it will catch all those LoadLibrary too.
I'm not using any native dll's at all. Winedump produces a nice import table for my exe file, but running winedump on the native wine dll files fails miserably.
It shouldn't.
I might try the --debugmsg +loaddll but I would prefer a static method. I guess I could look into the source tree and parse the IMPORTS and DELAYIMPORTS from each dll makefile, and build a static list from that.
In both cases you end up with a file containing the information you want so, i.e. a static list you can massage any way you like.
Francois Gouget wrote:
I'm not using any native dll's at all. Winedump produces a nice import table for my exe file, but running winedump on the native wine dll files fails miserably.
It shouldn't.
Does that point to an error in winedump then?
bklaptop:/usr/src/cvs/wine/tools/winedump>./winedump dump -j /usr/local/wine/lib/wine/advapi32.dll.so No known main signature (E/457f), aborting
I even did a wine install with all debugging compiled in and unstripped.
On Mon, 17 Mar 2003, Brad Campbell wrote:
Francois Gouget wrote:
I'm not using any native dll's at all. Winedump produces a nice import table for my exe file, but running winedump on the native wine dll files fails miserably.
It shouldn't.
Does that point to an error in winedump then?
Oh, sorry. 'native' threw me off, you meant 'builtin wine dll files'. Yeah, I believe winedump only supports the PE format, i.e. native windows dlls.
bklaptop:/usr/src/cvs/wine/tools/winedump>./winedump dump -j /usr/local/wine/lib/wine/advapi32.dll.so No known main signature (E/457f), aborting
Seems you're missing 'imports' after the '-j', not that it would make a big difference.
Francois Gouget wrote:
On Mon, 17 Mar 2003, Brad Campbell wrote:
bklaptop:/usr/src/cvs/wine/tools/winedump>./winedump dump -j /usr/local/wine/lib/wine/advapi32.dll.so No known main signature (E/457f), aborting
Seems you're missing 'imports' after the '-j', not that it would make a big difference.
Yeah, I typed it by hand and missed that bit. It's hard to cut'n'paste from an xterm on one machine to Mozilla on another :p)
Ok, I'll run with the --debugmsg idea. That does give me what I'm after but is a bit harder to automate. Thanks for the help.
-
Brad Campbell -
Dmitry Timoshkov -
Francois Gouget -
Sylvain Petreolle