Re: problem compiling code with OpenGL calls
William Wallace wrote: I trying to compile a simple .c program that I downloaded from sgi.com. I'm using the following to compile the program (works on my UNIX box...): gcc example.c -lglut -lGL -lGLU -L/usr/X11R6/lib -lX11 -lXmu -lm I get a slew of compile errors, for every OpenGL api call..For instance: /cygdrive/c/DOCUME~1//LOCALS~1/Temp/ccMTvQUj.o:example.c:(.text+0x2a): undefined reference to [EMAIL PROTECTED]' I noticed something a bit odd. The documentation states that /usr/include/GL should contain the files: glut.h and gl.h, but I ONLY have glut.h. ... OpenGL is a bit confusing in Cygwin, because you can compile programs to use Win32 WGL or X11 GLX as your OpenGL provider. This is a case of using WIN32 libraries versus Cygwin libraries is useful, because GLUT provides all of the OS-dependent interface. The Win32 headers are in /usr/include/w32api (included by default?) and are linked with -lOPENGL32. The X11 headers are under /usr/X11R6/include and are linked with flags as you describe above. Joe Krahn -- 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: MultiWindow versus MWExtWM
billh wrote: Any discussion of internal vs external window management cannot take place without acknowledging the fact that we are talking about XWindows operating within another window system, Cygwin/X. The immediate fact here is that any action that a window manager takes that is synchronous to the actions of the clients, such as on an xterm resize, when the window manager may inforce an incremental sizing based on the character width or heighth has to be handled in the window proc of the X server running as a Windows client, otherwise the sequence of events cannot be the same as in a native X Windows environment. In the case of window resizing, the first order solution has the window being resized to any arbitrary size by the Windows window system, and then a second event where an external window manager would resize the window to a size based on window hints registered with the X Window system. Though this can happen very quickly, there are always side effects typically in older programs that are perhaps more reliant on past behavior of X and even in some cases certain window managers. Okay, I'll fess up. I used to work for WRQ on the ReflectionX server. We found that in fact there were financial reasons, meaning enough customers, to support both approaches. Some customers wanted a more Windows centric look and feel and some needed for compatibility reasons an X window manager. I'm not trying to discuss Win32 WM-proxy versus a true X Window Manager. I'm simply comparing how the Win32 WM is implemented. I think most people would prefer using the Win32 WM, if there were no compatibilty problems. (BTW: what types of compatibilyt problems were there?) What I am aiming toward is Windows-managed windows, but proxied in a way that works more like a native X window manager. This means that most of the WndProc handling needs to be handled by Window Manager code. That's why I suggested WndProc Hooking. I ported GWM to our environment and my associate Kyle went through the ICCCM documents and made our Windows management mode honor all of that documents guidelines for window management. This gave us both modes at the flip of a switch in the control interface gui. For a commercial product, we could justify both. My idea is that WndProc hooking can allow you to turn the internal WM on or off by adding/removing WndProc hooks (or possibly internal hooks.) I'm just suggesting that using the external WM approach will simplify the code; it's rather messy right now. THings may have changed, but i tend to doubt it. PS This is offered in the spirit of openness. I am not saying that you should 'go commercial' for your X in Windows needs. Actually I am currently working on a Linux on Windows product that has its own X Server port via a frame buffer driver. Very cool! Don't port your Linux code, run it natively!!! Joe Krahn wrote: What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- 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/ -- 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/ -- 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/
Server design
I cam across this description of an X server design within windows: http://research.compaq.com/wrl/DECarchives/DTJ/DTJL03/DTJL03.HTM It has a Win32 WM interface that is functionally seperate, and uses Win32 Hooks to proxy Win32 WndProc messages; essentially the same as I recently suggested. It is sort of between the current MultiWindow and MWExtWM modes. Joe -- 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/
MultiWindow versus MWExtWM
What is the history of internal versus external Win32 WMs? It seems that Cygwin/X is favoring the internal WM, even though the external WM is a better fit to the X server design. I was looking into adding some NET_WM/EWMH features (mainly icons for now), and realized that most things have to be done differently on an internal WM, meaning extra work making non-reusable code. The current external WM is implemented using a proper X extension, which might be the source of some problems with the external WM. Maybe an efficient solution for the external WM would be to use WndProc hooks, so that window message passing can be done natively instead of through an X extension. Joe -- 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: Icon update .diff
Colin Harrison wrote: Hi, Another decision is what executables and dlls are built in distributions? Do we provide:- 1) Support for GL and Mesa only by two builds (current situation), where GL version is faster but less universally applicable? There should be one build with both renderers, handled just like Indirect/Mesa versus DRI in other X servers. 2) Support for builds of both Xwin and Xming from the same source tree? That will need separate versions of every object file, right? That is hard to do with the current design, but I have set up some Makefiles to prefix binary output files for multiple builds. I think this set up should really be more common, so one can build a Debug or Release versions without starting from scratch. 3) Additional specialist builds...I do my own xc/config/cf file changes, for instance, to optimise for Pentium processors and performance/codesize (~40% improvements easily made)? I think these types of tweaks are supposed to be confined to site.def if the main .cf is done right, but it seems that nobody distributes multiple example site.defs. This probably fits into the multiple-build Makefile idea. In the long run xorg is becoming modular (moving away from the original monolithic structure, we build against), should this be taken on board sooner or later? I would say later. As long as things get tweaked, Cygwin is likely to get a lot of incompatible changes. Best to wait until it is very stable. But, meanwhile, code additions and clean-ups should keep modularization in mind. Joe -- 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: Icon update .diff
Peter Valdemar Morch wrote: Joe Krahn jkrahn-at-nc.rr.com |Lists| wrote: 3) Decide if Win95/Me/NT/2000 need continued support. Win 2000 - yes please... OK, I was thinking this might be the one case where it may be needed for a while. Can you build and/or test code changes? Thanks, Joe -- 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: GetDC(NULL), GetModuleHandle(NULL), etc.
Alexander Gottwald wrote: On Fri, 2 Sep 2005, Joe Krahn wrote: GetModuleHandle(NULL) is also in several places. Maybe it's OK, but why not use the hInstance global? Global variables are bad(TM). With GetModuleHandle(NULL) there is no need to maintain a global hInstance. The other reason is there is no WinMain which has the hInstance parameter. So you'd require to set the global hInstance somewhere else and you have to make sure this occurs before the first reference to hInstance. GetModuleHandle(NULL) was used explicitly to reduce complexity. bye Globals are not really bad(TM), for things that really are global. But, a redundant global is definitely bad, so the global hInstance should be removed instead. Joe -- 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: Icon update .diff
Colin Harrison wrote: Hi, All your diffs seem to work almost correctly (see below), but still testing. In windialogs.c:- Should SM_CXICONSM be SM_CXSMICON, SM_CYICONSM be SM_CYSMICON ? Also had to remove the conditional on XWIN_MULTIWINDOW to get X icons It looks like that part of the code was #ifdef'ed out for XWIN_MULTIWINDOW. The intent was to use the two global overridable X icons for multiwindow mode, and get icons from the resources for other build modes. Maybe the multi-window mode needs to revert to resource icons if the global icons being undefined. I had set an override icon. As for Bugzilla, I would like to get a few more icon features tested, but maybe it's best to get bug-fixes sent in before trying enhancements. When I use the CVS defaults, only multi-window mode is built, so I didn't see the #ifdef XWIN_MULTIWINDOW code compiled. Why is only one version built? Is it rootless mode that gets excluded? Joe -- 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: Icon update .diff
Colin Harrison wrote: Joe Krahn wrote: When I use the CVS defaults, only multi-window mode is built, so I didn't see the #ifdef XWIN_MULTIWINDOW code compiled. Why is only one version built? Is it rootless mode that gets excluded? Mystery to me..the code is loaded with many ifdef's, the use of which is probably 'just-in-case' legacy stuff. Loosing a few as things are changed is maybe a good idea now. I was wondering about things like global icons (g_hIcon) which are #ifdef'ed in shared code to be used with XWIN_MULTIWINDOW, yet only the multiwindow code sets these icons. I guess there's a need for a round of overall code clean up. But, it works right now, so the incentive is small. It seems to me that it needs: 1) A review of globals, with true globals being made uniform across the root-window[less] modes, and other not-so-globals made non-global. 2) Get rid of unused 'legacy' #ifdef code. 3) Decide if Win95/Me/NT/2000 need continued support. 4) Reorganize files: get rid of the common win- prefix, and replace mode-specific prefixes with a directory, so xwin/winmultiwindowicons.c becomes xwin/multiwindow/icons.c. I think these could be done successfully without too much effort. But, these need some maintainer decisions first. Joe -- 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/
Icon update .diff
I didn't get around to finishing ARGB type icons yet, but here's some related patches for MultiWindow mode. See icon_and_class.diff at http://joekrahn.homelinux.com/XWin/ The code was changed to use a single Window class for all windows. Icon changes are sent to the Window instead of changing Class icons (much more reliable). With custom icons, the small icon is left undefined. MS-Windows will generate the small one for us. This will change with NET_WM_ICON support, which can define multiple icons. The horizontal-line mask problem is fixed. This came from using 32-bit aligne bitmap data, but creating device-dependent bitmaps which are 16-bit aligned. Joe -- 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: problem
Soong, SylokeJ wrote: When I first installed Cygwin/X and tried, I ran into the same puzzlement, if not panic. All the xterms and xclock I started were heaped into the same corner, intransigently unmoveable. (The sun shall not strike thee, nor the moon by night and your feet will not be moved, as though). Then I recalled, hmm There is an X Display Server and then there is an X Display Manager. I think. I'm sure I have not confused the terminology. Almost right: the Windows are managed by thw Window Manager, sort of like iexplore.exe in Windows, with the X Display Server being like Win32 GDI. The X Display Manager is actually access control, the log-in prompt on X-based systems. ... So I looked into the startxwin files and was as assured to find twm (which I guessed correctly is an X display mgr) commented out. I uncommented it and when XWin restarted my xterms and xclock were moveable. But I didn't like twm because the extremity of my X habits tends to pile up lots of windows and would have me a hard time searching for them without a desktop window locater. Which led me to install wmaker. Actually, the MultiWindow mode is nicer; it wraps windows to be managed by the native Win32 window manager, and also gets rid of the extra desktop root window. ... Or get a little more screwy, start x server on my laptop cygwin, throw wmaker from my win2k box to my laptop, login to sun box and throw xterms to my laptop. Sure, that would work just fine. X is well-designed enough to do such things, even if the remote host has a different binary format. You'll never see that from MS... Joe Krahn -- 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/
Some diffs to try
Some diffs to try out: http://joekrahn.homelinux.com/XWin/ Nice patch for windialogs.c icon issues. Removed hard-wired references to /tmp/XWin.log Still working on icons a bit. Question: How much should I worry about pre-WinXP compatibility? WinXP accepts ARGB icons. I think Win95/NT/2000 do not. Maybe just try an ARGB icon patch and see if someone can test it? Joe Krahn -- 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/
GetDC(NULL), GetModuleHandle(NULL), etc.
There are several GetDC(NULL) statements. Should these really be GetDC(hwndScreen)? It might make a difference for two screens with different pixel layouts. GetModuleHandle(NULL) is also in several places. Maybe it's OK, but why not use the hInstance global? These probably are just too low on the importance list for now. But, I thought it was worth mentioning. Joe -- 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: How to have more than one X display?
Soong, SylokeJ wrote: How to indecisively start more than one X display on my XP system? Currently I have a startxwin.bat: SET DISPLAY=127.0.0.1:0.0 .. run XWin -screen 0 1750 1350 -whateverelse run wmaker as well as startxwin1.bat: = SET DISPLAY=127.0.0.1:0.1 .. run XWin -screen 1 1750 1350 -whateverelse run wmaker The problem here is that you are varying the screen number, not the display number. Multiple screens come from one server. Try using DISPLAY=127.0.0.1:1.0 for the second one. It seems to work OK, at least if you don't try to use multi-window mode for both, even though several things hint that XWin code does not worry much about multiple servers. Joe -- 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: Icons
Joe Krahn wrote: ... It looks like can go from a device dependent X Pixmap (DDPixmap) to a device dependent Win32 bitmap (DDBitmap), then use Windows functions to scale when needed. This can only work if pixel data formats are the same between Windows and Cygwin/X. Does anyone know if there is any chance of an exception to this? This assumption does not completely work. Monochrome bitmaps have the reverse bit order in X11. I need to figure out if this is only true for monochome masks. I think the only other time it would matter is for a 4-bit display, but I don't know if this would ever happen. One thing that is a problem: If X Pixmaps and Win Bitmaps (excluding new RGBA icons) are stored in device-dependent format, what happens when the display depth gets changed while X is running? If I start X, change the depth, then start an X app, the icon is mangled. So, I think we should always expand to DIB RGBA format, and avoid using DDBitmaps. Can X RandR change depths? If so, is it not correctly tied in to Windows Display changes? Joe -- 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: How to have more than one X display?
Joe Krahn wrote: Soong, SylokeJ wrote: How to indecisively start more than one X display on my XP system? Currently I have a startxwin.bat: SET DISPLAY=127.0.0.1:0.0 .. run XWin -screen 0 1750 1350 -whateverelse run wmaker as well as startxwin1.bat: = SET DISPLAY=127.0.0.1:0.1 .. run XWin -screen 1 1750 1350 -whateverelse run wmaker The problem here is that you are varying the screen number, not the display number. Multiple screens come from one server. Try using DISPLAY=127.0.0.1:1.0 for the second one. It seems to work OK, at least if you don't try to use multi-window mode for both, even though several things hint that XWin code does not worry much about multiple servers. Oh... The DISPLAY variable has no effect on XWin. Try the following: XWin :0.0 and XWin :1.0 I can run several of these. But, I noticed that MultiWindow mode is broken for anything but display :0. Joe -- 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: Icons
Colin Harrison wrote: Hi, Here are my screen dumps http://www.straightrunning.com/test/icons_working.png http://www.straightrunning.com/test/icons_faulty.png Ignore the taskbar entries for [EMAIL PROTECTED] they are my PuTTY shells. Shows icon stripes and crappy X icon on exit window (exit one needs keen eyesight!) ... Yes, pictures clarify a lot. It's the mask that's bad, not the icon. I'll look through the code again this evening. Joe -- 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/
Icons
The newly built server does not leave a 'zombie' tray icon any longer. But, I still cannot get the XWinrc the set icons for client windows.Has anyone gotten this to work? Also, does XWin support X client defined icons? I don't recall seeing anything but the X icon, but maybe I just haven't run the right X program. Joe Krahn -- 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: # include statement in Xdefaults not working
Poor Yorick wrote: Hi, I hav a ~/.Xdefaults file with only one line in it: # include myXdefaults According to X man page, I expected myXdefaults to be included, but the resources declared in myXdefaults do not take effect. Any suggestions? Bye, Poor Yorick Try putting quotes around the file name (just as with CPP). Joe Krahn -- 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: Build problems, still.
Alan Hourihane wrote: I've just committed a couple of fixes which should cure the immediate problems. Let me know if something still doesn't work right. Alan. Yes! the whole build went OK, except for a patch to xedit/lisp to work around the problem of #including the wrong xedit.h. I also added some checks to disable visibility attributes in CYGWIN, which is not so critical. Thanks, Joe -- 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/
Build problems, still.
Has anyone gotten a full build to work recently? I got past the compsize.c changes in building the GL libs, but ran into similar problems in server GLX code. What is the relationship of Cygwin xc/ to the main Xorg xc/? Joe Krahn -- 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/
Fix for libGL building problems
In extras/Mesa/src/glx/x11/, some functions from compsize.c were moved to indirect_size.c. Some of these are implemented as function aliases, which does not work correctly under Cygwin. Cygwin uses these in Xserver/GL/windows/. This might be a problem in some other cases as well, but it works to add a !defined(__CYGWIN__) in indirect_size.c and indirect_size.h like this (I don't have CVS write access): # if (__GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ = 95)) !defined(__CYGWIN__) #define HAVE_ALIAS # endif I also noticed the inclusion of a visibility attribute based on the GCC version. Cygwin (and others?) does not support this either, but it is less critical because it seems to only cause attribute ignored warnings. Joe Krahn -- 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/
Build troubles at libGL
I'm trying to build Cygwin X. On the first try, I had a lot of unresolved OpenGL references. After cvs-update, the 'make World' went OK. But, then a 'make install', after moving the existing /usr/X11R6 directory, ended up with several unresolved GL symbols. No doubt, this is related to recent attempts at accelerated OpenGL support. Any ideas? Could this relate to the version of headers in /usr/include/GL? I was hoping to tweak the Tray icon a bit. When I exit X, the icon stays as a 'zombie', and disappears on mouse-over. Joe Krahn gcc -shared -Wl,--out-implib=libGL-1.dll.a -Wl,--enable-auto-import,--enable-runtime-pseudo-reloc -Wl,--exclude-libs,ALL -o cygGL-1.dll ../../../lib/GL/glx/?*.o -L../../../exports/lib -lXext -lX11 Creating library file: libGL-1.dll.a ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x3acc): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x3dd2): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x3fdc): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x42d2): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x4802): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x4d72): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x4fb2): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x50e2): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x8e62): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0x9942): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/indirect.o:indirect.c:(.text+0xe7ac): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/render2.o:render2.c:(.text+0x2a1): undefined reference to [EMAIL PROTECTED]@4' ../../../lib/GL/glx/render2.o:render2.c:(.text+0x809): undefined reference to [EMAIL PROTECTED]@4' collect2: ld returned 1 exit status make[4]: *** [cygGL-1.dll] Error 1 -- 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/
