This page on the MSDN seems to list a bunch of file operations that behave more or less exactly like condensed versions of the three functions used in this example. What's the purpose of these non-standard run-time functions that do things functions are written for in the Win32 API?
Are they just there for DOS compatibility? If so, then why are they getting updated with things like 64-bit support?
It's called "history" - when you make something like Windows you're not allowed to throw old functions away because it breaks existing programs.
One set of those look like "C" functions, one look like "Win32" functions. You can use whichever ones you like best.
If you have code you are importing from 16-bit Windows that called _findfirst and _findnext, it's OK to keep usiing them. Otherwise use the APIs.
If you look in the C run-time source code (which is included with VC++), you'll see that _findfirst calls FindFirstFile, and so on.
Please check out the graph on this site as well for a performance comparison. The Win32 API FindFirstFile variant is more efficient. Warning: The site itself is not in english, but the graph makes sense.
Probably the key thing you get over using the raw Win32 APIs (maybe the only thing) is that in a debug build the CRT will perform some validation for you (take a look at the source - there are quite a few validation assertions thrown in there).
And what's wrong with wrapping an OS API - even if only very slightly?
The C Runtime functions will also do things like set errno on failure, which is a different error mechanism than Win32.
The code also lives in separate DLLs, at one time people actually tried to write programs that didn't use the CRT because they didn't want to have another DLL loaded.