quote:
Never use any platform-specific API unless you have to. In other words, use fopen, fprintf, fwrite, and the rest, (include stdio.h in C or cstdio in C++) unless you have some good reason otherwise.

Wrong. If he knows he is going to be developing for the Win32 Api and the Win32 Api alone, then there is no reason not to use those functions which are provided with that API.

Not everyone wants to be a cross-platform developer so if you know you''re going to be developing for a specific API why not use the functions provided by that API? Why re-invent the wheel?

In any case, back to the original question.

You''re going to want to look into the API functions CreateFile(), ReadFile(), and WriteFile() .

quote:
If he knows he is going to be developing for the Win32 Api and the Win32 Api alone, then there is no reason not to use those functions which are provided with that API.

Wrong. Or, rather, this is a matter of opinion. I think it''s stupid to lock yourself into a particular API when a standard API does what you need it to do. For instance, let''s say that you need to concatenate and compare strings. You could use CString or std::string, and both would work equally well. Why needlessly bind yourself to MFC with CString? It''s the same case—most likely—with the Win32 API file functions and those of the C (or C++, for that matter) standard library. If, say, he just needs to open a file, write some text to it, why use the Win32 API (and this ignores that the Win32 API functions are usually pure overkill for such things).

Let''s say, for the sake of argument, that you agree with this logic. You can make yourself feel even better about it when you consider that although you "know" that you''re targetting x, you may someday change your mind. What about code reuse? You might decide that a particular routine is great and want to reuse it. That would be less than trivial if you hadn''t used the standard library or similarly platform-neutral library. Think about it.