Bad idea Jan.

For one, if I have a CRT set at 80Hz I would scream if anyone screwed
with my refresh rate and lowered it to 60Hz at which point in time I
would have a massive headache in under 60 seconds....

On an LCD you wouldn't even be able to modify the refresh rate so if
it isn't 60 Hz you can't do anything about it.

Secondly, Interval One only means you will get 60 frames per second IF
and only IF your rendering speed is greater than 60 frames per second!

If each frame is slightly longer it will drop you down to 30 frames
per second as it has to wait until the next vsync.

Now a couple notes to the original poster.

I assume you are trying to write some emulator here.

Using a counter to count cycles is a bad bad bad idea. Are you
counting real CPU cycles here? What if you run your code on a faster
or slower computer? Your count will be wrong and your execution speed
will be wrong. Try to run an old DOS Game on a modern machine and you
will seewhat I mean. Many of them still used hardcoded delay loops
instead of timers....

Learn how to use QueryPerformanceCounter to do your timing. Plenty of
tutorials out there on how to use it.

That way, your code can execute the same no matter how fast the
hardware is. Also it makes you less dependant on a fixed framerate.

If you absolutely need a fixed 60Hz framerate for your emulator code
then run it on a seperate thread and limit it to 60Hz via
QueryPerformanceCounter.

Then on either the main or another thread, run your rendering as fast
as it can possibly go. The rendering thread will just need to be able
to wait if the emulation thread isn't ready yet with the data for the
next frame.

This allows you to keep your logic at a fixed 60Hz, and display the
results to the user at whatever speed is left over in the end for
rendering.

The user is NOT going to notice any significant difference between 40
frames or 60 frames per second...some crazed FPS nut maybe, but the
average normal human being? No.

Also I would not lock the backbuffer. Instead I would use two
offscreen surfaces.

One surface that the video card is currently displaying.
One surface that you are currently working with.

Then when you are done, switch em around. The one you were working
with becomes the surface the hardware is displaying and the other one
becomes the one you are drawing pixels on.

This has the advantage that you never need to lock the surface that
the video card needs to do its work and can avoid stalling the
hardware.