I have recently noticed the large number of Stub DLLs being Added to wine with minimal functionality, for example Msi, MSHTML (they don't work for me in any case). These additions have not for the most part been accompanied with a new "native, builtin" entry in samples/config.
Due to the forthcoming removal of the config file, i assume this functionality will be added to winedefault.reg. This is less than ideal for people who track CVS or install from source with each new release since, as before, their registry will not be automatically updated to match winedefault.reg.
Is there a mechanism for Wine dlls to specify a preferred override automatically (e.g. where the built-in DLL holds no functionality, whereas the native one works correctly, and if not how difficult would it be to implement this, (e.g By adding the entries to the registry in DllRegisterServer or some similar mechanism)
On Wed, 2003-09-24 at 16:53, Matthew Davison wrote:
I have recently noticed the large number of Stub DLLs being Added to wine with minimal functionality, for example Msi, MSHTML (they don't work for me in any case). These additions have not for the most part been accompanied with a new "native, builtin" entry in samples/config.
Annoying isn't it? The config file is not the right place to do this anyway, better to have it hardcoded into loader/loadorder.c IMHO, otherwise users will always forget to update their config.
Tracking this stuff in the source probably makes the most sense anyway.
I'm not fully sure of the semantics of this structure. I have a feeling specifying LOADORDER_DLL here (native) will cause wine to fail with the standard "dll not found" error if native isn't present rather than fall back. Arguably for these two DLLs that's actually what we want - at least the "dll not found" error is understandable by most users as opposed to some random stub crash/hang/whatever caused by missing functionality.
ChangeLog Force native MSI and MSHTML in the load order
Index: loader/loadorder.c =================================================================== RCS file: /home/wine/wine/loader/loadorder.c,v retrieving revision 1.66 diff -u -r1.66 loadorder.c --- loader/loadorder.c 5 Sep 2003 23:15:43 -0000 1.66 +++ loader/loadorder.c 25 Sep 2003 10:23:47 -0000 @@ -67,6 +67,8 @@ { "keyboard", { LOADORDER_BI, 0, 0 } }, { "krnl386.exe", { LOADORDER_BI, 0, 0 } }, { "mmsystem", { LOADORDER_BI, 0, 0 } }, + { "mshhtml", { LOADORDER_DLL,0, 0 } }, + { "msi", { LOADORDER_DLL,0, 0 } }, { "mouse", { LOADORDER_BI, 0, 0 } }, { "ntdll", { LOADORDER_BI, 0, 0 } }, { "odbc32", { LOADORDER_BI, 0, 0 } },
Mike Hearn mike@theoretic.com writes:
Annoying isn't it? The config file is not the right place to do this anyway, better to have it hardcoded into loader/loadorder.c IMHO, otherwise users will always forget to update their config.
No, that hardcoded list is only for dlls that we know will never work as native. We don't want to have to change it every week depending on the progress of some other dll. There are plenty of things that you may have to add in the registry or config when upgrading Wine, that's just one of them; we'll need a general mechanism to do that anyway.
On Thu, 2003-09-25 at 18:21, Alexandre Julliard wrote:
No, that hardcoded list is only for dlls that we know will never work as native. We don't want to have to change it every week depending on the progress of some other dll. There are plenty of things that you may have to add in the registry or config when upgrading Wine, that's just one of them; we'll need a general mechanism to do that anyway.
OK, so the best way to tackle this then is probably once we moved the config entirely into the registry for packages to remerge the default registry on install/upgrade?
Of course people who do "make install" from CVS are a bit stuck - maybe we can use Makefile rules to do it ?
Cant work, as 'make install' must be done beeing root user.
OK, so the best way to tackle this then is probably once we moved the config entirely into the registry for packages to remerge the default registry on install/upgrade?
Of course people who do "make install" from CVS are a bit stuck - maybe we can use Makefile rules to do it ?
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thu, 2003-09-25 at 20:13, Sylvain Petreolle wrote:
Cant work, as 'make install' must be done being root user.
Good point. Possibly a timestamp key in the registry that is updated with each alteration of winedefault.reg and is also updated in the code. If they don't match, we print an error (and continue anyway).
How does that sound?
--- Mike Hearn mike@theoretic.com a écrit : > On Thu, 2003-09-25 at 20:13, Sylvain Petreolle wrote:
Cant work, as 'make install' must be done being root user.
Good point. Possibly a timestamp key in the registry that is updated with each alteration of winedefault.reg and is also updated in the code. If they don't match, we print an error (and continue anyway).
How does that sound?
We could do this in wine itself (or wineserver ?). 1- Add a registry key that points to the wine source dir 2- If the key doesnt exist, tell the user to locate winedefault.reg and run regedit. 3- Check the timestamp key.
It makes me wonder why regededit does not verify the format of the registry files it processes. This morning I gave it a bash script to import and it did not react. We can do this check that way : - if a parameter is given, try to print results into the console. - if not, we are in gui mode, then we can msgbox it or something else.
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thursday 25 September 2003 12:21 pm, Alexandre Julliard wrote:
Mike Hearn mike@theoretic.com writes:
Annoying isn't it? The config file is not the right place to do this anyway, better to have it hardcoded into loader/loadorder.c IMHO, otherwise users will always forget to update their config.
No, that hardcoded list is only for dlls that we know will never work as native. We don't want to have to change it every week depending on the progress of some other dll. There are plenty of things that you may have to add in the registry or config when upgrading Wine, that's just one of them; we'll need a general mechanism to do that anyway.
Perhaps we want to distinguish between "defaults" and "settings," which override the defaults. For example, we could just return default registry values (of the settings with defaults) when they aren't really there. That way new defaults could be hardcoded in source or winedefault.reg, and updating your wine would update any defaults you haven't overridden... such an approach could make things a little screwy from winecfg's perspective however.
-
Alexandre Julliard -
Gregory M. Turner -
Matthew Davison -
Mike Hearn -
Sylvain Petreolle