I assume you know that the reason you add a salt is to prevent rainbow table attacks. Without a salt, if someone obtains the hash then they need to just run it through a single rainbow table and with very high probability, obtain the password.
A SHA{1,2,3,128,256,512} hash is very VERY VERY fast. So fast, in fact, that an attacker who has the hash could easily run through all 8 character passwords given a few GPU machine clusters.
PBKDF2 is very much like a SHA hash, but it is repeated over and over. Instead of just salt||SHA1(password||salt) you compute salt||SHA1(SHA1(SHA1(SHA1(SHA1(password||salt))))). This makes it so an attacker with the hash has to do much more work in order to brute force the password.
Now, that's not exactly how it works, but just read the wikipedia article for that.
What you described is essentially PBKDF1, which is similar to PBKDF2, but only supports a fixed output key length. It's also a decent option; just not as flexible as PBKDF2.
I was describing it in order to explain the general idea; not to explain the exact algorithm. The wikipedia article does a better job at that than I could do, but since he asked the question after the link to the wikipedia article I assumed that what he wanted was a simple explanation of what the difference is between just SHA(password) and PBKDF(password).
A SHA{1,2,3,128,256,512} hash is very VERY VERY fast. So fast, in fact, that an attacker who has the hash could easily run through all 8 character passwords given a few GPU machine clusters.
PBKDF2 is very much like a SHA hash, but it is repeated over and over. Instead of just salt||SHA1(password||salt) you compute salt||SHA1(SHA1(SHA1(SHA1(SHA1(password||salt))))). This makes it so an attacker with the hash has to do much more work in order to brute force the password.
Now, that's not exactly how it works, but just read the wikipedia article for that.