Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Date: Thu, 8 Feb 2001 00:05:58 -0600 (CST)
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
To: Cygwin <cygwin AT cygwin DOT com>
Subject: Re: ksh93? -- also u/win question
In-Reply-To: <20010207230159.B22494@redhat.com>
Message-ID: <Pine.HPP.3.96.1010207233611.5245D-100000@hp2.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 7 Feb 2001, Christopher Faylor wrote:

> >I'm still working on it.  I sort of lost interest though, now that zsh runs
> >so smoothly under cygwin (no more status access violations, yay!).

Regarding ksh93, it's actually not that hard to port to Cygwin, once you 
figure out AT&T's build system. I've been using AT&T sources for many 
years, since the initial days of cfront, so it doesn't look that foreign 
to me. I've been way too busy with real life, and just haven't had the
time to tweak the various pieces yet (pathname handling, enhanced spawnv*
style api for cygwin, without using UWIN specific code, to speed things up,
etc). My shell scripts run under vendor ksh or bash, so I personally don't 
need it as much. 

> Can you give an example of some of the clever ideas in uwin?  I know that
> they have some sort of setuid daemon or something like that but it has been
> a while since I really investigated U/WIN.

Here's my take on this, and it's quite simple. A few years ago, when you
wanted Unix on PC with the feel of Unix, you had 3 or 4 choices, and the
prominent ones were Softway/Interix/now-Microsoft (which uses POSIX
subsystem, so different beast altogether), Cygwin and UWIN. UWIN provided
almost a real Unix feel right after you installed it, and that made a lot
of users feel more comfortable than the old pre v1.0 Cygwin layout scheme.
It also installed things like inetd etc right off the bat, and it just
made things easier. There were also little things like handling of hard
links and a few others.

In terms of technology, UWIN's process management was certainly much
faster (have not benchmarked against any recent Cygwin versions, so
please don't ask me how it compares now), and I/O subsystem using sfio
is *much* better. The system runtime uses AST library, which is also
very well done. Newlib is perhaps a good choice for an embedded system,
and while it's getting better, it still lacks of lot of features of a
modern hosted C runtime. The newlib math library is, ah how should I put 
it, not that great. UWIN has the advantage of leveraging MSVC runtime, 
which has a decent fp math library.

As an aside, those of you who go way back may remember the whole
debate about why Cygwin used newlib instead of GNU libc in the first
place (was it Fergus Henderson who started that thread?), but let's not
start that thread again since Geoffrey Noer et al had discussed the
rationale in some detail.

UMS/UCS in UWIN is certainly good technologies, which are "daemons" that
handle authentication. Cygwin has made huge progress in that area of
course.

> I thought that it was interesting that David Korn said that U/WIN may soon be
> open sourced.

That's what I hear as well; however, there are still remaining issues from 
I understand (AT&T is a big company, with lots of legal issues, and these
issues pay a lot of salaries ;-). I'd venture a guess for this motivation
(other than the usual go open source hoopla) -- one is the "mainstream"
popularity of Cygwin, thanks to all the work that's gone in since b19, and
more imporantly, the position of FSF that GCC can't be run under UWIN.

Two years ago, I had a contract to deliver a large software modeling and
simulation package for Windows based machine, and UWIN was the one that
I had to pick to get the work done. Now it's a whole different issue --
another research group within the same corporate entity gets the sources
from our CVS repo, builds it using locally using Cygwin and runs it very 
happily.

There's room for multiple competitors in this field, and that's good
thing. That's why we have Linux, FreeBSD, OpenBSD, other BSD's, Solaris
and probably a few others running on Intel hardware, all doing their
own thing.

Cygwin will thrive as long as contributors keep on chugging, with very 
valuable corporate support from RedHat. Making these tools commercially 
viable is a hard job, not that I feel for the marketing and sales 
types ;-)

Regards,
Mumit


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple