Hey, looking for feedback on my guard page implementation.
I wasn't sure on how to structure the additional windows specific memory
flags, since the emulation backends won't like additional guard flag. I
opted to create a new `memory_permission_ext` enum to hold the guard
flag, and a `nt_memory_permission` struct to wrap the "common" memory
permission flags, with the new extended flags. This struct implicitly
coerces to the original `memory_permission` to reduce the amount of
changes for the PR.
This however meant that I changed signatures of `map_memory` and
`apply_memory_protection` in `memory_interface` to accommodate this new
structure, and was an afterthought.
The `map_nt_to_emulator_protection` function might also need some
attention now, too. For future reference, windows uses
[MiMakeProtectionMask](https://doxygen.reactos.org/d1/d9a/marea_8c.html#adfb66408771a4df77c1056cc2a99ef21)
in ntoskrnl to map `PAGE_*` flags to [MM PTE
constants](https://reactos.org/wiki/Techwiki:Memory_management_in_the_Windows_XP_kernel).
The test added to the `test-sample` binary seems to be passing.
Fixes#21
Bumps [deps/flatbuffers](https://github.com/google/flatbuffers) from
`00eec24` to `64e5252`.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="64e5252b4e"><code>64e5252</code></a>
Fix typo in code comment (<a
href="https://redirect.github.com/google/flatbuffers/issues/8549">#8549</a>)</li>
<li><a
href="00c30807ff"><code>00c3080</code></a>
Fixed typo in quick_start.md (<a
href="https://redirect.github.com/google/flatbuffers/issues/8592">#8592</a>)</li>
<li><a
href="c15fe421ba"><code>c15fe42</code></a>
Use correct default type for str (<a
href="https://redirect.github.com/google/flatbuffers/issues/8623">#8623</a>)</li>
<li><a
href="6b251aa1cf"><code>6b251aa</code></a>
Bugfix/new decode flag (<a
href="https://redirect.github.com/google/flatbuffers/issues/8634">#8634</a>)</li>
<li><a
href="6fe8afb3b6"><code>6fe8afb</code></a>
[CI] Moves swift actions to use next (<a
href="https://redirect.github.com/google/flatbuffers/issues/8632">#8632</a>)</li>
<li>See full diff in <a
href="00eec2445b...64e5252b4e">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
