This is called timer based movement. The premise is that game should run at the same speed regardless of your hardware or the current frame rate. Your program needs to ask the system its current time so that the objects will appear to move at the same speed on all computers. Started unzipping a huge file? Your character will still walk the same speed, only instead of taking 500 frames to do it he'll do it in 50, moving 10 times the distance each frame.
Be careful of pausing! You'll have to distinguish between system time and game time. I do this by subtracting out the accumulated pause time, otherwise things will appear to "jump" ahead. For example, if you had a sun/moon cycle based on the system time, where an in game day was equal to 15 real minutes, pause the game while it's day. Come back in 15 minutes, unpause it a WOW! it's magically nighttime.
In my games, I have all speeds expressed in terms of meters per second, or, if it is a 2D game, pixels per second. This is much easier to work with than using "units per frame." At the beginning of my game loop, I call the tick() function which calculates the time difference in seconds between this call to tick() and the last call to tick(). This difference is stored in a variable called df which I multiply all speeds by before adding them to object positions. If you do this then BAM! your game has timer based movement.
Windows has functions called QueryPerformanceCounter and QueryPerformanceFrequency that you can use to pull this off. Last time I checked, there may be some problems with df being negative if you get shuffled to another processor. Frank Luna recommends clamping df to the nonnegatives in this situation. Don't worry about external libraries, in my game engine the timer functionality is all contained in one small class.