Re: Possibility of win32 executable on Cygwin/X
Mike Morgan wrote: I have been trying to come up with an answer to the following question through FAQs, google, and IRC, but to no avail. Its a simple question, but perhaps I am not asking/searching properly... I wish to know if its possible to run a proper windows formatted executable file through the local X server somehow. I assume this would take an extra program to do properly. My goal is to be able to run everything I do on my windows machine completely INSIDE of a KDE environment. This means that I could move the window around INSIDE the KDE desktop, from virtual desktop to virtual desktop, etc. I know this is asking a lot, but if it is possible yet, I would LOVE to know; otherwise I would be willing to work on such a goal, developing for the Cygwin/X project(s)? Sorry, I don't know all that much about them yet, but I would be willing to learn. For information on this, see the [EMAIL PROTECTED] mailing list archives, and search for cygpeace. More information linked from here: http://sources.redhat.com/XOpenWin/ In short, its a great idea, and somebody got an initial version (cygpeace) working with an old cygwin, but it doesn't work with the current one. But its not on topic for this mailing list, so please join the win32-x11 mailing list if you are interested in pursuing this further (it'll take some work on your part) David
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Probably best to test it using a local cygwin X server and a local application. Other than that I don't really understand cygpeace so I probably can't help, but you could always try contact the author though I'm not sure he intends to maintain it Karl Bowden wrote: Hmm. I have got it compiled ok, and installed ok, but it does not seem to have any effect. If I run the 'withdll -d:peacehook.dll winmine' from a remote linux session (with the env vars setup), withdll just sits there. No seg fault, nothing. I just have to end up hitting Ctrl-C. On Tue, 08 Feb 2005 13:57:11 +0200, David Fraser [EMAIL PROTECTED] wrote: Alexander Gottwald wrote: On Tue, 8 Feb 2005, Karl Bowden wrote: Has any body made any more progress on compiling and getting the CygPeace project working? This seems like a very worthwile project if somebody could supply binaries. The only other application I have seen to offer this feature of exporting applications, is the Citrix product. Not compiling is the big issue but running. It constantly crashed with cygwin 1.5.* but was reported to run with cygwin 1.3.* Afair there were some definitions which needed to be changed in order to get cygpeace to work, but these were quite simple changes. Below is error I get to do with inttypes.h that is included by a lot of files. $ make gcc -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C= -c -o ../common/handle.o ../common/handle.c g++ -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C=extern \C\ -c -o ../ui.so/BitmapBlock.o ../ui.so/BitmapBlock.cc In file included from ../ui.so/BitmapBlock.h:33, from ../ui.so/BitmapBlock.cc:29: include/sys/inttypes.h:6: error: conflicting types for `typedef unsigned int uint32_t' /usr/include/stdint.h:28: error: previous declaration as `typedef long unsigned int uint32_t' make: *** [../ui.so/BitmapBlock.o] Error 1 Maybe removing #inlude sys/inttypes.h helps Confirmed that I got it running fine on cygwin 1.3.x If you do make any progress on 1.5.x please report back to the list! David
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Alexander Gottwald wrote: On Tue, 8 Feb 2005, Karl Bowden wrote: Has any body made any more progress on compiling and getting the CygPeace project working? This seems like a very worthwile project if somebody could supply binaries. The only other application I have seen to offer this feature of exporting applications, is the Citrix product. Not compiling is the big issue but running. It constantly crashed with cygwin 1.5.* but was reported to run with cygwin 1.3.* Afair there were some definitions which needed to be changed in order to get cygpeace to work, but these were quite simple changes. Below is error I get to do with inttypes.h that is included by a lot of files. $ make gcc -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C= -c -o ../common/handle.o ../common/handle.c g++ -g -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I../common -I./include -DDLLMAIN -D__aconst= -DEXTERN_C=extern \C\ -c -o ../ui.so/BitmapBlock.o ../ui.so/BitmapBlock.cc In file included from ../ui.so/BitmapBlock.h:33, from ../ui.so/BitmapBlock.cc:29: include/sys/inttypes.h:6: error: conflicting types for `typedef unsigned int uint32_t' /usr/include/stdint.h:28: error: previous declaration as `typedef long unsigned int uint32_t' make: *** [../ui.so/BitmapBlock.o] Error 1 Maybe removing #inlude sys/inttypes.h helps Confirmed that I got it running fine on cygwin 1.3.x If you do make any progress on 1.5.x please report back to the list! David
Re: Packaged X Server for easy use
Christopher Faylor wrote: On Tue, Dec 07, 2004 at 11:43:33AM -0500, Joseph Miller wrote: Hello X Cygwin project. I got tired of the only option to use an X Server on Windows to be either use the X-Win32 trial (like i would pay $200+ for that!) or install the full cygwin environment. You don't have to install the full cygwin environment. The setup.exe installer allows you to install or not install whatever you please. So what I did was take out the binaries required to run the X Server (along with ssh and rsh) and put a Windows GUI interface to it, then packaged it with an installer so that the average user could download and use it. Please check it out at http://www.calcmaster.net/visual-c++/xwinlogon/ and let me know what you guys think. My next step is to rebuild the binaries from the sources, allow for installation along side of Cygwin without interference, and add -mwindows to remove the cmd.exe box that comes up with each window. Actually you may want to consider that your next step should be setting up a mailing list to discuss your package. We don't want to clutter this mailing list with discussion of random other packages that don't have anything to do with the intended purpose of this mailing list. And, for all of the people with fingers poised to fire off a I want hear about this interesting package response to this message -- please don't bother. You'll have to live with the fact that I am meanly not allowing this off-topic discussion. Would it be on-topic to discuss this on the [EMAIL PROTECTED] list? Then people (including Joseph) could be directed there... David
Re: Xfce for cygwin
Maarten Boekhold wrote: David Fraser wrote: Mark Fisher wrote: I've just ported xfce4.2 to cygwin, and start it like this: Fantastic! Are the patches included in the CVS, are their any particular build instructions? I'm on the xfce dev list but I didn't see anything about this ... The patches are in CVS (I was the one who committed them), and there are specific built instructions. You need to get libdbh and libstartup-notification yourself, and I'm using the attached script to build XFCE. Haven't tried this in some time though due to work load, so I can't guarantee everything still works out-of-the-box. And oh yeah, you need a very recent version of libtool. As I just wrote to Mark: Anyways, you do know that there is a couple of things that do not work in XFCE for cygwin, right? For one, panel plugins are not fully functional (just try to change the icon size in the panel and see what happens). Also, xffm doesn't work, neither is xfprint (I've never really tried this though), and xfce4-mixer. The problem with the panel plugins and xffm is that XFCE is coded such that the plugins must access variables in the loading program, and MS-Windows (and therefore cygwin) doesn't allow this. I've had some discussion with Jasper from the XFCE team about this, and we were thinking of a complete rewrite of the XFCE plugin system. However, this will have to wait until the 4.2 release, and I'm completely swamped in work at the moment... Maarten Fantastic, thanks Maarten David
Xfce for cygwin
Mark Fisher wrote: I've just ported xfce4.2 to cygwin, and start it like this: Fantastic! Are the patches included in the CVS, are their any particular build instructions? I'm on the xfce dev list but I didn't see anything about this ... David
Re: Why Xming.exe?
Christopher Faylor wrote: On Thu, Nov 11, 2004 at 10:30:48AM -0500, Christopher Faylor wrote: In any event Sorry. This message obviously slipped out before I was done with it. I blame my spastic index finger. It likes to press the y key. In any event, what I was going to say above was that In any event it is certainly possible to craft a Cygwin/X installation which only installs a minimal number of packages. No one has stepped forward to do this. Many of the observations made here are fixable just by having someone step forward to do the work in Cygwin. If no one is willing to do that, that's fine. You can do related work elsewhere but touting MinGW programs as a solution to Cygwin problems doesn't work. OK thats fine, just a minor point: there is one Cygwin problem that this solves, which is that people keep on requesting this kind of thing on the cygwin-xfree mailing list :-) Also its constructed from the same source code as cygwin/X so its arguably the same thing. But anyway we'll happy carry on discussion on a different list David
Re: Why Xming.exe?
Christopher Faylor wrote: On Thu, Nov 11, 2004 at 06:04:45PM +0200, David Fraser wrote: Christopher Faylor wrote: On Thu, Nov 11, 2004 at 10:30:48AM -0500, Christopher Faylor wrote: In any event Sorry. This message obviously slipped out before I was done with it. I blame my spastic index finger. It likes to press the y key. In any event, what I was going to say above was that In any event it is certainly possible to craft a Cygwin/X installation which only installs a minimal number of packages. No one has stepped forward to do this. Many of the observations made here are fixable just by having someone step forward to do the work in Cygwin. If no one is willing to do that, that's fine. You can do related work elsewhere but touting MinGW programs as a solution to Cygwin problems doesn't work. OK thats fine, just a minor point: there is one Cygwin problem that this solves, which is that people keep on requesting this kind of thing on the cygwin-xfree mailing list :-) Yes, and people keep requesting that Cygwin shouldn't be GPLed because it is inconvenient for them. People ask for su to work correctly. People occasionally want to discuss Xceed here, too. This isn't a ill-informed minority gets to decide mailing list. Fine, but at least we can have arguments about it :-) Also its constructed from the same source code as cygwin/X so its arguably the same thing. Is anyone here *at all* familiar with MinGW? Apparently few of you are or you wouldn't be making arguments like this. Much of MinGW is based on the same source code as what Cygwin uses. I use MinGW the whole time, yes, I know what it is. Using this logic, since Cygwin/X is based on the same source code that runs on many different platforms, apparently we should just shut this mailing list down and move everyone over to the main Xorg mailing lists. OK fine :-) But anyway we'll happy carry on discussion on a different list But not before trying to get off a few more shots, eh? Yes, you see I've managed to generate an extra 3 useless emails! And without your reply I wouldn't have managed to generate this one too ... You could actually compile Cygwin/X using cygwin GCC with the -mnocygwin option and that apparently would be off topic too. So I won't :-) Don't mean to hassle you so lets leave it at that David
Re: Project leadership change
Christopher Faylor wrote: On Thu, Jul 08, 2004 at 09:31:31PM +0200, Alexander Gottwald wrote: I have to make a sad announce: Harold Hunt, leader of the Cygwin/X project for some years will quit being the project leader because of his new job and family. With Harold quitting I'll take over leadership of the project and will be responsible for making releases, managing the website and documentation and managing the list. I hope I can come up with a similar performance as Harold had shown in the past and want to thank Harold for putting so much time and work into making Cygwin/X a great xserver with features similar to those from commercial ones. Thank you, Harold. After Harold, Kensuke and Takuma can not offer their time anymore we are now short on developers. This means that the external multiwindow windowmanager is not actively developed anymore and I can only continue working on small enhancements and bugfixes. Any help is greatly appreciated. I am also very sad that Harold is stepping down. It's the end of an era. However, thanks very much Andrew for your increased commitment to the project. Harold is leaving things in good hands. I presume you mean Alexander :-) This is one of the good things about open source. Harold etc have done fantastic work (as has Alexander) but they don't have to be forced into continuing it, others can... David
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Kensuke Matsuzaki wrote:
Hi,
On Sun, 30 May 2004, Ariel Burbaickij wrote:
I guess the topic says it all, gentlemen ;-)
No. There is currently no possibility to do this. The windows application
uses GDI to draw to the screen.
There is of course the possibility to catch the GDI calls at some point in
the windows layers and translate them to X11 but there is currently no
project which has managed to create at least code in alpha stage.
Sawanaka did that.
He ported PEACE on BSD to Cygwin, it seems to be called Cygpeace.
His site is wrote in Japanese. Please use online translation :)
http://www.d1.dion.ne.jp/~sawanaka/peace/
Screenshot of 'Mine Sweeper' on X
http://www.d1.dion.ne.jp/~sawanaka/peace/winmine.jpg
It has not been update since March 16, 2003.
Kensuke Matsuzaki
Wow! This is amazing! I wish I had known about it before ...
Still works, I only had to patch it to set the DEFAULT_CHARSET to Ansi
(see ttfont.cc, line 1140 or so for where to patch this)
Basic instructions for those not wanting to do the translation (actually
this is all in the page):
Download detours.exe from http://research.microsoft.com/sn/detours/
wget http://www.d1.dion.ne.jp/~sawanaka/peace/cygpeace-030316.tar.gz
Then make cygpeace:
tar zxvf cygpeace-030316.tar.gz
cd peace/dll/cygpeace
make
make install
Note that you make it in the cygpeace directory, don't try make in the
ui.so.dll directory
To extract and make detours (requires Visual C++)
$ ./detours.exe ([unzip to folder:] ./detours)
$ cd detours
$ rm lib/detours.pdb
$ nmake
$ cp samples/bin/withdll.exe /usr/local/bin/
To run a standard windows program using the hook to display in XWindows:
$ export PEACE_FONTPATH=`cygpath -u $WINDIR/Fonts`
$ export DISPLAY=:0.0
$ XWin -rootless
$ openbox # this is just to run a window manager
$ withdll -d:peacehook.dll winmine
To compile a program to use the hook interface directly:
$ cat msgbox.c
#include windows.h
int main()
{
MessageBox(NULL, test, NULL, MB_OK);
return 0;
}
$ gcc msgbox.c -o msgbox -L/usr/local/lib -lui.so
$ export DISPLAY=:0.0
$ ./msgbox
Voila. It even works on a remote X session from Linux :-)
David
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Alexander Gottwald wrote:
On Tue, 1 Jun 2004, David Fraser wrote:
Wow! This is amazing! I wish I had known about it before ...
Still works, I only had to patch it to set the DEFAULT_CHARSET to Ansi
(see ttfont.cc, line 1140 or so for where to patch this)
I got some errors with stdint.h vs sys/inttypes.h and LocalAlloc and
two other functions had SIZE_T instead of UINT arguments.
Yes, I actually forgot another fix I had to make... my full patch attached
But I'm still getting segfaults. The msgbox example segfaults
in cygwin1!aclcheck. Are you using the latest packages or some older
ones?
Probably a bit older but not too old ... attached my packages list
cygwin 1.3.22
I haven't tried it on a clean install.
It is worthwhile checking out previous error messages or using gdb for a
backtrace ... in my case the segfault was a font encoding issue, might
be different for you
Are the debug symbols for the cygwin1.dll still available?
Others would know better than me...
bye
ago
Cheers
David
diff -ur peace.orig/dll/ui.so/keyboard.cc peace/dll/ui.so/keyboard.cc
--- peace.orig/dll/ui.so/keyboard.cc 2003-03-12 14:38:37.0 +0200
+++ peace/dll/ui.so/keyboard.cc 2004-06-01 11:38:46.0 +0200
@@ -402,7 +402,7 @@
* @since Windows 98, Windows NT4 SP3
*/
EXTERN_C UINT WINAPI
-SendInput(UINT nInputs, /* INPUT* */void* pInputs, int size)
+SendInput(UINT nInputs, INPUT* pInputs, int size)
{
ADPRF2(USER32DEBUG, (SendInput [not implemented] ninputs=%u, size=%d\n,
nInputs, size));
diff -ur peace.orig/dll/ui.so/ttfont.cc peace/dll/ui.so/ttfont.cc
--- peace.orig/dll/ui.so/ttfont.cc 2003-03-12 14:38:37.0 +0200
+++ peace/dll/ui.so/ttfont.cc 2004-06-01 12:39:51.0 +0200
@@ -1178,6 +1178,7 @@
/* Search for matching font */
int facenamelen = strlen(logfont-lfFaceName);
+ charset = ANSI_CHARSET;
for (int i = 0; i fontfiles_num; i++) {
FontFileInfo *ffi = fontfiles[i];
diff -ur peace.orig/dll/ui.so/wingdi.cc peace/dll/ui.so/wingdi.cc
--- peace.orig/dll/ui.so/wingdi.cc 2003-03-12 14:38:37.0 +0200
+++ peace/dll/ui.so/wingdi.cc 2004-06-01 11:54:59.0 +0200
@@ -210,7 +210,8 @@
guiFont = CreateFontA(12, 0, 0, 0, 0, 0, 0, 0,
DEFAULT_CHARSET, 0, 0, 0, 0,
default_font_name);
- gdiobj_block_free(guiFont);
+ if (guiFont)
+gdiobj_block_free(guiFont);
}
return guiFont;
cygwin-packages.txt.gz
Description: GNU Zip compressed data
Re: Is it somehow possible to start Windows applications from xterm so that they remain in X-Server area?
Alexander Gottwald wrote: On Tue, 1 Jun 2004, David Fraser wrote: Alexander Gottwald wrote: But I'm still getting segfaults. The msgbox example segfaults in cygwin1!aclcheck. Are you using the latest packages or some older ones? Probably a bit older but not too old ... attached my packages list cygwin 1.3.22 I guess that's the main difference. I've updated to cygwin 1.5.9 now, and reproduced your bug I haven't tried it on a clean install. It is worthwhile checking out previous error messages or using gdb for a backtrace ... in my case the segfault was a font encoding issue, might be different for you The backtrace ended in cygwin1.dll. I'll try a debug build later. I found that commenting out the add_uithread calls as in the following patch got the msgbox example to work. But the withdll still doesn't work. Will be interested to hear the debug build result. BTW what mailing list should we discuss this on? David diff -ur peace.orig/dll/ui.so/winuser.cc peace/dll/ui.so/winuser.cc --- peace.orig/dll/ui.so/winuser.cc 2003-03-12 14:38:37.0 +0200 +++ peace/dll/ui.so/winuser.cc 2004-06-01 17:32:28.912746295 +0200 @@ -215,13 +215,13 @@ case DLL_THREAD_ATTACH: #ifdef __CYGWIN__ - add_uithread(GetCurrentThreadId()); + // add_uithread(GetCurrentThreadId()); #endif break; case DLL_THREAD_DETACH: #ifdef __CYGWIN__ - del_uithread(GetCurrentThreadId()); + // del_uithread(GetCurrentThreadId()); #endif break; }
Re: List membership top-level domain counts
Harold L Hunt II wrote: I pulled the subscribers list for this mailing list and did some aggregate counts of the top-level domains that people are subscribed from (results are below). The only problem with the results are that I suspect that a great number of people not residing in the US have a .com, .net, or .org email address which skews the results a bit towards the US. Nevertheless, we could probably use these counts as a simple priority list if we ever started localizing strings in the X Server. yes, i'm from south africa with a .com address... presumably a lot of the strings would be in common with a non-cygwin X server so localizations could be shared... David
Re: Upcoming X.org release and splitting packages
Harold L Hunt II wrote: We will soon (possibly next week) be releasing a new version of all Cygwin/X packages built from the source code tree managed by X.org and hosted on freedesktop.org. This will be a very good thing since all of the Cygwin/X developers will be able to stay in sync with the exact code that is in distribution via CVS, compared to our current system today where the code in distribution has many differences from that in CVS. The rebuild won't mean much to end users: all libraries remain binary compatible with the current packages and the contents of the release (programs, etc.) will be almost identical. In case you have not noticed, I created a build and packaging script system for Cygwin/X last week (took 60+ hours). This script system does a few things for us, such as allowing us to easily distribute source tarballs via Cygwin's setup.exe. More importantly, the script system allows us to exercise a finer control over what files each package contains and how many packages we break the distribution up into. We can very easily rename current packages when we make the next release, we can split existing packages into pieces, or we could take a set of packages, roll them back together, then split that entire mess into mixed pieces of the originals. I am mentioning this now because I can think of a few things that I would like to change in our package layout in time for the X.org release, but I would also like to get feedback from the community on what you think would be useful. Please take a look at my brief list of ideas below and send your thoughts to the mailing list if you have something about our packaging that you have wanted changed for a long time. My Proposals for Packaging Changes == 1) Due to popular demand, rename the prog package to devel. The name devel matches the defacto standard used by other packages for link libraries and header files; most people have no idea what the prog package is for, but they do know what a devel package is for. +1 2) Split the bin package into at least a few pieces (but not too many pieces): 2a) bin-dlls will contain the .dll files only. This would allow packages like emacs or xemacs to depend only on bin-dlls instead of on the entire bin package which includes programs not used by emacs nor xemacs. 2b) bin-lndir would contain the lndir utility. lndir has no dependence on X libs and can be used by any programmer for non-X projects. 2c) bin-apps would contain all other applications originally contained in bin but not contained in bin-dlls nor bin-lndir. This sounds great... although I wonder whether it would be good to split bin-apps into bin-apps (xterm, xeyes, etc) and bin-utils (xauth, xhost etc) 3) Rename all fonts packages from f100, cyr, fenc, fnts, fscl to something like fonts-100dpi, fonts-cyrillic, fonts-encodings, fonts-75dpi, and fonts-scalable. +1 4) Split the fnts package into a fonts-required and fonts-75dpi. fonts-required should be a very small package that would allow people to minimize their download if they are using Xdmcp to reach a KDE or Gnome desktop, both of which you client-rendered fonts (few fonts required on your Cygwin/X host in that case). +1 5) Rename the lib package to something more meaningful. The name currently implies that it might contain link libraries or run-time libraries, but it really contains files shared among X packages. Perhaps shared-files would be a better name. I would appreciate it if someone would look into what Debian and/or Fedora call this package. Fedora has all the /usr/X11R6/lib/locale/ files, /usr/X11R6/lib/X11/rgb.txt /usr/X11R6/lib/X11/XErrorDB and /usr/X11R6/lib/X11/XKeysymDB in XFree86-libs-data, the /usr/X11R6/include/X11/bitmaps/ files in XFree86-devel, and on my system doesn't have /usr/X11R6/lib/X11/xedit/lisp/ files so I can't say. So I guess libs-data is a good name... 6) Rename fsrv to font-server. +1 7) Rename html to manual-pages-html. 8) Rename man to manual-pages. what about docs and docs-html for these too? Let us know what you think of those and send in your own suggestions as well. Harold Just some ideas David
Re: Cygwin - Cygnus for Windows - Linux based ported to Windows
Yauger, Joshua (Contractor) wrote: Please provide some input; I can't find the information I need on the net to complete my mission at hand. This issue is ongoing and needs to be addressed, Thank you in advanced for any information you can provide for the following: PostgreSQL How can I dump (backup) and restore? How can I merge two PostgreSQL databases? Example: Authoritative server copies from A - B, Which will overwrite the existing file on B. Need to merge one file to another then copy from A - B. Open the file as a XLS then import the other file, then you can sort. Thanks a million for any help you can provide! Joshua Yauger System Administrator Defense Information Systems Agency This has nothing to do with cygwin-xfree86 - you would do better asking this on a postgresql mailing list. See the PostgreSQL website for more info David
Re: non-widget child DropSiteManager error (WAS: RE: Grace (xmgrace) 5.1.12-1 ... )
Atwood, Robert C wrote: Can you tell me the date/title of the announcement? I think it was a while before I started reading this list, and Harold is so active that I so far could not find it in the archives. Updated: lesstif-0.93.91-6 01/16/2004 07:13 AM ** Did you make sure that this step from Harold's lesstif announcement worked? 2) Make the build script run aclocal, autoconf, and automake, and make the mkpatch step exclude files generated by these programs. This makes the package patch readable and useful. I think you might need to include libtool in that list. Make sure all of the afore mentioned tools are up to date, and then try: autoreconf --install --force
Re: Cygwin - KDE
[EMAIL PROTECTED] wrote: My apologies in advance if this is considered to be 'off topic' for this list. I have heard rumour that it is possible to run the KDE desktop under Cygwin and wondered if anyone had any knowledge of this - experience or just a pointer to some details. Any help would be much appreciated. TIA Kevin. P.S.: Please feel free to reply to me personally if you don't want to clutter the list up with traffic like this - at: kevin_dot_lawton_at_bt_dot_com kde-cygwin.sourceforge.net has all the details you need. it works great. they have a mailing list if you need any more help. replying to the list so everyone else knows they don't need to mail you. david
Re: Avoiding the SPAM (was: Cygwin - KDE).
Hi Kevin Sorry about that. If you set your mail client to show your name in the From address, it will usually get quoted using the name rather than the address David Kevin Lawton wrote: Thanks for your reply, David, looking forward to an interesting weekend checking it all out. Sorry to add extra traffic to the list, but I feel I have to point out: When you replied to me, you (or your e-mail client) echoed my e-mail address (and yours, and that of the mailing list) back in the message in plain text. This is the 'staff of life' for spam harvesters ! Any spammer lurking on the list will now have a couple more e-mail addresses to sell to the advertisers and porn-mongers of this world. Aaarrgh ! Please try to avoid returning e-mail addresses as text in the messages - probably best to 'munger' your address or snip out the server part. Some e-mail clients can be set to do this for you. At the very least, replace the '@' with something less obvious. Please - I'm not trying to 'dictate terms' - hey, I've only just joined this list - but I would like to hope that everyone takes my point on board. These days, people are losing their jobs for receiving 'dodgy' e-mail adverts at work. Kevin. kevin_dot_lawton_at_bt_dot_com -Original Message- From: David Fraser snip Sent: 05 December 2003 10:41 To: cygwin-xfreesnip Cc: Lawton,K,Kevin,XJH3C C Subject: Re: Cygwin - KDE kevin.lawtonsnip wrote: My apologies in advance if this is considered to be 'off topic' for this list. I have heard rumour that it is possible to run the KDE desktop under Cygwin and wondered if anyone had any knowledge of this - experience or just a pointer to some details. Any help would be much appreciated. TIA Kevin. P.S.: Please feel free to reply to me personally if you don't want to clutter the list up with traffic like this - at: kevin_dot_lawton_at_bt_dot_com kde-cygwin.sourceforge.net has all the details you need. it works great. they have a mailing list if you need any more help. replying to the list so everyone else knows they don't need to mail you. David
Re: Slow performance over VPN/cable modem
Bruce A. Hamilton wrote: XP Pro SP1, Pentium 2.66 GHz, 1 GB memory. I am running the latest cygwin including XFree86 4.3.0. Performance connecting to my workplace via VPN over cable modem is painfully slow, similar to what I used to see running X over dialup years ago. I'm running a local window manager fvwm2 then ssh -X to hosts at work via my local xterms. The app I'm most interested in is Veritas NetBackup 4.5 jnbSA, which is written in Java and not exactly speedy even at work, but at work we are talking a couple of seconds to refresh the screen, versus nearly a minute for the tiniest changes at home. My Internet connection in general is very fast, on the order of 2 Mb/sec, and I get excellent response over my VPN to work using vanilla text apps and MS Outlook. Thanks for any suggestions. I'm quite sure this in an X issue. Wasn't MIT supposed to be working on low-bandwidth X years ago? Three years ago I had the good fortune to be able to use Graphon's Go-Global to channel X over dialup and was VERY impressed. More recently I played a little bit with VNC and it seemed to have its own performance issues so I have no pursued it further at this time, but I'll consider it if you recommend it. --Bruce (Bruce Hamilton, Redondo Beach, CA) [EMAIL PROTECTED] http://bhami.com/ I would recommend trying the latest version of VNC (4.0b4) from realvnc.com if you are having bandwidth constraints, though there may be other suggestions about X... David
Re: Grabbing XFree86.org's xc/ tree using cvsup
Harold L Hunt II wrote: Alexander, Alexander Gottwald wrote: Harold L Hunt II wrote: Another thing to keep in mind is how we want to do development. It has been suggested that we keep the HEAD branch in sync with XFree86.org and that we do our development on another branch. The question here is whether cvsup can preserve a local branch of the code and still be used to sync with XFree86.org. I doubt that this is the case, since cvsup is essentially mirroring the files, not branches/tags/etc. Does this mean that we must manually track XFree86.org and apply their patches after the initial import? My suggestion is to import the current stable release into our CVS. With CVS we can later import the next release and merge all patches we have already commited. Fixing severe bugs is still an issue and might be solved by regulary importing the snapshots of the stable branch and by monitoring the XFree-commit list (I still read every posting on this list and would just pay more attention to security fixes) Mike Harris had a good point that we should grab XFree86's CVS tree with cvsup and use a perl script to change the root for all of the files. Then we have both the current version of all files *and* the history of all of those files. Note that this requires cvsupd to run on the server side ... do XFree86 already run cvsupd? If not, you may find it easier to ask them for a tarball of the CVSROOT to get going, and then something like cvsps (suggested by Mike below) to keep up to date. He suggested using cvsps to generate patch sets. He also suggested doing our development on a branch, keeping HEAD more or less in sync with XFree86.org CVS HEAD, and merge HEAD to our branch whenever required (to get bug fixes, etc.). I doubt that a complete mirror of the XFree86 CVS is a good solution since there is no way (at least I konw of none) to automaticly track changes in the XFree86 repository and commit them to ours too. So importing the whole repository is in my opinion a waste of space since we'd have to import all old revisions from the XFree repository too. I think Mike had a good point that it would be wise to have the history of each file in the tree... what do you think? I think this would be great ; it also allows the possibility of producing security-patched versions of older versions of XFree86, and the version history also provides a kind of documentation of the source David
Re: freedesktop.org - Hosting for future Cygwin/X development
Harold L Hunt II wrote: I am interested in the work going on in the xlibs and xserver repositories, which are an autotooled build of most X libs and the X Server. I was able to build all but Xft from CVS (need a newer version of FontConfig to build the latest Xft) using static libs, but it should be easy to get shared libs built again by adding -no-undefined flags. I am very interested in pursuing this modern build system. We won't use it immediately, but we could probably do a distribution from it in three to six months. I reckon this alone would be worth the move... Good decision David
Re: partnership with the Xouvert project?
Harold L Hunt II wrote: Jonathan, Jonathan Walther wrote: Hi Harold. Hello, hello. My name is Jonathan Walther, and I am the coordinator for the Xouvert project. I read your post on Slashdot yesterday, and it looks like you are responding to some of the same frustrations and desire for change that inspired the Xouvert project. http://xouvert.org Xouvert is using arch instead of CVS. We aren't doing this lightly; we see a clear benefit to it. One of the benefits is it's revision control discipline is more natural and makes it vastly easier to have a wide diversity of branches going at once, keeping in sync with each other. Hmm... I have been looking into Xouvert since it keeps getting mentioned to me... but I still can't find anything that indicates that arch works (or would be easy to make work) on Cygwin. Could others please check the status on arch on Cygwin? We would love to incorporate your changes, and give you and anyone you delegate full commit access to our revision control tree. Would you be interested in partnering with our project? I think we can both provide each other with a lot of positive benefits. No action is required on your part, Xouvert is working on our first release which should be soon. Like you, we are starting with XFree86 4.3 as our base. We believe once you go through the arch tutorial, you also will be sold on it's benefits for projects like ours. I'm sure it has benefits, but it has to compile to be useful :) Waiting for status of arch on Cygwin report... Harold Just googling, I haven't tried it since last year ... See this (very recent) thread: http://mail.gnu.org/archive/html/gnu-arch-users/2003-10/msg00437.html It seems it works, with some limitations, which may/may not be addressable from Cygwin's side. BTW, arch is quite different in structure from CVS, so it's worth reading just a little bit about the architecture - I think it's a great idea David
Re: Generic rootless
Kensuke Matsuzaki wrote: Hello, This uses miext/rootless. rootless mode create Windows window for each toplevel X window. The remote X apps's reorder/maximize/minimize performance is improved. And to click one X window doesn't raise all X window together. Known problem: When using twm, I click window then that window raise top in Windows but it stay previous position in X. I don't know how to avoid clicking Windows window raise window. Kensuke Matsuzaki Hi Kensuke Wow, you keep on coming up with brilliant improvements Thanks! David
Re: Tight loop in Xwin startup under Win2k
Jeffrey C Honig wrote: No, it does not happen when I use startxwin.bat. Even if I configure it for -fullscreen. But it is only starting one xterm. I need to do more testing trying to start multiple xterm. I'll also post on the cywin list. I just thought it likely that someone on this list may have seen it. Thanks. Jeff If you are struggling debugging this, you may want to try starting the programs with nice so that they don't completely take over the system, which may make it easier to see which processes are causing the problem Or give the top/Task Manager process a higher priority so that it still runs when the manic process is trying to take over David
Re: Enabling SHM support in default build of XWin.exe
Harold L Hunt II wrote: Ralf Habacker sent some patches on 2003/09/05 that I am working on getting committed to the XFree86 CVS tree. Those two patches are here: http://cygwin.com/ml/cygwin-xfree/2003-09/msg00092.html http://cygwin.com/ml/cygwin-xfree/2003-09/msg00090.html I have opened Bug 698 in XFree86's Bugzilla to track the fixing of the xf86bigfont extension initialization: http://bugs.xfree86.org/show_bug.cgi?id=698 After Bug 698 is committed I will be adding a function (from Ralf's patches) to XWin.exe to check whether or not the IPC daemon is running, then I will be adding a call to that function in the initialization of the SHM and xf86bigfont extensions (again, per Ralf's patch). This should result in a build of XWin.exe that supports SHM when the IPC daemon is running, but is not hindered when the IPC daemon is not running. This will be a nice addition, as it will allow Ralf to stop distributing ancient copies of XWin.exe for KDE on Cygwin. :) My one question is this: KDE on Cygwin (last I checked) is also distributing a handful of X libraries (X11?) that need SHM support as well, can SHM be dynamically enabled/disabled for these libraries, or are they going to have to be built in two different flavors still? Regardless of the answer, adding dynamic SHM support to XWin.exe will solve the majority of the problems of KDE on Cygwin distributing custom files. XWin.exe gets updated so frequently that it would be an unreasonable burden for them to try to keep their copy up to date. Harold This is great news, thanks for working on this David
Re: kde tool bar
Lung.Allen wrote: I'm trying to get kde to display only the toolbar on my system! Here is what my start file look like. ___--- @echo off set DISPLAY=localhost:0.0 set REMOTE_HOST=remotehost set CYGWIN_ROOT=\cygwin set PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix start XWin -from %DISPLAY% -query %REMOTE_HOST% -nodecoration rem -fullscreen Allen D. Lung Hi You don't say whether you're reporting a problem or success, or what the problem is! Also, I think this question is better asked on the kde-cygwin mailing list, [EMAIL PROTECTED] See http://kde-cygwin.sourceforge.net/ml/ or http://mail.kde.org/mailman/listinfo/kde-cygwin to subscribe... David
Re: XWinrc configurable server (menus/icons)
Earle F. Philhower III wrote:
Howdy Harold,
At 07:31 PM 8/5/2003 -0400, you wrote:
In other words, I might look at your patch tomorrow, or I might look
at it next week. Can't say for sure.
In any case, thanks for the patch, I like the idea and am looking
forward to seeing what it does.
No rush. But just delete the tar file I sent yesterday, that was
really just
a parser that read the config file. It took a few hours of futzing
around today,
but I got it nicely integrated into the server. Now on init it parses
~/.XWinrc
or /usr/X11R6/lib/X11/system.XWinrc and makes custom menus and
submenus for
the taskbar icon and each window, and can replace icons with ones
specified
in the rc file.
I'm attaching the diffs against test95 below, please use these for any
testing
you do (there are several new files, so if patch asks: you do want to
make new
files...). The file _usr_X11R6_lib_X11_system.XWinrc has all the
documentation
on the RC format anyone'd need. If the file's not found, you get the
exact
same behaviour as test95 as far as menus/icons/etc.
** There's also a off-by-one bugfix in winmultiwindowclass.c, so no
matter
what that file's changes should go in... **
Oh yeah, a simple if (fork()==0) { execl(); exit(0); } seems to
spawn X and
Windoze apps fine. I know there was some discussion about this
earlier...
Below's the sample config that I'm running that replaces the X.ico
with one that's
floating in my Windows directory, and replaces Xterm's with another,
and adds
custom menus to Xterm, all other windows, and the toolbar window...
Wow! This is great! Just what we were discussing earlier...
Just one comment: Is it not possible to automatically set the DISPLAY
variable from X so that it automatically starts the xterms etc in the
right X display, rather than having to pass a commandline parameter? (In
fact, if they inherited the environment, this might happen anyway, but I
don't know if X defines DISPLAY inside itself...)
David
Re: request for new feature
Alexander Gottwald wrote: Harold L Hunt II wrote: I am all about baby steps. We haven't even proven that we know how to start a new application for the user from the system tray icon yet. Until we actually do that this discussion is really pointless. I can send you code which spawns new processes from a running windows app. Could you send it to the list? Thanks David
Re: request for new feature
java java wrote: Then give this a try... Start-Run c:\cygwin\usr\X11R6\bin\run /usr/X11R6/bin/xterm-display :0 YES! , this works perfectly. Now could this be added as a right click menu option to the tray? I don't think everyone would neccessarily like such an option. What might be better is a way to configure items to be added to the tray... David
Re: XDM now working on cygwin to manage remote displays
msg wrote: Greetings: Just reporting progress on making a working XDM for Cygwin/XFree86 to manage remote displays: I now have XDM working to provide a greeter dialog, authenticate the 'root' user (who has setuid privs on the host) and spawn the .xsession (in my case startup an rdesktop session). Very satisfying. Work remains to to fix authFile (change the colon character to something storeable on the NTFS filesystem) and to add ntsec setuid code to permit non-setuid-privilened user authentications. Michael Grigoni Cybertheque Museum Wow! This is great news! Let us know when code is available ... Thanks David
Re: Off list until I return
Harold L Hunt II wrote: All, I have removed myself from the [EMAIL PROTECTED] mailing list until I return from my honeymoon. Actually, we get back right near the 4th of July weekend, so I won't really be back until around July 7th. I expect many patches to be waiting for me ;) Have fun until then! Harold Have a fantastic time! David
Re: Konsole-like application?
William E. Kempf wrote: Are there any applications similar to Konsole for Cygwin. By similar, I mean an application with a tabbed frame for multiple consoles and a button to create new consoles, but one that doesn't require KDE (I want to run -multiwindow). You can actually run konsole from the kde-cygwin package without using kwin as the window manager. It works perfectly in multi-window mode... might use up a bit more memory than others, but then, konsole rocks... David
Re: xwinclip/-clipboard - Development on no selection stealing version
Harold L Hunt II wrote: I have been working with the code for Keith Packard's XFIXES extension. The XFIXES extension includes a new hook in Xserver/dix/dispatch.c that allows functions within the Xserver (such as the XFIXES xtension) to register for a callback when a selection's ownership changes, among other things. [snip] 2) What would be the best way for me to share the code with other developers? I don't want to commit the XFIXES stuff to our SourceForge tree's HEAD, but could I use another branch? If so, please give me some instructions for what to do... I haven't got time to study CVS all day. Basically just say cvs tag -b XFIFES_BRANCH on a tree you've checked out (so far unchanged). Then say cvs update -r XFIFES_BRANCH so that it marks the code as using that branch (for future commits). Then do all the changes (you could do this by making a diff from your existing work and use patch to apply it to this tree), and commits will go onto the branch. Others can get them by doing cvs update -r XFIFES_BRANCH. From the cvs man page: Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing main-line development, you could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of cvs conflict resolution. The scenario might look like: example% cvs tag -b EXPR1 example% cvs update -rEXPR1 [[ hack away ]] example% cvs commit Others would simply do `cvs checkout -rEXPR1 whatever_module' to work with you on the experimental change. Hope that helps David
Re: X icon was not updated in XFree86-xserv-4.2.0-42
Earle F. Philhower, III wrote: Hi Harold, -- Original Message - Subject: X icon was not updated in XFree86-xserv-4.2.0-42 .. Benny was right. A newly compiled XWin.exe is 2 KiB larger than 4.2.0-42, which accounts for the 2 KiB increase in the size of X.ico. Additionally, I was looking at the icon on the upper left-hand corner of an X term, not the tray icon... the tray icon is indeed 20 pixels by 20 pixels. Finally, the tray icon did change under magnification from Test91 to my newest build. So, it is using the 24 x 24 icon to generate the 20 x 20 icon, rather than the 16 x 16 or the 32 x 32. However, my 24 x 24 icon still looks crappy when scaled down to 20 x 20... not sure if it looks better than the 16 x 16 scaled up to 24 x 24 though. It really is a close call. Can somebody else spend some time on X.ico with the free icon editor I found and fix this once and for all? - Not to be silly, but instead of hand scaling/etc have you just tried running xlogo -geometry 20x20 and PrntScrn'ing the window and pasting it into the .ico? Earle, Sorry to be nit-picky but I really struggle to read this -- Original Message - mails... Is this your mail client that does this? David
Re: Code reorganization heads up
Alexander Gottwald wrote: Harold L Hunt II wrote: I really don't know much about administering CVS... and I kinda don't have time to learn right now. However, if someone else is willing to set it up, I would be more than happy to start using it. I would want the xoncygwin CVS default branch updated to 4.3.0 and I would want the latest test release checked into hw/xwin... then I would be good to go. Any volunteers? *meld* I'd take this part. Beware... I haven't tried to build the 4.3.0 branch on Cygwin, nor have I tried to cross compile it. I have no idea if it still works :( Cross compiling still works (at least until 3-4 weeks ago). And native should also work. The was a question on the list about the dll renaming. So I guess Benjamin(?) also compiled from cvs. bye ago NP: grauzone.03-05-26 Just wanting to clarify, what is the difference between the xfree86 cvs and the xoncygwin cvs at sourceforge? (http://xfree86.cygwin.com/docs/cg/prog-obtaining-source.html mentions using anoncvs.xfree86.org) Which contains the latest code? Thanks David
Re: making X server a COM object..
Chan Kar Heng wrote: thank you for the courtesy.. :) .. and i would likely (85%) agree with you that i do not have a firm grasp on the scope... probably more.. probably less.. but if i had a firm grasp, i probably wouldn't need to ask around the gurus here right? :) what i do hope is to be able to get some pointers directly at potential problems... and why it might be impossible to solve... rather than spending the time to research each one of them (cygwin, cygwin xfree, COM, etc) in detail to look for potential problems... if the issue might be a lengthy one... i suppose some urls or general description of the issue would suffice. I think you should describe exactly why you want to put XFree86 in a COM object, for what purpose, what you would use it for etc. I presume you mean you want to make it an ActiveX control, is this true? David
Re: Crashing with -clipboard and -multiwindow
Harold L Hunt II wrote: Anyone that is experiencing a crash on startup when using -clipboard and -multiwindow, please try the debugging release that I made last night: http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test76-DEBUG.exe.bz2 (1.2 MiB) I am still awaiting confirmation that this does or does not fix the problem. If it fixes the problem I will make an official Test77 release with the fix that it contains. Thanks for testing, Harold Works great for me. Attached the log diff just in case it needs to be compared to someone else's. Thanks for sorting this out... David --- XWinrl-multiwindow-76-DEBUG.log 2003-01-29 17:41:11.0 +0200 +++ XWinrl-multiwindow-clipboard-76-DEBUG.log 2003-01-29 17:42:08.0 +0200 @@ -1,50 +1,60 @@ ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 690 1024 winAdjustForAutoHide - Adjusted WorkArea: 0 0 690 1024 winCreateBoundingWindowWindowed - WindowClient w 1024 h 690 r 1024 l 0 b 690 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1024 height: 690 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1024 height: 690 depth: 32 size image: 2826240 winAllocateFBShadowGDI - Created shadow stride: 1024 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. +winFinishScreenInitFB - Calling winInitClipboard. +winInitClipboard () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () +winClipboardProc - Hello +winClipboardProc - Calling pthread_mutex_lock () (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) winBlockHandler - Releasing pmServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. DetectUnicodeSupport - Windows NT/2000/XP winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - XInitThreads () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 +winClipboardProc - pthread_mutex_lock () returned. +DetectUnicodeSupport - Windows NT/2000/XP +winClipboardProc - pthread_mutex_unlock () returned. +winClipboardProc - XInitThreads () returned. +winClipboardProc - DISPLAY=127.0.0.1:0.0 winBlockHandler - pthread_mutex_unlock () returned winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. +winClipboardProc - XOpenDisplay () returned and successfully opened the display.
Re: -clipboard on Test73
Harold L Hunt II wrote: David, I have made a new debugging release for you to try out: http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test73-DEBUG-2.exe.bz2 (1201 KiB) This new release has many more debug messages around the calls to _XSetLocale. I have also made the MultiWindow WM call _XSetLocale instead of setlocale, which could have been causing problems... I really have no idea. In any case, the above release should help us to figure out when is going on when you run with ``XWin.exe -clipboard -multiwindow''. Thanks for testing, Harold Thanks I've done the same as last time by attaching a diff between the plain -multiwindow and the -multiwindow -clipboard logs. Let me know if this isn't the best way. It's interesting the winClipboardProc call to setlocale seems to return directly after the winInitMultiWindowWM call... David --- XWinrl-multiwindow-2.log2003-01-22 11:28:32.0 +0200 +++ XWinrl-multiwindow-clipboard-2.log 2003-01-22 11:25:33.0 +0200 @@ -1,51 +1,52 @@ ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root _XSERVTransmkdir: Mode of /tmp/.X11-unix should be set to 1777 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - Initial w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 690 1024 winAdjustForAutoHide - Adjusted WorkArea: 0 0 690 1024 winCreateBoundingWindowWindowed - WindowClient w 1024 h 690 r 1024 l 0 b 690 t 0 winCreateBoundingWindowWindowed - Returning winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - Calling winInitClipboard. +winInitClipboard () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. winInitMultiWindowWM - Hello winInitClipboard - Calling pthread_mutex_lock () (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) winBlockHandler - Signalling pcServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. winInitMultiWindowWM - pthread_cond_wait () returned. winInitMultiWindowWM - pthread_mutex_unlock () returned. +UnicodeSupport - Windows NT/2000/XP +winClipboardProc - Calling _Xsetlocale () winInitMultiWindowWM - XInitThreads () returned. UnicodeSupport - Windows NT/2000/XP winInitMultiWindowWM - Calling _Xsetlocale () -winInitMultiWindowWM - _Xsetlocale () returned -winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 -winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. +winClipboardProc - _Xsetlocale () returned
Re: -clipboard on Test73
David Fraser wrote: Sorry, should have said I tried that too. Tried again now, X -multiwindow works fine X -clipboard works fine X -multiwindow -clipboard crashes X -rootless -clipboard works fine There are no other options given (and I presume if you run X like this it won't read any .xinitrc or .xserverrc). I downloaded the debug build of Test73 and that gave me the following backtrace: _libkernel32_a_iname _libkernel32_a_iname _size_of_stack_reserve__ _Xsetlocale _libkernel32_a_iname _libkernel32_a_iname _libkernel32_a_iname I'm guessing this is where the significant crash is as they are other segfaults, this is the last one before the program crashes. How do I make XWin produce a log file (XWinrl.log)? this build was supposed to have more messages but I don't know where to find it David Harold L Hunt II wrote: Check what happens if you give it just the -multiwindow flag. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Fraser Sent: Monday, January 20, 2003 4:43 AM To: [EMAIL PROTECTED] Subject: -clipboard on Test73 Hi just some feedback on -clipboard Running Cygwin xterm on it works really well (i.e. I can easily copy both ways) Running kde-cygwin on it works really well. Connecting using XDMCP to my Linux machine, works really well, but sometimes it seems to disconnect (before any X window appears, or when I logon) without an error. If I try run X -multiwindow -clipboard, it crashes, tried gdb, seems to be in a _Xsetlocale call. What should I test? David Through the cunning technique of reading other people's posts I have deduced (surprise!) that the log file is in /tmp Anyway here is the output of diff -u1000 XWinrl-multiwindow.log XWinrl-multiwindow-clipboard.log (in other words a diff between running with just the multiwindow option and running with the clipboard option too, showing every single line of the files...) This does indeed seem to show that the problem is in the way setlocale is called for with both of these options, as Harold suggested. David --- XWinrl-multiwindow.log 2003-01-21 10:50:42.0 +0200 +++ XWinrl-multiwindow-clipboard.log2003-01-21 10:44:39.0 +0200 @@ -1,48 +1,47 @@ ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root _XSERVTransmkdir: Mode of /tmp/.X11-unix should be set to 1777 (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window = ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - Initial w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 690 1024 winAdjustForAutoHide - Adjusted WorkArea: 0 0 690 1024 winCreateBoundingWindowWindowed - WindowClient w 1024 h 690 r 1024 l 0 b 690 t 0 winCreateBoundingWindowWindowed - Returning winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - Calling winInitClipboard. +winInitClipboard () winFinishScreenInitFB - returning winScreenInit - returning InitOutput - Returning. -winInitMultiWindowWM - Hello. (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = xfree86 Model = pc101 Layout = us Variant = (null) Options = (null) +winInitMultiWindowWM - Hello. winBlockHandler - Signalling pcServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. +UnicodeSupport - Windows NT/2000/XP winInitMultiWindowWM - pthread_cond_wait () returned. winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - XInitThreads () returned. -winInitMultiWindowWM - setlocale () returned. -winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 -winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display.
-clipboard on Test73
Hi just some feedback on -clipboard Running Cygwin xterm on it works really well (i.e. I can easily copy both ways) Running kde-cygwin on it works really well. Connecting using XDMCP to my Linux machine, works really well, but sometimes it seems to disconnect (before any X window appears, or when I logon) without an error. If I try run X -multiwindow -clipboard, it crashes, tried gdb, seems to be in a _Xsetlocale call. What should I test? David
Re: Using XFree to replace explorer.exe as the window manager for Windows
Stuart Adamson wrote: Yep - I've done this. However - some of the control panel stuff didn't work correctly afterwards (like the program installation wizard). I had to move back to explorer.exe, install my program then move back to using X as the shell. Stuart -Original Message- From: Ralf Habacker [mailto:[EMAIL PROTECTED]] Sent: 20 January 2003 07:19 To: [EMAIL PROTECTED] Subject: RE: Using XFree to replace explorer.exe as the window manager for Windows I am wondering if anyone has attempted to use Cygwin/XFree86 to replace explorer.exe as the window manager. David Fraser has reported done so with kde-cygwin. See http://lists.kde.org/?l=kde-cygwinm=103072530327420w=2 for further infos. Regards Ralf Which just shows why its bad to have a monolithic OS instead of one made up of separate components That's Windows for you... David
Re: -clipboard on Test73
Sorry, should have said I tried that too. Tried again now, X -multiwindow works fine X -clipboard works fine X -multiwindow -clipboard crashes X -rootless -clipboard works fine There are no other options given (and I presume if you run X like this it won't read any .xinitrc or .xserverrc). I downloaded the debug build of Test73 and that gave me the following backtrace: _libkernel32_a_iname _libkernel32_a_iname _size_of_stack_reserve__ _Xsetlocale _libkernel32_a_iname _libkernel32_a_iname _libkernel32_a_iname I'm guessing this is where the significant crash is as they are other segfaults, this is the last one before the program crashes. How do I make XWin produce a log file (XWinrl.log)? this build was supposed to have more messages but I don't know where to find it David Harold L Hunt II wrote: Check what happens if you give it just the -multiwindow flag. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Fraser Sent: Monday, January 20, 2003 4:43 AM To: [EMAIL PROTECTED] Subject: -clipboard on Test73 Hi just some feedback on -clipboard Running Cygwin xterm on it works really well (i.e. I can easily copy both ways) Running kde-cygwin on it works really well. Connecting using XDMCP to my Linux machine, works really well, but sometimes it seems to disconnect (before any X window appears, or when I logon) without an error. If I try run X -multiwindow -clipboard, it crashes, tried gdb, seems to be in a _Xsetlocale call. What should I test? David
Re: multiwindow problem with kterm
[EMAIL PROTECTED] wrote: From: Sylvain Petreolle [EMAIL PROTECTED] Date: Fri, 17 Jan 2003 01:36:54 +0100 (CET) ::If I remember correct, when the dcop server isnt loaded it is started ::automatically when you call a kde application. :: ::Could the kde window manager be loaded the same way ? Well, kterm is not a KDE application. It's just a Japanese capable xterm. ;-) Thanks for the info anyway. For future reference, no, KDE apps won't load the kde window manager, I can run the whole of KDE under cygwin with the multiwindow manager instead. David
Re: multiwindow segmentation fault
Alexander Gottwald wrote: On Wed, 15 Jan 2003, J S wrote: Kensuke, I'm not an expert on gdb but managed to get the following debug info for you. Also in answer to Harold's question I only have one cygwin1.dll. Program received signal SIGSEGV, Segmentation fault. 0x77e8c40c in _libkernel32_a_iname () No. This is not the right point. If the segfault occurs in _libkernel32_a_iname you can continue debugging with c until another segfault occurs at another place. bye ago I know this is not relevant, but this was a very helpful revelation for me... what causes these _libkernel32_a_iname segfaults in cygwin, can it be disabled/fixed? David
Test 71
Milos Komarcevic wrote: Harold, just tried Test 71, works fine on my Win2k box. Kensuke's patch you mention in the release notes is for the detached menus I believe (someone correct me if I'm wrong), which it does indeed fix - but who knows, maybe it fixes the segafult as well. It could be the other way around though :-) Regards, Milos Indeed, I have the whole of KDE running (just disabled the window manager, using the multiwindow manager), not a problem at all. Quite nice in that kicker can then be used as a separate window by itself, moved around etc. David
Re: Rootless mode
Kensuke, Harold, I was just wondering whether it would be possible to create a test build of the X server with this multi-window mode. Obviously there are issues with it but I presume they only come up in multi-window mode? It would just be really nice to see it beginning to work - this is something lots of people have wanted for a long time, congratulations for getting it going! David Harold L Hunt II wrote: JS, Kensuke titled his message ``rootless mode'' when it should really have been titled ``multi-window mode''. The goal of multi-window mode is to create a Windows-window for each top-level X Window, rather than creating one huge window for your entire X desktop. Harold J S wrote: Kensuke, The new patch is an architectual improvement. However, when I run it, if I move a window it gets moved, then it jumps back to its original position and retraces the move path that I took it on, over and over again until I feel like I will throw up. :) I am not sure what is causing this problem, but obviously the queue of messages is not being cleared and is instead being looped through repeatedly. My log file from this session is on the web: http://www.msu.edu/~huntharo/xwin/XWinrl.log.bz2 (33 KiB) The unpacked log file is 800+ KiB. Harold Kensuke Matsuzaki wrote: Harold, It remains only for debugging. Am I correct that the root window is still being drawn, even thought it is not really usable? Is that something that remains to be fixed, or did I have something go wrong with my patching? By the way, this is new patch that integrates XWin and the window manager. Kensuke Matsuzaki How does this patch change what Rootless mode already does? I thought that rootless mode already integrated the window manager? I have windowmaker running, and when I'm in rootless mode the xterms come up with windowmaker frames. Can you integrate with the Windows windows manager? _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Cygwin GNOME 1.4 binary packages
Ian Harcombe wrote: Just to voice a quick vote of thanks to all involved in getting this working. I am now happily running Gnome 1.4 (with all the extra bits n bobs you've provided) under Cygwin on a Windows XP Professional laptop as my normal development environment at work. It is clean and responsive, and now that sawfish is running properly, very pretty indeed. My vote of thanks too! But I can't get it to work, would appreciate any comments. It seems to be a problem with the goad_server which seems to be something to do with CORBA/COMM. Is there any way I can debug it? I have attached the startup log below. BTW, I installed it using the cygwin setup utility, not the installpkg script, could this be a problem? Thanks David starting gnome on display :0 _IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root _IceTransmkdir: Mode of /tmp/.ICE-unix should be set to 1777 SESSION_MANAGER=local/auga:/tmp/.ICE-unix/1868 env: gnome-upgrade.py: No such file or directory /bin/bash: line 1: aumix-minimal: command not found can't load fixed font during initialisationxscreensaver-command: not found xscreensaver: not found Gnome-Message: gnome_execute_async_with_env_fds: returning -1 ** WARNING **: goad_server_activate: goad.c 673: unexpected exception IDL:CORBA/ COMM_FAILURE:1.0: ** WARNING **: sysex: IDL:CORBA/COMM_FAILURE:1.0. ** WARNING **: usrex: IDL:CORBA/COMM_FAILURE:1.0.
Re: Multiwindow mode
[EMAIL PROTECTED] wrote: -multiwindow is not stable, so I thought binary is not needed. XWin.exe is here. http://peppermint.jp/products/asis/XWin.2002_12_09.exe.bz2 And libfreetype 2.1.1 is here. http://peppermint.jp/temp/libfreetype.tar.bz2 Kensuke Matsuzaki Thank you Kensuke! I have konsole running by itself in a separate window! This is great! Much appreciated! By the way I have no stability issues other than moving windows as Harold mentioned. I can resize a window as long as I don't move it. David -=-=- ... Micro$oft is not an answer. It is a question. The answer is 'no'. * TagZilla 0.030
Re: Rootless mode
Harold L Hunt II wrote: David, I have not released a test version because the version that Kensuke sent me didn't work at all. It just kept repeating the dragging of a window if you ever moved one. I sent a report to the list but he never responded. I didn't want to bug him about it for awhile in case he had seen it... but it seems now that he never saw it. I will release a test version once there are no obvious bugs. I mean, are we really going to benefit from 100 people saying ``multiwindow mode doesn't work, it keeps doing foo''? I don't think so :) Harold OK, I see the reason now, thanks for explaining. In the mean time has been quite fun getting it to run :-) I'm quite happy with not moving windows as long as I know that it's to be avoided. David -- Micro$oft is not an answer. It is a question. The answer is 'no'.
Re: Cygwin GNOME 1.4 binary packages
Hansom Young wrote: Hi, Now you can download some prebuilt packages from http://www.sourceforge.net/project/cygnome Hi Hansom, Thanks for doing this! The URL should be http://www.sourceforge.net/projects/cygnome (missing s) Currently only core libraries and a brunch of applications are available I've packaged all the core libraries into a single tarball cygnome-libs_1.4b1-x.tar.bz2 The same to cygnome-apps. But lib*.a in cygnome-libs-devel were stupidly stripped by me. (I'm a really newbie,g) So at present you can not build GNOME application by yourself with it. This sunday I'll upload the other packages, including almost the whole GNOME 1.4 desktop (except Nautilus) and Sawfish, gnumeric etc. I see if you have now done this... I downloaded it all and tried to get it working, a few questions/issues: startgnome seems to find its own display unless $display is set... which it tries to read from $serverargs (pointing to .xserverrc). So it is designed to start X itself (in contrast to KDE's startkde, which assumes X is started) I would like to get startx to start gnome, what should I put in .xinitrc (since startgnome doesn't work)? In any case, I start Gnome using startgnome and it brings up the nice splash screen, goes through everything, says Starting Panel, then Done. But I get an Error: Application panel has crashed due to a fatal error (segmentation fault). This seems to be a problem with CORBA. The following error messages are printed out: 3 [unknown (0x828)] XWin 2132 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 7493 [unknown (0x828)] XWin 2132 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 16136 [unknown (0x828)] XWin 2132 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 24205 [unknown (0x828)] XWin 2132 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 3 [unknown (0x720)] sh 2108 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 14209 [unknown (0x720)] sh 2108 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 59792 [main] sh 2108 fhandler_console::dup: error opening console, Win32 error 5 3 [unknown (0x638)] xkbcomp 2092 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 20937 [unknown (0x638)] xkbcomp 2092 fhandler_console::fixup_after_exec: error opening input console handle after exec, errno 13, Win32 error 5 _IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root _IceTransmkdir: Mode of /tmp/.ICE-unix should be set to 1777 SESSION_MANAGER=local/auga:/tmp/.ICE-unix/1824 env: gnome-upgrade.py: No such file or directory /bin/bash: line 1: aumix-minimal: command not found can't load fixed font during initialisationxscreensaver-command: not found xscreensaver: not found ** WARNING **: goad_server_activate: goad.c 673: unexpected exception IDL:CORBA/COMM_FAILURE:1.0: ** WARNING **: sysex: IDL:CORBA/COMM_FAILURE:1.0. ** WARNING **: usrex: IDL:CORBA/COMM_FAILURE:1.0. Note: In fact, nearly all the packages are built with the hints and patches distributed by Steven O'Brien at http://homepage.ntlworld.com/steven.obrien2. All that I did are just building them, packaging them and uploading then there. (That doesn't mean he is responsible for the bugs and defects in this port). Still is there no one would like to help me? I presume reporting the problems I am having counts as help :-). Regards David
Re: Cygwin GNOME 1.4 binary packages
Hansom Young wrote: - Original Message - From: Lisi [EMAIL PROTECTED] Date: Thu, 21 Nov 2002 20:57:52 +0200 To: [EMAIL PROTECTED] Subject: Cygwin GNOME 1.4 binary packages Hi Hansom, I am definitely interested in a cygwin GNOME binary, like the KDE binary which is available on sourceforge using the standard cygwin setup.exe (but I have not yet managed to get running properly on Win98). Could you please keep us updated, maybe by posting back on the list, when your port is available for download? Surely no problem. I just started a project on sourceforge.net. I'll upload the binary packages in a few days, including some applications very usful, such as gftp, sylpheed, gtktalog, anjuta etc. Great! What is the project name? I see there is gnome-cygwin, is this it? But I'm so busy with my work in recent months. Could somebody give me a hand? And we want to start to work on GNOME 2.0. I tried to compile GNOME 2.0 on cygwin unsuccessfully. But if there is a base framework there, I'd be very interested in anjuta, and could help out with that. Can I suggest that rather than just hosting diffs you actually have the full source code? If you import it into CVS you can then import later versions again and merge the changes. Since sourceforge is hosting it you shouldn't have bandwidth problems... David
Re: Running XDMCP server
Jean-Claude Gervais wrote: I tried running XDM ?!? And it replies only root wants to run xdm... But there is no user called root on my system... Thanks. An equal and opposite reaction... Is it possible to run XDMCP as a server (sorry probably wrong terminology) on the cygwin side, so I can run say Xnest from Linux, connect to XDMCP on Cygwin, login...? And what does the xdm running as root message mean ... I even tried creating a user called root and that didn't work... Just out of interest David
Re: SSH Notes
Thomas Chadwick wrote: What to Fix === ssh should assume ``DISPLAY=127.0.0.1:0.0'' when the DISPLAY variable is not set on the Cygwin host. I am not sure why this is not currently the case. I can only guess that the lack of this assumption is either do to 1) a whiny security geek on the openssh project, or 2) that the assumed usage scenario for openssh is more like a Linux/X machine where you have probably got your X Server running when you connect to your remote machine with ssh, thus DISPLAY would already be set. At the very least, we should patch the Cygwin release of openssh to assume that DISPLAY=127.0.0.1:0.0 when DISPLAY is not defined in the environment. That would make X11 tunnelling much much easier for 95% of our users and I either can't see or I don't care about any pseduo-security hole that this might open up. (Hey, if SSH Secure Shell makes this assumption, then we can too.) I don't agree with this fix. I think the correct fix should be to make ssh die if the -X flag is specified but the DISPLAY variable is not set (instead of quietly continuing on in a somewhat broken state). A simple error message like the following should be sufficient: Error: In order to enable X11 forwarding the DISPLAY variable must be set. I know you want to make ssh behave correctly for the masses, but you don't want to make it behave incorrectly for advanced users trying to debug their code. For instance, I may have 3 different screens running on my local box (:0, :1, and :2) and want to set up an ssh channel between screen :2 and a remote machine. If I screw up the way I assign a value to DISPLAY, I don't want ssh to keep going and forward my X traffic to the wrong display! I agree. In fact even a warning would be great. Then you could have the ForwardX11 variable set to yes in /etc/ssh_config or ~/.ssh/config and there would be a warning as well. Also a warning if DISPLAY is not set would be useful in all versions of openssh, not just the cygwin one, so hopefully it could go into the main trunk and we wouldn't have to patch it specificly. David
Re: New Project (was RE: X client wrapper for Win apps?)
OK. Let's use [EMAIL PROTECTED] for the mean time if there is any discussion needed. Once it's going we can discuss elsewhere. It would be really nice to have this hosted at sources.redhat.com but actually at the moment we don't need that, we just need to start developing. But that can all be discussed on that list. I've subscribed - Nicholas, unfortunately it seems like you don't have wide backing for keeping the discussion going here, and it can't really be that hard to subscribe to another list you can unsuscribe to later if neccessary... Christopher Faylor wrote: On Fri, Sep 20, 2002 at 03:05:05PM -0400, Harold L Hunt II wrote: I say move the discussion elsewhere. I have put up with it for now, but it really needs to go so we can get back on topic here. Of course, with the level of continuous contributions flowing from other members of the Cygwin/XFree86 project, I can't hold out much hope for this new project. Best of luck, but don't think much will happen after the excitement of picking a name, license, etc. Of course, I love to be proven wrong with oodles of code. This was my impression, too, after having experienced this many times in cygwin and other projects (the freevms and debian-win32 projects spring to mind). This is following the pattern by by discussing the trivial things like what do we call it and where do we put it. But, eventually all of the people who think it is a really good idea but have no actual experience to contribute will quiet down and you'll be left with the fact that no one has time to start a major new project. Actually, if you want an existing mailing list to discuss this on, you can use [EMAIL PROTECTED] That was Suhaib's list but he's indicated that he's had to move on and the project is basically dead. The name even makes a certain amount of sense. You can use that for the discussion until an actual project name is chosen. At that point, I'm happy to set up what is required on sources.redhat.com. Don't let my pessimism (or Harold's) stop you if you are fired up about this but please be aware that this will require substantial work, probably by more than one person. You'll probably need a project lead, too, if you want this to succeed. cgf
Re: New Project (was RE: X client wrapper for Win apps?)
Sorry everyone, posted to wrong list! Yikes! David Fraser wrote: This is a notice to everyone on this list that we will (for a short time at least) be using this list to discuss a new project intended to allow ordinary Windows programs to appear in X-Windows. This is quite different to the original purpose of this list, but was suggested on a discussion on the cygwin-xfree list where it was felt that this was appropriate as the win32-x11 project is no longer being actively developed. See the cygwin-xfree archives over the last few days for more info (and the suggestion in Christopher Faylor's message below) (http://sources.redhat.com/ml/cygwin-xfree/2002-09/) David Fraser Christopher Faylor wrote: Actually, if you want an existing mailing list to discuss this on, you can use [EMAIL PROTECTED] That was Suhaib's list but he's indicated that he's had to move on and the project is basically dead. The name even makes a certain amount of sense. You can use that for the discussion until an actual project name is chosen. At that point, I'm happy to set up what is required on sources.redhat.com. Don't let my pessimism (or Harold's) stop you if you are fired up about this but please be aware that this will require substantial work, probably by more than one person. You'll probably need a project lead, too, if you want this to succeed. cgf
Re: X client wrapper for Win apps?
Rasjid Wilcox wrote: On Fri, 20 Sep 2002 5:58 am, Alexander Gottwald wrote: snip VNC is not the better solution. It grab parts of the picture _after_ they were drawn. X11 sends the drawing commands across network. There was always a VNC client for windows which allowed access to a unix session. But as this is far from being fast someone started building a xserver for windows. VNC requires much higher bandwidth than X11 and will fail on fast changes of the display content. As a VNC user who runs Linux and home to control a Windows NT machine at work, and finds the performance less than satisfactory even with ADSL both ends, I would be very interested in the 'X client wrapper for Win apps' idea. I suspect the performance would be subtantially better (assuming decent optimisation and caching). As far as I can tell, Radmin (http://www.radmin.com) is a commercial product that uses the GDI hook idea, and if you believe its marketing, it outperforms all other (windows) remote control software by a significant margin. Unfortunately, it is only Windows-Windows. Anyway, I think that something that allows Windows apps to be easily displayed on Xservers (other than VNC) would be a really good thing. Particularly if just the application could be displayed as opposed to the entire desktop. It opens up all sorts of possibilities, in the same way that a rootless mode does. I would like to see this happen and would be happy to test! :-) Rasjid. What would be even better than either VNC or Radmin is that you could use a standard Windows machine like a Terminal Server if we got this all set up right... If an office wants to migrate to Linux but some people still need Windows apps, they could just use one Windows box and let people connect to that to run the apps they need... David
Re: New Project (was RE: X client wrapper for Win apps?)
Stuart Adamson wrote: As what we are wanting to do here isn't strictly a cygwin/Xfree86 thing could I suggest we start a new sourceforge project and mailing list for this? Of course - we need a name for that ... Stuart Yes, I've been thinking this and then we can include it back into cygwin if neccessary later. Possible names: gdi2X win2X xgdi I'm happy to register the project and set it up...
Re: New Project (was RE: X client wrapper for Win apps?)
Harold L Hunt II wrote: Please don't use GDI in the name. I ask this because I don't want there to be confusion between the Cygwin/XFree86 NativeGDI engine and any foogdi project. Consider instead something like the following: XShell XExplorer Something more along those lines would help to differentiate your project from Cygwin/XFree86. Harold David Fraser wrote: Yes, I've been thinking this and then we can include it back into cygwin if neccessary later. Possible names: gdi2X win2X xgdi I'm happy to register the project and set it up... Qualities we need for the name of the project: Should reflect what it does (displays ordinary Windows programs on an Xserver) Should be intelligible to end users Other names: OpenWin[dows] (because it's open source replacement for windows gdi) XOpenWin[dows] I reckon XExplorer sounds to much like it's a different of Windows Explorer, XShell is fairly good, as it's replacing the normal shell functions. XDesktop would be good except it would sound like its a generic X Desktop like KDE or Gnome I like the combination of Open and Windows as it's reflective both of the fact that its open source and that its using an open protocol, which is important because it gives flexibility that Windows currently lacks. And it's metaphorically nice. I don't think we can simply use OpenWindows though as that's a Sun windowing system... We should clarify the scope of the project. It could be an umbrella project to house a few different ways of goiig about this (that have been discussed so far) or we could settle on It takes a while to register a project anyway (about a day) and these are the things we need... (from sourceforge page) 1. Project Full Name You should start with specifying the name of your project. The Full Name is descriptive, and has no arbitrary restrictions (except a 40 character limit). 2. Project Purpose and Summarization *Submitted description should be at least a paragraph in length, and provide details of your intended implementation (programming language, OS platforms supported, graphics libraries you might intend to use, etc. as applicable). This description will be the basis for the approval or rejection of your request for project hosting on SourceForge.net, and later, to ensure that you are using the services in the intended way. This description will not be used as a public description of your project. * 3. License I would think GPL or LGPL here unless there is a reason we need to keep this the same as cygwin/Xfree86 4. Project Public Description This is the description of your project which will be shown on the Project Summary page, in search results, etc. Maximum length is 255 chars. 5. Project Unix Name In addition to full project name, you will need to choose short, Unix name for your project. (This is the name discussion above) Once it's up, we need to set up mailing lists and the web site and then we can get going... David
Re: New Project (was RE: X client wrapper for Win apps?)
Yes, will do as soon as the new project is set up. So it'll hopefully be only a few more emails. Jim Drash wrote: Can we move this discussion to another mailing list? and Get back to the business of cygwin-xfree, here. TIA jim drash
Re: New Project (was RE: X client wrapper for Win apps?)
Alexander Gottwald wrote: On Fri, 20 Sep 2002, David Fraser wrote: Other names: OpenWin[dows] (because it's open source replacement for windows gdi) XOpenWin[dows] OpenWindows is the X11 environment from SUN. Using this name might bring some trademark problems. bye ago Thanks, had realized that (mentioned later in email)...rats thesaurus time: Window: light port sky lattice sun shine viewpoint outlet shutter gate hmmm... Anyway I'm happy with XOpenWin. I prefer it to win2x because it sounds more professional. Any objections? Here's a stab at the project descriptions etc: 1. Full Name XOpenWin 2. Project Purpose and Summarizations XOpenWin is a project to utilize X Windows as an alternative user interface for Windows operating systems. It will use the the cygwin xfree86 project (particularly xlib) to display the equivalent of GDI calls for Windows applications. It may import or use code from the Wine project that does similar things on Linux; however this is essentially different to Wine as it is only converting the display, not emulating any other Windows functions. Programming language will be C/C++, OS platforms as many windows variants as possible. This has been discussed extensively on the cygwin-xfree86 mailing list and planning has already begun. 3. License GPL. 4. Project Public Description: XOpenWin is a project to utilize XWindows as an alternative user interface for Windows operating systems. It will allow any app (or the whole UI) to be displayed in an X server, on the user's screen (cygwin) or remotely. 'Say goodbye to the Windows GDI' 5. Unix name XOpenWin Any changes, post them quickly, otherwise I'll go ahead...
XOpenWin
Submitted an application to source forge to create project XOpenWin. Will post again when it is set up (takes a while for them to process) David
Re: XOpenWin
Yes, but then I posted some other alternatives and suggested this name and nobody seemed to mind. I could always reapply for the project under a different name... I just thought a huge discussion about the name would take time... but if people generally want Win2X we can do that I guess. Pros/cons? Jean-Claude Gervais wrote: Um, was Win2X pitched as a name? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Fraser Sent: Friday, September 20, 2002 1:23 PM To: [EMAIL PROTECTED] Subject: XOpenWin Submitted an application to source forge to create project XOpenWin. Will post again when it is set up (takes a while for them to process) David
Re: X client wrapper for Win apps?
Stuart Adamson wrote: Every Windows draw command is translated into calls to a GDI driver. this driver is either the driver of the graphics card or a printer. The people from wine already have written a driver which exports a GDI interface and maps all calls to X11. Maybe this is a starting point. But xfree86 will also be using this interface to draw to the screen (as will the logon box etc). I can see this becoming rather circular You need to be able to set the GDI context per application. Maybe the way forward is to filter calls to user32.dll (where most of the basic windowing functions end up). By filtering I mean renaming user32.dll to user32-real.dll and writing your own user32.dll which either sends requests to X11 or to user32-real.dll, depending on the process id of the requesting process. Stuart Yes, this way makes more sense and in fact I've started investigating it already. To make debugging easy rather than replacing user32.dll I'm using Windows hooks to try and catch all the function calls and log them first ... then we'll know which ones to work on to get simple apps going ... it also gives us the ability to call both the original user32.dll function and a modified one which will do something with X which might be useful in debugging. Not much progress yet, just got the hooks working...
Re: X client wrapper for Win apps?
Alexander Gottwald wrote: On Thu, 19 Sep 2002, Jehan wrote: 4. Give me valid point (like the hardware thing) and I'll just up. API compatibility isn't a valid one since it can be easily fix (more easily that writing a new GDI driver). Just explain the design you have in mind. Is it Application User32.dll User32-orig.dll XWin LineTo(x,y)+LineTo(x,y) | +shadowDrawLine If so, then you must call the xserver drawing function directly Application User32.dll User32-orig.dll XLib LineTo(x,y)+LineTo(x,y) | +XDrawLine In this case you have the X11 Protocol overhead again. And of course the problem with the replaced User32.dll My proposal was ApplicationUser32.dll GDIDisplayGDI XLib --LineTo(x,y)gdiLineTo(x,y)---gdiLineTo(x,y) | +--XDrawLine This requires the same work as replacing user32 since all exported functions from the library must be replace with stubs calling the original functions and the code for converting the calls to X11 or the Xserver functions must be written. bye ago Now we're talking. This is the type of thing we should be discussing. It is clear that doing this Windows-X thing would useful and there is a fair amount of interest in it. I suggest we discuss an implementation strategy and do it. Maybe we can separate out the why would you want to do that thread from a planning thread... I've thought about several ways for doing various things but really need to read up more of the docs on how the GDI works. Unless of course someone wants to post a nice explanation of whats relevant. Pros/cons of the two approaches above? Essentialy I've thought that wine has a lot of the code we need but we probably need to start a separate system to establish the basic framework before we try getting the wine code ported. Maybe I'm wrong. Anyone tried to compile x11drv? Also, it may be advantageous to only use X for certain applications ... in that case you want to be able to set (say with environment variables like DISPLAY) whether you're using X or not and which display you're exporting it to. This would also involve allowing different users to logon at the same time from different X servers etc. If we're looking at this type of approach, I'm not sure a GDI driver would work because you may need different gdi drviers for different apps - is that possible in Windows? I've made a whole lot of notes on different possible approaches which might be useful to start things off which I can post as the discussion proceeds...
Re: X client wrapper for Win apps?
Keith D. Tyler wrote: David Fraser was recently quoted as saying... I've discovered that rather than using -fullscreen, if you simply use -nodecoration and set the X server to run at the same size as fullscreen, it doesn't minimize when you switch tasks, but still stays the same size as the full screen in the background. The advantage being you can still see it behind your other apps (if they're not maximized), although they're still not actually inside X windows. Yeah... but unless you only use alt-tab to switch apps, you have to minimize the X server periodically to see the minimized app icons (which are ugly as sin in Win95+, but that's another matter) Another thought on this theme (these are all just patch-ups, we really want the whole Windows running in X thing) is to have a hook that catches Shell functions (opening, closing of Windows, etc) and use that to create dummy (transparent?) windows in X corresponding to each top-level window in Windows. Selecting the window in X should then activate the window in Windows. They would then appear in the taskbar / list of windows in whatever window manager system is being used in X. Windows has a nice Hook system that is fairly easy to use... Could we modify them to send messages between them for certain desktops? Doubtful. So say you have Ctrl-F1, Ctrl-F2 switching to Linux Desktop 1 and 2, then Ctrl-F3, Ctrl-F4 switch back to the Windows one and tell it to activate a certain desktop. That way we'd be writing glue code rather than a whole new system. Well, I use directional window-switching keystrokes. The JSPager set uses Ctrl-Up,Ctrl-Down, etc, and my FvwmPager set uses Alt-Up, Alt-Down, etc. This is, I realize, all probably very unrealistic dreaming, but any leads or tips are welcome. Sounds like if Wine emulates a Win32 environment and then converts Win32 apps to X windows, the problem is partly solved there. But AFAIK Wine doesn't have a multi-window mode, you get one X window which contains a Windows desktop *within* which normal GDI windows run. Is that right or has that changed? No, each GDI window runs in a separate X window == Keith D. Tyler[EMAIL PROTECTED] Federal Way, WA http://www.keithtyler.com -- Terrorists can attack freedom, but only Congress can destroy it. ==
Re: Using KDE as default desktop under Windows
Hadn't tried that till you mentioned it ... I tried starting actual .msi files with my win32start script (in my previous message) and could both install and uninstall programs that way without any problems without explorer running. Also tried starting C:\Winnt\system32\appwiz.cpl (Add/Remove programs box) and that started fine, let me add and remove programs without any problems. Couldn't start appwiz from a link to it though, and I only tried adding and removing one program. Not sure what problems you are having - running msiexec from commandline? I'm running Windows 2000 David Stuart Adamson wrote: As somebody else that has replaced explorer with cygwin/Xfree86 - have you solved the program of being unable to install windows programs via MSI when explorer isn't running? Stuart -Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: 03 September 2002 01:29 To: [EMAIL PROTECTED] Subject: RE: Using KDE as default desktop under Windows Interesting. Harold
Using KDE as default desktop under Windows
Hi there I posted this to the kde-cygwin mailing list and someone suggested reposting it here. Basically an explanation of my kde setup under Windows... I am now using KDE as my default shell under Windows. Thanks to everyone for the effort - it's so much nicer than explorer :-) I thought it would be nice to have a page on the web site explaining how to do it, and indicating status as more integration gets done... basically this is what I did (this is for Windows 2000 but should be portable to others): make XFree86 server run full screen without window decoration change ~/.xserverrc to include -fullscreen in the parameters: exec X - screen 0 1024 879 -engine 4 -fullscreen -depth 32 -ac -nowinkill -noreset -emulate3buttons 100 you can say -nodecoration (which -fullscreen implies) instead if you want a non-fullscreen window without border etc. replace the default shell, explorer.exe with X-windows change the following reg entry under from explorer.exe to c:\cygwin\bin\bash --login -c startx HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell Once this is done, logging in starts up the X server but no Windows desktop, Start bar etc. Note: if you want to run windows programs from here, on Windows 2000 you can press Ctrl-Shift-Esc which brings up the Task Manager, then go File/Run. Logging out from KDE doesn't actually log out, you need to close KDE in another way and then press Ctrl-Alt-Del and choose logout. Depending on your .xserverrc parameters, Ctrl-Alt-Backspace or Alt-F4 can be made to close the X server. Otherwise, you can close it from the Task manager (select the Cygwin task and say End Task). This also brings up a bash shell window which is behind the X server. I tried to get rid of it by running cmd /c start /b bash ... but this was unsuccessfull. If you switch to any windows applications, the X server will be minimised. I seem to remember some discussion on slashdot or somewhere about how Cygwin XFree86 cannot run in rootless mode (as the actual background window like Windows exlporer does for the desktop). Does anyone have any info on why this is, or on how we could patch it so that it will? That way windows apps will run in front... Next step: get KDE to run windows applications from short cuts. I created a simple script called win32start: #!/bin/bash startpath=$* if [[ -L $startpath ]] then # this is a symbolic link. find the actual file, start that startpath=`find $startpath -printf %l` fi startdir=`dirname $startpath` startfile=`basename $startpath` cd $startdir cmd /c start \starting application\ $startfile This is put in /usr/bin It handles cygwin unix-style symbolic links to Windows shortcut files as well (both are given the extension .lnk, but have different stuff inside ... if you create a link to a shortcut it is thus called .lnk.lnk). Basically it gets whatever parameters are given (it needs to use them all so you can pass spaces without it separating them out; escaping the spaces with backslash confuses cmd, although they could be unescaped) and works out what directory the file to start is in. It's easiest to get into this directory as we then don't have to convert the path from unix to windows style. Then it runs cmd and tells it to start the application. The first parameter to start is the window title which has to be given if we quote the start file. But this window title only applies to cmd, which just starts the application and quits. Example: $ win32start /c/Documents\ And Settings/All\ Users/Start\ Menu/Programs/Acrobat\ Reader\ 5.0.lnk on my system this starts up Acrobat. Now we want to make KDE associate these files with win32start so we can click on them from konqueror and put them in menus. First we need a mime type for the Windows shortcut files... Add the following to a new file ~/.kde2/share/mimelnk/application/win32shortcut.desktop (on most systems, it could be ~/.kde/... - I've had KDE 1 installed ...) This users the link icon which just looks like a shortcut. It would be nice to get KDE to read the windows Icon out of the shortcut file but probably lots of work [Desktop Entry] Comment=Win32 shortcut file Hidden=false Icon=link MimeType=application/win32shortcut Patterns=*.lnk Type=MimeType Then create the association. To do this, create a desktop file under ~/.kde2/share/applnk/win32start.desktop and place the following into it: [Desktop Entry] Comment=Start Win32 applications or files Exec=win32start Icon=exec InitialPreference=3 MimeType=Application;application/win32shortcut Name=Win32 Starter Path= ServiceTypes= Terminal=false TerminalOptions= Type=Application X-KDE-SubstituteUID=false X-KDE-Username= This can also be done through control panel if you want to make life easier ... but on my system it gave some trouble ... Now you should be able to for example browse to your Start Menu on your windows drive and start programs. I then added a nice second start menu to
