HOWTO: Delay autostart of a program with batch file

If you shoot at mimes, should you use a silencer?  - Steven Wright

This is kind of an interesting little exercise that came from our eggheadcafe.com forums and I thought I’d write it up for posterity:

User has some sort of logging program (not a service) that depends on SQL Server being up and running in order to do it’s work. Problem is, the little proggie is starting to work before the SQL Server service does on bootup. So the user is asking how you can delay the start of the proggie.

Being my helpful self, I advised him to write a .NET console app, have the app sleep the main thread for the specified time, and then use Process.Start to execute the real program.

User responds that he doesn’t know what Sleep means; if only there was a way to do this with a batch file.

Well, not to be daunted, I went out and did a bit of research. Turns out that there isn’t any native DOS command to “sleep” a batch file. The only way you could do it is to use something from one of the Windows Resource Kits, and that’s a real pain.  But I did find a way:

if you ping a nonexistent address with a number of repetitions specified and a timeout, and redirect the output into NUL, ping will happily ping away, waiting for the specfied time period, quit,  and then the next line of your batch file will execute. Example:

PING 1.1.1.1 -n 1 -w 10000 >NUL
NOTEPAD.EXE

Save the above as “delay.bat” and double –click on it. Cool, eh?  Just as a refresher, –n is the count, and –w is the timeout:

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
            [-r count] [-s count] [[-j host-list] | [-k host-list]] 
            [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name

Options:

    -t             Ping the specified host until stopped. 
                   To see statistics and continue - type Control-Break; 
                   To stop - type Control-C.

    -a             Resolve addresses to hostnames. 
    -n count       Number of echo requests to send. 
    -l size        Send buffer size. 
    -f             Set Don't Fragment flag in packet (IPv4-only). 
    -i TTL         Time To Live. 
    -v TOS         Type Of Service (IPv4-only). 
    -r count       Record route for count hops (IPv4-only). 
    -s count       Timestamp for count hops (IPv4-only). 
    -j host-list   Loose source route along host-list (IPv4-only). 
    -k host-list   Strict source route along host-list (IPv4-only). 
    -w timeout     Timeout in milliseconds to wait for each reply. 
    -R             Use routing header to test reverse route also (IPv6-only). 
    -S srcaddr     Source address to use. 
    -4             Force using IPv4. 
    -6             Force using IPv6.

 

N.B. One user commented that you can do all this with Task Scheduler. I took a look, and at least in Windows Vista, TS has become much more feature-rich; indeed you can do the above and a lot more just by setting up a task.

Are online Video Tutorials really that useful?

I’ve noticed lately that it seems more and more developers / gurus / etc.  are turning to putting out online videos instead of written articles. Personally, I don’t usually find videos that useful, unless it is something important and the video is the only thing available. Most video tutorials aren’t well produced, they are linear in nature (unlike an article where you can easily jump from one place to another), and you certainly cannot copy and paste code samples from them!

I much prefer written articles with images and sample code, and a downloadable solution zip file. What do you think?

In Other News....

This Google search, Silverlight Patent Suit -- is already bringing up over 72,000 results... So, what else is new? More Mindless Patent Extortion!

          Regarding Twitter, I see that some people I follow have already started migrating to FriendFeed, which automatically picks up your "stuff" from a number of different services. There's a .NET API and I may double my IttyUrl.net links, all of which are automatically posted on Twitter,  to FriendFeed as a backup move in the near future. See my post on "The Social API we really need". Twitter is a great concept, BUT!

Russell Beattie explains:

"The lesson from Twitter is that microblogs aren't Content Management Systems at all, but are instead Messaging systems, and have to be architected as such. SMTP or EDI are our models here, not publishing or blogs.

Here's how a microblog system has to work to scale: All the messages created by users have to go into a Queue when they're created, and an external process then has to go through one by one and figure out which messages go into which subscriber's message list. As the system grows and more messages are created, the messages may arrive in your "inbox" slower, but they will still arrive. This type of system can be easily broken up into dedicated servers and multiple processes can handle different parts of the read/write process, and the individual user message lists can be more easily cached - as once a page is created that contains messages, it doesn't change."

It's funny, because I actually built a system just like Beattie describes, for a former employer. The main difference was that it was for SIP VOIP messages instead of Twitters, but the concept is the same. Messages were sent over the wire and a collector process deposited them into MSMQ. A second process continually read out each message from the queue and handled the routing and addressing (think, "which users this message should be shown at, and how"). The thing processed 2,000 messages a second - and these message were BIG - not the measly 140 character twits you get at Twitter. It's easy to scale out such a system where there can be multiple destination queues and multiple processing services. The endpoint simply round-robins the messages into different queues on different machines on the processing farm.

I don't know what the real bottlenecks are at Twitter, but if you look at services like Live.com for Messenger (390 Million accounts, supposedly) they don't go down very often, and when they do, it's usually not for very long.