Re: WIN32_FIND_DATA and gigantic file sizes
On Mon, 13 Apr 2009 12:50:13 -0700, brander <brander@noreply.com> wrote:
The point being that I originally used what was suggested at
http://msdn.microsoft.com/en-us/library/aa365740(VS.85).aspx (into an
__int64). Post release, it was discovered that it wasn't working
properly for large file sizes.
Which led to the 32/64 bit confusion and the post.
Many MSDN examples are written in a language called "Fanciful". It's up to
you to figure out their intent and translate them into a real language.
Fanciful somewhat resembles C, and this makes things both easier and
harder. It's easier because it seems familiar to you, and it's harder
because it requires you to be familiar with many nuances of C and Windows
programming. So, the only way to approach a Fanciful example is to assume
that the design and implementation are both wrong, and that the example may
not even remotely demonstrate what it is claimed to do. However, it's not
all bad news. There is a web site called "Connect" that lets you report
Fanciful examples to Microsoft, and they do fix them. Here's proof:
Original article:
http://msdn2.microsoft.com/en-us/library/8w5bsb4f(VS.80).aspx
My feedback:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=300428
New article:
http://msdn.microsoft.com/en-us/library/8w5bsb4f.aspx
This is much better. They translated the original Fanciful example into the
second language of MSDN examples, "Almost". An Almost program demonstrates
what it is supposed to demonstrate, and it works under some conditions,
perhaps even most conditions, but it still contains flaws that must not be
copied. Here, the major flaw is the use of _beginthread. (The minor flaw is
the almost ubiquitous failure to check return codes, which, ironically, may
both save the example and ensure it doesn't get translated into the third
and most rarely used language of MSDN examples, "Robust".) The problem is
that _beginthread automatically closes the thread handle when the thread
ends, similar to how a CWinThread object auto-deletes itself. This makes
the subsequent use of WaitForMultipleObjects invalid, because (a) There is
a race condition between the thread ending, the handle being closed, and
WFMO being called, and (b) It is undefined for a handle to be closed while
WFMO is waiting on it.
In all seriousness, I think two things have been demonstrated, (a) The
language (C or C++) is hard, and (b) The platform (Windows) is hard. It
takes a fair amount of experience in both to combine the two and come up
with something that truly works. MS does not have their most experienced
people writing MSDN examples, so mistakes should be expected. There's just
so much of it though, and some of it is so bad, that it's hard not to have
a little fun with it from time to time. The lesson, however, is to report
the issues you find on Connect. It does work:
https://connect.microsoft.com/default.aspx
--
Doug Harrison
Visual C++ MVP