Shachar Shemesh <[EMAIL PROTECTED]> writes: > Because of you, I actually opened up the wine code that parses this > thing. If you pull the wine source you will find it in > server/registry.c, in a function called "load_key". The line you are > looking for is "if (sscanf( buffer + res, " %d", &modif ) != 1) modif > = default_modif;". In other words, leaving this number out altogether > will default to a reasonable number, and this is, in general, the > modification time of the key (seems to be a simple time_t).
Thanks! This is way more effort than I could have expected! > > Now, the answer you won't like. Messing with this file is risky. You > have to make sure no wine process (including wineserver) is up while > you do so. In general, I realize that. What seems to be going on on this system though is that a particular app, on invocation, copies a system.reg that lives in /opt/<app>/wine-config/etc (*not* in /etc/wine) to the user's $HOME/.<app>/.wine, and I only operate in $HOME/.<app>/.wine/system.reg. The app is a singleton, i.e. only one instance (per user) can run at a time. Why it is done this way I have no idea. I am only hacking the bloody thing to make the file associations behave in a sane manner (don't ask). I definitely don't want to learn winelib or regedit for this purpose. Hopefully I'll do a working prototype and let others bother about foolproof implementation. I wonder though if the fact that the system behaves as described makes the situation a bit less perilous. Thanks again for your help, -- Oleg Goldshmidt | [EMAIL PROTECTED] ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
