Currently a large switch-case is generated in uwin-remill. This is fine with small executables, but fails miserably with larger ones (order of 100,000s of recompiled functions) due to scalability problems in modern C++ compilers (see gcc bug). Either using binary trees or perfect hashing might be a good idea.

(For now perfec hashing seems very promising)

Will need to generate the memory map, apply relocations and imports (for target dlls) and then lift.

Replacing indirect dispatches to the native dlls with direct calls might also be a good idea.

Interpreting them correctly requires memory context & some environment. We need to pass those to (a hypothetical) Dump trait.

It's also still unclear how much env do we need (for str - at least memory ctx + current ansi encoding)

Probably gonna use OpenWatcom as a primary compiler, but should have several MSVC 6.0 binaries to test its runtime initialization.

Also, we somehow have to handle remill dependency (probably setting an external environment variable)

Initial idea was to use ICU, but now it seems that it's not the best way to do this: ICU encodings do not directly correspond to windows codepages. Probably an approach taken by wine is good enough.

win32::svc::locale is broken design, str is a good idea overall

This might be stubbed (I think), but it would be nice to have a generic implementation.

It is used in HoMM3 to get some DirectX services

As for now, attempt to recompile the lifted code for HoMM 3 binary with optimization results in utter failure due to enormous size of llvm Module produced. We either want to chunk the resulting bitcode, so that it can be optimized independently (and in parallel!), or create a custom optimization pipeline that will not get clogged by large modules (or, ideally, do both).

See also #6

See also lifting-bits/remill#451

What is threading model?

How do we map target execution threads to host threads, how we start, execute, suspend and stop them.

Design requirements:

• Be as portable as possible, i. e. require only the bare minimum from the host platform. Currently these platforms are considered:
  • linux on x86_64
  • linux on arm64
  • windows on x86_64 (still needs some work, but should work in principle)
  • Atmosphere with libnx on arm64 (Nintendo switch homebrew)
• Enforce strict mutual exclusion of thread execution (for both the target and native code). This is not required per se, but greatly reduces complexity (mostly concerning the memory ordering issues on arm64, which will require additional work on remill side of things)
• Be preemptive, i. e. be able to switch threads when target code is executing (think: inifinite loop). This is only for target code, native code may be written so that it will not get stuck.

Different existing implementations:

• qemu: make the code non-executable and handle the raised signal; needs to enforce special structure of the recompiled code (recompiled target code being separate from the native code). Needs some linker magic
• LuaJIT: run hook in every looping path (can be changed to just an interrupt variable check). Needs some work on remill side and research into how to find good places to put the hook in LLVM IR (see 1, 2, 3)
• luavela: similar approach; TODO: is it any different?
• wine: Uses a combination of sending an async POSIX signal and select inside it. Good approach, but, unfortunately, works only on POSIX platforms, needs adaptation otherwise. (see 1, 2)

All of these approaches might be feasible in uwin, but portability should be considered. (The most restrictive platform for now is the Atmosphere).

In the long run, we may want to implement something similar to layered fs (maybe even share some code using templates ;)), but for running HoMM 3 some basic RW access will be enough (in the first iteration INI files were used)

Preemting (probably round-robin); should also support iowait

Depends on #3

The current vision is to have a UNIX-style filesystem: you can mount various FS backends to different locations.

Possible backends include:

• static asset data (See #8)
• host system directory (need to handle the case-sensitivity/insensitivity situations)
• custom fs on a block device (might be useful for host systems without the file system, but no such are planned (yet))
• overlay (like linux overlayfs); may be useful to allow writes to the emulated application directory (like in HoMM 3, which uses it to store hiscores)

A function can contain multiple basic blocks, but now only the first basic block address will match with the label address and not all recompiled basic blocks will get the original function name.

It is not possible to fully statically analyze the program to find all of its basic blocks, so some fallback should developed at least. Emulation should be a good strategy: we always can do it. Also, this way we can dynamically collect all the basic blocks entered and feed them back to recompilation step, reducing the amount of code not recompiled.

Some library implementing the x86 emulation through fetch-decode-execute should be found (or implemented).

Some possible candidates (probably needs more research):

• halfix: C implementation. Uses A LOT of global variables, so probably will need to be refactored to be of use. On the other hand, it is fairly easy to separate the cpu emulation code from everything else
• JPC: Java implementation. Not usable per se, but might be worth taking a look at
• v86: JS implementation. Ditto
• libx86emu: C++ library. Seems to be good, but claims that not much instructions are implemented. CPU is fully isolated and instrumentable
• x86emu: C++ full-system emulator. CPU component does not seem to be isolated
• unicorn: CPU emulation framework. Seems to be cool, but probably would not work on Atmosphere (portability)
• Pokas x86 Emulator: Not entirely sure how good it is, but seems to be of a design similar to what is needed. Portability and instruction coverage are unknown, need to research more
• The x86 Emulator plugin for IDAPro: ???

These problems have risen after migration from unicorn to unicorn-engine crate, which itself was prompted by ABI-breaking update of 2.0.1 of unicorn itself:

I think there is some thread synchronization issue in the unicorn-engine (or LLVM, which was also updated!), as some tests are non-deterministically failing with multiple threads but are fine in single-threaded context.

Then there is a problem of the pushfd_pop_eax test, which simply does

pushf
pop eax

The mismatch is that rusty-x86 has EAX be 0, while unicorn has it be 2. This result is stable, but I don't think it's right

Quite early to start implementing, just notes.

Toolchain file: https://github.com/devkitPro/pacman-packages/blob/master/pkgbuild-scripts/switch.cmake

Virtual memory issue: switchbrew/libnx#503

For now, only basic support without precise semantics:

• WriteConsole (stdout and stdin)
• ReadConsole (might block the thread, so depends on #3 & #20)

Low-level functions will require to implement an actual screen buffer, which is not needed yet

For the begging, some API to get a frame buffer with desired resolution/pixel format & handle mouse and keyboard input. Should be enough to make HoMM 3 (which only uses a DirectDraw framebuffer and several offscreen DirectDraw surfaces).

If we were to implement the windowing, we might want to integrate more deeply with existing windowing systems. Or, for more portability, create our own windowing system, which will use this exact framebuffer as a target.

Need to implement:

1. function pointer type projections & codegen for them
2. a way to actually transfer execution back and forth between native and target code that will work nicely with selected threading model (see #3)

Should include a way for recompiled code/emulator to understand that the return is being done to the native code (probably by introducing a special return address)

Project name isn't cute enough - should rename to uwuin

The idea is to have some EXE files that should be lifted, recompiled and emulated and to have some assertions about it's behavior. One variant may be "their output should be same under WINE and uwin", but this is not the only way to do this...

Need to give some thinking in it

This is to ease debugging, because, as of now, when debugging, you can only know the location up to a basic block.
The location will (somehow) signify the original instruction address. Probably the filename should be path to the original module and line number should be the address.

What to look out for:

• need custom repo (patches, custom build configurations and that stuff)
• build for libnx with devkitpro (as one of targets)
• ability to use a edit package without publishing it (to debug linked changes)

Also a good question: how to do CI with dependent PRs? How will the build system at CI time will get the source/binary?

Need to implement a generic way to bundle non-executable data with the program. Probably will need several back-ends for different platforms (put to data/other section on Linux, as the load is on demand; use romfs for libnx/Atmosphere)

What it can be used for:

• embedding localization data (like encoding mapping tables or locale information)
• embedding the target executable file, dlls and their resources (for the ease of distribution)
• embedding the ICU data (if we will stick with it)
• etc

In windows each thread has a message queue, which can be accessed with various win32 APIs (PostMessage, PostThreadMessage, GetMessage, PeekMessage, TranslateMessage, DispatchMessage and others).