A customer wanted to know how they could have their program wait until the system has finished booting completely. Their program runs in the Startup group, but they found that there is so much activity during startup that when their program displays a prompt to the user, it often gets covered by other things that run at startup. They want to wait until the system has finished booting and become idle, and then they can start their work.

The customer wanted to know whether there was a signal they could listen for to tell them that the system has finished booting.

Well, if such a signal existed, it would be a lie.

This program is going to wait for the system to go idle, and then start doing stuff. Which means that the system is no longer idle and hasn’t finished booting. So the signal was premature.

The customer has created a philosophical deadlock. They want their code to run after the system has finished starting up, but the system won’t be finished starting up until after they run their code.

This also suffers from the What if two programs did this? problem: Suppose two programs waited for the signal. Then they both try to do work, and they are now competing with each other, even though they were trying to wait until there was no contention for resources.

The customer explained that they are willing to do something hacky, because they got so many client complaints that their program was slow, that they felt they had to do something. They ended up polling the system for CPU usage, and waiting for the CPU usage to remain low for 10 seconds. (I don’t know what they do if the CPU simply never reaches that state, say, because it’s a multi-user system, or because the client has another program in their Startup group that uses a lot of CPU.)