I was talking with a friend recently who told me that CopyFile and CopyFileEx are not allowed in C++ Metro applications(which appears to be correct). Why is this? And why did they put forward an odd replacement named CopyFile2
All of them copy a file, so why ban part of the established API to put forward a new function to figure out?
The general stance taken with the metro APIs has been "if there is an Ex function or something supersedes it, you have to call the new one." Same goes for the 8-bit-string (misnamed "ANSI encoding" for historical reasons) versions of functions. Among other benefits, this keeps the code size down for Windows RT.
Let's look analytically at CopyFile2... For one, the options parameter is now a structure which has a size as the first member. I would argue this is better for future extensibility than the approach taken by CopyFileEx. This allows Microsoft to add new options while maintaining binary compatibility with older callers. (Microsoft can extend the length of the structure, then check dwSize to determine what version of the structure you have, and adapt its behavior accordingly.) This alone makes it more future proof than CopyFileEx which would require a function signature change (hence an entirely new function) to add a single option. (I haven't read carefully, maybe they did already add an option in CopyFile2 as well...)