Windows port?

[Rob Landley]

On Wednesday 14 April 2010 15:42:41 Denys Vlasenko wrote:
> On Tue, Apr 13, 2010 at 10:33 PM, Nguyen Thai Ngoc Duy
>
> <pclouds at gmail.com> wrote:
> > On Wed, Apr 14, 2010 at 4:34 AM, Denys Vlasenko
> >
> > <vda.linux at googlemail.com> wrote:
> >>> 4. ash
> >>> ~1000 lines, half of them to work around fork(). Not everything works,
> >>> and not really stable. I'm thinking about a thread-based ash so that
> >>> it would work faster, but stability first.
> >>
> >> hush may be a better shell to work with, it can avoid using fork()
> >> (will use vfork+preparatory_work_in_the_same_process_image+exec
> >> if built for NOMMU, which probably maps better to Win CreateProcess()
> >> call or whatever)
> >
> > And its functionality is quite limited too.
>
> What do you miss most in it?
>
> > The
> > preparatory_work_in_the_same_process_image is done, all needed memory
> > is packed into a big block, then mapped over the child process. Anyway
> > I spent to much time with ash already.
>
> It was just a suggestion. Maybe hacking on ash will be actually easier.
> I don't know.

For clarification:

Denys and I got to hang out together a lot at CELF, and he pointed out to me 
that lots of Ash is still legacy code nobody understands, but he (Denys) has a 
good mental model of everything Hush is currently doing.

That makes Hush a good basis for things like me trying to replace bash with a 
busybox shell in FWL and then build lots of other packages with it.  If 
something in hush breaks, we can fix it without having to first do extensive 
forensic analysis of the current code to see what behavior we actually got and 
where it needs to be changed.

Thus hush may see significant development soonish, enough to be able to replace 
Bash.  Ash is unlikely to see such development.  And ash is harder to CONFIG 
down to be small, Hush is nicely granular.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds