Before this change, dwCreationDisposition parameter of CreateFileA was
ignored by wibo. However, it turns out that PSYLINK.EXE in PsyQ 4.4
sometimes depends on correct handling of that parameter.
When building overlays with PSYLINK.EXE, it sometimes opens the
resulting overlay file the second time, with OPEN_EXISTING creation
disposition (as opposed to TRUNCATE_EXISTING). Before the change,
wibo opened that file with fopen(..., "wb+") which truncated the file
even though OPEN_EXISTING (non-truncating) was requested. This affected
https://github.com/foxdieteam/mgs_reversing, where one of the overlays
(camera.bin) was built incorrectly when using wibo (worked correctly
on Windows or with wine).
This commit adds proper handling of dwCreationDisposition parameter.
The file now can be opened in truncating or non-truncating mode.
Additionally, the implementation now reacts correctly to file
existing/non-existing as specified by the requested creation disposition
mode. For example, if CreateFileA is called with OPEN_EXISTING and the
file does not exist it will set an error and not create a new file
(the previous behavior). If the file exists, it's opened in
non-truncating mode, as TRUNCATE_EXISTING or CREATE_ALWAYS is required
for truncation.
After the fix you can correctly build the whole mgs_reversing project
with wibo - tools running under wibo: ASMPSX, ASPSX, CC1PSX 4.0 & 4.4,
PSYLINK. I have NOT tested other executables apart from those.
* Ensure we don't reallocate during 2GB address space block
* Use std::string_view and std::from_chars to avoid allocations
* Use MAP_FIXED instead of MAP_FIXED_NOREPLACE
* Use raw syscalls and stack buffer
* Use exit(1)
`TlsGetValue` disambiguates 0 and an error by relying on `GetLastError`. Depending on the program state, `GetLastError` could be non-0, even though `TlsGetValue` succeeded. Resolve this by always setting `wibo::lastError`. This matches the behavior described by the documentation.
Additionally, when reading resources, later versions of mwcc and mwld call `GetModuleHandleA` with the program path, and then call `LoadStringA` on that handle. Support this behavior by _actually_ loading the PE at the path passed in to `GetModuleHandleA`, instead of assuming it's the current program.
(This is especially useful because sjiswrap relies on overriding `GetModuleFileNameA`, so the wrapped program reads its own resources, rather than sjiswrap's.)
Other small changes:
- Add ms-win-crt `exit` & run atexit funcs
- Implements vcruntime `memmove`
- Implements kernel32 `GetModuleFileNameA`
* GetLocaleInfoW for ee-as.exe 991111b
* Try to do it the right way
* 3rd time's the charm?
* round 4
* it doesn't matter now what happens i will never give up the fight
* comments
* fin
