Examining exFAT

Posted Aug 30, 2019 20:58 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Examining exFAT by Deleted user 129183
Parent article: Examining exFAT

Given the sad state of Linux on classic desktop, Microsoft doesn't care at all. And they are still selling online Office subscription for Androids just fine.

As others said in this thread, it won't be surprising if Windows 11 moves to Linux kernel instead of the old creaky NT kernel.

to post comments

Examining exFAT

Posted Aug 30, 2019 21:29 UTC (Fri) by Deleted user 129183 (guest, #129183) [Link] (16 responses)

> it won't be surprising if Windows 11 moves to Linux kernel instead of the old creaky NT kernel

I find it completely unlikely. They would have nothing to gain by it, and they would need to rewrite probably over half of their operating system, and we all know it is a recipe for a disaster.

Examining exFAT

Posted Aug 30, 2019 22:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (15 responses)

> They would have nothing to gain by it
Well, the NT kernel sucks in many ways. Its filesystem layer is slow, the scheduler is way behind Linux and the network stack is so ancient that it's not even funny.

Switching to Linux would allow them to stop investing in improvements in these areas.

> and they would need to rewrite probably over half of their operating system, and we all know it is a recipe for a disaster.
If Microsoft decides to drop the kernel-level compatibility then it's actually surprisingly realistic. Especially if Microsoft decides to port their shell to Linux, then they'd just need to implement parts of the kernel API that is exposed for the Win32 API DLLs (user32.dll, gdi32.dll, ...).

Windows NT kernel design even makes it much easier to conversion in userspace shims. For example, IOCTLs are usually self-contained packets with a length field, not custom structures passed as "void *" into the kernel space.

Examining exFAT

Posted Aug 30, 2019 22:50 UTC (Fri) by scientes (guest, #83068) [Link] (2 responses)

> the network stack is so ancient that it's not even funny.

It doesn't help that they try to segment the market by limiting the number of half-open TCP connections:

https://www.fsf.org/bulletin/2007/fall/antifeatures/

Examining exFAT

Posted Aug 31, 2019 18:11 UTC (Sat) by Sesse (subscriber, #53779) [Link]

That was 1996…

Examining exFAT

Posted Nov 7, 2019 17:58 UTC (Thu) by Spudd86 (guest, #51683) [Link]

They've stopped that, YEARS ago. IIRC XP was the last time this was a thing.

Examining exFAT

Posted Aug 31, 2019 6:09 UTC (Sat) by epa (subscriber, #39769) [Link] (10 responses)

The Wine project has been doing this for a quarter of a century and, while there has been impressive progress, it’s a long way off the level of compatibility needed to be branded as ‘Windows’. Microsoft has more resources but adding more people does not magically fix the issues Wine faces. Not to mention device drivers and 101 annoying fiddly things that will depend on the NT kernel or the quirks of its interfaces to user space.

It is much easier to get Linux working on every desktop (with no particular requirement to run Windows binaries or even binaries from old Linux systems) than to get Linux+Win32/64 layer on every desktop with full backward compatibilty. Yet even the former goal is proverbially unreachable.

Merging Windows and Linux

Posted Aug 31, 2019 10:21 UTC (Sat) by smurf (subscriber, #17840) [Link]

Well, the easiest way forward is probably a Windows runtime that uses Wayland as its graphics back-end. Run the rest of the Windows kernel in a KVM sandbox, attach the Linux file system to a random drive letter. Add appropriate features to a bunch of management programs. Done (step one, that is; step two is to phase out a heap of legacy code in favor of native Linux implementations).

Doing this should easily be within the capability of Microsoft. They have enough people they could throw at a problem like this, and long term they'd probably need fewer coders than they do now.

Examining exFAT

Posted Aug 31, 2019 16:45 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> but adding more people does not magically fix the issues Wine faces
Porting the Windows userspace at a lower level than Wine would fix a lot of issues, actually. It's just not feasible for Wine.

> It is much easier to get Linux working on every desktop
Well, "classic" Linux has been trying this for the last 20 years or so. With pretty much zero success to show for it.

Examining exFAT

Posted Sep 1, 2019 6:15 UTC (Sun) by epa (subscriber, #39769) [Link] (2 responses)

That’s my point — in 20 years even Linux on the desktop has been hard to achieve; how much harder if you require 100% Windows compatibility (including device drivers and every crappy installer) as well. It’s just not feasible in the real world.

Examining exFAT

Posted Sep 1, 2019 6:56 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Windows is not 100% compatible with itself anymore. The "backwards compatibility" faction in MS basically lost the good fight. Reasonable compatibility is doable, though. Even for many drivers that use the UMDF.

And for installers Windows already uses quite a few hacks.

Some parts of Windows will still be tricky - the graphics stack there is top-notch and is well-integrated with such subsystems as font rendering.

Examining exFAT

Posted Sep 2, 2019 7:12 UTC (Mon) by cpitrat (subscriber, #116459) [Link]

> Windows is not 100% compatible with itself anymore.

Exactly, just look on GOG the number of games that do not run on modern windows (typically 8+). Interestingly, many of them run fine on wine!

Examining exFAT

Posted Sep 2, 2019 8:48 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (2 responses)

Have you even ever tried to install windows? Up until windows 7 it might not have the drivers to use the hard disk, and it never had network drivers and the screen would be 600x400.

And let's not even mention that it is easier to partition a disk from linux than from the windows installer.

What you normally experience with windows is a windows distribution created by the computer maker for that machine. Not at all stock windows.

Examining exFAT

Posted Sep 2, 2019 18:42 UTC (Mon) by flussence (guest, #85566) [Link]

I remember the last time I (ever) installed windows myself, sitting and waiting all day for the updater to pull down a 35MB sound driver and 90MB video driver before the machine was usable.

That was 17 years ago, sure, but every time I've had to babysit an installer for someone else in the past decade it's been a similarly miserable experience. Windows 8/10 manages to make it even worse because they can't multitask while doing OS updates. Microsoft really doesn't want people to use their OS.

Examining exFAT

Posted Sep 2, 2019 18:57 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, many times and since the early Windows NT 4.0 era.

Windows NT had a purely text-based installer and it needed a floppy disk with drivers if you had a RAID controller, but otherwise it just used BIOS-based IO to install the initial system. And the initial system had support for IDE/SCSI/ATA drivers.

Consumer versions of Windows had a GUI installer, working in 640x480 16 color VGA mode. I don't remember ever needing drivers for the initial installation on consumer hardware. Windows also happily used VESA BIOS drivers for the GUI.

Both consumer and server versions had network drivers (and back then most network cards were NE2000-compatible). Sound indeed was bad, with only SoundBlaster working out of box on NT.

Examining exFAT

Posted Sep 20, 2019 14:03 UTC (Fri) by epa (subscriber, #39769) [Link]

Ah I understand, you didn't mean provide a Win32 API on top of Linux, you meant provide a Windows NT kernel API and run the existing Windows subsystems on top of that.

Examining exFAT

Posted Mar 28, 2020 4:21 UTC (Sat) by yuhong (guest, #57183) [Link]

A lot of the problems can be solved by using a lot of the Windows source code directly, like MSHTML, .NET Framework, Jet 4.0, MSVCRT, etc...

Examining exFAT

Posted Sep 2, 2019 7:08 UTC (Mon) by cpitrat (subscriber, #116459) [Link]

> Switching to Linux would allow them to stop investing in improvements in these areas.

If they were investing significantly in it, it wouldn't suck that much.

Examining exFAT

Posted Aug 31, 2019 18:09 UTC (Sat) by alison (subscriber, #63752) [Link] (5 responses)

> it won't be surprising if Windows 11 moves to Linux kernel instead of the old creaky NT kernel.

I'm more concerned that Android will move to the Zircon kernel and pull a lot of corporate developers along with it. That could, in the long run, really be a blow to Linux.

Examining exFAT

Posted Aug 31, 2019 18:18 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Zircon won't be able to match Linux's performance for a long time. On the other hand, it's likely to be way more secure. Hm... It's actually a tough choice.

Examining exFAT

Posted Aug 31, 2019 18:34 UTC (Sat) by alison (subscriber, #63752) [Link] (2 responses)

I suspect that the choice is not tough if you prefer permissive licenses. The widespread adoption of Zircon by other will, over time, truly weaken Linux, I fear.

Examining exFAT

Posted Aug 31, 2019 18:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Well, Linux does need a kick in the butt in many areas. So I don't see anything wrong with a real Open Source competitor. And it's not like Linux's GPL enforcement has any teeth either.

Examining exFAT

Posted Aug 31, 2019 18:47 UTC (Sat) by alison (subscriber, #63752) [Link]

>I don't see anything wrong with a real Open Source competitor.

It feels to me as a mere user like the advent of LLVM/Clang has made GCC much better.

Examining exFAT

Posted Sep 1, 2019 8:40 UTC (Sun) by smurf (subscriber, #17840) [Link]

Well, that's one side. The other is that Zircon is supposed to have a stable ABI. Thus we can (in principle, assuming somebody is motivated to do the work, which I assume will happen once there are otherwise-unsupportable Zircon phones out there) support the kernel side of the thing in Linux and bingo every Zircon driver out there just works.