Hacker News Reader

Comment by robomartin | Hacker News Reader

If Windows 10 was built on top of Linux I'd get a lot more excited.

I have to use Windows for the myriad of engineering tools that are not available under any other OS, for example, SolidWorks, Altium Designer, various embedded toolsets, etc. And, while I've been using PC's (and Macs and Linux) since they came on the scene I hate, hate, hate the DOS or technically DOS-like underbelly of the beast.

I know it is a ridiculous idea. It would break everything, including their profitable corporate platforms.

Yes, there are ways to mitigate this but it'd be nice if all computing platforms got behind a common standard. Utopia. I know.

View on HN

The APIs may be annoying (HWND, NULL, NULL, NULL, NULL, NULL, DWORD_PTR dwcsprcadrswtfbbq, NULL, ...) but that backwards compatibility you're suggesting they do away with is pretty much the best thing about Windows. I got so fucking sick of the desktop Linux people constantly breaking everything on foppery and whim that I went back to Windows 7+mingw, and while Stallman would be ashamed of me, I have to say that it's incredibly comforting to use a platform that mostly figured itself out over a decade ago, that won't change under my feet every other month, and even when it does (Windows 8) I can keep using the version I liked best for years and years because they actually took binary compatibility seriously throughout the entire system. There are still people on XP for christ's sake. I'll take that over overzealous redhatters who think they know what's best for me any day.

Being built on Linux as GP suggested doesn't mean its just Linux -- presumably you'd implementing Windows APIs on top of Linux. Think WINE, but without the disadvantage of having to be done by third parties.

Though a more likely way, were Microsoft to want to bridge that gap, would be to have a solid first-party POSIX environment on top of Windows, rather than the other way around.

Why? What's the point? NT isn't bad at all, it's just different from POSIX (hell, I can't believe the irony of this statement, but I'm glad that Microsoft is still around to resist the POSIX monoculture). Neither Microsoft nor the Free Software™ world would gain much from killing the NT kernel, but the latter camp would gain so much more from learning the lessons that made Windows so successful 20 goddamned years after the fact. It's so sad hearing Linus passionately say "you do not break binary compatibility in the kernel" then watching people on the outside flagrantly disregard this concept time and time again.

> Why? What's the point?

The point is portability. People now write all of their server software for Linux. More people would bother porting it to Windows if doing so was easier.

Example: There is no Windows equivalent to epoll/kqueue. Neither of them is even POSIX. But if you bring this up to most Windows people they tell you to use IO completion ports, which are totally different and require the core of the program to be redesigned.

> There is no Windows equivalent to epoll/kqueue

There is: Overlapped IO: http://msdn.microsoft.com/en-us/library/windows/desktop/ms68...

> But if you bring this up to most Windows people they tell you to use IO completion ports, which are totally different and require the core of the program to be redesigned

IO completion ports and epoll both require the programs flow logic to be designed for them. If a program has been designed for synchronous IO, a redesign is required to take advantage of any asynchronous IO pattern. There's no magic fairy dust that allows you to magically drop "asynchronous" to an otherwise synchronous program.

The reactor pattern (Windows overlapped IO) is - at least theoretically - more scalable than the proactor pattern (Linux epoll/aio).

Under the proactor pattern (Linux epoll/aio) the process must indicate it's desire to perform an IO operation. The OS will notify the process through a callback/event when the IO resource is available for the operation, and must then perform the actual operation. However at that point there is no guarantee that all of the IO will be completed - the OS will inform you how many bytes were actually read/written, and it is your responsibility to wait for the next "ready" event before trying again.

Under the reactor pattern (Windows overlapped IO) the process asks the OS to perform the IO operation directly. The operation is started by the OS while the call returns immediately. When the operation has been carried out, the OS notifies the process through a callback/event. There is no complexity in managing partially transfers - the transfer in the responsibility of the OS and you'll receive notice when it's completed. IO completion ports is actually a thread pool dedicated to IO ops, and queuing is built-in.

The proactor pattern (Linux/epoll) requires a context switch between the IO resource becoming ready for the operation and the actual operation (higher latency). If transfers are partially completed - e.g. large transfers - you'll have extra context switches for each remaining transfer operation (lower throughput).

The reactor pattern (Windows) allows the OS to directly complete the operation without a preceding context switch (lower latency), only notifying the process when done, thus avoiding unnecessary context switches even for large buffers (higher throughput).

Both approaches require the program to be deliberately designed to support asynchronous IO. However, the Windows API was always designed with overlapped (asynchronous) IO in mind, Windows IO completion ports was designed in NT from the start. The problem was always (for both platforms) how to coach the developers to actually leverage the asynchronous APIs as opposed to the simpler-to-understand synchronous APIs.

The new Windows Runtime API takes it a step further and requires virtually all IO to be asynchronous (there simply are no synchronous versions any more). That is coupled with programming language innovations like async/await (C#/VB.NET) which makes it very easy indeed to take advantage of this.

You, I like you.

(https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...)

Awesome! Thanks!

This is exactly what I'm talking about. The attitude is that overlapped IO is "better" and screw you if you don't want to redesign your existing software to use it.

First, here's a real example where it isn't better. You have some app which holds a thousand some sockets and receives packets infrequently. With epoll you need one buffer when the odd packet arrives regardless of which socket is ready. With overlapped IO the amount of buffer memory you need is more by a factor of a thousand because each idle socket still requires a buffer to be allocated to it.

But that's not really the point. Having overlapped IO available is fine -- it is better for some applications. The problem is not having epoll, not only because epoll is sometimes better, but because it makes portability unnecessarily difficult. Because in most cases the performance difference between the two is irrelevant and the important criteria is how much work I'm going to have to do to make them both behave the same way on each platform.

>With overlapped IO the amount of buffer memory you need is more by a factor of a thousand because each idle socket still requires a buffer to be allocated to it.

Use the select function then. Wait for completion of that instead. No need to allocate buffers for sockets that receive messages infrequently.

epoll is a horribly designed API. It should absolutely not be replicated on other platforms.

Troll level: Asinine.

Which bit of Windows do you feel is DOS-like? Did you ever use DOS? The DOS underbelly of Windows disappeared with the release of Windows XP over a decade ago. Windows 95 and 98 were DOS-based, or at least had DOS underpinnings to some extent I think.

From an API point of view, the Win32 API is incredibly stable and reliable and allows the ability to run programs from decades ago. This contrasts sharply with Linux, where the APIs are in a constant state of irritating flux. From a serious development perspective, this might be why the commercial application market has flourished under Windows and why you see commercial Linux applications few and far between, and (usually?) treated as a side attempt before falling by the wayside (as it appears that few Linux users will pass over cash for an application).

I would believe it is a naive approach to ask that Windows be "built on top of Linux". They are architecturally different: http://en.wikipedia.org/wiki/Architecture_of_Windows_NT

I do not install mingw or cygwin or any other "Linux-land" compilers/systems on Windows because it feels like I'm using the wrong system - just install Linux if I want all that! It would be better to just use native Visual Studio in Windows-land and keep everything separate, no? Ordinary users that I am writing software for will typically have the Visual-C++ runtimes already installed so bundling of different GNU DLLs is redundant.

We are now starting a large Python/Django project. All of our software development to date save iOS has been done on Windows machines. It is quickly becoming a PITA to develop these kinds of projects on a non-unix platform. Serioulsly considering switching everyone to Mac Pro's despite cost (10 to 12 seats). Yes, there are work-arounds. Not sure they solve the problem. More than willing to listen to suggestions.

I would switch to the Mac Pro, even an older tower one. They still have bonkers performance (it's my main development machine for native C++ and Windows development in a VM). But you don't feel like you're fighting with the system to do "unix" things like you do on Windows, and it doesn't feel like you're trying to fit a peg into a square hole, which shoving all GNU tools etc. onto Windows certainly feels like to me.

Or I suppose you could go with Linux and fight the shifting desktop sands? (That's why I got fed up with it and switched mainly to Mac OSX; despite the OSX changes, they're gradual and not insisting that we drop the dock or window behaviour etc.)

If Windows 10 was built on top of Linux I'd get a lot more excited.

GPL would make that impossible. There are reasons OS X is based on BSD, and not all of them are about technical superiority.

Android is built on Linux, and it seems to do just fine despite the kernel being GPL'd.

"just fine" isn't perfectly true. The bionic interface they somehow "wash" from GPL headers to BSD headers is questionable.

Nope, there is nothing questionable about it. Linus himself has stated it: http://www.groklaw.net/articlebasic.php?story=20110322014831...

That's interesting. Still, there are a huge number of copyright holders of the linux kernel and some may have a different opinion on the legalese applies.

WebOS and Jolla had/have a ton of closed source components(pretty much the whole GUI) but run on top of Linux so there's a loophole somehere.

There is no loophole, the Linux license explicitly allows usermode apps to use the (GPL-licensed) interface headers without requiring the app to be GPL. See https://github.com/torvalds/linux/blob/master/COPYING

And would all Windows developers leave? Most I bump into see Linux as a toy still, despite the ever-growing army of vocal Python developers who favour development on the platform (if you love slow GUI programs, Python sure is the way to go!)

What about just real POSIX and some kind of X interop or compatibility baked in? My (poorly informed) guess is this would allow a lot of low-hanging fruit from Linux, BSD, etc to be ported properly.

Inevitably that effort would still fall short, and therefore not really at all. The leverage of linux is the linux community, and the access. Not ls vs dir. IMO. In any case, if they provided the Windows 8 experience built right on top of linux (and all the binaries and everything still worked) it would be a marvel.

Windows used to have those things. Windows 8 was where they removed it. I believe the official answer nowadays is "run a Unix using Hyper-V."

Well, no, they didn't remove it; its been a separate component for a long time, and with Windows 8 they restricted it to Windows 8 Enterprise and Server 2012. (Though I think the Windows 7 version can actually be used in Windows 8.)

It's deprecated in Windows Server 2012:

http://technet.microsoft.com/en-us/library/hh831568.aspx

I believe it was removed with 2012 R2.

I wonder if it was because nobody used it? It must have been a large thing to maintain and test every release.

It was gaining popularity at the point where they killed it; there was this real buzz, a feeling that this really cool thing was finally spreading to more people.

> It was gaining popularity at the point where they killed it

Was it? As far as I can tell, it had been losing popularity for a long time before Windows 8, and it was rare and getting rarer that any nx-based project would recommend using it on Windows, though occasionally you'd find people outside the main projects with recipes for making it work (or horror stories of their attempts to do so.)

I felt like it was. Things like the gentoo-on-windows project were new and lively, and that company that was backing it was getting a bigger and bigger set of packages in their repo.

Reply on news.ycombinator.com