27 Mar
2003
27 Mar
'03
5:50 p.m.
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
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
3 Apr
3 Apr
3:29 p.m.
New subject: Transient registry entries?
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(a)signal.qinetiq.com>
QinetiQ - Malvern Technology Center
5:26 p.m.
New subject: Transient registry entries?
Mike Hearn <m.hearn(a)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.
--
Alexandre Julliard
julliard(a)winehq.com
9:26 p.m.
New subject: Transient registry entries?
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?
10:05 p.m.
New subject: Transient registry entries?
Mike Hearn <mike(a)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
julliard(a)winehq.com
4 Apr
4 Apr
6:30 a.m.
New subject: Transient registry entries?
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(a)theoretic.com> writes:
--
Maxime Bellengé <maxime.bellenge(a)laposte.net>
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.
9:14 a.m.
New subject: Transient registry entries?
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(a)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.
--
Mike Hearn <m.hearn(a)signal.qinetiq.com>
QinetiQ - Malvern Technology Center
6 Apr
6 Apr
7:13 a.m.
New subject: Transient registry entries?
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
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
7714
days inactive
7724
days old
7 comments
5 participants
participants (5)
-
Alexandre Julliard -
Dan Kegel -
Maxime Bellengé -
Mike Hearn -
Mike Hearn