My app reads the registry to figure out network information, in particular it queries the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards] key to discover network cards, then [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services] to figure out the IP address of each one (this program can bind to multiple adaptors). ... a) In initial setup, ie when you install Wine b) At Wine startup c) On demand, ie by writing special cases into the registry access code.
Clearly c) because that will work properly even when doing hotplugging of pcmcia cards and doing interactive dialup to an isp. Might want to cache it for 10 seconds or something, and you might need to worry about what happens when programs are reading the reg entries *while* an interface is changing. (heh.)
BTW there is a system call getifaddrs on many flavors of Unix that does this kind of query, and there's a library implementation of it for linux. See http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.c http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.h The registry code should probably just call this function. - Dan
OK, more questions :)
Clearly c) because that will work properly even when doing hotplugging of pcmcia cards and doing interactive dialup to an isp. Might want to cache it for 10 seconds or something, and you might need to worry about what happens when programs are reading the reg entries *while* an interface is changing. (heh.)
I'd note that Windows sets the volatile (what i called transient) entries at startup. For Wine though, startup time is always an issue, so yeah I'd think it makes sense to trap key not found errors.
BTW there is a system call getifaddrs on many flavors of Unix that does this kind of query, and there's a library implementation of it for linux. See http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.c http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.h The registry code should probably just call this function
Thanks, I took a look at this, seems to do the trick nicely.
Of course, now I'm wondering exactly what part of the registry code I should use. Either:
a) In advapi32 b) In ntdll c) wineserver.
The wineserver seems the most logical choice, but I'm not sure if there are any special rules regarding it, nor whether Alexandre would accept stuff like interface probing into the server, it might be considered bloat. Care to comment Alexandre? Which is the best place for this code?
thanks -mike
Mike Hearn m.hearn@signal.qinetiq.com writes:
The wineserver seems the most logical choice, but I'm not sure if there are any special rules regarding it, nor whether Alexandre would accept stuff like interface probing into the server, it might be considered bloat. Care to comment Alexandre? Which is the best place for this code?
I don't think we want to have 'magic' registry entries that are computed dynamically, at least not inside the normal branches. There are dynamic branches like HKEY_DYN_DATA where we will need that, but I think the rest should use the normal update mechanisms. For things like plugging in a new interface, there should already be callback scripts in Linux that you can hook into to set the corresponding registry key.
I don't think we want to have 'magic' registry entries that are computed dynamically, at least not inside the normal branches. There are dynamic branches like HKEY_DYN_DATA where we will need that, but I think the rest should use the normal update mechanisms. For things like plugging in a new interface, there should already be callback scripts in Linux that you can hook into to set the corresponding registry key.
So that leaves either initialising these entries at wine install time (which is what windows does it seems, i was wrong about it computed at startup), or at wine startup.
Install time is an extra step that would increase packaging complexity. Wine startup would hit startup time. Perhaps, check if the keys exist at startup and if they don't, create them? If the network config changes perhaps a small winelib app that recalculates the keys could be used - tying into kernel notifications could come later. Would that be OK?
Mike Hearn mike@theoretic.com writes:
Install time is an extra step that would increase packaging complexity.
We will need a way to create the initial registry anyway, 'regedit winedefault.reg' is clearly not enough, we need to do the dll registration etc. So it can be added there.
Wine startup would hit startup time. Perhaps, check if the keys exist at startup and if they don't, create them? If the network config changes perhaps a small winelib app that recalculates the keys could be used - tying into kernel notifications could come later. Would that be OK?
You should be able to do that with a script that calls regedit IMO, no need for a Winelib app.
Maybe a little bit off topic but I think it is interesting.
I am working on kernel32 LanguageGroups functions (patch soon) and they need some registry entries to work. As the registry keys are language dependent, it could be great if they could be set at install time according to the will of the user.
Max
On Fri, 2003-04-04 at 00:05, Alexandre Julliard wrote:
Mike Hearn mike@theoretic.com writes:
Install time is an extra step that would increase packaging complexity.
We will need a way to create the initial registry anyway, 'regedit winedefault.reg' is clearly not enough, we need to do the dll registration etc. So it can be added there.
Wine startup would hit startup time. Perhaps, check if the keys exist at startup and if they don't, create them? If the network config changes perhaps a small winelib app that recalculates the keys could be used - tying into kernel notifications could come later. Would that be OK?
You should be able to do that with a script that calls regedit IMO, no need for a Winelib app.
As part of my work on autopackage during the week, I'm hoping to develop a packaging system that is a bit more flexible than RPM, ie would allow user interactions and such. For now though, it's still a long way off, so we'd need to allow Wine installation to be completely automatic.
It seems that the ./tools/wineinstall script will need to be modularised somewhat, perhaps split into the compilation stage and the setup stage. Setup would right now just be a script that creates the initial fake windows drive and imports the registry, later it could be extended to dynamically set up certain elements of the registry, for instance:
- NIC info (read from /proc?) - Proxy data (read from gconf2 in gnome2 or environment variables) - Language settings (env vars) - ????
Writing scripts to do this is probably easier than adding registry code, so I'll get started on doing that split sometime next week, if people are happy with that plan.
On Fri, 2003-04-04 at 07:30, Maxime Bellengé wrote:
Maybe a little bit off topic but I think it is interesting.
I am working on kernel32 LanguageGroups functions (patch soon) and they need some registry entries to work. As the registry keys are language dependent, it could be great if they could be set at install time according to the will of the user.
Max
On Fri, 2003-04-04 at 00:05, Alexandre Julliard wrote:
Mike Hearn mike@theoretic.com writes:
Install time is an extra step that would increase packaging complexity.
We will need a way to create the initial registry anyway, 'regedit winedefault.reg' is clearly not enough, we need to do the dll registration etc. So it can be added there.
Wine startup would hit startup time. Perhaps, check if the keys exist at startup and if they don't, create them? If the network config changes perhaps a small winelib app that recalculates the keys could be used - tying into kernel notifications could come later. Would that be OK?
You should be able to do that with a script that calls regedit IMO, no need for a Winelib app.
Alexandre Julliard wrote:
I don't think we want to have 'magic' registry entries that are computed dynamically, at least not inside the normal branches. There are dynamic branches like HKEY_DYN_DATA where we will need that, but I think the rest should use the normal update mechanisms. For things like plugging in a new interface, there should already be callback scripts in Linux that you can hook into to set the corresponding registry key.
How about this: We will probably need to call getifaddrs() to populate the registry on startup. On Linux, some sort of hotplug system may be available such that whenever a network interface comes up, Wine is told to add the new registry entry. (Presumably Wine should have an SPI or a script or something to handle that event.) However, on operating systems without that capability, Wine should probably have a fallback mode, e.g. calling getifaddrs() once a minute to update the registry. Add caching to that for efficiency, maybe, who knows (though that comes quite close to the magic registry entry you wanted to get away from). - Dan
-
Alexandre Julliard -
Dan Kegel -
Maxime Bellengé -
Mike Hearn -
Mike Hearn