Jay,
You seem to have some very major problems with both the AT&T web site and your understanding of the available software. You are not meant to download every single package you see on the site. Each and every downloadable file serves a completely different purpose. For your purpose, you should IGNORE anything that does not start with uwin. If you only download uwin stuff, there is no reason to get anything else. Do not get anything labeled anything else. Once you get the uwin stuff, you are done. There is no reason to want to do anything else except install the binary files. There is no reason for you to recompile anyting. The source is there if you want to change things, but it is better to just use it for a few months before you try compiling things. Simply give up the idea of recompiling. It serves no purpose. The software already works "out of the box". There is no reason to set or change environment variables. Just leave everything alone as it is installed. Use it and see what you think first before you start mucking things up. UWIN is a complete ast-based environment. It starts with ast and includes all ast-based utilities, including ksh. It is a complete environment. Nothing else is required. Cygwin is a giant pile of linux and has no relation to anything in UWIN. Do not associate anything in cygwin with anything in UWIN. Remove cygwin from your system and you will be better off. /Jow ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay Sent: Thursday, April 10, 2008 5:45 AM To: David Korn; [email protected] Subject: RE: [uwin-users] first impressions.. David, thanks for replying. realize: I am a potential user of both AST and/or UWin. I am not sure which is which, and I don't think that is terrible. I added myself to "all" the lists. I guess UWin is posix.dll and pthreads.dll. AST is ksh and Graphvis and CDT. UWin is stuff exclusively for Windows. AST is stuff on top of UWin and top of "native Unix". I said the package collection is NOT huge, but I was unclear. What do you consider "Cygwin" binaries vs. non-Cygwin Windows binaries? I guess you consider "native UWin" to be like, any of a variety of Win32 toolsets? Whatever your cc wraps? Pardon me for merging multiple toptics into one mail, here goes: Your cc didn't find my cl. Here are more strategies: Imagine a) At every opportunity where setup asked to set some variables, I declined. b) or after running setup, I clean installed the OS. and/or c) I have my own .bat files that establish %PATH%/%LIB%/%INCLUDE% Some implications: Various versions of Visual C++ have unique variables, besides the common PATH/LIB/INCLUDE. While I clear those after setup, they are not unreasonable to depend upon. Here is my prototype Python code (You can find this via modula3.elegosoft.com) VCBin = "" VCInc = "" VCLib = "" MspdbDir = "" # 4.0 e:\MSDEV # 5.0 E:\Program Files\DevStudio\SharedIDE MSDevDir = os.environ.get("MSDevDir") # 5.0 MSVCDir = os.environ.get("MSVCDir") # E:\Program Files\DevStudio\VC # 7.1 Express VCToolkitInstallDir = os.environ.get("VCToolkitInstallDir") # E:\Program Files\Microsoft Visual C++ Toolkit 2003 (not set by vcvars32) # 8.0 Express # E:\Program Files\Microsoft Visual Studio 8\VC # E:\Program Files\Microsoft Visual Studio 8\Common7\Tools DevEnvDir = os.environ.get("DevEnvDir") # E:\Program Files\Microsoft Visual Studio 8\Common7\IDE VSInstallDir = os.environ.get("VSINSTALLDIR") # E:\Program Files\Microsoft Visual Studio 8 # VS80CommonTools = os.environ.get("VS80COMNTOOLS") # E:\Program Files\Microsoft Visual Studio 8\Common7\Tools VCInstallDir = os.environ.get("VCINSTALLDIR") # E:\Program Files\Microsoft Visual Studio 8\VC # # This is not yet finished. # # Probe the partly version-specific less-polluting environment variables, # from newest to oldest. # That is, having setup alter PATH, INCLUDE, and LIB system-wide is not # a great idea, but having setup set DevEnvDir, VSINSTALLDIR, VS80COMNTOOLS, etc. # isn't so bad and we can temporarily establish the first set from the second # set. # if VSInstallDir: # # Visual C++ 2005/8.0, at least the Express Edition, free download # if not VCInstallDir: VCInstallDir = os.path.join(VSInstallDir, "VC") if not DevEnvDir: DevEnvDir = os.path.join(VSInstallDir, "Common7", "IDE") MspdbDir = DevEnvDir elif VCToolkitInstallDir: # # free download Visual C++ 2003; no longer available # VCInstallDir = VCToolkitInstallDir elif MSVCDir and MSDevDir: # # Visual C++ 5.0 # pass # do more research # VCInstallDir = MSVCDir elif MSDevDir: # # Visual C++ 4.0, 5.0 # pass # do more research # VCInstallDir = MSDevDir else: # # This is what really happens on my machine, for 8.0. # It might be good to guide pylib.py to other versions, # however setting things up manually suffices and I have, um, # well automated. # Msdev = os.path.join(SystemDrive, "msdev", "80") VCInstallDir = os.path.join(Msdev, "VC") DevEnvDir = os.path.join(Msdev, "Common7", "IDE") if VCInstallDir: VCBin = os.path.join(VCInstallDir, "bin") VCLib = os.path.join(VCInstallDir, "lib") VCInc = os.path.join(VCInstallDir, "include") if DevEnvDir: MspdbDir = DevEnvDir #elif VCBin: # MspdbDir = VCBin _SetupEnvironmentVariableAll("INCLUDE", ["errno.h"], VCInc) _SetupEnvironmentVariableAll( "LIB", ["kernel32.lib", "libcmt.lib"], VCLib + os.path.pathsep + os.path.join(InstallRoot, "lib")) # # Do this before mspdb*dll because it sometimes gets it in the path. # _SetupEnvironmentVariableAll("PATH", ["cl", "link"], VCBin) _SetupEnvironmentVariableAny( "PATH", ["mspdb80.dll", "mspdb71.dll", "mspdb70.dll", "mspdb60.dll", "mspdb50.dll", "mspdb41.dll", "mspdb40.dll", "dbi.dll"], MspdbDir) _SetupEnvironmentVariableAny( "PATH", ["msobj80.dll", "msobj71.dll", "msobj10.dll", "msobj10.dll", "mspdb50.dll", "mspdb41.dll", "mspdb40.dll", "dbi.dll"], MspdbDir) # # The free Visual C++ 2003 has neither delayimp.lib nor msvcrt.lib. # Very old toolsets have no delayimp.lib. # The Quake config file checks these environment variables. # Lib = os.environ.get("LIB") if not SearchPath("delayimp.lib", Lib): os.environ["USE_DELAYLOAD"] = "0" if not SearchPath("msvcrt.lib", Lib): os.environ["USE_MSVCRT"] = "0" _SetupEnvironmentVariableAll checks if all the listed files are in the variable, else adds the parameter. _SetupEnvironmentVariableAny checks if any are, and if not, adds. def _SetupEnvironmentVariableAll(Name, RequiredFiles, Attempt): AnyMissing = False Value = os.environ.get(Name) if Value: for File in RequiredFiles: if not SearchPath(File, Value): AnyMissing = True break else: AnyMissing = True if AnyMissing: if Value: NewValue = Attempt + os.path.pathsep + Value else: NewValue = Attempt for File in RequiredFiles: if not SearchPath(File, NewValue): print("ERROR: " + File + " not found in " + _FormatEnvironmentVariable(Name) + "(" + NewValue + ")") sys.exit(1) os.environ[Name] = NewValue if Value: print(Name + "=" + Attempt + os.pathsep + _FormatEnvironmentVariable(Name)) else: print(Name + "=" + Attempt) def _SetupEnvironmentVariableAny(Name, RequiredFiles, Attempt): Value = os.environ.get(Name) if Value: for File in RequiredFiles: if SearchPath(File, Value): return if Value: NewValue = Attempt + os.path.pathsep + Value else: NewValue = Attempt for File in RequiredFiles: if SearchPath(File, NewValue): os.environ[Name] = NewValue if Value: print(Name + "=" + NewValue + os.pathsep + _FormatEnvironmentVariable(Name)) else: print(Name + "=" + NewValue) return print("ERROR: " + _FormatEnvironmentVariable(Name) + " does not have any of " + " ".join(RequiredFiles)) sys.exit(1) # # http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52224 # def SearchPath(name, paths = getenv("PATH")): #Given a search path, find file if (name.find("/") != -1) or (name.find("\\") != -1): if os.path.isfile(name): return name if paths == "": return None (base, exts) = os.path.splitext(name) if not exts: exts = (getenv("PATHEXT") or "").lower() for ext in exts.split(";"): if ext == ".": ext = "" name = (base + ext) for path in paths.split(os.path.pathsep): candidate = os.path.join(path, name) if os.path.isfile(candidate): return os.path.abspath(candidate) So this is two strategies in one: search %PATH% for cl.exe, link.exe, etc., and if not found, look in some other environment variables. As well, check the default install locations. I don't have all that data collected, but like %systemdrive%:\dm for digital mars. %systemdrive%:\program files\blahblah for Visual C++ I install Metrowerks (don't use it much) to \mwerks\6, \mwerks\7, but that's me. Visual C++ to \msdev\40, \msdev\50, \msdev\60, \msdev\70, \msdev\80, etc., also just me. SO you are saying if I setup things so that cc/ld find cl/link, I can just build X from source? A particular branch? The Cygwin stuff builds from a particular branch I think. There is some overlap of packages and it is confusing. CDT is available as a separate download, but appears old. And it is part of other packages, up to date?? > 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. I'm not stupid..but I am a bit confused. The downloads are all together. I understand UWin is a Unix portability layer akin to Cygwin. And AST is a bunch of "apps", like Graphviz, not a portability layer. You'd build it on Cygwin or UWin, maybe either works similarly. But UWin I think has a "better" license. The UWin and AST downloads are in the same place and I'd rather hope that folks (you) knowledgable about one, are also knowledable about the other... - Jay ________________________________ > Date: Wed, 9 Apr 2008 10:10:34 -0400 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED]; [email protected] > Subject: Re: [uwin-users] first impressions.. > > 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
