On 1/14/2013 20:59, Ruben Van Boxem wrote: >> >> But seriously, you will probably end up writing your own PE loader to >> simulate fork(), since specs say new process must have exact memory >> layout as the parent, not to mention Posix signaling pipelines to route >> to the correct process. fork() is especially tricky since win32 is >> lacking anything similar unless you go with undocumented Vista+ APIs >> that I heard rumors about. >> > > Well yes. But I would like to draw a fine (make that an extremely, very > thin line) between the shell and its programs: all executables will be > Win32 native executables, using nothing POSIX specific. Heck, I'll port > Coreutils and its brethren on top of the bare Win32 API if I find the > motivation ;-). > I'm not sure to what extent the shell interpreter in the role of running > configure scripts requires specific memory layout stuff specifies in the > POSIX spec and as you say quite ... involved. > Would not a simple command evaluator coupled with natively ported > applications possessing the required interface bring me quite far? > >
I suppose you could do that, just that don't expect coreutils and other unix apps to work, they make those assumptions when forking. Otherwise, you'd just be making an expensive copy to clone the process, might be worst than Cygwin. >> >>> This might be exactly what MSYS does of course, but it requires a special >>> build environment and ancient GCC (although the mysterious MSYS2 will >>> probably fix this). >> >> Give Services for Unix a try, assuming you have Vista/7 enterprise or >> ultimate edition installed. IIRC Win8 pro has it too. It is even 64bit. >> > > I've tried it and never got it to work anywhere near decently. Also, this > again tries to bring a whole POSIX programming environment with it. And > they EOL'ed it after Win7. > > What I would (very hypothetically) want to do is just have a filesystem > wrapping shell interpreter that is capable of executing sh scripts, and > then use native Win32 ports of the common Unix utilities called through > this layer. > I'm not trying to create an environment to run POSIX programs in, I want to > bring the common Unix tools' functionality to an sh interpreter running in > Windows. I imagine most of my work is made quite trivial by using Boost's > extensive functionality (regex, filesystem, etc...). > Do these interact with win32 processes? How does signal IPC work? How do piping and coproc work? How do you do the path translation? > If you could give me a real-world (albeit simple) example of some sh > trickery that is impossible to implement (without e.g. the fully spec'ed > functionality of fork()), I would love to know so I can dump this crazy > idea in the trash can before I spend any lost time in it. Sh itself doesn't actually need full spec fork, since it has no concept of memory addresses. The hard part is the other Unix apps that already use fork calls in C. Another hard part is the fork/exec pairs. As you run exec, the process is expected to still have the same pid. It is possible to have a process to dump it's pid before exec'ing something else. Not sure how to accomplish this in Windows without some external bookkeeping.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
