Re: xwinclip patch
Well, then I will fork the xwinclip development. That's the greatness of open source. I think that seamless integration with windows is very important. And a Windows user never expects to lose the clipboard contents when he selects text with the mouse. Thanks for all. Good bye.
Re: xwinclip patch
Howdy Harold, you took the words right out of my mouth (well, maybe they were a bit kinder than I'd have been!): Subject: Re: xwinclip patch ... Not all applications used the CLIPBOARD atom... a lot of them still only use XA_PRIMARY. Dropping support for XA_PRIMARY is a HUGE reduction in the feature set of xwinclip and it will not be accepted by users. XA_PRIMARY is what's used by the two largest apps used under X (according to the Unix Hater's Guide): emacs and xterm. I think you'd have a line of people knocking on your door to yell at you if you were even to think about removing the select = paste flow from these apps, or the even worse option of having to select then move the mouse to the taskbar and select some option from a popup menu to paste things. I've realized that I'm targeting a diffent user profile. I work with Windows users that want to use remote X11 apps, and you are thinking on X users that want to work from a windows box. The difference is subtle but important. Therefore, I fear that a code fork will be the best choice. Goodbye. PD: Both emacs and xterm can be configured to work with the clipboard.
PATCH: The mouse wheel doesn't work on Windows 95
--- xc/programs/Xserver/hw/xwin/winwndproc.c.orig 2003-02-12 16:01:38.0
+0100
+++ xc/programs/Xserver/hw/xwin/winwndproc.c2003-06-05 12:54:36.0 +0200
@@ -58,6 +58,8 @@
static Bools_fCursor = TRUE;
static Bools_fTracking = FALSE;
static unsigned long s_ulServerGeneration = 0;
+ static UINTs_wheel_message = WM_NULL;
+ static Bools_wheel_message_defined = FALSE;
intiScanCode;
inti;
@@ -87,6 +89,41 @@
s_hwndLastPrivates = NULL;
}
+ /* Init s_wheel_message */
+ if ( !s_wheel_message_defined )
+{
+ OSVERSIONINFO osvi;
+
+ /* Gets the operating system version */
+ ZeroMemory (osvi, sizeof (osvi));
+ osvi.dwOSVersionInfoSize = sizeof (osvi);
+ GetVersionEx (osvi);
+
+ /*
+ * If we're running an OS version that doesn't support WM_MOUSEWHEEL,
+ * find out what message number we should be using instead.
+ */
+ if (osvi.dwMajorVersion 4 ||
+ (osvi.dwMajorVersion == 4 osvi.dwPlatformId != VER_PLATFORM_WIN32_NT))
+{
+ s_wheel_message = RegisterWindowMessage (MSWHEEL_ROLLMSG);
+ if (s_wheel_message == WM_NULL)
+ErrorF (Error registering MSWHEEL_ROLLMSG window message.);
+}
+ s_wheel_message_defined=TRUE;
+}
+
+ if (message == s_wheel_message message != WM_NULL)
+{
+ if (s_pScreenPriv != NULL !s_pScreenInfo-fIgnoreInput)
+{
+#if CYGDEBUG
+ ErrorF (winWindowProc - MSWHEEL_ROLLMSG\n);
+#endif
+ winMouseWheel (s_pScreen, wParam);
+}
+}
+
/* Branch on message type */
switch (message)
{
Re: PATCH: The mouse wheel doesn't work on Windows 95
Interesting.
Thanks for contributing,
Harold
[EMAIL PROTECTED] wrote:
--- xc/programs/Xserver/hw/xwin/winwndproc.c.orig 2003-02-12 16:01:38.0
+0100
+++ xc/programs/Xserver/hw/xwin/winwndproc.c2003-06-05 12:54:36.0 +0200
@@ -58,6 +58,8 @@
static Bools_fCursor = TRUE;
static Bools_fTracking = FALSE;
static unsigned long s_ulServerGeneration = 0;
+ static UINTs_wheel_message = WM_NULL;
+ static Bools_wheel_message_defined = FALSE;
intiScanCode;
inti;
@@ -87,6 +89,41 @@
s_hwndLastPrivates = NULL;
}
+ /* Init s_wheel_message */
+ if ( !s_wheel_message_defined )
+{
+ OSVERSIONINFO osvi;
+
+ /* Gets the operating system version */
+ ZeroMemory (osvi, sizeof (osvi));
+ osvi.dwOSVersionInfoSize = sizeof (osvi);
+ GetVersionEx (osvi);
+
+ /*
+ * If we're running an OS version that doesn't support WM_MOUSEWHEEL,
+ * find out what message number we should be using instead.
+ */
+ if (osvi.dwMajorVersion 4 ||
+ (osvi.dwMajorVersion == 4 osvi.dwPlatformId != VER_PLATFORM_WIN32_NT))
+{
+ s_wheel_message = RegisterWindowMessage (MSWHEEL_ROLLMSG);
+ if (s_wheel_message == WM_NULL)
+ErrorF (Error registering MSWHEEL_ROLLMSG window message.);
+}
+ s_wheel_message_defined=TRUE;
+}
+
+ if (message == s_wheel_message message != WM_NULL)
+{
+ if (s_pScreenPriv != NULL !s_pScreenInfo-fIgnoreInput)
+{
+#if CYGDEBUG
+ ErrorF (winWindowProc - MSWHEEL_ROLLMSG\n);
+#endif
+ winMouseWheel (s_pScreen, wParam);
+}
+}
+
/* Branch on message type */
switch (message)
{
Re: xwinclip patch
Excellent. [EMAIL PROTECTED] wrote: Well, then I will fork the xwinclip development. That's the greatness of open source. I think that seamless integration with windows is very important. And a Windows user never expects to lose the clipboard contents when he selects text with the mouse. Thanks for all. Good bye.
xhost problem?
Hello, Since Cygwin/XFree86 now has a functioning rootless mode, I would like to start it up when Windows starts up. I have two computers networked: my Windows machine and a FreeBSD box that does web serving, mail, DHCP/NAT, etc. Since I often connect to the FBSD box via serial terminal over a null modem, I use xhost to allow it to run applications on the Cygwin/XF86 server. My problem is that when starting up, the start script that I have in my Startup directory doesn't do the xhost correctly. I have (essentially) the following in my startup batch script: --- @echo off SET DISPLAY=127.0.0.1:0.0 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 if %OS% == Windows_NT goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP start XWin -multiwindow run xhost +10.0.0.1 rem run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash -- (The last two lines are one line in the batch file.) When this script runs at system startup, the xhost line doesn't take, as typing xhost from a Cygwin bash shell indicates when the system is loaded. Two things, though, can make the script do the xhost correctly: 1) uncommenting the xterm, or 2) running the unmodified script after system startup. Does anyone have any ideas on this? Hopefully this isn't somnething that's been discussed to death; I did comb the archives and didn't find anything. Thanks for reading! regards, -Felipe Gasper Champaign, IL -- --- Felipe M. L. M. Gasper http://fgmusic.org Judge ideas, not people. Love people, not ideas.
RE: OT - Terminal embedded in desktop
Hi Igor, OK, so you've basically resolved ONE question for me; there is NO existing app/terminal/window-manager that does what I want. As for your suggestion that I code one myself, I think that that is the only direction to take. If it were for Windows, I have no doubt that I could manage it, because I know Win32 well enough, but for X, it's another matter altogether; I wouldn't really know where to start... Possibly looking at XEarth and ETerm or ATerm. Have you any suggestions? Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Igor Pechtchanski Sent: Tuesday, June 03, 2003 9:03 AM To: [EMAIL PROTECTED] Subject: RE: OT - Terminal embedded in desktop Umm, Jean-Claude, most likely I'm missing something, but shouldn't you be able to create one yourself rather easily by taking the code for a stock xterm (the simpler - the better), removing the call that creates the window, and using root drawing calls instead of window drawing calls? I know it won't be *that* simple, but as a general direction, does the above look feasible? Igor On Tue, 3 Jun 2003, Jean-Claude Gervais wrote: Hi Biju, Thanks for taking the time to try and understand. I know I am not totally clear. I'm not looking for something for Windows. It's something for X, Gnome, KDE, or whatever other X thingie I'd need to run it where the desktop is a normal Linux X desktop, with icons and things on it, but at the same time, it is a terminal window. The terminal window is transparent, yes. But not transparent like a lot of X terminals I've seen that only put the same bitmap that the X root window is using in their client area. With normal terminals, you see a fake transparence; it simulates transparence by using the desktop bitmap as a background in its (the terminal's) window. I'm talking about a desktop applet (maybe an applet, maybe something else, I'm not sure) that is a terminal window, covering the desktop, but really transparent. And if you click on an item on the desktop, you can activate it. Does that make any sense? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Biju G C Sent: Sunday, June 01, 2003 3:55 PM To: [EMAIL PROTECTED] Subject: Re: OT - Terminal embedded in desktop --- Jean-Claude Gervais [EMAIL PROTECTED] wrote: Hello, Also, the terminal window, since it is the desktop, would not have a border, would take up the entire desktop and could not be moved. It would not appear in the window list of the window manager. Is there such an animal? Is it an application, a window manager or a combination of the two? Thanks. R u looking some thing like the following They are not X Window manger, But May be use it along with XWin.exe (I have not tried) http://blueboxshell.org/ http://bb4win.org/news.php http://www.litestep.net/ http://indiestep.sourceforge.net/ http://www.lokai.org/ http://www.geoshellx.com/ http://geoshell.sourceforge.net/GeoWiki http://carbon.shellscape.org/ http://shells.lokai.net/ -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
RE: Problem with releases since -37
You did say that and I misread it. I have been looking for a 1.3.23 package and, after checking a half a dozen or so mirrors, have not seen one. Has it been released yet? Is there an ETA? -Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Tuesday, June 03, 2003 10:49 AM To: [EMAIL PROTECTED] Subject: Re: Problem with releases since -37 On Tue, Jun 03, 2003 at 10:38:52AM -0400, Andrew Braverman wrote: I updated the XWin package to -42 and changed nothing else. The new stackdump is attached. Thank you again for all the help. I was talking about the latest CYGWIN DLL, not the latest XWin package. [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Monday, June 02, 2003 7:44 PM To: [EMAIL PROTECTED] Subject: Re: Problem with releases since -37 On Mon, Jun 02, 2003 at 05:56:19PM -0400, Andrew Braverman wrote: Sorry. Missed that one. It is attached now. Doh. I was hoping that if I saw the cygwin version from the cygcheck output I would be able to figure out the stack dump but I've removed the debugging version of cygwin 1.3.22 that I'd need to do that. If you want to try the latest (i.e., the soon to be uploaded June 2 version) cygwin snapshot DLL and send the stackdump file again, I should be able to say where it is dying from the hex address.
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: There is a temporary release of XWin.exe available that watches our for more NULL pointer dereferences. Please try it out and report your results: That's the way I like it, JIT-fixes ;-) I had started to get crashes with the new Emacs I built today, when I was browsing through the menus. I think all the new tooltips that Emacs has in this version were the problem. The debug XWin.exe seems to fix that. so long, benny
RE: Problem with releases since -37
http://cygwin.com/, in the Contributing section of the left menu, follow the Snapshots link. Igor On Wed, 4 Jun 2003, Andrew Braverman wrote: You did say that and I misread it. I have been looking for a 1.3.23 package and, after checking a half a dozen or so mirrors, have not seen one. Has it been released yet? Is there an ETA? -Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Tuesday, June 03, 2003 10:49 AM To: [EMAIL PROTECTED] Subject: Re: Problem with releases since -37 On Tue, Jun 03, 2003 at 10:38:52AM -0400, Andrew Braverman wrote: I updated the XWin package to -42 and changed nothing else. The new stackdump is attached. Thank you again for all the help. I was talking about the latest CYGWIN DLL, not the latest XWin package. [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Monday, June 02, 2003 7:44 PM To: [EMAIL PROTECTED] Subject: Re: Problem with releases since -37 On Mon, Jun 02, 2003 at 05:56:19PM -0400, Andrew Braverman wrote: Sorry. Missed that one. It is attached now. Doh. I was hoping that if I saw the cygwin version from the cygcheck output I would be able to figure out the stack dump but I've removed the debugging version of cygwin 1.3.22 that I'd need to do that. If you want to try the latest (i.e., the soon to be uploaded June 2 version) cygwin snapshot DLL and send the stackdump file again, I should be able to say where it is dying from the hex address. -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Build from Sourceforge Xoncygwin
Hi, I just finished building XWin from the SourceForge xoncygwin cvs. I took the HEAD xc and made World. I hacked the build through, on the hoof as it were, to get sufficient dll's and an exe for XWin to run. Some things I had to 'work around':- 1) Various missing links out from exports/include/X11 to various .h files in lib/X11 and sub-directories, stopped compilation in XWin. 2) Various makes were not happening in lib's including X11, Xext, Xt, Xmu, ICE, SM, Xmuu..some Imakefiles were older than the Test91 ones and Makefiles were not being generated. This stopped the .dll exports appearing and prevented XWin linking. Not too bad on the whole...and at least I'm now seeing the:- winSelectionCallback - Selection changed! trace! Instead of just hacking through the make I'll have I more detailed look if I have time and come up with fixes. I always like to ring fence things first before doing a proper job! Colin
Re: Build from Sourceforge Xoncygwin
On Wed, 4 Jun 2003, Colin Harrison wrote: Hi, I just finished building XWin from the SourceForge xoncygwin cvs. I took the HEAD xc and made World. I hacked the build through, on the hoof as it were, to get sufficient dll's and an exe for XWin to run. Some things I had to 'work around':- 1) Various missing links out from exports/include/X11 to various .h files in lib/X11 and sub-directories, stopped compilation in XWin. I left some things out when commiting the xfree 4.3.0 sources: xc/programs/* (except Imakefile and Xserver) xc/doc xc/fonts xc/workInProgress None of these should result in the error you reported. Are these files sill missing after make includes in xc/lib/X11? 2) Various makes were not happening in lib's including X11, Xext, Xt, Xmu, ICE, SM, Xmuu..some Imakefiles were older than the Test91 ones and Makefiles were not being generated. This stopped the .dll exports appearing and prevented XWin linking. make Makefiles should always create new Makefiles. Does this help? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Build from Sourceforge Xoncygwin
Hi Alexander, I'll try again from a clean tree and only use make World. When it stopped last time I just 'wadded' in. After manually symbolic-linking the .h files I later discovered the missing dll lib builds. This time I'll stop at the first failure and find why the libs were skipped (sans Makefiles)! Probably something silly! I can't try this for a few hours..duty calls. Colin
Re: xwinclip patch
Nope, you really didn't read the mailing list.
Not all applications used the CLIPBOARD atom... a lot of them still only
use XA_PRIMARY. Dropping support for XA_PRIMARY is a HUGE reduction in
the feature set of xwinclip and it will not be accepted by users.
Harold
[EMAIL PROTECTED] wrote:
What I'm requesting is so simple as this:
--- xwinclip.c.orig 2003-01-13 02:27:22.0 +0100
+++ xwinclip.c 2003-06-04 10:09:18.0 +0200
@@ -362,15 +362,6 @@
exit (1);
}
- /* Assert ownership of PRIMARY */
- iReturn = XSetSelectionOwner (pDisplay, XA_PRIMARY,
- iWindow, CurrentTime);
- if (iReturn == BadAtom || iReturn == BadWindow)
-{
- printf (Could not set PRIMARY owner\n);
- exit (1);
-}
-
/* Local property to hold pasted data */
atomLocalProperty = XInternAtom (pDisplay, CYGX_CUT_BUFFER, False);
if (atomLocalProperty == None)
With this patch, xwinclip works as a Windows user would expect.
With a few lines, I've configured xterm and emacs to copy/paste to/from the clipboard:
~/.Xresources:
*VT100.Translations: #override \
Shift KeyPress Insert: insert-selection(CLIPBOARD) \n\
Ctrl KeyPress Insert: select-set(CLIPBOARD) \n\
~/.emacs:
(global-set-key [S-delete] 'clipboard-kill-region)
(global-set-key [S-insert] 'clipboard-yank)
(global-set-key [C-insert] 'clipboard-kill-ring-save)
Gnome 12, Gvim, and KDE 3 works correctly.
I acknow that there is lots of old applications (KDE12 mainly) that ignores
completely the clipboard, so I will try to rewrite xwinclip as a windows
taskbar app that will allow to copy (at user request) the primary selection to the
clipboard and vice versa.
Good bye!
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Benny, Okay, I will release this debug version as soon as I get a chance. Thanks for testing, Harold Benjamin Riefenstahl wrote: Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: There is a temporary release of XWin.exe available that watches our for more NULL pointer dereferences. Please try it out and report your results: That's the way I like it, JIT-fixes ;-) I had started to get crashes with the new Emacs I built today, when I was browsing through the menus. I think all the new tooltips that Emacs has in this version were the problem. The debug XWin.exe seems to fix that. so long, benny
Re: Build from Sourceforge Xoncygwin
Alexander Gottwald wrote: 1) Various missing links out from exports/include/X11 to various .h files in lib/X11 and sub-directories, stopped compilation in XWin. I left some things out when commiting the xfree 4.3.0 sources: xc/programs/* (except Imakefile and Xserver) xc/doc xc/fonts xc/workInProgress None of these should result in the error you reported. Are these files sill missing after make includes in xc/lib/X11? The integrated clipboard manager requires the Xlib headers... which are not in the build tree anymore. I had to change it from #include foo.h to #include X11/foo.h. Unfortunately, this means that you must already have Cygwin/XFree86 installed with the -prog package... otherwise those headers won't be found. The only other way to solve this is to put those headers back into the tree... which might be more of a pain than a real solution. I already updated the files in question in CVS... just do an update in hw/xwin. Harold
Re: xwinclip patch
Howdy Harold, you took the words right out of my mouth (well, maybe they were a bit kinder than I'd have been!): Subject: Re: xwinclip patch ... Not all applications used the CLIPBOARD atom... a lot of them still only use XA_PRIMARY. Dropping support for XA_PRIMARY is a HUGE reduction in the feature set of xwinclip and it will not be accepted by users. XA_PRIMARY is what's used by the two largest apps used under X (according to the Unix Hater's Guide): emacs and xterm. I think you'd have a line of people knocking on your door to yell at you if you were even to think about removing the select = paste flow from these apps, or the even worse option of having to select then move the mouse to the taskbar and select some option from a popup menu to paste things. -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
RE: [ANNOUNCEMENT] Server Test 91
Harold,
after submitting this patch I recognized a rare case memory leak in
winMultiWindowGetClassHint() if the memory allocation for res_class fails.
This is fixed by the appended small patch, which is based on the previous one.
(Hope the indention is right)
Ralf
--
$ diff -up winmultiwindowclass.c.orig winmultiwindowclass.c
--- winmultiwindowclass.c.orig 2003-06-04 19:48:36.0 +0200
+++ winmultiwindowclass.c 2003-06-04 19:55:38.0 +0200
@@ -76,8 +76,11 @@ winMultiWindowGetClassHint (WindowPtr pW
(*res_class) = malloc (len_class + 1);
-if (!*res_class)
- return 0;
+if (!*res_class)
+ {
+free(*res_name);
+return 0;
+ }
strcpy ((*res_class), ((char *)prop-data) + 1 + len_name);
--
Ralf,
Thanks.
http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test91-DEBUG.exe.bz2
Harold
Ralf Habacker wrote:
Harold Hunt wrote:
5) winclass.c, winclass.h - Rename these files to
winmultiwindowclass.c and winmultiwindowclass.h, respectively, since
they are only used in MultiWindow mode. Prefix the functions in these
files with MultiWindow. (Harold L Hunt II)
The appended patch contains some function parameter checking to
avoid segfaults
in case of invalid parameter values.
It is based on the xwin-Test91 release.
RE: Problem with releases since -37
I am usually not this slow. I do know what a snapshot means and that it is not a release and can read when you ask me to change a dll and not the XWin executable. For some reason, I did not process things correctly in the last couple of days. My apologies. I did some more testing based on your suggestions. I first tried the XWin-Test91-DEBUG version of the server with the released version of the dll. That failed as before and gave me a new stackdump. I then put in cygwin1-20030602.dll as /bin/cygwin1.dll. I restarted windows to make sure that the correct dll was used. I ran with the XWin-Test91-DEBUG version of the server again and it gave me Microsoft's do you want to report this box again, but did not produce a stack dump. I tried the 042 version again, and got the same results (do you want to report this and no stackdump). Putting the last working version (037) back in with the new dll works fine. Anyone have any other ideas that I can try? Thanks again for the help so far. - Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Wednesday, June 04, 2003 12:28 PM To: [EMAIL PROTECTED] Subject: Re: Problem with releases since -37 On Wed, Jun 04, 2003 at 09:54:14AM -0400, Andrew Braverman wrote: You did say that and I misread it. I have been looking for a 1.3.23 package and, after checking a half a dozen or so mirrors, have not seen one. Huh? The next version has not been released. Go to the cygwin web site and look for the word Snapshot. A snapshot is not the same as a release. It looks like Harold has done some work with null pointers recently. Maybe that will rectify your problem.
Re: Multiwindow mode problem with Mozilla/Phoenix on Solaris
Hi Harold, Harold L Hunt II [EMAIL PROTECTED] writes: Okay, I will release this debug version as soon as I get a chance. Cool. BTW, I forgot to mention that the icons are *much* better now, that bit also works. so long, benny
RE: Problem with releases since -37
Howdy Andy.. At 02:37 PM 6/4/2003 -0400, you wrote: I did some more testing based on your suggestions. I first tried the XWin-Test91-DEBUG version of the server with the released version of the dll. That failed as before and gave me a new stackdump. I then put in cygwin1-20030602.dll as /bin/cygwin1.dll. I restarted windows to make sure that the correct dll was used. I ran with the XWin-Test91-DEBUG version of the server again and it gave me Microsoft's do you want to report this box again, but did not produce a stack dump. I tried the 042 version again, and got the same results (do you want to report this and no stackdump). Putting the last working version (037) back in with the new dll works fine. Anyone have any other ideas that I can try? Since nobody seems able to reproduce your failure, you might try debugging it, at least to the point of failure, yourself. You should be able to recompile the XWin.exe in debug mode and start it up in in gdb, and when the crash occurs you should get an annotated function trace with add'l debug info... I think the -DEBUG version is just one with Ralf's new parameter checks, not really a debug version, so you'll really have to recompile with the -g option... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Possible X-Wndows problem
Howdy... At 01:39 AM 6/4/2003 -0700, you wrote: I had Cygwin crash on me the other day and was wondering if this is my machine doing this (like it ran out of memory or some such) or if it was a known problem with Cygwin. I wrote a small program which opened a 400x400 pixel screen and then proceeded to write to each pixel varying colors. The program worked at first but after allowing the program to run several hours while it randomly wrote colors to the dots (in the proper range of course), Cygwin crashed and died leaving the system in an unstable state (ie: I had to reboot my Windows box). Are you running a W98 based OS, or were you able to kill W2K/NT/XP with this? That sounds more like a driver issue if it's the latter. Also, do you have a check as to the number of GDI handles, etc., and how they increase with time? I think there are some leaks still there but haven't run into any problems under W2k. W95 based OSes do have more limitations, though, and will crash where NT OSes will continue running. (To see GDI handles/etc bring up taskmgr, select View-Select Columns, and check GDI objects, Handle Count, USER objects, and memory usage...) If you do see one of those numbers increasing without stop then maybe just posting your source code would be useful. -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
RE: [ANNOUNCEMENT] Server Test 91
Hi Ralf, let me just say thanks for doing all the boring work of parameter checking and NULL malloc fixes. Hacking code's fun, making it bulletproof is just work... At 08:02 PM 6/4/2003 +0200, you wrote: after submitting this patch I recognized a rare case memory leak in winMultiWindowGetClassHint() if the memory allocation for res_class fails. This is fixed by the appended small patch, which is based on the previous one. (Hope the indention is right) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: Alternate Window Managers
R U looking for http://cygnome.sourceforge.net/ http://cygnome2.sourceforge.net/ http://kde-cygwin.sourceforge.net Redirecting to cygwin-xfree mailing list. Please continue this discussion there. On Wed, Jun 04, 2003 at 08:57:07AM -0700, Robert Pollard wrote: Hello all, I was curious if there was other window managers aside from the one that is used on default in X? The window manager that is used on default is okay but I sort of got use to Gnome and KDE in Linux. If there are, how and where do I get them or use them if they are already on the system? I don't know how to get the version of cygwin I'm running but I just downloaded it about 2 months ago. Thanks for all your help, Robert __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Newer version of MorseCode source code and executable
I cleaned up the code for the MorseCode project a bit. I changed the settings variables from global scope to being a static structure with a reference pointer passed amoung the various functions. I also added info to the Properties window about what units each of the settings has (milliseconds and Hz). Finally, I cleaned up the installation of the hook DLL to use a single function and pass minimal variables between the DLL and the EXE. The new source code and binary are here: http://www.msu.edu/~huntharo/MorseCode/ Anyone that looked at the source code before should look at the new souce code... it is much cleaner. Harold
-multiwindow vs -rootwindow (Was: Re: Setup failures during mirrored install)
On 4 Jun, Igor Pechtchanski wrote: Umm, I noticed the typo before, but I was hoping you'd notice it too and correct it. It should have been startx -- -multiwindow (you're passing the -multiwindow to the server, not to the clients). Sorry about that. No worries. (I had assumed startx had been modified to treat -multiwindow specially, which was a silly thing to think.) Interestingly, I just did some tests and found that -rootless seems to work much better overall: 1) Able to type in all rxvt and xterm windows, instead of unable to type! 2) Responsiveness of mouse tracking at least twice as good using -rootless compared to -multiwindow. One advantage of -multiwindow is it gives you a confirmation dialogue box when you right click and choose exit from the startx.bat window's task bar entry, not just from the X taskbar entry. Plus you have an option to show the root window. I was using Xserv 4.2.0-37, but have just upgraded to 4.2.0-42 and there's no real change. I'm using Window Maker as the window manager, and running 24 bit colour on 1600 x 1192, under Windows XP Professional on a Dell C400 laptop driving an external monitor. One thing I noticed was that when using -multiwindow, for a short while (just after WM replaced the default window decorations with its own), I was able to type a few characters in one of the rxvt windows. By the time WM had started up all my rxvt and xterm windows, though, I could no longer type in any X window. And Xserv 4.2.0-42 seems about 5 to 10 times more responsive at tracking the mouse cursor when using -rootwindow instead of -multiwindow. This sounds to me interesting enough to Cc: to the mailing list - hope you don't mind. Regards, luke
Re: what is the Status of Native engine?
Mike, Nothing has happened in quite some time. The version of the the Native GDI engine in the Cygwin setup.exe is not the most up to date. There is a newer version in one of the branches of the 'xoncygwin' SourceForge project. I make no promises that it still builds. Also note that it is extremely slow and not complete. Development may start on Native GDI again when some other easier features are complete. Harold mike stout wrote: starting XWin -engine 16 uses the experimental native engine. Is development continuing on this engine?
