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

51–60 of 92 posts

Re: Midipix: Posix for Windows

#51

Post by markbnj »

cwyers wrote: post #40
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'm sympathetic to people who want to develop portable GUI apps across Linux/Windows/OS X. If you're developing something like Inkscape or LibreOffice, most of your potential user base is on Windows and they are NOT going to install a Linux VM just to run your app. But yeah, there are a lot of people on HN who constantly post about how their work issued them a cat and they have all these tools they install on their c…

>> I'm sympathetic to people who want to develop portable GUI apps across Linux/Windows/OS X.

I am too, but I wonder whether it is even a relevant goal anymore. It's one of those things that has always been a topic of conversation, and has never really happened in a way that a mass of end users has adopted. Everyone who ever ran a java desktop app on Windows back in the day probably has some theory of why, but I think it was mostly because there was never really a strong need on the user side, despite the idea being so attractive to devs.

Now... I don't even know what the world of work is going to look like in ten years... Android? Windows? Linux? Mac? Tablet? Phone? Laptop? All of the above and more, I assume, and the whole interface portability thing seems to be heading down the exact same road that it headed down on the desktop, i.e. either write native or accept some lesser solution.

Re: Midipix: Posix for Windows

#52

Post by mwcampbell »

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…

Which aspects of midipix, if any, will be under the GPL? If you plan to release any of the runtime components under the GPL, will you also offer a commercial license?

Re: Midipix: Posix for Windows

#53

Post by ddevault »

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…

The entire fork/exec model is bonkers. The most egregious offsense is that it leads to things like Linux's OOM killer. If you ever find yourself writing something called an "OOM killer" you need to stop and seriously reconsider your choices up until that point. Even on the older Unix systems when the fork/exec model was first introduced, it was bloody stupid because there were much less sophisticated memory managers at the time and the performance cost of fork/exec was massive.

Re: Midipix: Posix for Windows

#54

Post by dalias »

ddevault wrote: post #53
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…

The entire fork/exec model is bonkers. The most egregious offsense is that it leads to things like Linux's OOM killer. If you ever find yourself writing something called an "OOM killer" you need to stop and seriously reconsider your choices up until that point. Even on the older Unix systems when the fork/exec model was first introduced, it was bloody stupid because there were much less sophisticated memory managers…

No, OOM killer is completely orthogonal to this and is a consequence of not doing correct commit accounting. With strict commit accounting turned on (vm.overcommit_memory=2) fork will correctly fail when there is not sufficient physical backing. But you're correct that fork+exec is a bad model.

Re: Midipix: Posix for Windows

#55

Post by ddevault »

dalias wrote: post #54
ddevault wrote: post #53

Earlier quoted context omitted.

The entire fork/exec model is bonkers. The most egregious offsense is that it leads to things like Linux's OOM killer. If you ever find yourself writing something called an "OOM killer" you need to stop and seriously reconsider your choices up until that point. Even on the older Unix systems when the fork/exec model was first introduced, it was bloody stupid because there were much less sophisticated memory managers…

No, OOM killer is completely orthogonal to this and is a consequence of not doing correct commit accounting. With strict commit accounting turned on (vm.overcommit_memory=2) fork will correctly fail when there is not sufficient physical backing. But you're correct that fork+exec is a bad model.

The OOM killer exists because of memory overcommitment, which exists because of fork/exec. The justification for overcommitment is that a big-ass process might fork just to do an exec immediately afterwards. If that is the case, then it would be lame to error out the fork because there's not enough room for a second copy of it. But if it doesn't actually exec, then suddenly there's not actually as much memory as it thinks it has as the forked process starts modifying things. This justified overcommitment in the first place and then it snowballed from there.

Re: Midipix: Posix for Windows

#56

Post by poizan42 »

the8472 wrote: post #43
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.

Not if they are opened with FILE_SHARE_DELETE.

Re: Midipix: Posix for Windows

#57

Post by mpixorg »

mwcampbell wrote: post #52
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…

Which aspects of midipix, if any, will be under the GPL? If you plan to release any of the runtime components under the GPL, will you also offer a commercial license?

The overall approach is to license cross-platform tools under the MIT license, and the Windows-specific runtime components under GPLv2 and GPLv3 that could be supplemented with a commercial license.

Re: Midipix: Posix for Windows

#58

Post by poizan42 »

wfunction wrote: post #17
TickleSteve wrote: post #16

Earlier quoted context omitted.

[ https://www.cygwin.com/faq.html#faq.api.fork ] Here's how it works: Parent initializes a space in the Cygwin process table for child. Parent creates child suspended using Win32 CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child's .d…

And where is the copy-on-write happening here? If I recall correctly, the problem was that attempting to reproduce fork()'s copy-on-write behavior on Windows resulted in a massive performance hit. (Which, IIRC, contributes to the slowness of Cygwin.) EDIT: Oh, I'd skipped the part above "here's how it works"... that just says exactly the same thing I said above.

It is possibly to fork on Windows by using ZwCreateProcess directly, however the win32 subsystem and every single thirdparty library you are using does not expect this. If you are only using the NT native api then it should work just fine, but you are prevented from interacting with the win32 environment.

Re: Midipix: Posix for Windows

#59

Post by dalias »

ddevault wrote: post #55
dalias wrote: post #54

Earlier quoted context omitted.

No, OOM killer is completely orthogonal to this and is a consequence of not doing correct commit accounting. With strict commit accounting turned on (vm.overcommit_memory=2) fork will correctly fail when there is not sufficient physical backing. But you're correct that fork+exec is a bad model.

The OOM killer exists because of memory overcommitment, which exists because of fork/exec. The justification for overcommitment is that a big-ass process might fork just to do an exec immediately afterwards. If that is the case, then it would be lame to error out the fork because there's not enough room for a second copy of it. But if it doesn't actually exec, then suddenly there's not actually as much memory as it t…

No, fork is only one path that can lead to overcommit. Allocation of new memory as COW references to a zero page, and COW writable MAP_PRIVATE mappings of files (such as the writable LOAD segments of any executable or library file) also lead to overcommit unless you do proper commit accounting. Any system that does not need to do detailed commit accounting to avoid overcommit is basically wasting the fact that it has virtual memory/MMU.

Re: Midipix: Posix for Windows

#60

Post by the8472 »

poizan42 wrote: post #56
the8472 wrote: post #43

Earlier quoted context omitted.

> 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.

Not if they are opened with FILE_SHARE_DELETE.

right, but it's still not the same as unlink it seems: http://blogs.msdn.com/b/oldnewthing/archive/2004/06/07/15004...
Post reply on HN