The old code will not correctly report the number of threads on CPUs with
more than one processor group, i.e. when there are more than 64 logical
processors (threads).
The signature for calloc is void *calloc(size_t num, size_t size), where num
is the number of elements to allocate, and size is the size. Therefore, to
allocate a single struct, we should pass 1 for num and the size of the struct
as size.
In some places, we use the opposite order, and we should flip it.
We now enumerate all IVSHMEM devices, sort them based on PCI bus, slot,
and function numbers, then index from the resulting order. This should
be consistent across boots.
To help the user identify the correct IVSHMEM device, we also print the
list of IVSHMEM devices on startup.
When our window is destroyed, our timers are also destroyed. This causes our
attempt at destruction to fail. Instead, set MessageHWND to NULL in the
WM_DESTROY handler and don't try destroying the timers if the window is gone.
This so called "enhanced" event logic is completely flawed and can never
work correctly, better to strip it out and put our faith in windows to
handle the events for us.
And yes, I am fully aware I wrote the utter trash in the first place :)
Due to a failure to understand atomics when this code was originally
written it has a critical flaw with the fast path where an event could
be signalled when it should not be. This change set corrects this issue
by using atomic operations.
People often miss the warnings about invalid arguments in their command
line, this last minute patch attempts to address this by making
warnings, errors, fixme's and fatal errors stand out if stdout is a TTY.
This commit uses the DbgHelp library which is shipped with Windows to
generate stack traces with function names and line number information.
It takes advantage of the pdb file generated by cv2pdb that is now
installed with looking-glass-host.exe.
This makes it a compile-time error to call a function that semantically
takes no parameters with a nonzero number of arguments.
Previously, such code would still compile, but risk blowing up the stack
if a compiler chose to use something other than caller-cleanup calling
conventions.
