Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Midipix: Posix for Windows

midipix.org

Post reply on HN
Print view View original

41–50 of 92 posts

Re: Midipix: Posix for Windows

#41

Post by pjmlp »

cwyers wrote: post #39
pjmlp wrote: post #33

Earlier quoted context omitted.

Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Which leaves the question how much POSIX can be implemented on top of WinRT. Similarly not all POSIX calls are allowed inside Mac OS X App Sandbox. And if we restrain ourselves to POSIX there is little more than command line applications, TCP/IP…

> Not only that, like Mac OS X, Windows is moving into another application model WinRT with containers. Just like Carbon, only selected Win32 APIs will survive in the long run. Microsoft would still let you run 16-bit DOS apps on Windows if Intel hadn't dropped compatibility from their 64-bit processors. Both of us will be dead and buried before Win32 goes away.

Sure, but it doesn't change the fact that one day it will be gone, specially if Windows 10 becomes another 7.

Re: Midipix: Posix for Windows

#42

Post by mpixorg »

The project's pre-pre-alpha will be out very soon (in a week or less) and will already give a nice taste of its design and speed. The primary focus thus far has been major challenges (toolchain, process creation and initialization, signals, glue layer between posix system call layer and libc, etc.). This means that while you will be able to test functions such as fork(), execve(), mmap(), or fopen() with a utf-8 path, some of the easy/easier-to-implement system calls will "surprisingly" still be missing.

For one or the other reason, fork() has become in many discussion of posix on windows something of a fetish. The interface surely has its place, and figuring out how to efficiently implement it took a huge amount of effort, yet the vast majority of applications do not truly need it. Matter of the fact is that even on linux, where fork(2) is natively supported, the sequence fork+execve is more costly than clone+execve (where clone's flags are CLONE_VM && !CLONE_THREAD). For additional reference, see for instance the implementation of posix_spawn in musl libc (http://git.musl-libc.org/cgit/musl/tree/src/process/posix_sp...).

If high performance of the posix layer were not possible the project would have not existed. Among the factors that make high performance possible are 1) direct use of kernel interfaces (aka the Native API, where most of the runtime layer is written as a user-space driver), 2) utf-8 as the primary supported multibyte encoding as a foundational concept rather than an afterthought, and 3) tls implementation that matches in speed the native tls facility.

Re: Midipix: Posix for Windows

#43

Post by the8472 »

mpixorg wrote: post #42

The project's pre-pre-alpha will be out very soon (in a week or less) and will already give a nice taste of its design and speed. The primary focus thus far has been major challenges (toolchain, process creation and initialization, signals, glue layer between posix system call layer and libc, etc.). This means that while you will be able to test functions such as fork(), execve(), mmap(), or fopen() with a utf-8 path…

> For one or the other reason, fork() has become in many discussion of posix on windows something of a fetish.

how about this one?

fopen + mmap + unlink

Afaik windows APIs forbid deleting mmaped files.

Re: Midipix: Posix for Windows

#44

Post by glibgil »

TickleSteve wrote: post #13
opaque_salmon wrote: post #2

That's an interesting name choice that might make it hard for me to remember in the future, do you happen to know why they chose it? In any case, I welcome a posix interface for windows, it would be a cool tool to have, especially in the case of cross-platform utilities.

Any reason Cygwin isnt suitable? Thats the goto project for the type of stuff.

Cygwin doesn't have copy-on-write.

Re: Midipix: Posix for Windows

#45

Post by Sanddancer »

tkubacki wrote: post #9

Deploying Linux apps on Windows Server is easier these days (Hyper-V). If you really need decent POSIX OS on Windows just use virtualiztion.

I disagree there. Just virtualizing means that you now have another machine that you have to audit, keep up to date, have disaster recovery procedures for, etc. Plus, if your potentially trivial app needs to run on multiple boxes, that just amplifies these costs.

Re: Midipix: Posix for Windows

#47

Post by beagle3 »

TickleSteve wrote: post #26
beagle3 wrote: post #18

Earlier quoted context omitted.

Cygwin is just a DLL, and it works reasonably well, but it does come with some nontrivial baggage: - It's GPL licensed, or you buy a license from RedHat; either might be too onerous for the people who develop midipix - You can only have one cygwin1.dll in memory at a given time; If you have two cygwin using programs, they must both use exactly the same version of the cygwin1.dll; Which means that you can't just distr…

Like you say, some issue are inherent in the problem-space. but... multiple versions of Cygwin can coexist these days. It did used to be an issue, granted. tho these days quite a few programs distribute their own cygwin dll and tools. I agree, licensing may be an issue for some people.

Thanks. It's good to know that the multiple version issue has been addressed - although from the FAQ it sounds like there are still a few (unlikely) corner cases one needs to keep in mind.

Re: Midipix: Posix for Windows

#48

Post by dalias »

mpixorg wrote: post #42

The project's pre-pre-alpha will be out very soon (in a week or less) and will already give a nice taste of its design and speed. The primary focus thus far has been major challenges (toolchain, process creation and initialization, signals, glue layer between posix system call layer and libc, etc.). This means that while you will be able to test functions such as fork(), execve(), mmap(), or fopen() with a utf-8 path…

I have a sequence of tweets here summarizing basic measurements I did on musl's posix_spawn versus fork+exec:

https://twitter.com/RichFelker/status/602313644026761216

There are still plenty of applications that use fork semantically, to keep the same process image in the child, which benefit somewhat from a fast fork. But most places where fork affects performance now are things that are already pessimized by using fork+exec instead of posix_spawn: the shell, make, cgi, etc. (GCC still uses vfork, but GNU make recently switched from vfork to fork because of vfork-related bugs.) Regardless of how fast or slow fork is on midipix (but I expect it to be fairly fast, much faster than cygwin), they would benefit a lot more from just switching to using posix_spawn.

Re: Midipix: Posix for Windows

#49

Post by dalias »

kickingvegas wrote: post #46

Interix did this, and then they were shelved. http://en.wikipedia.org/wiki/Interix

Interix is a lot different because it requires installing a system component, which requires administrator privileges. Midipix produces applications that (at least as I understand it) run on basically any NT-based Windows with no special privileges.

Re: Midipix: Posix for Windows

#50

Post by dalias »

hsivonen wrote: post #12

Having fopen() that takes utf-8 on Windows is a huge deal. I already want to investigate using this for Firefox on Windows for this reason alone.

Yes, this is the really big deal that everyone focused on fork and mmap semantics and other details is overlooking. Having midipix as the means of producing Windows versions of cross-platform software like Firefox should make it possible to remove a lot of ugly #ifdeffery and/or whole "portability layers" that are avoiding the standard functions like fopen because of a lack of Unicode support on Windows.
Post reply on HN