You don't need any custom sensor hardware to read the disk as the original drives have signal lines that provide all that's needed. They usually have some automatic gain control, but it usually gives the right result.

You still need to connect the drive to a cheap device like the Greaseweazle (USB), which reads the raw flux reversals from the surface (plus timing information) as they're picked up by the drive head. All data decoding is done in software on the host system, which can handle ANY encoding type, and be smarter about error recovery.

The disks themselves sometimes need a bit of manual cleaning to be in a good position to read. Not everything can be recovered but older disks are generally more reliable than cheaper newer media.

CompatTelRunner.exe is the bane of my existence. As soon as I hear my CPU fans spin up I know it's off again.

Blockchain as a technology is very useful. It's just how it's pushed as some kind of magic sauce that makes everything better just to sell things. There's a similar problem with Artificial Intelligence and Machine Learning. Blame the application not the technology.

That will still be a problem, as any properly HDCP-compliant capture card will not (or should not!) give you access to the data either. Every device should check the downstream devices are compliant before passing any data on, and not provide any way to intercept it. Any that knowingly do are breaking the HDCP licensing agreement and are likely to be sued.

You'll probably run into copy-protection issues with many media sources. If you can get at the bits to analyze it, you can dump them out to create a copy. I'm not even sure sharpness is going to be easy to measure, if a soft/low-res source has been artificially sharpened to give the appearance of quality. Sports broadcasts seem to be the worst for it for it from my experience, with glowing halos around high-contrast edges to make them stand out even more.

It can if it's still tracking positions at the original resolution, with only the display down-scaled.

Windows 7 x64 can't run 16-bit apps*, and all Windows 3.1 apps are 16-bit, so it can't actually run ANY Windows 3.1 apps.

* actually, there's a reimplementation to support some 16-bit installers, but they're still not executed natively.

Settings -> General -> Restrictions -> Require Password -> Immediately

No more 15 minute password caching :)

One of the books that includes all the maze patterns: http://www.amazon.com/Video-Masters-Guide-Pac-Man/dp/0553229591

Though it doesn't go as far as achieving the maximum possible score, as that requires other manual tricks to round up the ghosts.

Trine supports multi-player, but everyone has to play on the same machine. Trine 2 (due in the Spring IIRC) should have network multi-player, hopefully. It's a beautiful single-player game too :-)

It is indeed more common in Win32 code, but that's not exactly a small segment.

I've never come across that mix of separate attributes with defined types. Typically there will be a PCFOO to go with the PFOO, which has the const as part of the typedef: such as LPSTR and LPCSTR.

Typedefs allow you to keep the whole type atomic. I prefer:

PCSTR p1, p2;

to

const char *p1, *p2;

where the pointer symbol needs to be repeated on the second variable, despite 'const char' being common to both.

That was true in the beta versions of Vista x64, but it was disabled for the final release (which now require the same F8 menu selection on every boot).