mirror of https://github.com/decompals/wibo.git
c6fa592a31
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. |
||
---|---|---|
.github/workflows | ||
cmake | ||
dll | ||
test | ||
.clang-format | ||
.clang-tidy | ||
.dockerignore | ||
.gitignore | ||
CMakeLists.txt | ||
Dockerfile | ||
LICENSE | ||
README.md | ||
common.h | ||
files.cpp | ||
files.h | ||
handles.cpp | ||
handles.h | ||
loader.cpp | ||
main.cpp | ||
processes.cpp | ||
processes.h | ||
strutil.cpp | ||
strutil.h |
README.md
wibo
A minimal, low-fuss wrapper that can run really simple command-line 32-bit Windows binaries on Linux - with less faff and less dependencies than WINE.
Don't run this on any untrusted executables, I implore you. (Or probably just don't run it at all... :p)
cmake -B build
cmake --build build
build/wibo
Rough to-do list:
- Implement more APIs
- Do something intelligent with Windows
HANDLE
s - Convert paths in environment variables (and the structure of
PATH
itself, maybe) to Windows format - Implement PE relocations rather than just failing unceremoniously
- Make the PE loader work for DLLs as well in case we ever want to load some
Related projects: