Cygwin anyone?
Cygwin is just a DLL for API translation with an associated package manager (Though many people think its more heavyweight than that and consequently dont like it).
Midipix: Posix for Windows
11–20 of 92 posts
Re: Midipix: Posix for Windows
#12Having 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.
Re: Midipix: Posix for Windows
#13That'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.
Re: Midipix: Posix for Windows
#14Earlier quoted context omitted.
I've never had a problem with msysGit [1] [1] https://msysgit.github.io/
Compare it to linux git, it's about 10-20x slower on same hardware
That's probably the NTFS MFT rather than the actual runtime. Git plops lots of small files on the disk which end up in the MFT. The MFT is really slow. We have the same trouble with SVN.
You can tune this a bit with fsutil and turn off last access time, 8dot3 filenames and change mftzone size and it'll be significantly faster.
ReFS is a little better in this respect. I suspect this was a hang-back from early NT versions which were tuned to larger binary blobs as a normal file statistic rather than lots of small text files.
Re: Midipix: Posix for Windows
#15This project sounds too good to be true. I would be quite astonished if they can make fork() work seamlessly without an amazingly high performance cost. In my experience the only way to do such a thing is to use NtCreateProcess(), but that function itself seems impossible for anyone besides Microsoft to use correctly. (I have tried numerous times and failed, and so have many others.)
Re: Midipix: Posix for Windows
#16This project sounds too good to be true. I would be quite astonished if they can make fork() work seamlessly without an amazingly high performance cost. In my experience the only way to do such a thing is to use NtCreateProcess(), but that function itself seems impossible for anyone besides Microsoft to use correctly. (I have tried numerous times and failed, and so have many others.)
[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 .data and .bss subsections by copying from its own address space into the suspended child's address space. Parent then starts the child. Parent waits on mutex for child to get to safe point. Child starts and discovers if has been forked and then longjumps using the saved jump buffer. Child sets mutex parent is waiting on and then blocks on another mutex waiting for parent to fill in its stack and heap. Parent notices child is in safe area, copies stack and heap from itself into child, releases the mutex the child is waiting on and returns from the fork call. Child wakes from blocking on mutex, recreates any mmapped areas passed to it via shared area and then returns from fork itself.
Re: Midipix: Posix for Windows
#17This project sounds too good to be true. I would be quite astonished if they can make fork() work seamlessly without an amazingly high performance cost. In my experience the only way to do such a thing is to use NtCreateProcess(), but that function itself seems impossible for anyone besides Microsoft to use correctly. (I have tried numerous times and failed, and so have many others.)
[ 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.
Re: Midipix: Posix for Windows
#18Cygwin anyone? Cygwin is just a DLL for API translation with an associated package manager (Though many people think its more heavyweight than that and consequently dont like it).
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 distribute a self-contained cygwin program and expect it to work.
- It's a bit clunky at the edges, with the mounts (it looks like you have a /usr directory on the root, and you can see it with "ls" or cygwin "dir" but not cmd "dir", for example; user integration is a bit clunky).
I'm not sure midipix will be better - some problems are inherent. However, cygwin was designed around Win95/NT4 deficiencies some 20 years ago. It has evolved very gracefully, but it's possible a modern version without all that legacy will work better.
Re: Midipix: Posix for Windows
#19Earlier 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.
I've personally never had any real performance issues with Cygwin. What are you doing that involves lots of forking?
For me, Cygwin has always been pretty much native-speed, its only an API translation layer.
Re: Midipix: Posix for Windows
#20Earlier 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.
[deleted]