I'm trying to emulate a gameboy, but it plays a little too fast.

This how I'm doing my timing inside the main loop.

if (cpu.T >= CLOCKSPEED / 40) // if more than 1/40th of cycles passed
{
        // Get milliseconds passed
	QueryPerformanceCounter(&EndCounter);
	unsigned long long counter = EndCounter.QuadPart - LastCounter.QuadPart;
	MSperFrame = 1000.0 * ((double)counter / (double)PerfCountFrequency);
	LastCounter = EndCounter;

        // if 1/40th of a second hasn't passed, wait until it passes
	if (MSperFrame < 25)
		Sleep(25 - MSperFrame);

	cpu.T -= CLOCKSPEED / 40;
}

CLOCKSPEED is the cycles per second of the emulated cpu (4194304)

cpu.T is cycles passed.

I'm using Visual Studio 2013. I even tried switching to C++ and using steady_clock but nothing changed. What could be the problem?

Devil; you need to time-slice your emulation processing, instead of trying to run it synchronously at a perfect rate. Read http://gafferongames.com/game-physics/fix-your-timestep/ , use a fixed framerate of, say, 60 or 120 "physics" ticks per second, except in this case the "physics" you are running is actually 1/60th or 1/120th of one second's execution of the emulated CPU, sound chips, and graphic chips of a Game Boy.

More specifically; lots of early consoles and machines could do things to the framebuffer "in between" scan lines, and the code had to either have super-fast interrupt service routines or exact timing to take advantage of them. The Atari ST could completely change the 16-colour screen palette between scan lines, allowing for wild vertical gradient effects. The NES and SNES could change several GPU registers between scanlines, but most important of these was on the NES the scroll register (both X and Y), and on the SNES the 2x2 matrix used by the Mode 7 layer (which is how all of those perspective map effects were done).

So, to emulate those, you have to not just run your CPU for 1/60th of a second every physics timestep; assuming you have a vertical resolution of, say, 256 pixels, you have to run your CPU for 1/(60*256)th = 1/15,360th of a second, then run one scanline of the GPU, then repeat 256 more times, until you have a complete framebuffer which you can present.

If you start under-running on time (i.e. your host PC isn't fast enough to emulate the entire guest at full speed), you could disable the actual writing-to-screen in a cycle, getting "dropped frames" while still running the guest CPU at full speed... or you could just put a cap on emulation speed, and let the guest slow down to below realtime.

The Atari 8 bit machines could change the screen resolution between scan lines

So you could swap between hires low colour and lowres high colour per screen line.

That was fun!

Yeah, changing the horizontal resolution between scanlines is a pretty cool trick. But I'm betting those machines only had enough VRAM to pre-compose one scanline at a time, anyways, as opposed to a 75kB framebuffer?