Native and Builtin dll

Batt212 · Post by **Batt212** » Thu Jul 24, 2008 1:39 pm

I'm studing wine for my thesis but I've an question: if I can use native dll for an application because are there many builtin dll in usr/lib/wine? I understand for system dll like kernel32.dll, user32.dll etc

Thanks.

John Drescher · Post by **John Drescher** » Thu Jul 24, 2008 1:50 pm

On Thu, Jul 24, 2008 at 2:39 PM, Batt212 <[email protected]> wrote:

I'm studing wine for my thesis but I've an question: if I can use native dll for an application because are there many builtin dll in usr/lib/wine? I understand for system dll like kernel32.dll, user32.dll etc

I am not sure I understand the question.

Yes you can use a native dll for a dll that wine provides as a builtin
(well except for a few directx ... ) but it is usually better that you
do not do this.

John

James Mckenzie · Post by **James Mckenzie** » Thu Jul 24, 2008 2:01 pm

Batt212 at Jul 24, 2008 11:39 AM (MST) said about [Wine] Native and Builtin dll

I'm studing wine for my thesis but I've an question: if I can use native dll for an application because are there many builtin dll in usr/lib/wine? I understand for system dll like kernel32.dll, user32.dll etc

You can substitute some of the Wine built-in dlls but you may create additional problems. A well known problem is RichText functionality with the riched20.dll and riched32.dll being incomplete. You may not substitute the system dll's as this MAY violate the EULA from MA and WILL break Wine.

The best way to test whether or not built-in dll substitution is to place the native dll in the program directory and not /windows/system32 and run Winecfg to add the program and then change the dll from built-in only to native then built-in.

This should also be available on the Wine HQ web site FAQ.

Hope this helps with your thesis.

James McKenzie

Batt212 · Post by **Batt212** » Thu Jul 24, 2008 2:09 pm

Ok, I didn't write bad my question. If I've source code for an dll I can produce a builtin dll (with winelib) but if I dot not have it I must use only native dll. For example I copy and paste an exe file into linux enviroment and run it. If it founds its dll it goes otherwise no. Why cannot I take iexplorer.exe and its dlls and run it?

Thanks.

John Drescher · Post by **John Drescher** » Thu Jul 24, 2008 2:28 pm

On Thu, Jul 24, 2008 at 3:09 PM, Batt212 <[email protected]> wrote:

Ok, I didn't write bad my question. If I've source code for an dll I can produce a builtin dll (with winelib) but if I dot not have it I must use only native dll. For example I copy and paste an exe file into linux enviroment and run it. If it founds its dll it goes otherwise no. Why cannot I take iexplorer.exe and its dlls and run it?

Most windows applications need installed to run. IE is one of the
applications. It needs registry entries and some dlls need registered.
And on top of this you can not replace every wine dll with a native
one that will not work.

John

Batt212 · Post by **Batt212** » Thu Jul 24, 2008 2:28 pm

In reply to James Mckenzie, I've understood that if I use free native dll for free application I've no problem but I cannot use no free native dll, ok?
but I didn't understand what you writed: "...run Winecfg to add the program and then change the dll from built-in only to native then built-in."

Thank you.

John Drescher · Post by **John Drescher** » Thu Jul 24, 2008 2:33 pm

On Thu, Jul 24, 2008 at 3:28 PM, Batt212 <[email protected]> wrote:

In reply to James Mckenzie, I've understood that if I use free native dll for free application I've no problem but I cannot use no free native dll, ok?
but I didn't understand what you writed: "...run Winecfg to add the program and then change the dll from built-in only to native then built-in."

run the winecfg program

add your application to the list

select you application

change your .dll to native

John

vitamin · Post by **vitamin** » Thu Jul 24, 2008 2:44 pm

Batt212 wrote:Ok, I didn't write bad my question. If I've source code for an dll I can produce a builtin dll (with winelib)

Not correct. Wine built-in dlls are those dlls that are part of Wine itself. Everything else is a native DLL.

Batt212 wrote:but if I dot not have it I must use only native dll.

If Wine doesn't have such dll, then yes you have to use native dll instead.

Batt212 wrote:For example I copy and paste an exe file into linux enviroment and run it.

Not correct. You don't copy anything. Most programs have to be properly installed with their installer. This is true even on windows.

Batt212 wrote: Why cannot I take iexplorer.exe and its dlls and run it?

This is special case. IE is a part of the system and depends on big number of undocumented functions. And to run it you have to replace big parts of Wine. This is strongly discouraged. Especially in this case, since Wine has it's own IE replacement.

James Mckenzie · Post by **James Mckenzie** » Thu Jul 24, 2008 2:56 pm

Vitally:

Good explanation. Is this not covered in a FAQ on the Wine HQ site?

James McKenzie

vitamin on Jul 24, 2008 12:44 PM (MST) wrote about Native and Builtin dll:

Batt212 wrote:
Ok, I didn't write bad my question. If I've source code for an dll I can produce a builtin dll (with winelib)
Not correct. Wine built-in dlls are those dlls that are part of Wine itself. Everything else is a native DLL.

This should also be expanded to state:

Any dll that is a part of the Wine package is a built-in dll. Substitution with a dll that is part of any Windows distribution is considered a native replacement. Installation packages may also install dlls in the installation directory. These are also considered native dlls.

Batt212 wrote:
but if I dot not have it I must use only native dll.
If Wine doesn't have such dll, then yes you have to use native dll instead.

Correct. Wine does not, at this time, include all of the dlls distributed with Windows or any installation product. Windows does not ship with some dlls, such as the Visual C++/Visual C#/Visual J# dlls. These dlls are normally included with the product as part of the installation package.

Batt212 wrote:
For example I copy and paste an exe file into linux enviroment and run it.
Not correct. You don't copy anything. Most programs have to be properly installed with their installer. This is true even on windows.

This really needs to be pointed out. You CANNOT just copy a program from a Windows installation to a Wine installation. You CANNOT just point to your Windows Program Files directory and run a program from there. And lastly you CANNOT just overlay a Wine installation with a Windows installation for many reasons, the main one is that you will break Wine and prevent it from running.

Batt212 wrote:
Why cannot I take iexplorer.exe and its dlls and run it?
This is special case. IE is a part of the system and depends on big number of undocumented functions. And to run it you have to replace big parts of Wine. This is strongly discouraged. Especially in this case, since Wine has it's own IE replacement.

You can try to use ies4linux/ies4MacOSX to run IE. However, unless you really require IE functionality, use FireFox instead.

Batt212 · Post by **Batt212** » Thu Jul 24, 2008 3:15 pm

thank you vitamin, but I've tryed copy and paste an free simple program HoverSnap.exe and its HoverKHook.dll and I didn't installed anything else and It runs. However, i've understand that built-in dlls are of use Wine and they are implementation of the Windows API.

For my thesis I find a simple program for windows that dump an exe file and this is dump's HoverSnap.exe. Is correct to say that wine look for dll reading into exe file? in fact, here all built-in dlls are listed and only one is native.

Imports Table:
KERNEL32.DLL
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FD9D4
Ordn Name
0 LoadLibraryA
0 GetProcAddress
0 ExitProcess

advapi32.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FD9E4
Ordn Name
0 RegCloseKey

comctl32.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FD9EC
Ordn Name
0 ImageList_Add

gdi32.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FD9F4
Ordn Name
0 SaveDC

HoverKHook.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FD9FC
Ordn Name
0 StopHook

ole32.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FDA04
Ordn Name
0 IsEqualGUID

oleaut32.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FDA0C
Ordn Name
0 VariantClear

shell32.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FDA14
Ordn Name
0 ShellExecuteA

user32.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FDA1C
Ordn Name
0 GetDC

version.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FDA24
Ordn Name
0 VerQueryValueA

winmm.dll
OrigFirstThunk: 00000000 (Unbound IAT)
TimeDateStamp: 00000000 -> Thu Jan 01 01:00:00 1970
ForwarderChain: 00000000
First thunk RVA: 000FDA2C
Ordn Name
0 PlaySoundA

vitamin · Post by **vitamin** » Thu Jul 24, 2008 3:48 pm

Batt212 wrote:thank you vitamin, but I've tryed copy and paste an free simple program HoverSnap.exe and its HoverKHook.dll and I didn't installed anything else and It runs.

Small programs that don't have anything in the registry and you know which dlls they depend on can be copied of course. This is the same as between two separate windows PCs.

Batt212 wrote:However, i've understand that built-in dlls are of use Wine and they are implementation of the Windows API.

For my thesis I find a simple program for windows that dump an exe file and this is dump's HoverSnap.exe. Is correct to say that wine look for dll reading into exe file? in fact, here all built-in dlls are listed and only one is native.

Wine built-in dlls are loaded and presented to application as a normal dll, otherwise most programs won't work. So if you trying to see the difference between native and built-in with a windows program - you won't find it. Unless you know exactly what to look for.

Of course Wine dlls implementing the same functions that are present in the corresponding native dll. That's a requirement. And yes those functions are the Windows APIs (there are more then one).

To make it clear:
Built-in dlls - dlls that are part of Wine itself (see Wine source for the complete list)
Native dlls - all other dlls
Fake Wine dlls - dlls that could be found in newly created WINEPREFIX (~/.wine dir). They are nothing more then real windows PE files only with resources from corresponding Wine built-in dll. But no code.

Batt212 · Post by **Batt212** » Thu Jul 24, 2008 4:03 pm

but when does wine need to use Fake Wine dlls? and is it correct or not to say that wine looks for dll reading into exe file?

vitamin · Post by **vitamin** » Thu Jul 24, 2008 4:20 pm

Batt212 wrote:but when does wine need to use Fake Wine dlls?

Never. Some programs look for those "dlls" and don't start if they can't find them. Wine will always find it's own built-in dlls that are not even present in WINEPREFIX

Batt212 wrote:and is it correct or not to say that wine looks for dll reading into exe file?

I'm not sure what you asking here. Wine does the same exact thing as loader on windows. With the exception of having one more place to look in for built-in dlls.

Chris MacKay · Post by **Chris MacKay** » Thu Jul 24, 2008 4:20 pm

sigh

Wine emulates Windows DLLs with it's own DLLs, so that when a Windows application makes calls that normally require those common DLLs, Wine intercepts those calls and interchanges Linux functionality for Windows functions. Ergo, Wine DLLs are "fake" in the sense that they are not Windows DLLs, but a reverse engineered version that substitutes Linux capabilities when a call is made for a Windows function. I can't make it any more precise than that.

REAL DLLs are used whenever a Wine DLL is not available, in order to attempt to extend the functionality available in Wine to include applications who require those DLLs, and may or may not include them with their installation application.

Chris.
----------------------------------------

From: [email protected]
Date: Thu, 24 Jul 2008 16:03:23 -0500
To: [email protected]
Subject: [Wine] Re: Native and Builtin dll

but when does wine need to use Fake Wine dlls? and is it correct or not to say that wine looks for dll reading into exe file?

_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207=

vitamin · Post by **vitamin** » Thu Jul 24, 2008 5:56 pm

Chris MacKay wrote:Wine DLLs are "fake"

Not really. Wine dlls are as real as it gets, only in the different file format (ELF instead of PE). And no they don't just pass some windows calls. Wine _reimplements_ windows API on top of POSIX.

What I was referring to as a "fake dlls" are the dlls Wine itself creates in system32 (and other) directories. Those are real PE dlls, just have no code in them, only resources.