Hacker News Reader

Comment by kasabali | Hacker News Reader

> Address POSIX compatibility concerns

Best way to address POSIX compatibility concerns is implementing a proper POSIX layer in Windows (and not in a half-baked manner like the now deprecated SUA). I can't imagine how it would hurt anybody.

View on HN

SUA was not half-baked, this is a very, very hard problem. There is a very serious difference in the way POSIX and Windows model a lot of really important OS primitives, from asynchronicity model in signals, to the semantics of syscalls like `fork`. Every process using these primitives on POSIX has specific behavior defined under those primitives, and if you don't choose _exactly_ the right behavior on the POSIX subsystem in Windows you will definitely break programs.

So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.

Indeed. The Cygwin project has done an amazing job working to act as a compatibility layer between Windows and POSIX, but even Cygwin, with all the time and energy that's gone into it, still has some rough edges. Not to say that using it isn't awesome, but it's not perfect.

Microsoft does control the kernel, and given that, none of this stuff is particularly complicated.

As for choosing "_exactly_ the right behavior" ... the whole point of POSIX is to clearly define the exact right behavior!

Sure, its "easy" if Microsoft wants to redefine Windows in POSIX terms; iits not easy to keep Windows functioning as Windows and provide a POSIX compatibility layer, since Windows isn't designed around POSIX expectations.

Do you actually have specifics, here? I'm happy to discuss things like how to model fork() in-kernel.

Which for everyone that has written code across UNIX systems knows it has quite some issues across systems that are supposed to share some kind of common architecture.

Even worse when the architecture is completely different.

Is this not what midipix.org intends to do? Granted, they're nowhere near close to being finished at this point in time, but it would be great to see the project pick up steam in this space.

midipix looks awesome, but seems to be GPL (not LGPL). Does that mean anything using it must be GPL too? I think that would be unacceptable for such a low layer of the stack.

I don't know why you're being downvoted, but this is a legitimate concern for some businesses (well, legitimate may be too strong, but it is a concern a lot of legal departments will have).

After discussing this issue on #midipix on freenode, they had mentioned they will explore dual-licensing or some variant of such once the software is more stable and can be reliably deployed. In any case, the project is far too early in its infancy to start worrying about what license they might have.

The longer a project proceeds, the harder it is to get developers' permission to change licenses.

I don't understand the point of dual-licensing. Anything licensed under a BSD-style license such as ISC or MIT can to my understanding be redistributed under GPL anyway. IANAL, TINLA.

Thanks for mentioning it. I check their website occasionally and hope that it'll be a reliable and sustainable alternative.

We have enough POSIX to go round, I think. No need for any more ;)

and I'm just here still using UnxUtils :D no installation needed too

Because people would build for that instead of Win32.

That is a valid concern. On the other hand, win32 has a strong developer community with 20+ years of legacy as the primary API of Windows. Now only if Microsoft hadn't try to screw its own developers by trying to push a new framework every 5 years.

It does but as you say due to the emperor's new clothes every few years, the loyalty isn't there now. I know of no companies doing greenfield desktop dev that are using any of their tech. It's all Qt, CEF, python/wx and JavaFX. Even the financial companies we deal with who were pretty heavy with the WPF are canning it next cycle.

Incumbent MFC, Winforms and WPF stuff will live as long as VB6 did (and still does) though.

Edit as HN won't let me reply (submitting too fast). In Europe and JavaFX also has hardware acceleration as does CEF as it uses Chrome's rendering engine.

That's interesting.

>> Even the financial companies we deal with who were pretty heavy with the WPF are canning it next cycle.

Where are you based? What are they planning to adopt?

My company is consulting a couple of hedge funds in New York and they have no plans of replacing WPF for their trading apps.

The desktop CLR VM plus proper GPU acceleration makes WPF faster than any alternative (when avoiding binding). As far as I'm aware no other UI toolkit comes anywhere close.

> Edit as HN won't let me reply

But it does, it just hides the link. All you have to do is to go to the child's comment by clicking the time link, then you'll get a reply box. In your case the comment you probably want to reply to is this: https://news.ycombinator.com/item?id=10416018

ssssh! There is a reason the system is as it is...

So how would it hurt anybody exactly?

Shareholders.

I doubt shareholders would be hurt by making things easier for developers. It's a retarded mentality that lock-in is good (while it hurts developers).

developers will abandon win32 whether windows supports posix or not

Reply on news.ycombinator.com