Microsoft released its first emulator for Windows 10X today, allowing developers to get a first look at the new operating system variant for dual-screen devices. Microsoft wants to give developers a head start on optimizing apps before devices launch later this year, so this basic emulator provides an early look at Windows 10X before it’s finalized.
My first thoughts? Windows 10X feels like a slightly more modern version of Windows 10 that has been cleaned up for future devices.
In Windows 10X, everything is new. There’s none of the old Win32 code and applications lying around, or fallbacks to old Win32 dialogs. Everything is a Modern application (or whatever they call it these days), including things like the file manager – the traditional Explorer is gone.
While Windows 10X does support Win32 applications, they run in a container. As detailed in this video from Microsoft (select the video titled “How Windows 10X runs UWP and Win32 apps”), Windows 10X has three containers – Win32, MSIX, and Native. Win32 applications run inside a single Win32 container, capable of running pretty much anything “classic” you can throw at it, such as Win32, WinForms, Electron, and so on. MSIX containers are basically slightly more advanced classic applications, and these containers run inside the Win32 container as well. The Native container runs all the modern/UWP applications.
The Win32 container is actually a lot more involved than you might think. As you can see in the below overview diagram from the video, the container contains a kernel, drivers, the needed files, a registry, and so on. It’s effectively an entire traditional Win32 Windows operating system running inside Windows 10X. Applications running inside the Win32 container are entirely isolated from the rest of the host Windows 10X operating system, and Windows 10X interacts with them through specialised, performance-optimised RDP clients – one for each Win32 application.
This seems to finally be what many of us have always wanted out of a next-generation Windows release: move all the cruft and compatibility to a glorified virtual machine, so that the remainder of the operating system can be modernised and improved without having to take compatbility into account.
For now, Windows 10X seems focused on dual screen devices, but a lot of people in the know seem to think this is the actual future of Windows. Time will tell if this is actually finally really the case, but this does look promising.
I am not strictly opposed to moving win32 into it’s own isolated subsystem, but was does that mean for administrative privileges on the host? As far as I’m aware administrative access is limited to win32 programs and UWP applications cannot be elevated to administrative privileges by design.
https://social.technet.microsoft.com/Forums/en-US/94485bfa-3937-47b3-a6b2-b04c418c246b/uwp-app-elevated-priviledges
With windows 8 I felt that microsoft’s attempts at imposing IOS-like restrictions on users & developers through “modern” apps was largely defeated by everyone simply continuing to use “legacy” win32 instead to bypass restrictions. With this change to deprecate win32 applications into a container, what does this mean for owner control over the computer as a whole? Is microsoft going to add administrative privileges for UWP? Worst case scenario I fear this may be microsoft’s subtle way of taking administrative control away from windows 10 computer owners altogether.
I’ll plead ignorance here since I haven’t been following any of this. Can someone more familiar with the details speak towards what this means for owners who want or need low level “root access” on windows 10 computers in the future? It’ll be a dark day in personal computing history if windows 10 becomes restricted like IOS.
Yeah, that is what I thought when I read the piece. As far as I understand, this is another attempt by Microsoft to impose its own app store and start charging 30% on any application purchase, and outright dismissing apps which compete with Microsoft offerings.
What I don’t understand is why anyone is excited about it.
I agree with your assesment. While I am intrigued by Windows 10X seeing the light of day, I am a certain that the idea is a competing iPadOS-like platform with its own app store, applying the same restrictions.
What do I personally expect? Over the years Microsoft has been trying their very best to copy Apple’s playbook regarding vendor lock-in. So, I expect we will see a platform developed around a hardware “security” chip – similar to Apple T2 – providing unique and detailed telemetry excrypted at hardware level, at the same time providing remote administrative control with the ability to restrict software and hardware.
The Windows 10X Win32 container will use a blacklist and probably need to be online for some applications. So, every single time you execute a piece of win32 software, it will have to be approved by Microsoft for it to run.
On the surface Windows 10X looks really promising, but looking at a) what has been done, b) what can be done and c) what is Microsoft interested in doing, I really expect the worst from Microsoft at this point.
And I have heard people, who wants the Win32 Container for Linux, to run Win32 programs side by side to native Linux programs.
The Win32 container would then something like WINE, but more compatible, because its using original Microsoft Win32 libraries and programs.
Possible there comes out an Windows ISO extractor by anyone in the future. Running on Linux the extractor. Selecting in the extractor an Windows or Windows 10X ISO image. And then the extractor integrates the Windows fonts, Windows wallpaper, Win32 and other parts in Linux.
It’s possible, but not 100% because some of the Wine DLLs need to be Wine provided or you lose things like clipboard and drag-and-drop integration between Windows and Linux applications.
(And, of course, the Windows GDI DLLs expect to talk to Windows API-based video drivers.)
You’d still need to implement a fully compatible Windows kernel environment and windows container/host interface. Some of that already exists in ReactOS of course, so you could use that to reimplement windows-kernel-on-linux, but at that point you may as well be running ReactOS natively, or using a full VM.
I think you mean WINE and not ReactOS. To run Microsofts original Win32 on Linux, it needs not a kernel-reimplementation (like ReactOS), it needs a kernel-layer (like WINE).
And Windows libraries on WINE for Linux already exists in Windows 3.x times.
There it was possible to replace user.exe, gdi.exe (in that times most are in .exe and not in .dll) and other parts of WINE with the original Windows parts with the *.fon files. And that was really a difference: With the original Windows-parts it “feels” more like Windows. 🙂
No, I mean ReactOS.
To be able to pick up a Windows container and run it as-is on Linux you’re going to have to basically implement something like a kernel personality or subsystem to emulate Windows at a lower level than WINE usually does.
Unless of course we’re talking about Hyper-V containers, in which case you’re not really running a container, you’re running a VM. Linux can already run a Windows VM.
The1stImmortal,
I don’t understand why wine doesn’t fit the bill here? I haven’t tried this, but couldn’t you run win32 under wine inside a linux container (as long as you have all the necessary dependencies inside the container)?
I’m probably misunderstanding what you are saying, are you talking about re-implementing windows at the kernel level and merging that with linux? I don’t think that is necessary because windows applications generally invoke the kernel through system DLL helpers rather than calling syscalls directly. Calling syscalls directly on windows requires some trickery (and I’m not sure whether this works on wine).
https://www.evilsocket.net/2014/02/11/on-windows-syscall-mechanism-and-syscall-numbers-extraction-methods/
So given that windows applications normally interact through system DLLs, it seems like they should mostly fit comfortably inside a linux process without too much reliance on dynamic code recompilation or kernel hackery, although I’d like to hear from anyone familiar with wine’s implementation.
Alfman,
I was taking the reference to a “win32 container for Linux” to mean the ability to pick up a Windows Container image, running Windows code and a windows core userland environment and run it unmodified on a Linux machine. If that’s not what theuserbl meant then I’m off base, but it is what I had in mind in my earlier posts..
Windows Containers don’t even work across patch levels of Windows without having to be encapsulated into a VM with a kernel environment injected into the image (so called “Hyper-V Containers” – which are just VMs in the end). Given process-level containers basically work by isolating user processes and environment from other processes on the same kernel, that makes sense. Traditionally, Microsoft hasn’t had to worry about the user/kernel interface too much as it expected apps to talk through the various libraries and services. With a container, though, the User/kernel interface has to be stable, and the kernel has to behave the same way on the other side of that interface for the user environment to function. That means to implement a native Windows container support on Linux you’d have to implement large swathes of Windows functionality inside the linux kernel (or at least accessible via the kernel). A windows process would have to start inside its container, have processes marked “windows” behave like Windows processes (not like Linux processes), use its own copies of .dll files in the container to talk to the linux kernel, which would have to go “hey, this is a Windows process, I have to pretend to be Windows here!” and respond accordingly.
So yeah, WINE isn’t the ticket here because the container includes the libraries that WINE would normally replace.
The1stImmortal,
Personally I’d still go the WINE route myself since it’s effective, works today, is more efficient and takes less work than merging windows into a windows/linux hybrid kernel. I just don’t see any scenario where the maintenance burden of merging a windows user/kernel ABI into the linux kernel would be justified, but maybe that’s just me. If system DLLs couldn’t be substituted for linux equivalents like they are when using WINE, then I’d opt for a VM instead, which seems to be what microsoft itself is aiming for.
Obviously with RDP, the application windows in the VM become windows on the host desktop to make the VM experience more natural than exposing a VM’s frame buffer. This could all work on linux as well.
Another reason to use WINE instead of a VM for some people is that they may need to run windows programs but not have or want windows licenses, WINE doesn’t depend on microsoft’s system DLLs or kernel. Correct me if I’m wrong but wouldn’t the implementation you are considering require a windows license since it would be running run microsoft’s userspace code?
Alfman,
So would I 🙂
I was talking to what I interpreted the specific implementation being discussed as. WINE is a better solution in general, agreed.
The line between ReactOS and WineHQ is very small as both projects are tightly linked together. ReactOS provides additional binaries and tooling to bootstrap the entire OS, but the Wine Libraries are still used to emulate Windows.
Some people bringing Win10X to real hardware
https://twitter.com/imbushuo/status/1227831774996131840
https://twitter.com/stroughtonsmith/status/1228110304216784902
https://twitter.com/NTAuthority/status/1227401579902459904
https://twitter.com/gus33000/status/1228034037085802501
I’m dubious regarding this architectural info from microsoft. The whole point of a container is to not have a (real) kernel inside the container, for example. UWP (and the browser environment for PWA) is implemented on top of Win32 so they’d have to have reimplemented that on something else to make that work without Win32. Finally that RDP client and the GUI environment it runs in has to be using something, probably Win32.
This isn’t a way to “get rid” of Win32. It’s a way to containerize and limit non-store-derived apps. It’s a way to wall the garden of traditional self-installed Win32 apps. Using glass walls.
Win32 used by UWP is just a subset, they can trim the fat for everything else.
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-and-com-for-uwp-apps
RDP was support for DirectX since ages, and DirectX has a UWP variant.
Your link seems to show Win32 APIs that are exposed to UWP apps rather than ones that exist to be used by the UWP implementation itself. I’d be curious if anyone’s actually tried to investigate where UWP touches the underlying environment. I’m sure it’s not too much though, given it was really originally built for Windows Phone.
I’m curious as to whether they’d be using EdgeHTML for PWA on this or whether they’ll be using something Blink based – Blink is probably going to have a slightly wider dependency sweep than the minimal UWP footprint.
I really doubt they’re not going to gut Win32 too much. They may not expose much but there’ll be a lot still there, ready for some upper level software to take advantage of at some point.
On RDP, while RDP might support remoting of DX etc, the rdp client itself isn’t, as far as I’m aware, written to write directly to DX. There is the UWP RDP client (which MS purchased) but it lags quite a lot behind the Win32 implementation. It’s likely they’ll be using the existing Win32 RDP client implementation rather than the UWP or a new one.
The1stImmortal,
Who knows. In the past with windows RT microsoft gave itself full win32s under the hood (to run it’s own software including office), it was just blocked for everyone else “do as I say, not as I do”.
I’m curious how a lot of drivers are going to work since many have win32 userspace counterparts. Will there be new incompatibilities? Will legacy hardware still work inside the win32 container? Is microsoft going to start forcing manufactures to port their code to UWP?
If windows 10 X really works as the article depicts it (it might not), then obviously the new native RDP client is needed to access all win32 software. It seems like win32s are almost going to be in a VM of sorts. Technically the more functional win32 RDP client could still be used from the win32 container through the new RDP client. This should work, even though it’s not optimal.
Universal Drivers are the future of Windows drivers.
https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/getting-started-with-universal-drivers
moondevil,
Thanks for the link. According to that “The driver binary can use KMDF, UMDF 2, or the Windows Driver Model (WDM).”,
and
The quote is as clear as day, but is this really true that UI components for microsoft “universal drivers” must be distributed through the microsoft store? What about getting drivers directly from manufacturers?
I also found this also:
https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/
Alas, all these documents are dated 2018 and could be obsolete with respect to the future of windows 10 x. I’ve experienced software & driver breakages after windows upgrades, and I won’t be surprised if windows 10x is the same. That said, I’m pretty much a sideline spectator at this point, I haven’t kept up with windows 10. Hard to believe it’s been ~15 years since I’ve done windows driver development.
Win32 is just a personality of the NT kernel, and UWP is the evolution of COM, being increasingly used to what was originally though of Longhorn would be having in .NET.
Edge Chrome PWA capabilities are being extended, that was also a talk about the Surface Duo Web development.
Yeah how bad is the performance? every time I’ve seen the container idea brought up it ends up just murdering performance so you end up with the programs feeling like you are running Win 9X on a 486. People these days are used to having fricking octocores on their phones, slow ain’t gonna cut it.
For once, I like seeing the “legacy’ win32 APIs being moved to the container, since they tend to interact with modern Windows systems in all kinds of freakish ways. For example old games using DirectInput will attempt to read HID devices such as fan speed controllers and AlienFX comtrollers as gamepads and either crash or keep polling and run slowly.
However, some questions I have are:
– Performance, especially on 3D accelerated programs
– Is win32 now a “legacy API” that won’t see any further improvement? Because UWP is not a suitable replacement.
RDP has support for remote DirectX since quite a few years now,,
https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/deploying-graphics-devices-using-dda
And before that RemoteFX was an option as well.
Win32 has been a legacy API since Windows Vista was released, as WinDev team won over DevTeam regarding Longhorn. All the Longhorn ideas to be done in .NET have been rebooted into a mix of COM and .NET, and since then, with a few exceptions, all new native APIs are COM (aka UWP).
Anyone using only Win32 is constraining themselves to what is basically Windows XP view of the world.
Your link here refers to DDA, which is mapping PCIe devices into Hyper-V VMs (a process involving hardware support and which most hypervisors these days have a variant of). It doesn’t remote DirectX through RDP, it gives a VM direct access to the graphics hardware to send its own graphics commands to. RDP might then pick up the results of the rendering to send out to a client. RemoteFX is sort of DX over RDP, though it seems to be almost abandoned other than utilizing the existing hooks for it in the system to provide emulated/shared graphics support to VMs.
As for Win32, I’m going to assume you’re taking a very narrow definition of Win32 (since it can mean a few things). Realistically, though, Windows is Win32, pretty much everything is built on it.
“but a lot of people in the know seem to think this is the actual future of Windows.”
Drop some names or this is just standard “Year of Desktop Linux” delusional thinking. The jury is still out on whether the Surface X will flop as badly as RT. Plus any advantages ARM had other than price have been gone for a while. E.g. an LG Gram advertises 17 hour battery life.
Win32 already gotten sandbox capabilities as Microsoft introduced MSIX packaging model, which extended UWP sandboxing into W32, thanks to Project Centipede.
Surface X doesn’t need to succeed, like the story of frog in cooking water, Microsoft just needs to keeping releasing their Win32 improvements alongside regular Windows updates, as they have been doing thus far.
First I’m seeing anything about Windows 10X. I wonder if this will be the OS where you can finally have files named: AUX.txt, COM1.txt, COM2.txt, COM3.txt, COM4.txt, COM5.txt, COM6.txt, COM7.txt, COM8.txt, COM9.txt, CON.txt, LPT1.txt, LPT2.txt, LPT3.txt, LPT4.txt, LPT5.txt, LPT6.txt, LPT7.txt, LPT8.txt, LPT9.txt, NUL.txt, PRN.txt.
It’s fun to add files like this to a Git repo and it’ll mess with people who try to work with the project on Windows. It can be any extension actually, not just txt.