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 > > > >
