I suspect this makes it pretty much impossible to use (although the guy with the pad has the glowing report of, "and it seemed to work OK") but without actually having a pad with which to test, it's about all I can do.
on WSAECONNRESET, just return 0, not error
set STATE_SHUTDOWN on shutdown, though nothing uses this right now;
maybe this should be removed, and instead say "always call Close()
at the end of successful processing in the thread" (to ensure that we don't
block later)
the pipes in the parent, so it kept a reference to the
handles. (This didn't cause problems normally, but since
the child's ends of the pipes remained open when it closed,
it reduced reliability in failure cases.)
over HTTP as a POST form. This is intended to decrease the
amount of effort required to submit bug reports, reduce the
potential for human error, and increase the consistency of
the form of bug reports (always a crashinfo.txt, no wrapping
or RARring, not pasted into BTS text fields, and no forgetting
it entirely).
This offers less chance to fix the bug than a real BTS entry.
We can't interact with the user (since the submission is
anonymous and not tied to an email), so we can't get more
information about the problem or offer solutions; we can only
fix it based on the crashinfo. This will result in noise, due
to crashes caused by drivers.
We don't want people to send bug reports accidentally, but we
also don't want to encourage cancelling the report. This dialog
defaults to "view", so pressing enter neither sends the report
nor cancels.
We don't want people to modify crashinfo.txt before they send
it, since we want consistency. (Data sent is not re-read from
crashinfo.txt; it's simply kept in memory.) We also don't want
to give people the impression that changes in "view" will change
what's sent. At the same time, it's convenient to have the
crashinfo "view" function load notepad. So, crashinfo.txt is
marked read-only, so attempts to save over it in notepad will fail.
In this mode, we don't offer the option to load log.txt, or
point to a BTS. This is intended to make bug submission as
simple as possible for casual users. Keep the dialog simple
and to the point.
The id number that's displayed after a submission is intended
to be used as a reference; we can say "reproduce the crash,
submit the report and tell us what number is shown in the corner",
and easily locate the report. It's intended to be ignorable by
the most users, so no attempt is made at explaining what it means.
(It should probably be grayed out, but I havn't dug into it yet
to figure out how to gray it while still allowing the text to get
focus, so it can be copied.)
We send over HTTP, on port 80. This is probably the most likely
way to be able to send data out without any configuration.
(The localization support is incomplete.)
Steve Checkoway