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?