Index
> Windows > WHP layer for 64-bit fasmg EXE/DLL |
| Author |
|
|
bitRAKE 23 Apr 2026, 21:53
This directory is a Windows Hypervisor Platform projection of the `fasmg` core. It builds a normal command-line executable and a modern Win64 DLL that both run the same 32-bit assembler core inside a WHP partition.
Features [compressed] cacheable startup state which allows bypassing include files! (slower); support 4GB of memory for the fasmg core. DLL supports timeout, cancel and other options. (Different interface from standard DLL.) The caching introduces an interesting use case: if you've engineered a product of various micro-controllers and written a DSL for fasmg to compile into code for your product. It's possible to distribute the cache for a special interface without distributing the include files! Be creative, you'll find other use-cases. * Note: Uncompressing in fasmg/fasm2 directory is the intended structure.
_________________ ¯\(°_o)/¯ AI may [not] have aided with the above reply. |
|||||||||||
23 Apr 2026, 21:53 |
|
|
bitRAKE 28 Apr 2026, 08:20
The caching feature has been in the works for some time - many prior posts addressed concerns with fasmg/2 startup: cache compiler state in a meaningful way, FASM2 - Candidate to Benefit from Persistent Precompilation?, and I'm sure there are others.
It's possible to have a sufficiently complex source where cached startup would be faster, but presently that is not the case with any sources I'm aware of -- fasmg core is just too dense and algorithm efficient (and the host-side memory system is quite efficient). This doesn't mean the caching couldn't be used for greater efficiency with fan-out of common source compiles. For example, a directory of small object file sources. They can all use the same memory mapped file, decompressed into the partition. One would need to engineer a WHvClonePartition, likely with a host-side copy-on-write semantic, and dozens of partitions could be spun up quite fast. I'm not posting this to github -- it's just a feature for the board and those who chose to communicate here. Although the code is in the public domain, I hope you will respect this. |
|||
|
28 Apr 2026, 08:20 |
|
|
bitRAKE 02 Jul 2026, 03:57
One reason to cache startup, if you include the whole win32 API surface.
Code: { "arch": "x64", "constants": 85670, "enum_values": 59563, "flexible_arrays_treated_as_one": 857, "functions": 17083, "interface_guids": { "conflicting_export_guid": 0, "from_exports": 6, "from_metadata": 7514, "iid_constants_without_interface": 0, "interfaces": 7579, "missing_guid": 59, "with_guid": 7520 }, "json_files": 304, "property_keys": 2432, "renamed_symbols": 75, "string_constants": 7055, "types": { "Com": 7579, "ComClassID": 2482, "Enum": 7005, "FunctionPointer": 2617, "NativeTypedef": 248, "Struct": 12397, "Union": 1102 }, "unicode_aliases": 2491, "unresolved_refs": {}, "uuid_constants": 5432 } |
|||
|
02 Jul 2026, 03:57 |
|
|
bitRAKE 11 Jul 2026, 02:57
The above API set has been vetted end-to-end through several build trajectories. The usage matrix looks like:
legacy(32-bit, 64-bit), calm(64-bit) pe, link (coff, newcoff) direct, apiset Currently advancing the CALM projection because the API surface is made more vertical and it has more feature opportunities going forward. Should eventually support 32-bit, but 64-bit is the priority. Even if you don't like the syntax the tools can be used to create various abstractions. _________________ ¯\(°_o)/¯ AI may [not] have aided with the above reply. |
|||
|
11 Jul 2026, 02:57 |
|
< Last Thread | Next Thread > |
Forum Rules:
|