In reference to bug #11973, I've the following observation.
Using the native .NET 2.0 installed via winetricks, I located what is potentially a problem with the method that .NET is using to locate the DLLs that it wishes to load.
The problem seems to be that .NET is attempting to locate the various DLL's it is going to use, by searching various directory paths. Once this does not occur (by placing a native DLL into the windows/system32 path) it causing a crash further down. It doesn't seem to utilize the LoadLibrary initially to locate but another function (from memory I think it NtCreateFile). With the native DLL in place it starts to process properly, at least until it runs into other files not located (as stated above).
I believe that .NET 2.0 is assuming that the files are located within the directory path (this may be so that it can independently utilize application supplied DLL files - I read that WinXP supposedly uses this policy to reduce problems with DLL dependencies). This of course, totally by-passes the built-in DLL files (which should be located using this method, except that they do not exist in the paths .NET searches).
There are two possible ways currently that I can think of, which would potentially solve this problem: 1. Have symbolic links within the system directory (I find this to be bad method, for multiple reasons) 2. Have some interception of the searching for files located within the system32, to include all of built-in dlls.
Unfortunately, since I don't know a huge amount about Wine yet, I have no idea on how to code the second one, and I think having a patch for this, may solve quite a few problems that currently exist with using .NET based programs.
--------------------------------- Get the name you always wanted with the new y7mail email address.
Am Mittwoch, 16. April 2008 16:43:13 schrieb Rhys McGuckin:
There are two possible ways currently that I can think of, which would potentially solve this problem: 1. Have symbolic links within the system directory (I find this to be bad method, for multiple reasons) 2. Have some interception of the searching for files located within the system32, to include all of built-in dlls.
Many applications behave that way, and we create fake .DLL files in system32. They are real PE files from their file header, but they do not contain the implementation. When an app tries to LoadLibrary this DLL we load the builtin one instead
So we just have to add the needed DLLs to the fake DLL list. We don't add one there without an application requiring it, because it makes it harder to install MS library packages. E.g. the IE6 installer fails unless the user deletes a bunch of those faked DLLs first
Stefan Dösinger stefandoesinger@gmx.at wrote:Many applications behave that way, and we create fake .DLL files in system32. They are real PE files from their file header, but they do not contain the implementation. When an app tries to LoadLibrary this DLL we load the builtin one instead
So we just have to add the needed DLLs to the fake DLL list. We don't add one there without an application requiring it, because it makes it harder to install MS library packages. E.g. the IE6 installer fails unless the user deletes a bunch of those faked DLLs first The other problem was that it also failed attempting to find l_intl.nls. And is this list of fake DLLs application specific? Since I'm not sure what dlls all .NET 2.0 applications are going to try to search for, would we add all the DLLs that are central to windows? The program that I am using that relies on .NET requires (imm32, lz32, iphlpapi, & l_intl.nls), before it runs into an unimplemented RAS function.
--------------------------------- Get the name you always wanted with the new y7mail email address.
-
Rhys McGuckin -
Stefan Dösinger