Formatting fixes.
Add comment about SSE2 builds not working on non-AVX(2) CPUs.
Don't build tests.
Prepare artifacts:
Switch to PowerShell.
Rename xenia.exe to xenia-canary.exe.
Add Releases:
This allows GitHub Actions to have a link to the latest artifacts like AppVeyor, except not slow as fuck.
Currently AVX-only since users will get confused which one to download (this is also why vfs-dump isn't included in the zip), and I don't know how to use the upload_url from another job configuration.
Releases won't be created for PRs.
You can download the latest Release from here: https://github.com/xenia-canary/xenia-canary/releases/latest/download/xenia-canary.zip
Changes NtAllocateVirtualMemory so that it ignores specified page size when a
base address is specified. Requires verification if this is desired behavior.
[Kernel] Make XexUnloadImage fully release the image
Previously XexUnloadImage did not cleanup the image fully,
and if XexLoadImage was to be called again on the same module,
it was not initialized fully, leading to a crash when using it.
[Kernel] (Partially) fix module refcounting
.xex module handles were retained twice in several places,
possibly causing them to leak.
More placed may have to be fixed too.
PR 1461
xenia-build:
Make release the default config. (no longer need --config=Release)
Add --cpu_arch argument;
Valid options are SSE2 (default), AVX, AVX2, and AVX512.
CI:
Remove unneeded env vars since we're only building Release for Windows anyway.
Only do tests on AppVeyor since they only work there.
AppVeyor:
Remove empty tab/space.
Remove unneeded cmds.
Turn deploy off since it didn't do anything.
GitHub Actions:
Rename GitHub Actions artifacts.
Premake:
Remove commented out garbage.
This fixes cases introduced by 52e836d0f81e752ba368717e68773b591adfa9cf
where thread handles get closed before the thread finishes.
Handle was assumed to be alive there, which was not true as
threads self-referenced only their objects, not their handles.
Affected games: Payday 2 Demo
Although this seems counter-intuitive, operating on handle
reference counters in
- ObLookupThreadByThreadId
- ObReferenceObjectByHandle
- ObDereferenceObject
allows to cleanly clean up handles for resources created elsewhere
and destructed by ObDereferenceObject (for example, threads with 0x80
creation flag). Operating on pointer reference counters alone
would leave a stray handle in the slots list.
Closing the thread handle should delete the thread object
if it's finished. When this handle was retained, closing the handle
left a lingering handle reference and thus this XThread would leak
Margen67