januari (1) februari maart (1) april mei (1) juni (2) juli (1) augustus (1) september (2) oktober (1) november (1) december (6)
What if they replaced Windows with Microsoft Linux...
2020-10-11 20:26 winmslinux [permalink]
→ What if they replaced Windows with Microsoft Linux
Hmm, in the very far future, sure, why not. But right now, it may be a little harder than these people make it look like. So, where are we now and what would it take? I'll do some projections here based on what I personally feel and think, so I may be far off, but I hope I can make some points some people may be overlooking in this matter...
We've got WSL which was a great first step in the right direction. The most important thing here, and I guess it follows from the work that was done to get Docker working on Windows, is that there's deep deep down in the mechanics of the kernal, made an opening into the very fiber of the very thing that makes Windows Windows, and a base into the task scheduler so it could work with both the heavy-handed old-style Windows processes, and the lighter, moderner Linux-like processes. (I believe it was chosen to call them pico-processes because I guess at that level you'll not really want to get tied to something specific like Linux there and then...) What I really think is the most important that this serves as a precedent, that the kernel team is listening and willing to budge in any direction at all. So yes perhaps into a hybrid model where Windows allows a little more *nix very close to it's internals, and move from there to a little more and more of this and a little less and less of the old until it's all fine and ready to move up into an emulation layer. At this point they should have seen this coming, Windows 95 had to be able to run 16-bit applications for DOS, and ran 'Windows on Windows' 16-bit application with a translation layer that would convert all the calls to the underlying system 32-bits system. So, if you're on Windows, check your machine now for
C:\Windows\SysWOW64, yes there's another emulation layer your 32-bits applications use to get work done on the underlying 64-bits system. I guess they're very hard at work as we speak to have a "Windows x64 on Windows ARM" as we speak, I've noticed some news items about that here and there recently.
(Which I regret a little bit, to be honest. I guess things could get a lot smoother to first have a "Windows ARM on Windows x64" sub-system and start promoting the developer tools to get your current applications already running in (fake) ARM and have the plain user completely oblivious. Performance will probably be comparable, and the gain you'd get when you finally get a hand on Windows-ready ARM hardware would be even greater because they've already prepared for ARM... But this may be all wishful thinking on my part, and a hard sell to management that need to get to maximum success with minimal investment...)
WSL 2 is another step in this direction, it lets go of talking the speach a kernel would, and talks all like 'system' what a kernel itself understands. It's only a step though, and what I'm really looking forward to is having a full-on Linux application play nice with the Windows graphical environment. There's a lot of differences to overcome there to make it happen, but it would open the way for the next steps. If there's a way to have both side by side, the work can start on the mirror movement: having a revised Windows graphical sub-system that talks with a *nix-style graphical setup, and have that as primary agent handling the graphical environment. With that you'll have much more in place to build a solution that runs as a Linux process and emulates a system with the DLL's in place to make an EXE work.
I know too little about the Linux kernel to know if this would mean Linux needs to provide the neccessary to have pico-processes of its own (or better giga-processes to fully reverse the projection), so this emulation layer actually shows in process enumeration that there's an EXE image running together with the other ELF-based images. Then again, I don't even know if Wine has this now, or even needs it. It would be nice though, that in this progress Microsoft pays respect to what went into Wine and silently and respectfully makes it so that the end-result nicely overlaps with Wine, progressing into a single strong solution to run Windows programs on Linux.