In the current ongoing effort for sourcemod to fully support 64 bits, we are introducing "virtual address".
# Explanation
Because SourcePawn does not yet support a 64 bits-wide type it's been impossible for any plugins to hold addresses in regular 32-bits wide variable.
A first attempt at solving this issue was made in commit ce1a4dcac0 therein dubbed "PseudoAddress", however this turned out to be an unsatisfactory solution, as any 'high' address if offsetted could turn invalid (or outright be impossible to map).
This leaves us with three alternatives :
- New type
- Convert Address into a handle
- Virtual Address
A new type is the most destructive solution, as it entails breaking every single Address related method. While that solution is still not off the table, we're reserving it as the last attempt should this commit fail.
Converting into a handle type is a good compromise between a brand new type whilst also preserving the Address methods. However, this comes with two issues: the first being that you can no longer offset Address, the second is that we would require authors to free the handle type which will be very confusing. This will likely not be implemented.
# Virtual address
Under a reasonable assumption, we've noted that the average plugin is unlikely to play with more than 4 GB of memory; this shouldn't be too surprising as all valve games were once 32bits and therefore limited to 4GB. Assuming this stays mostly true and a plugin isn't interested with the mapped memory of lesser known modules (like soundlib or matlib), it is fair to assume plugins are unlikely to access more than 4GB of mapped memory. Working with this in mind, we map the memory the plugins are likely to access to our custom virtual address ranges (from 0 to 4Gb, the values of which can fit on 32bits variable). If any memory was missed and plugins were to try an access it later those ranges will be late-mapped to our virtual address ranges until we run out of them.
In order to use virtual addressing, whether on 32 bits or 64 bits. Plugins must now "#include <virtual_address>", as well as use the new SDKCall_VirtualAddress, SDKType_VirtualAddress, LoadAddressFromAddress & StoreAddressToAddress where it's appropriate to.
* Add x64 Windows support
* undo changes of hook.cpp
* undo changes of hook.h
* undo changes of extension.cpp
* undo changes of listeners.cpp
* undo changes of signatures.cpp
* fix dhooks on x86
* Fix-up dhooks buildscript
---------
Co-authored-by: Kenzzer <kenzzer@users.noreply.github.com>
The passflags are only supported by SourceHook for virtual hooks and are ignored for detours with DynamicDetours. This caused confusion, so throw an error when trying to set e.g. the DHookPass_ByRef flag on detour arguments.
We always created a new vector object instead of changing the passed in vector directly. This works for the function being called using our changed values - but the caller doesn't see the changed values if it's passing a vector by reference.
Only create a new vector if there isn't one being passed in and set the values directly in the passed in vector otherwise.
* DHooks: Allow setting CBaseEntity* param to NULL #1751
The param had to be a valid entity and wasn't allowed to be set to NULL. Behave similar to SetReturn which maps INVALID_ENT_REFERENCE (or -1) to NULL.
* Update include documentation
