Updated: 2023.01.31

There was a disagreement in fex-emu, with several technical and non-technical angles.

Ryan & Scott have chosen a new home page, fex-emu.com

I (skmp) will continue to slowly work on hex-emu, on a non-sponsored, free time basis, for now.

Differing Technical Priorities between the projects

As a emudev old-timer, over the years I've learned to work from a "guarantees to guest" viewpoint, with well defined specs and boundaries on what is emulated, to what extent, and what is not.

My experience from both open source and commercial emulators I've worked on has lead me to a strong preference for that position, over ad-hoc, auto-magical, wishful, leaky abstractions that constantly need to be re-defined through tedious debugging.

While fex has similar priorities in some cases, in other, critical ones, it does not.

The loose definition of the IR ops, the often inaccurate and partial implementation of the Linux kernel ABI, the casually treated leaky rootfs 'overlay' design, and the complete disregard for several dead ends in the thunks direction were some sources of unresolved disagreement and conflict.

To be fair, the scope of a x86/64 Linux user-mode emulator is vast, and temporary solutions can be stopgap way of advancing development.

I don't agree with the view of that being the end goal, though.

As a developer, I prefer code-bases that are consistent, dense and generative over confusingly named, organically-grown spaghetti style of code.

Emulators can be very hard to design cleanly, as typical OOP patterns don't map well, and hard real-time performance is often a key priority.

Unfortunately, the way fex-emu source code was (is?) organized could quite objectively be considered subpar and confusing. I've learned myself from past projects, primarily reicast, that if technical dept is systematically ignored it only gets worse.

To list a few problematic aspects of the code-base, af or September 2022.

• Confusingly named files that don't actually match the class names contained within.
• Source and accompanying Header files having different names.
• Several classes and subclasses having the same name, on same named files, in different namespaces / folders.
• Confusing, non-obvious folder structure.
• Confusing, non-obvious type names.
• A widespread violation of DRY and SRP principles, entangling highly unrelated parts of the code-base together. This is most obvious in the configuration and guest syscalls/os systems.
• Widespread inline forward declarations in header files, which has led to several forward declarations of types that don't even exist any more.
• Over complicated, over abstracted code-base for the scale of the project. Eg, the C interface of the C++ 'context' class.
• A ton of unused, legacy code, that still defines structural aspects of the project.
• Several instances of unfactored, duplicated code which has inconsistently diverged over time.

Summarizing, working in the code-base often felt like working on a highly-legacy project, before even having a stable release.

All projects have growing pains, even more so highly complicated ones. And we all write bad code while focused on other aspects. Without a focus on keeping the source code in a good shape, long term, working with it can be very frustrating.

In hex-emu I'm trying to work towards refactoring, cleaning up, and providing stronger guarantees.

Preferring consistency and predictability over performance and wishful abstractions, while planning for configuration options that offer trade-offs when performance becomes a priority.

As I had registered this domain myself, and due to how things went down, I decided to keep a notice of the situation here before letting the domain expire in April 2023.

There used to be an iframe of fex-emu.com here for continuity for a few months. I assume people have updated their bookmarks at this point.

hex-emu homepage on emudev.org

fex-emu.com homepage

Cheers for reading this far,
~ skmp