You’re thinking, as someone else said, of P = NP. This is technically an unsolved problem. We don’t know if P = NP is true, there is no proof that guarantees it. However, it’s looking pretty unlikely.
This problem would have huge consequences for a wide range of fields, and it would break most cryptography and encryption algorithms we have (assuming it is proven true).
Anyway, this is what Anubis is already doing. That’s why OP complained about being stuck for 3 minutes with the CPU at full blast. Anubis gave the PC some problem that was difficult to compute. The problem itself was not important, it’s just to keep the computer busy for a bit. (The idea is that this significantly slows down spam bots and other automated access, I believe).
Of course Anubis has to verify the answer is correct, and that the client didn’t just send garbage. So the problem Anubis already uses is one that is easier to verify than to compute.
Btw, it is possible to verify solutions where checking is as expensive as solving. You provide each client with at least 2 problems. One where you already know the answer, and one where you don’t. You have the client solve both. If the known one is good, you let them through, and add the unknown one to the known set. You can even verify it by sending it to two other clients, see if they all get the same answer. But I believe that this solution wouldn’t be required, because protein folding ‘violates’ the P=NP problem.
So, both Linux and Windows comes with a component called the “Kernel” (technically, Linux is the kernel, and the OS is something like Ubuntu, Fedora, etc…). This Kernel sits between the actual hardware and the rest of the operating system. It is responsible for things taking your app and loading it into memory, then handing the starting point to the CPU, things like this.
Since both of these kernels are developed independently, and basically from scratch, they work quite differently. When a program (app) is launched, the operating system needs to know a lot of small details in order to actually run it. What it needs to know and how to find it is quite different between Linux and Windows. Windows “Portable Executable” files (.exe files), and linux uses Executable and Linkable Format files. Your idea would be to simply re-arrange and augment the data in this header so it executes on the other platform, right?
There is a major wrinkle with this though, and that is the system libraries. Both the OSes have functionality to make it easier to write applications, provided by the OS. Things like sound libraries to write sound to the speakers, or graphics APIs so the application can draw to the screen. For Linux running on Windows, you can just look at what Linux provides and emulate that, or grab the source code and port that to Windows. However, the reverse is not so easy, because Windows is closed-source. Rebuilding every windows API from scratch is quite difficult, and made harder because the architecture is different, and solutions that are easy to provide in Windows might be quite hard in Linux.
It’s this library gap where the value of Wine comes from, and how it works.
You might ask, then, if it’s possible to run both kernels, and provide both options. Yes. In fact, this is how WSL on Windows works. It runs a customised version of the Linux kernel as a Windows application. Likewise, docker allows you to run a Windows nanosever, which is somewhat similar. However, running a container has more overhead than running the system API translations.
Running them ‘natively’ doesn’t really make sense, in the same way I cannot connect K’nex pieces to my Lego model directly. The two operating systems simply have different shapes, and cannot be directly connected.