- client: if downloaded project list file is garbage, ignore it.
- all: accept <foo /> as an XML bool
- client: Apparently it is valid for the autoproxy to return successful API completeion but a null proxy list. Check for the null instead of crashing.
- client: only support one of the ati13* plan classes at a time. A couple users had not updated their amdcal* runtime libraries after upgrading catalyst drivers. This was leading to crashes of the project applications when work was supplied looking for the old DLL names.
- client: fix a handle leak I just introduced (From: Andreas a.k.a Gipsel)
- lib: Fix memory/resource leak. (From Nicolás Alvarez)
- lib: Add additional ATI descriptions.
- lib: Fix some inaccurate ATI capabilities in certain cards. (From: Andreas a.k.a Gipsel)
- lib: Fix memory/resource leak. (From Nicolás Alvarez) (reprise)
- client: restore calDeviceGetInfo(), add its info to COPROC_ATI struct (some plan class might need to know this).
- Code cleanup.
- client: better behavior if a GPU goes away:
1) if an APP_VERSION is missing a coprocessor, don't delete it and its files. (If the coprocessor returns, we won't need to re-download)
2) if a RESULT uses an app version that is missing a coprocessor, abort it (rather than deleting it). The client will report the result on the next scheduler RPC, and the server will make a new instance.
- client: fix bug where if you change project "no CPU/NVIDIA/ATI" prefs and update, the change wouldn't take effect until client restart.
- client: fix bug in enforcement of "no CPU/NVIDIA/ATI" prefs
- client: make the order of the result vector consistent with the order used to select coproc jobs
- client: improve coproc_debug messages
- client: if a task is running, uses a GPU, and the system has >1 GPU, append text to its resource string saying which GPU it's using
- manager: tweak Task properties text
- DIAG: Suspend threads right before extracting their context and then resume them afterwards. Otherwise we could end up in a deadlock state where both the main thread and a support thread are attempting to use the same system resource. In the last situation it was way down in Winsock.
- DIAG: Don't resume after the thread has been suspended, otherwise the thread stack may be trashed after extracting the context. This should still be okay though as by the time the diagnostics framework has gotten here it has already downloaded all the symbols it'll need.

- client: fix crashing bug introduced in [18605]