Find the answer to your Linux question:
Results 1 to 5 of 5
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    I'm a bit confused

    The wine docs state that the replacement dlls that they made can only work so well compared to the native dll's. Why isn't there a list of the ones that are worth importing?

  2. #2
    Just Joined!
    Join Date
    Aug 2008
    From my understanding Windows DLL's could mess WINE up badly. WINE dll's are made for wine specifically. Using third party dll's only if they are asked for is ok however.

  3. #3

    3.1.2. Libraries Settings

    Likewise, some applications require specific libraries in order to run. Wine reproduces the Windows system libraries (so-called native DLL's) with completely custom versions designed to function exactly the same way but without requiring licenses from Microsoft. Wine has many known deficiencies in it's built-in versions, but in many instances the functionality is sufficient. Using only builtin DLL's ensures that your system is Microsoft-free. However, Wine has the ability to load native Windows DLL's.


    They're designed to do the same thing, but not guaranteed to do it as well. The only apparent reason to only use WINE libraries is to ensure your system is "Microsoft-free". Sounds to me like the functionality is phoned in compared to the "legit" dlls.

  4. $spacer_open
  5. #4
    Just Joined!
    Join Date
    Aug 2008
    Yeah I noticed I am hearing to different things. There are some that can never be used. I am not sure why they don't have a list, might be because Windows is Closed source and Microsoft would throw a fit, take WINE to court or something. Best thing to do would be to do a Google search for the DLL's that would break WINE, maybe there is a list of those somewhere. Then the rest by default might be ok. Just experiment with it (After you make a copy of a your .wine directory. DLL Overrides

    It's not always possible to run an application on builtin DLL's. Sometimes native DLL's simply work better. After you've located a native DLL on a Windows system, you'll need to put it in suitable place for Wine to find it and then configure it to be used. Generally the place you need to put it is in the directory you've configured to be c:\windows\system32 (more on that in the drives section). There are four DLL's you should never try to use the native versions of: kernel32.dll, gdi32.dll, user32.dll, and ntdll.dll. These libraries require low-level Windows kernel access that simply doesn't exist within Wine.

    With that in mind, once you've copied the DLL you just need to tell Wine to try to use it. You can configure Wine to choose between native and builtin DLL's at two different levels. If you have Default Settings selected in the Applications tab, the changes you make will affect all applications. Or, you can override the global settings on a per-application level by adding and selecting an application in the Applications tab.

    To add an override for FOO.DLL, enter "FOO" into the box labeled New override for library: and click on the Add button. To change how the DLL behaves, select it within the Existing overrides: box and choose Edit. By default the new load order will be native Windows libraries before Wine's own builtin ones (Native then Builtin). You can also choose native only, builtin only, or disable it altogether.

  6. #5
    Sounds like a plan, cheers.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts