Re: Built XWin on mingw - with patches
On 10/11/2011 16:50, Ryan Pavlik wrote: > On Mon, Nov 7, 2011 at 12:10 PM, Jon TURNEY wrote: >> 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch >> >> I am a bit unclear why this is needed, surely the winsock API predates XP? >> It might be better to add this define to CFLAGS rather than to start >> sprinkling it around source files as needed? > > Yes, but one of the calls in that file uses a part of the winsock API > introduced in XP - getaddrinfo and freeaddrinfo. > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ws2tcpip.h?rev=1.12&content-type=text/x-cvsweb-markup&cvsroot=src In my build testing, this only seems to be a problem if you explicitly ./configure the X server with --enable-ipv6, and in that case other build problems exist as well (No inet_pton/inet_ntop, inclusion of ws2tcpip.h is needed) (Ideally, if you were to ./configure with CFLAGS=-D_WIN32_WINNT=0x0501, IPv6 should be auto-detected by ./configure and build successfully. But this auto-detection doesn't work, because AC_CHECK_FUNC(getaddrinfo) fails because the test program generated doesn't prototype getaddrinfo, so it doesn't look for it with stdcall mangling...) So it seems there are a couple of generic problems here, so I'm not sure fixing it like this is the right thing to do. >> 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch >> >> Interesting. >> >> It would probably be useful to quote the language from the appropriate >> standard which describes the behavior of realloc() in this error case in the >> comment. >> >> I don't think this change is fully correct however. If the realloc'ed size >> is 0, realloc() may return NULL, but the previously allocated memory has >> been freed. Perhaps you need to check if errno has been set by realloc to >> distinguish these two cases? >> >> Did you notice this by inspection or actually have a problem caused by this >> code? Have you audited the rest of the xserver code for this class of error? > > Good point. I found this with cppcheck - a static analysis tool that, > despite its name, is useful for C code as well. There were other > issues it mentioned in the xserver code, but I didn't get to any of > the others yet. In any case, it's a completely orthogonal patch. Might > be useful for someone more familiar with the code to run cppcheck and > address the issues. Since it's outside my area of expertise to do a good review, I'd suggest you post this patch (when you have it in a correct form) directly to xorg-devel. >> 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch >> >> Use whitespace consistently with the context, please > > Oops - will correct. Looking at this again, I'm a bit puzzled by the comment "Fixes having to pass this flag for a successful MinGW build" I can understand adding MinGW to the set of targets which don't have setuid binaries, but I'm not sure how the MinGW build can fail if this flag isn't supplied: INSTALL_SETUID appears to only apply to installing the Xorg DDX. Is the real bug here that the test immediately below this assumes that we are not cross-compiling? Should the test check for cross-compiling and assume setuid binaries are possible unless it's on the list of excluded targets? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
Ryan Pavlik iastate.edu> writes: > > On Mon, Nov 7, 2011 at 12:10 PM, Jon TURNEY dronecode.org.uk> wrote: > > Sorry, I should have mentioned this before, but please can you add a > > 'Signed-off-by' line to these (git commit --amend --signoff will add one for > > you) > > > > A few comments, I'll take a deeper look later: > > > > 0001-os-osinit.c-Exclude-new-signal-sigaction-code-on-non.patch > > > > Shouldn't this be X_NOT_POSIX rather than X_NO_POSIX? > > Good catch, thanks! > > > > > 0006-hw-xwin-Makefile.am-Include-manifest-in-the-dist-tar.patch > > > > Good catch! > > > > Yeah, notices this when trying to build for tarballs. > > > 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch > > > > I am a bit unclear why this is needed, surely the winsock API predates XP? > > It might be better to add this define to CFLAGS rather than to start > > sprinkling it around source files as needed? > > > > Yes, but one of the calls in that file uses a part of the winsock API > introduced in XP - getaddrinfo and freeaddrinfo. > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ws2tcpip.h?rev=1.12&content-type=text/x-cvsweb-markup&cvsroot=src > > > 0013-hw-xwin-InitOutput.c-Remove-duplicated-code-for-sett.patch > > > > Comment should probably say 'Consolidate duplicate code' rather than > > 'Remove' > > > > It seems this changes more than that, though, as it now looks for the files > > in both PROJECTROOT and basedir? > > > > 0017-dix-registry.c-non-cygwin-find-protocol.txt-in-reloc.patch > > > > I think the answer to the question 'Should this actually be checking > > RELOCATE_PROJECTROOT ?' is yes > > > > The catch here is that RELOCATE_PROJECTROOT is currently (added by me, > since it wasn't in any header except the unused autogenerated one) in > xwin-config.h. Would it be appropriate to move it to dix-config.h for > this purpose? > > > I think it would probably be neater to do something like arrange for > > FILENAME to start with the platform-appropriate path separator, rather than > > to define FILENAME_ONLY as the same name without an initial path separator? > > > > The difference is not just the path separator - the FILENAME also > includes the macro define (string literal) of the install location, > which is concatenated with the filename by the preprocessor. > > > 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch > > > > Interesting. > > > > It would probably be useful to quote the language from the appropriate > > standard which describes the behavior of realloc() in this error case in the > > comment. > > > > I don't think this change is fully correct however. If the realloc'ed size > > is 0, realloc() may return NULL, but the previously allocated memory has > > been freed. Perhaps you need to check if errno has been set by realloc to > > distinguish these two cases? > > > > Did you notice this by inspection or actually have a problem caused by this > > code? Have you audited the rest of the xserver code for this class of error? > > > > Good point. I found this with cppcheck - a static analysis tool that, > despite its name, is useful for C code as well. There were other > issues it mentioned in the xserver code, but I didn't get to any of > the others yet. In any case, it's a completely orthogonal patch. Might > be useful for someone more familiar with the code to run cppcheck and > address the issues. > > > 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch > > > > Use whitespace consistently with the context, please > > Oops - will correct. > > > > > -- > > Jon TURNEY > > Volunteer Cygwin/X X Server maintainer > > > I have successfully built XWin with some Xming project patches( manually adopted line by line after understanding the purpose) on MINGW environment and also activated GLX. not AIGLX yet because I couldn't find a way to build swrast driver of Mesa with xlib option, but server side is activated. I am finalizing my built, and I am facing on an issue point. 1. in MINGW environment, I could successfully compile xkeyboard-config 1.3 version package, but higher version is failed. below is an error message from version 2.3 interesting thing is "xkbcomp -lfhlpR -o compat.dir '*'" command doesn't generate the compat.dir file and even command from 1.3 also doesn't generate the file when I manually wrote in MINGW shell. but 1.3 version is working in script operation in the shell. why I am trying to do this is to figure out an root error point after calling XSync() command in XMesaSwapBuffers() which is the last call after rendering 3D objects. Now, XWin is working fine before calling the command and the command is generating "BadRequest" and I believe that it comes from Xi module and then digging the root cause. ( to clean out a possibility because I used too old xkeyboard-config ) *** [ Client End ] seongnam@Panda ~/build/bin $ ./GLlesson05.exe Got Doublebuffered Visual! glX-Version
Re: Built XWin on mingw - with patches
On 11/10/2011 11:29 AM, Ryan Pavlik wrote: On Wed, Nov 9, 2011 at 1:11 PM, Charles Wilson wrote: You *think* you're safe in assuming that WIN32 == !__CYGWIN__, but...#include breaks all your assumptions. But jpeg.h *did nothing wrong*. It's better to be explicit. -- Chuck OK, so this leads me to the next question: The existing codebase has substantial numbers of places with #if defined(WIN32) - do these all imply #if defined(WIN32)&& !defined(__CYGWIN__) ? That I don't know. I generally avoided touching things I didn't have to, A good policy. but this may be worth clarifying codebase-wide. Perhaps -- I'll leave that call to others. I suspect a global patch that affected only #if lines should be a separate patch from any other changes, if taking this action was desirable. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
On Mon, Nov 7, 2011 at 12:10 PM, Jon TURNEY wrote: > Sorry, I should have mentioned this before, but please can you add a > 'Signed-off-by' line to these (git commit --amend --signoff will add one for > you) > > A few comments, I'll take a deeper look later: > > 0001-os-osinit.c-Exclude-new-signal-sigaction-code-on-non.patch > > Shouldn't this be X_NOT_POSIX rather than X_NO_POSIX? Good catch, thanks! > > 0006-hw-xwin-Makefile.am-Include-manifest-in-the-dist-tar.patch > > Good catch! :-) > Yeah, notices this when trying to build for tarballs. > 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch > > I am a bit unclear why this is needed, surely the winsock API predates XP? > It might be better to add this define to CFLAGS rather than to start > sprinkling it around source files as needed? > Yes, but one of the calls in that file uses a part of the winsock API introduced in XP - getaddrinfo and freeaddrinfo. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ws2tcpip.h?rev=1.12&content-type=text/x-cvsweb-markup&cvsroot=src > 0013-hw-xwin-InitOutput.c-Remove-duplicated-code-for-sett.patch > > Comment should probably say 'Consolidate duplicate code' rather than > 'Remove' > > It seems this changes more than that, though, as it now looks for the files > in both PROJECTROOT and basedir? > > 0017-dix-registry.c-non-cygwin-find-protocol.txt-in-reloc.patch > > I think the answer to the question 'Should this actually be checking > RELOCATE_PROJECTROOT ?' is yes > The catch here is that RELOCATE_PROJECTROOT is currently (added by me, since it wasn't in any header except the unused autogenerated one) in xwin-config.h. Would it be appropriate to move it to dix-config.h for this purpose? > I think it would probably be neater to do something like arrange for > FILENAME to start with the platform-appropriate path separator, rather than > to define FILENAME_ONLY as the same name without an initial path separator? > The difference is not just the path separator - the FILENAME also includes the macro define (string literal) of the install location, which is concatenated with the filename by the preprocessor. > 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch > > Interesting. > > It would probably be useful to quote the language from the appropriate > standard which describes the behavior of realloc() in this error case in the > comment. > > I don't think this change is fully correct however. If the realloc'ed size > is 0, realloc() may return NULL, but the previously allocated memory has > been freed. Perhaps you need to check if errno has been set by realloc to > distinguish these two cases? > > Did you notice this by inspection or actually have a problem caused by this > code? Have you audited the rest of the xserver code for this class of error? > Good point. I found this with cppcheck - a static analysis tool that, despite its name, is useful for C code as well. There were other issues it mentioned in the xserver code, but I didn't get to any of the others yet. In any case, it's a completely orthogonal patch. Might be useful for someone more familiar with the code to run cppcheck and address the issues. > 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch > > Use whitespace consistently with the context, please Oops - will correct. > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer > -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
On 11/9/2011 1:46 PM, Jon TURNEY wrote: On 07/11/2011 19:36, Charles Wilson wrote: But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... True. I guess what I meant to say is that there isn't any compiler which defines both WIN32 and CYGWIN (I hope :-)). Any portable code which includes w32api headers before checking if WIN32 is defined isn't going to be very portable :-) But it's perfectly portable to check for __CYGWIN__ (or, for that matter, __MINGW32__) instead of WIN32 before #including w32api headers, because you know that the windows API will be available in those cases as well. The difference is, IF you do this (perfectly fine, legal, and portable) thing: #if defined(WIN32) || defined(__CYGWIN__) # include #endif then you can no longer rely on #if defined(WIN32) ...stuff that applies only for truly "native" windows (e.g. ...msvc or mingw), but not cygwin #endif even though both hunks above are legal and make perfect sense *in isolation*. The problem occurs when both hunks are present in the same translation unit -- and that's not always under your control. What if libjpeg's header does the first hunk (it doesn't, but assume that it does for argument's sake), and your project's headers only do the second? You *think* you're safe in assuming that WIN32 == !__CYGWIN__, but...#include breaks all your assumptions. But jpeg.h *did nothing wrong*. It's better to be explicit. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
On 07/11/2011 19:36, Charles Wilson wrote: On 11/7/2011 1:10 PM, Jon TURNEY wrote: I see what you are trying to do here, but I'm not sure it actually adds any clarity. I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN are mutually exclusive, so '#if defined(WIN32)&& !defined(__CYGWIN__)' can just be written '#ifdef WIN32' But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... True. I guess what I meant to say is that there isn't any compiler which defines both WIN32 and CYGWIN (I hope :-)). Any portable code which includes w32api headers before checking if WIN32 is defined isn't going to be very portable :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
On 11/7/2011 1:10 PM, Jon TURNEY wrote: > I see what you are trying to do here, but I'm not sure it actually adds > any clarity. > > I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN > are mutually exclusive, so '#if defined(WIN32) && !defined(__CYGWIN__)' > can just be written '#ifdef WIN32' But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... windef.h: #ifndef WIN32 #define WIN32 #endif #ifndef _WIN32 #define _WIN32 #endif -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
On 04/11/2011 23:39, Ryan Pavlik wrote: On Thu, Nov 3, 2011 at 2:18 PM, Jon TURNEY wrote: On 01/11/2011 20:39, Ryan Pavlik wrote: specific and probably more appropriate than the overall xorg lists. I wanted to build a native windows X server (essentially an open-source Xming). I had to patch a number of the packages along the way, but did eventually arrive at a build that worked. I looked at and used a few of the Xming patches, but only generally went to those when the naive approach didn't work. This may be a problem. The material on the Xming website is licensed under a Creative Commons license, which is not compatible with the X11 license. So, patches from the Xming website are not acceptable unless the author has agreed to re-license them appropriately. I emailed him and he indicated that he already has a process worked out for re-licensing a patch at a time to submit to you. As such, I have re-worked my patch queue to remove all patches derived from the Xming web site. It doesn't add everything that the previous branch did, but it does build and start to work, and all these patches are licensed like the X11 source itself as they are my work. I also re-worked the commit messages and patches a bit, and added some additional patches. Okay, thank you. https://github.com/rpavlik/Xserver/tree/cleanpatches-1.11-branch I've quickly looked over these patches and in general they look good, and I'd be happy to help get them merged upstream. A couple of general points I'd make though: It helps a great deal in reviewing if the comments state why the change is a good idea (e.g. what problem it fixes), rather than just describing the change which is made. I've revised the commit messages for xorg-server accordingly - hopefully these are better. I also noticed that a bit more care might be needed with the define you are using to enable platform specific code: WIN32 and __MINGW__ should not be used interchangeably. WIN32 will also be defined when building VcXsrv, and neither is defined on Cygwin. Ah, true. I have gone through and improved this in my cleanpatches branch, and have also added some convenience defines to make this easier to get right - this is the last half of the commits. I see what you are trying to do here, but I'm not sure it actually adds any clarity. I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN are mutually exclusive, so '#if defined(WIN32) && !defined(__CYGWIN__)' can just be written '#ifdef WIN32' So, can you post your patches here, preferably in git-send-email format so we can review them in detail? I wasn't sure if you wanted one email per patch, and 43 emails seemed like an awful lot, so I've attached them all (git format-patch) to this one. If you prefer, I can send them individually to this (or another) list with git send-email. These are just the xserver patches, not the ones for other packages that I mentioned in the mingw-cross-env repository. Sorry, I should have mentioned this before, but please can you add a 'Signed-off-by' line to these (git commit --amend --signoff will add one for you) A few comments, I'll take a deeper look later: 0001-os-osinit.c-Exclude-new-signal-sigaction-code-on-non.patch Shouldn't this be X_NOT_POSIX rather than X_NO_POSIX? 0006-hw-xwin-Makefile.am-Include-manifest-in-the-dist-tar.patch Good catch! :-) 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch I am a bit unclear why this is needed, surely the winsock API predates XP? It might be better to add this define to CFLAGS rather than to start sprinkling it around source files as needed? 0013-hw-xwin-InitOutput.c-Remove-duplicated-code-for-sett.patch Comment should probably say 'Consolidate duplicate code' rather than 'Remove' It seems this changes more than that, though, as it now looks for the files in both PROJECTROOT and basedir? 0017-dix-registry.c-non-cygwin-find-protocol.txt-in-reloc.patch I think the answer to the question 'Should this actually be checking RELOCATE_PROJECTROOT ?' is yes I think it would probably be neater to do something like arrange for FILENAME to start with the platform-appropriate path separator, rather than to define FILENAME_ONLY as the same name without an initial path separator? 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch Interesting. It would probably be useful to quote the language from the appropriate standard which describes the behavior of realloc() in this error case in the comment. I don't think this change is fully correct however. If the realloc'ed size is 0, realloc() may return NULL, but the previously allocated memory has been freed. Perhaps you need to check if errno has been set by realloc to distinguish these two cases? Did you notice this by inspection or actually have a problem caused by this code? Have you audited the rest of the xserver code for this class of error? 0041-configure.ac-mingw-doesn-t-have-setuid-eithe
Re: Built XWin on mingw - with patches
On 01/11/2011 20:39, Ryan Pavlik wrote: Not sure if this is the right forum for this, but it seemed more This is absolutely the correct list. Thanks very much for putting in the effort to do this. specific and probably more appropriate than the overall xorg lists. I wanted to build a native windows X server (essentially an open-source Xming). I had to patch a number of the packages along the way, but did eventually arrive at a build that worked. I looked at and used a few of the Xming patches, but only generally went to those when the naive approach didn't work. This may be a problem. The material on the Xming website is licensed under a Creative Commons license, which is not compatible with the X11 license. So, patches from the Xming website are not acceptable unless the author has agreed to re-license them appropriately. I'm looking for some feedback on the patches so that they can get into the main line of the projects. I built using mingw-cross-env, with my fork here that includes the dependency packages: https://bitbucket.org/rpavlik/mingw-cross-env/ This builds everything except the xorg-server module (ignore the fact there's an xorg-server makefile there - the patches aren't up to date for that module.) Patches for these dependencies are as follows, in that mingw-cross-env repo (These should all have commit messages from being exported from git format-patch): libX11-1-add-xwinsock-include, libX11-2-windows-threads, libX11-3-MinGW-lacks-caddr_t libXaw-1-need-winsock libXfont-1-dummy-readlink libxcb-1-fix-include-order-with-Xdmcp, libxcb-2-wsastartup - this last one fixes running libX11 apps built for Windows, including the integrated multi-window WM. xkbcomp-1-Use-X11-Xwindows.h, xkbcomp-2-Look-in-windows-base-dir-too - this last one supports the "RELOCATE_PROJECTROOT" option in the XWin server - should still work fine in the normal case though. I've quickly looked over these patches and in general they look good, and I'd be happy to help get them merged upstream. A couple of general points I'd make though: It helps a great deal in reviewing if the comments state why the change is a good idea (e.g. what problem it fixes), rather than just describing the change which is made. I also noticed that a bit more care might be needed with the define you are using to enable platform specific code: WIN32 and __MINGW__ should not be used interchangeably. WIN32 will also be defined when building VcXsrv, and neither is defined on Cygwin. So, can you post your patches here, preferably in git-send-email format so we can review them in detail? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Built XWin on mingw - with patches
All, Not sure if this is the right forum for this, but it seemed more specific and probably more appropriate than the overall xorg lists. I wanted to build a native windows X server (essentially an open-source Xming). I had to patch a number of the packages along the way, but did eventually arrive at a build that worked. I looked at and used a few of the Xming patches, but only generally went to those when the naive approach didn't work. I'm looking for some feedback on the patches so that they can get into the main line of the projects. I built using mingw-cross-env, with my fork here that includes the dependency packages: https://bitbucket.org/rpavlik/mingw-cross-env/ This builds everything except the xorg-server module (ignore the fact there's an xorg-server makefile there - the patches aren't up to date for that module.) Patches for these dependencies are as follows, in that mingw-cross-env repo (These should all have commit messages from being exported from git format-patch): libX11-1-add-xwinsock-include, libX11-2-windows-threads, libX11-3-MinGW-lacks-caddr_t libXaw-1-need-winsock libXfont-1-dummy-readlink libxcb-1-fix-include-order-with-Xdmcp, libxcb-2-wsastartup - this last one fixes running libX11 apps built for Windows, including the integrated multi-window WM. xkbcomp-1-Use-X11-Xwindows.h, xkbcomp-2-Look-in-windows-base-dir-too - this last one supports the "RELOCATE_PROJECTROOT" option in the XWin server - should still work fine in the normal case though. Then, the xorg-server is here: https://github.com/rpavlik/Xserver/commits/patched-1.11-branch I've tried to make the commits independent, atomic changes. (For some of the patches from XMing, this does mean that I split some patches, and combined some from multiple files, since those patches are offered per-file, not per-topic.) With this, I can run in -rootless or default mode (metacity over ssh forwarding as well as local, patched Fluxbox work great for window managers), as well as -multiwindow, on a Windows 7 machine. This should run fine when installed to its prefix, as well, so I have hopefully not negatively affected a Cygwin build with any of my changes. I've put up some information on the wiki of my github repo, including full build instructions: https://github.com/rpavlik/Xserver/wiki I would appreciate any feedback either through this list, or through comments on the github commits, whichever is easier. A number of the xorg-server patches are not XWin specific, and most are not even XWin on MinGW-specific (that is, they may apply to Cygwin/X as well), so I'd like to see as much as you're comfortable with merged. Thanks for your time! Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
