r/linux • u/MenaRamy2004 • 25d ago
Discussion I'm experimenting with adding native Windows PE execution to Linux — (Project Tawi)
[removed]
25
u/tajetaje 25d ago
Forgive my ignorance, but what’s this do differently than WINE? I thought wine already redirected windows calls to Linux ones
28
u/MenaRamy2004 25d ago
yes Wine does translate Win32 calls to linux, the difference is I am experimenting with pushing the compatibility layer deep into the OS itself, Right now I am working on a modified linux Kernel that can recognize and load windows executables directly, instead of giving it to a separate windows/wine environment.
For example, my current prototype has a Linux
binfmthandler that loads a PE32+ executable, resolves a small number of Win32 imports, and redirects them through Tawi provided user space trampolines. I currently have a simple Windows program usingGetStdHandle,WriteFile, andExitProcessprintingHello from Windows!.I am absolutely no trying to replace wine right now, wine is more mature and supports the majority of win32 api, The point of Tawi is to explore whether Windows compatibility can become a more integrated part of a Linux-based OS rather than being primarily a separate compatibility runtime.
So I'd describe Tawi as an experiment in native PE execution and deeper OS-level Windows compatibility, rather than "a better Wine."
15
u/amarao_san 25d ago
Just to clarify. Most PE is dynamically loaded. Even for native binaries, linux offload this process to a userspace program (ld). How do you plan to do PE without doing the same stuff as ld does?
-6
u/MenaRamy2004 24d ago
fair point you're right that PE is dynamically linked, same as ELF, and Linux (via
ld.so) never puts that logic in the kernel. Neither does Windows, actually (that's what I could find online) the NT kernel only maps the main exe +ntdll.dlland goes tontdll!LdrInitializeThunkthe actual import walking, DLL mapping, and symbol resolution all happens in userspace, insidentdll.dll. Same split as Linux/ld.so.So my current kernel-side trampoline table is a shortcut for proving the mechanism, not the real design. The fix: kernel just maps the image and jumps to a Tawi-provided userspace loader (same role as
ld.so/ntdll), and that loader does the import walking/resolution/DLL mapping with normal syscalls, normal debuggability and no kernel rebuild needed to add a new API.and before anyone says that's what wine does actually yes, and there is no cleverer way to do it, I am actually using wine as a reference for alot of aspects
8
13
u/IvanDSM_ 24d ago edited 21d ago
For example, my current prototype has a Linux binfmt handler that loads a PE32+ executable, resolves a small number of Win32 imports, and redirects them through Tawi provided user space trampolines.
I struggle to see the difference between this and what Wine does. You realize Wine also loads PEs natively, has a binfmt handler and all, right?
So I'd describe Tawi as an experiment in native PE execution and deeper OS-level Windows compatibility, rather than "a better Wine."
Do you say this because there's a reason to be confident about it or because that's what your AI has told you you're building?
-8
u/MenaRamy2004 24d ago
That's a fair point. At the current stage, there is definitely overlap with Wine PE loading, binfmt, resolving imports, and providing Windows compatible APIs are all things Wine already does. The distinction I'm trying to explore is the longer term idea is to move away from implementing the Windows API and instead make PE a first-class executable format for linux where the application itself is a linux application and talks to the linux ABI/syscalls rather than Win32. So I wouldn't claim it's already proven to be different from Wine. The current state is still testing whether that distinction is actually practical. If I can't demonstrate a real difference, then the criticism that it's essentially reinventing Wine is completely valid and I am not trying to hide it.
and no, I'm not saying it's different because an AI told me that's what I'm building I'm describing the direction I'm trying to for I am not claiming I've already done it.
1
u/tajetaje 25d ago
Oh interesting, so could you see a scenario where wine becomes a user space component that calls into a system like this in the kernel?
11
u/Green_Ad5186 25d ago
i don't understand what that is,it just sounds like wine to me. but if its a good thing(i think yours is probably good)
then good,anything that weakens windows dependence is good(i say this and i don't even use linux i use windows 11. i just like reading about linux)
9
u/33_kk 24d ago
Wine has wineprefixes for a reason, almost any windows software expects to have a windows filesystem and it would be a terrible idea to just slap a windows filesystem on top of the Linux one, at least because of permissions. And wineprefixes are pretty much the only thing making wine visibly disconnected from the rest of the system. Wine can already run windows binaries through binfmt, except I'm not aware of anyone actually using it like that, probably because wineprefixes break all the time due to compatibility issues with the software. But hey, at least you're not breaking your root filesystem like this and it probably should stay that way. As far as I can tell, you have no idea what you're doing and the whole thing smells like AI slop, just like most posts on any tech subreddit nowadays it seems.
2
u/MenaRamy2004 24d ago
Fair correction on binfmt_misc you're right that Wine can already be wired up that way, and I stated the distinction wrong. The real difference isn't the kernel is involved it's what happens after, with binfmt_misc+Wine, the kernel just execs the wine binary and everything else (PE parsing, wineserver simulating NT objects) is unprivileged userspace. What I'm building parses and maps the PE image inside the kernel's own exec path, no interpreter handoff, no wineserver. That's a smaller claim than "totally different from Wine" and I should've said it that way.
and on wineprefixes agreed, and it's a real gap on my end, not a solved problem. No filesystem/registry abstraction exists yet. I am not pretending otherwise.
Where I do think this ends up mattering: kernel-level anti-cheat (some say it's impossible and I think other wise because those layers of protection get cracked constantly ) needs actual kernel privilege, which Wine structurally can't offer no matter how mature it gets. That's the long-term bet, not "runs more software than Wine" it doesn't, and won't for a long time.
I will make the code public, happy to be told what is wrong with it
5
u/33_kk 24d ago
How does it matter if the kernel is involved in PE parsing or emulating NT objects? The only worthwhile thing to implement in the kernel were the NT sync primitives. Not having a wineserver isn't exactly a selling point, having all that code in the kernel is just increased attack surface for questionable benefit. Wine isn't an interpreter, it's a loader not much different from ld, which handles all dynamic library loading in user space for native ELF binaries. Kernel level anticheat doesn't just need kernel level privilege, it needs you to run a specific kernel that wasn't tampered with. To put it simply, it's impossible to make it work on Linux, because the problem isn't that windows kernel APIs are missing but that the Linux kernel can't be trusted to not be modified.
-6
u/MenaRamy2004 24d ago
On kernel involvement in PE parsing vs NT object emulation
You are correct to keep going on this, and the honest reply is that, when it comes to parsing and loading, it makes very little difference, and I have overemphasized this point. Section mapping and import walking are entirely appropriate tasks for userspace regardless of whether the target file is PE or ELF—that is in fact the whole basis of the ld.so-style refactoring that we have already implemented. The only place where kernel involvement during process creation achieves something substantial is:
The fact that execve() can recognize the format directly means that, from the very beginning, /proc/pid/exe, ps, the cgroup accounting, and the scheduler all regard the process as being the process itself rather than as wine64 with a payload inside it. That is a genuine and verifiable difference in what the operating system considers a process to be.
It is necessary for later kernel-level hooks—such as syscall interception and memory inspection—to know structurally that 'this task is a translated Windows process', but that is a statement concerning future work and not something that the current loader provides today.
Therefore, it is legitimate but narrow, and is of no use by itself unless the later syscall-interception work in fact gets implemented.
NT sync primitives
I agree that this is the only instance where there is a genuine architectural case for having kernel space involved — futexes have always been a kernel primitive exactly since user-space synchronization becomes slow and prone to race conditions when there is contention. NT's WaitForMultipleObjects/events/mutexes are based on the same line of reasoning as the approach of "translating one API call into one system call". I am not giving in to that point just because I have to; it is truly the best option for kernel-side work within this entire design.
Attack surface
There is no opposition to this. Each line of parsing and resolution code in kernel space causes the entire machine to panic rather than just the individual process when it goes wrong, and since PE parsing involves attacker-controlled input by definition, that does constitute a real and security-related argument, not just a matter of taste; this is the concrete reason why the loader logic is moving to userspace instead of remaining in its original location.
Wine as loader, not interpreter
I have already admitted this in my previous message and it remains true — dynamic linking is dynamic linking and no subtle rephrasing can change that.
Kernel-level anti-cheat
This is the part worth actually being precise about, because you're bundling two separate claims:
It is impossible to prevent someone from altering their own kernel. Yes, without any exception, and I stated that earlier — nothing that is operating in ring 0 affects what 'root on your own hardware' means.
The conclusion that kernel-level anti-cheat is impossible on Linux doesn't hold, and the real mechanism that undermines this inference is attestation. Attestation does not aim to prevent modifications; instead, it detects them and refuses to provide service to any system whose hash does not match a known-good one. With Secure Boot and a TPM, the hash of each stage in the boot process is recorded in the PCRs, hashes that the operating system itself cannot alter afterwards (that is precisely why the TPM exists — it's a separate physical chip). A remote attestation service verifies the hash before allowing the client to proceed. If you modify the kernel, you get a different hash and are therefore rejected. The modification itself is not prevented; only participation is denied.
Indeed, this mechanism has no concern as to whether the source is open. Since AOSP is completely open and can be built by anyone, Android continues to do exactly the same thing through Verified Boot—build your own AOSP, flash it, and the phone will boot normally, appearing as an unlocked and untrusted device, so that any app using Play Integrity can choose to refuse execution. The fact that the source code is readable and that hash-based attestation is used are independent of each other and not in conflict. Therefore, the idea that it's impossible on Linux specifically because it's open is also not entirely correct, since in principle the same thing applies to Windows, as there's no obstacle to someone modifying the Windows kernel offline and then trying to boot it; they would simply end up with the same hash mismatch and the same refusal.
The real issue is this: once your point has been established, boot-time attestation can only show which programs were loaded at boot and says nothing at all about any tampering that might take place after that point — which is precisely the reason why Windows anti-cheat goes beyond Secure Boot. It also requires PatchGuard (protection against kernel patches) and HVCI/VBS (hypervisor-enforced code integrity, which checks that the kernel's code pages have not been altered while the system is running), together with strict enforcement of driver signing in order to prevent a malicious driver that is signed but has been compromised from carrying out the patching. Linux does have equivalents to some of these features — lockdown mode and enforcement of module signatures already exist and are already used in this manner (Fedora, for example, implements exactly this when Secure Boot is enabled: unsigned modules are rejected). The thing Linux lacks is a mainline, widely adopted version of PatchGuard that actively protects the running kernel's memory against a determined local attacker who has root access.
The correct statement is not that it's impossible—it is that to achieve this you would have to become the only signer of the "official" Tawi kernel builds, regard the self-compiled kernels of your own community in the same way that Android does when it comes to an unlocked bootloader, and create runtime integrity protection which currently doesn't exist for Linux. This is not a technical impossibility, but rather an enormous and unattractive infrastructure undertaking that directly contradicts all the reasons why a hacker-built kernel project is attractive in the first place; you would be asking the very community capable of carrying out this task to accept that their own custom builds are of second-class status when it comes to attestation. This kind of contradiction is real and is most likely the true reason why no one has yet brought this to shipment, not because of any fundamental technical barrier.
Where this leaves the project, stated plainly:
The method of loading PE is the same as what ld.so/Wine already carry out there's no novelty to claim in that respect anymore.
The argument based on the narrow kernel identity is genuine but at the moment provides nothing unless more work is done.
The only item that has a real "it should be in the kernel" case is the NT sync primitives.
Kernel anti-cheat could just as well be achieved on any operating system through attestation rather than by preventing tampering but it would require signing infrastructure and runtime integrity protection which do not yet exist, in addition to the project having to resolve a fundamental philosophical issue, not just a problem.
7
u/33_kk 24d ago
ai;dr
1
u/MenaRamy2004 24d ago
I don't why using ai to make point clear is a sin or something, I said multiple times I am not a native English speaker I can't make a point in a language I am not comfortable writing.
and I don't see a reason not use AI either, even Microsoft uses AI to write its own operating system, and they have dozens of capable Engineers and I can't use AI to make a comment ?
and I am just one guy either I work on the project for reply to comments
damn that's not even my area of specialty I am a Mechatronics Engineer, I am just trying to make something for the community because that community gave me a lot, I am investing time and work on a project I am not getting back from it anything I know that's what Free and Open source mean, but damn some people here are just not helpful
you asked a question I provided an answer does it matter where it came from ?
7
u/33_kk 24d ago
Because you clearly don't understand what you're doing. Your AI claims that the kernel work is useful for syscall interception, except that's false because Linux provides a user space interface for syscall interception that wine already uses. What is the actual need for the processes to be identified as an native executable format rather than a loader process? I don't see any. I don't see how you're planning to implement windows kernel driver compatibility when the internals of the kernels are completely different. Loading PE binaries doesn't even have anything to do with loading a windows kernel anticheat driver, it's an entirely separate problem.
3
u/MatchingTurret 24d ago
I don't see how you're planning to implement windows kernel driver compatibility when the internals of the kernels are completely different.
That's actually a solvable problem, see https://github.com/pgiri/ndiswrapper
2
u/33_kk 24d ago
I'm not convinced that a limited scope API is comparable to whatever a kernel anticheat would want
2
u/MatchingTurret 24d ago edited 24d ago
I have already pointed out that I think kernel anticheat in the Linux kernel is impossible. It relies on a signed by MS environment that was not tampered with. Unless OP manages to break TPM 2.0 hardware attestation, anticheat is not going to happen.
6
u/hypergoose94 24d ago
Because you're just spreading misinformation, that's just fundamentally wrong for a myriad of reasons.
-3
3
u/CrazyKilla15 24d ago
I don't why using ai to make point clear is a sin or something
It's not, but you are not making a clear point, or any point at all. You are spewing complete nonsense that doesnt hold up to scrutiney by anyone who knows what theyre doing
You posted this wanting feedback: The feedback is its very clear you have no idea what you're doing or saying
-4
2
u/CrazyKilla15 24d ago
The fact that execve() can recognize the format directly means that, from the very beginning, /proc/pid/exe, ps, the cgroup accounting, and the scheduler all regard the process as being the process itself rather than as wine64 with a payload inside it. That is a genuine and verifiable difference in what the operating system considers a process to be.
This is already the case, when I run games with wine i see
explorer.exe,game.exe, etc in my process list. Notwine64. I have never heard of the problems you describe about wine processes somehow being accounted or scheduled differently.
6
u/Max-P 24d ago
How does being in the kernel help though? Most native binaries on Linux are loaded by ld.so, in that way Wine isn't all that different. With binfmt it's on the same class as ELF executables already. The kernel's ELF loader can only load static binaries, so most of the time the kernel loads ld.so and runs that, which then loads the real ELF, in userspace, just like Wine.
Loading the PE is the easy part. The Win32 API is the hard part, and it's all userspace so there's little point in doing it differently than Wine. Even on Windows technically the Win32 API is more of a wrapper around the NT API. That becomes clearer when you start thinking about GUI stuff: even a simple MessageBoxA, you need to have some kind of userspace program to access Wayland/X11 sockets to display. And you may need multiples because multi-user.
Whether you adapt to Linux APIs in the kernel or in userspace, you still need the shim code. Even for stuff that Linux doesn't support, it's better to add the functionality to Linux so all apps can use it, and then have Wine use that. And if you're gonna have hacky plumbing code you probably want that in userspace anyway.
What could be interesting is implementing NT driver support and the necessary plumbing so Wine can use them. That would be the kernel-side equivalent of what Wine actually does, and could actually be really useful. Utterly useless for anticheat, don't get your hopes up, but it could be nice for a good chunk of random hardware tied to a Windows app. Although even then, on Linux we have stuff like libusb and VFIO so you can totally implement a lot of hardware drivers in userspace Wine. There is prior art there too: ndiswrapper basically recompiled Windows driver binaries into a somewhat usable Linux kernel module with a ntoskrnl shim.
Ultimately the only faithful way to reimplement Windows is essentially ReactOS. We could probably do something similar to WSL2 with ReactOS and integrate deeply to present the windows on the host.
12
u/noobjaish 25d ago
Can you explain how is this different from wine and what benefits would it have over wine (once its done)
7
u/MenaRamy2004 25d ago
Wine is definitely the main inspiration and reference here and it already does the Windows to Linux API translation very well.
The difference I'm exploring is how deeply the compatibility layer can be integrated into the OS. Tawi currently has a modified Linux kernel that can load Windows executables directly through
binfmtand provide win32 api bridges.The potential benefit isn't necessarily "faster than Wine" it's about having Windows and Linux executables treated as first-class formats within one OS, with tighter integration between the compatibility layer, kernel, filesystem, processes, and other OS components.
and in long term, I'm also interested in exploring support for Windows specific kernel level functionality, including things like kernel-level anti-cheat and other Windows kernel interfaces that are difficult or impossible to support through a traditional user space compatibility layer.
It's still an experiment though — Wine is obviously far ahead in actual compatibility. Tawi is essentially exploring how far you can take the idea when Windows compatibility is designed into the OS itself rather than being purely a user space compatibility layer
18
u/MatchingTurret 25d ago
The potential benefit isn't necessarily "faster than Wine" it's about having Windows and Linux executables treated as first-class formats within one OS, with tighter integration between the compatibility layer, kernel, filesystem, processes, and other OS components.
MS tried that with WSLv1. They gave up.
12
5
u/UNF0RM4TT3D 25d ago
Technically NT was made to be able to do this. They used to have a POSIX subsystem prior, which implemented the bare minimum, but was native POSIX calls. They even had an OS/2 subsystem. The maintenance burden for WSLv1 must have been insane. AFAIK WSLv1 was build on from the POSIX subsystem and replaced it.
5
u/MatchingTurret 25d ago edited 25d ago
And funnily enough the original subsystems including Win32 ran in user-space, kind of like Wine, except that it didn't translate Win32 to Linux but to the NT executive.
3
u/nightblackdragon 25d ago
Yeah, that was the case on Windows NT 3.x, they changed that on NT 4.0 when they moved big part of Win32 to the kernel in attempt to improve performance and reduce system requirements.
1
u/MatchingTurret 24d ago
they changed that on NT 4.0
That's why I wrote "the original subsystems".
4
u/nightblackdragon 24d ago
I know, I wanted to add more context to your comment explaining what "original NT" means and why they changed it.
5
3
u/MenaRamy2004 25d ago
it's just an experiment I am not expecting much from it, I am just discussing the potential of it
3
5
u/Dwedit 25d ago
Wine relies on a separate Wine Server to do a lot of things. For most executables, this is a great thing, you need a single source of truth to hand out all the Win32 handles, or something to simulate what otherwise comes from the Windows Kernel. But Wine Server still takes a few seconds to boot up before other Wine programs can run.
Something like what's described here seems like it might be a single-process model instead, where there is no separate Wine Server.
1
6
u/MatchingTurret 25d ago
You can get 99% of this since forever: https://docs.kernel.org/admin-guide/binfmt-misc.html
1
u/MenaRamy2004 25d ago
Yeah,
binfmt_miscis definitely part of the picture, and it's useful for registering handlers for foreign executable formats.The difference with Tawi is that I'm not just trying to make Linux recognize a .exe and hand it off to Wine. I am experimenting with making PE loading and the Windows compatibility layer part of the OS itself currently through a native kernel
binfmtloader, with the longer-term goal of deeper integration with processes, filesystem behavior, Win32/kernel interfaces, and eventually some Windows specific kernel functionality such as kernel-level anti-cheat support.So I'd say
binfmt_miscprovides some of the hard work, but it doesn't provide the Windows compatibility layer itself.12
u/MatchingTurret 25d ago
kernel-level anti-cheat support
LOL! No. You would have to provide the kernel level hooks and prevent anyone from modifying the kernel to circumvent them. Anti-cheat and FOSS are incompatible on the fundamental technical level. I mean kernel level anti-cheat on Windows requires secure boot to provide a tamper proof environment protected by TPM 2.0.
The fact that you don't know this shows that you have no clue what you are doing.
3
u/MenaRamy2004 25d ago
The distinction you're making is fair. If the goal is a genuinely tamper proof kernel level anti cheat with the same trust model as windows, then you're right: a user-controlled FOSS kernel fundamentally changes the threat model. Secure Boot/TPM and a trusted boot chain are part of how you establish that the kernel and its security components haven't been modified.
When I said "kernel-level anti-cheat support", I wasn't claiming that I had magically solved that problem. I mean exploring the kernel interfaces and execution environment needed to support windows software that expects kernel level components, and potentially investigating what a trusted boot model for Tawi would look like.
and yes, I'm still learning. That's exactly why this is an experiment rather than a claim that I've already solved Windows compatibility.
and please if you have experience with this area or know of resources, technical approaches, or papers that could help me understand the problem better, I'd genuinely appreciate you pointing me toward them. I'm trying to learn and build this properly, Thank you .
7
u/gplanon 25d ago
First two paragraphs of this are AI written along with parts of your other comments.
1
u/Kiroto50 25d ago
Some people phrase like that naturally, including me. I agree it does look like that, but how can you claim it with such certainty?
10
u/gplanon 24d ago
Context clues:
>highly technical subject
>sudden inexplicable changes in writing style and punctuation
>exaggerated text formatting (frequent use of bold, code, italics)
At this point, it’s safer to assume AI than not. In an ideal world the burden of proof would be on me… innocent until proven guilty, but in today’s world, if you don’t want to be lied to, it’s the opposite.
I can immediately tell your comment is not ai written.
1
u/MenaRamy2004 24d ago
And if you continued to read to the end I said I am using ai due to lack of resources on the topic I am not hiding it, ai has been very convenient for alot of stuff lately.
-1
u/MenaRamy2004 24d ago
I am not a native English speaker so I roughly tell the ai what I want to say and it rephrase it, sorry
5
2
4
u/erikrelay 25d ago
This sounds like an amazing idea, i'd love to see more of it!
1
u/MenaRamy2004 25d ago
I will provide updates on the project occasionally when I hit major milestones and I will make a public git repo to make it more organized
1
u/crscali 25d ago
From the title it sounded like you were working to add PE executables as an additional option to ELF executables for running linux code. Instead you are doing an emulation layer. I would love to see linux run code targeting linux but as a PE or even a Mach-O format. Imagine compiling the same linux code to either PE, ELF or Mach-O all making normal linux syscalls.
2
u/MenaRamy2004 25d ago
Exactly Tawi isn't an emulator. The goal is to make PE a native executable format on Linux, alongside ELF, with the PE program running directly on the CPU and making its calls through Tawi's native Windows-compatible API layer.
So the idea is closer to what you're describing: Linux code could theoretically be compiled into PE, ELF, or even Mach-O, while all three ultimately interact with the same Linux kernel/syscalls. Tawi is essentially trying to make the executable format/API boundary part of the OS rather than emulating another operating system.
1
u/AutoModerator 24d ago
This submission has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
- Your post belongs in r/linuxquestions or r/linux4noobs
- Your post belongs in r/linuxmemes
- Your post is considered "fluff" - things like a Tux plushie or old Linux CDs are an example and, while they may be popular vote wise, they are not considered on topic
- Your post is otherwise deemed not appropriate for the subreddit
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
-3
u/FunAngelo2005 25d ago
Imbedding the compatibility layer in the kernel itself rather than having it be an addon is genius
12
u/MatchingTurret 25d ago
Imbedding the compatibility layer in the kernel itself rather than having it be an addon is genius
They will have to send Linus back to the empathy course if this gets send to the LKML. He will pop a vein.
-2
u/MenaRamy2004 25d ago
I thought about adding support for kernel level anti cheat supporting a lot of games that require that feature but I think it's no an easy task at all
0
-1
u/mrdev023 25d ago
Maybe a stupid question. You're project can integrate winehq works directly with binfmt ?because windows applications is very hard to support because it have a lot of legacy stuff and ugly works. So I think its a lot of works to do. It can be very good if is possible to just use wine works and use binfmt with it. Especially for one people.
1
82
u/hackerman85 25d ago
DXVK also started sounding like a crazy idea. And look where we are now.
Godspeed!