`CreateThread` expects `lpStartAddress` to be a function with the
signature
DWORD WINAPI ThreadProc(
_In_ LPVOID lpParameter
);
on Win32 `WINAPI` is `__stdcall`, but `CheckHookThread` previously
had the effective signature
DWORD __cdecl CheckHookThread(LPVOID param);
because the calling convention was unspecified. The cast that was hiding
this error is also removed.
* In a previous update in 2021 many copyright ranges were truncated
accidentally, and some files have been copy-pasted with wrong years. These
dates have been fixed based on git history and original copyright messages.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* This was for no good reason anyway. You absolutely shouldn't be
creating threads in DllMain... but if you do, don't delay return from
it to wait on those threads, as they won't even start until you've
returned. Ooops.
* This means that all APIs pass byte string types. ALL strings everywhere
in the entire codebase must be assumed to be and treated as UTF-8 content
not ASCII.
* Gets rid of all the horrible %hs specifiers that caused warnings on
linux! Hooray.
* We convert to wide strings, or use wide characters, only when necessary
to use the Win32 API. Some windows specific code will stay in wide chars
just for convenience.
* Files are already serialised as UTF-8 strings for linux/windows binary
compatibility, so this change doesn't break backwards compatibility.
* This allows you to hook into processes that are difficult to launch
directly with the existing functionality in RenderDoc.
* This is rather risky, as it modifies the AppInit_DLLs registry key to
inject a small shim dll that checks for the desired process and injects
the full renderdoc.dll. If that registry key got left, or if there was
some incompatibility with the shim dll, you could have problems. It
should only ever be used as a last resort if there's no other way to
capture.
widberg