Alexandre Julliard wrote: > Well, if you discard all objections as "not real" then of course there > isn't a real objection. But the two mentioned seem very real to
Sorry, I didn't mean them to be not real. It's only that I doubt that the check for the existence of a registry key and alternatively for a configurable switch is that performance intensive to hinder such an implementation. The other one (forcing an entire reboot) is not a real objection to me as I never wanted to implement it in that way. I don't like the idea to have all applications to stop just because some program needs to rename/delete some files for itself. Especially under Unix where this is no problem anyway. So this was not meant to discard that objection, rather I never intended this solution anyway. :) > me. Another one is that you need to be able to control when bootup > processing happens, and this is a policy decision that doesn't belong > in the lowest layers. This is why we need a separate app, which can be > launched when some higher layer decides it's the right time. I can understand that as a more "real" objection. :) That's why I posted my first mail, because I wanted to know which reasons could exist to justify that. I hate to code something without understanding it's needs, and even more so when I don't agree with it. The disagreement could be because I don't know about other issues, which I wanted to find out about here. So why is it neccessary for this to be in a seperate app and are there already any plans on how this should have been integrated? Which layer would that be that decides this? If the decision is done in a higher app, why not just implement it in a seperate module (which I would have done anyway) and then execute the code when it is needed?