cc:  [EMAIL PROTECTED]
Subject: Re: [uwin-users] first impressions..
--------

First, thanks for the feedback.
> I spent just a small amount of time trying to use/install/build uwin/ast.
> My experience was good and bad.
> I'm mainly a Win32 user and that's what I used.
> The base Win32 binary installer + X Windows installers work.
> I would prefer a somewhat smaller base -- like maybe no services.Or 
> prompting. I
>  was surprised good and bad to see sshd running.
> I would prefer that the install not deny me access to some of the files.But 
> that
>  is easily fixed. I take ownership and then reacl.
>  
> The /apparent/ but not yet realized by me ease of building the system from 
> sourc
> e, esp. from just sh+ratz+package, is attractive.
>  
> The /apparent/ but not yet clear to me more liberal license than that of 
> Cygwin 
> is attractive (below).
>  
> That it includes an X Windows server is somewhat attractive. I have some X 
> code 
> I'd like to try on Windows.
> Ok, now my big complaints:
> 1) several packages appear to be out of date.Some packages have no source 
> distri
> bution.  For example mawl.  For example X Windows.  cdt appears old.
Since mawl is not part of UWIN, I assume that you are talking about
other packages on the site; not just UWIN.  UWIN has a recent version of
cdt as part of the ast library and is in src/lib/libast/cdt in the
source code.  The X-Windows package was built from a download of
the X11R6.6 source several months ago.
> It sounds like some of the source archives overlap, but I don'tthink the 
> overlap
> ping ones had the same dates.
> Given that there aren't a HUGE number of packages, some "all" option would be 
> ni
> ce.
UWIN does not have a huge number of packages.  There are the following:
        base
        developement
        x11base
        x11development
        groff
        perl
The base package contains the AST software which contains many libraries such 
as vcodex and cdt.
>  
> 2) Attempting to build the system from source appears  to lead to much 
> different
>  results than that the installer produces.  Besides that I got compilation 
> error
> s that I haven't dug into yet,  the file system layout is different. This 
> seems 
> wrong.
> The binaries claim to be for a "cygwin.i386" flavor.I don't quite get the 
> relati
> onship between uwin and cygwin.I get, sure, that cygwin can be used to 
> bootstrap
>  using ratz/package.I get, sure, that uwin doesn't really include a compiler, 
> po
> ssibly a good thing.But, e.g. being "cygwin" implies a possible cygwin1.dll 
> depe
> ndency.
The "cygwin.i386" binaries have nothing to do with UWIN.  The cygwin.i386
is a compilation of the AST software for Cygwin.  UWIN contains
a compilation of this for UWIN as well as many other commands that
are not part of AST.
> The directions are not clear as to if I must alter %PATH%.They have some 
> wierd w
> ording about some things requiring it.Is the point, like, if I use nmake, I 
> need
>  to alter %PATH%?And it is just..I installed to 
> \uwin...\uwin\arch\cygwin.i386 o
> r such?I forget now if the X binaries were there -- but actually, the X 
> binaries
> have no source, so I they were installed with a binary installer, whichputs 
> the 
> files elsewhere entirely.
We will post at least the changes we made to the X11 sources.
> I don't think I ever found a short summary of the license.That would be nice.
Here is a short summary:
1.      Don't sue us.
2.      If you distribute, make it clear to anyone that AT&T has no
        liability.
3.      If you make changes to source code in any of our modules and
        distriubte, you must make this changes available as well.
4.      You can add new modules that are proprietary and distribute.
> I will fiddle around more here.I realize my report here is all very 
> unscientific
>  and devoid of details.
> uwin looks like a good alternative to Cygwin.I'll have to find how it 
> implements
>  fork/vfork/exec, see if it isefficient unlike Cygwin (I get that fork would 
> be 
> quite difficult, butvfork+exec maybe not..)
UWIN implements fork() as well as vfork().  Actually, exec was harder to
implement than fork().
> Do you have any AMD64 (or IA64?) Windows versions?
We expect to build a 64 bit version some time this year.
>  - Jay
> (attachment  1    66/3194               text/html "1.att")
> 
> _______________________________________________
> uwin-users mailing list
> [email protected]
> https://mailman.research.att.com/mailman/listinfo/uwin-users
> 

David Korn
[EMAIL PROTECTED]
_______________________________________________
uwin-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/uwin-users

Reply via email to