[Wine] Help with debugging Fable

[James McKenzie]

ShideKnight wrote:
> Okay. I'll have to do that then...
>
> In the mean time, I have a couple questions
>
> - Is it possible to remove just one program with a command like that so I don't have to try to reinstall anything else?
>   
This might work, if you have an installer that supports command line
de-install. 

> - What exactly is the native vs. builtin distinction in user.reg? I got the impression that native uses a dll from the system or system32 folder, whereas builtin uses a dll from the /usr/ directory. But if you switch a file from builtin to native, for instance, does it write over the file in the /usr/ directory, or does it just redirect the command to the other file? Also, what does it mean when it lists both native and builtin?
>
>
>   
Native dlls are dlls obtained from a licensed copy of Windows
(preferably WindowsXP) that you place either in the execution directory
(.wine/drive_c/Program\ Files\<Path to executable>) or in the system32
directory, replacing the .dll 'stub' file that is there.  It is
preferable to put the native dll in the execution directory and create
an entry with winecfg that 'overrides' the dll file settings for that
program only.

Built-in dlls are 'stub' files that redirect program activity from the
dll file that resides in the system32 directory to *NIX static object
(.so) or MacIntosh dynamic library (.dylib) files located in the /usr
directory structure.  Please keep in mind that you do not and should not
remove the *NIX files nor rename them as some do provide extended
functionality not normally provided by a native dll.

Setting native, built-in will first scan the native dll (if available)
for a desired function call and then Wine's dll.  This provides Windows
like performance in some cases, but is not best to test if Wine is
correctly emulating Windows functionality as the Windows dll will be
used first.

Setting built-in, native will first scan the built-in dll and then the
native dll.  This may be better than using native, built-in for Wine
functionality tests, however, if you are looking for Windows performance
this may be worse than using only the built-in capabilities.

The remaining two settings should be self-explainatory.

James McKenzie

>
>
>
>