2013/1/14 JonY <[email protected]>
> 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.
>
Yes, I'd avoid this kind of implementation. Which constitutes a rewrite of
certain/most Unix utilities.
>
> >>
> >>> 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?
Sure, these would be win32 processes, bookkept by the main shell
interpreter if this is even required/necessary.
> How does signal IPC work?
Boost.Interprocess.
How do piping and coproc work?
I suppose piping is classified under IPC, and coproc seems like a Bash/ksh
extension not in POSIX sh, so I suppose outside of scope for now.
> How do you do the path translation?
>
That is of course a difficult one. Either internal bookkeeping or a simple
(?) translation function *where need be* (the hardest part being the latter
of course). MSYS achieves this somehow, so I'd start there.
>
> > 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.
>
That's good news, the C programs will need porting as I've said before in
sofar the ports don't already exist.
>
> 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.
That sounds like something that falls under the scope of the sh
interpreter. I'm not sure how relevant this is when we have fully Win32
native Unix-like utilities though.
I'll give the POSIX sh spec another good read and see if I can
self-motivate enough to get started on this :)
Remember: the goal is only writing a sh interpreter and making available
the Unix/GNU utilities which are mostly already available as native Win32
applications.
Ruben
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
