XWinrc configurable server (menus/icons)
Harold L Hunt II
huntharo@msu.edu
Wed Aug 6 15:59:00 GMT 2003
Earle F. Philhower III wrote:
> Howdy Harold...
>
> At 09:30 AM 8/6/2003 -0400, you wrote:
>
>> That is really the problem: the machines don't die; they just freeze.
>> So I have a computer sitting here that I can't keep my hands off but
>> it randomly freezes between a couple of times an hour and once every
>> couple of hours. Oh well, the return is authorized now, so I have to
>> send it back within five days :)
>
>
> That's why it's always brand-X Frankenstein machines for me. Unfortunately
> laptops are the only type of machine today that really need a manufacturer.
> For desktops, everyone just slaps together the same parts. I'll take good
> note of the Inspiron crashes, my company is offering to buy us a computer
> at Dell and I don't feel like getting a piece of junk.
>
I concur. I just built a desktop machine to serve as a backup until the
Gateway gets here. I have an Inspiron 7500 that powers off due to a
heat problem caused by me sticking a 5400 RPM drive into it that pulls a
little too much juice. With this setup I will basically use the 7500 as
a dumb terminal to RDP into the new desktop machine. When the 7500
crashes I can just reboot it and log back in to my RDP session without
losing any work. :)
The Inspiron 8500 is the only computer of the bunch where if you google
for the model name and freeze you get a forum with 500 messages about
freezing problems. The exact query I used was "Inspiron 8500 freeze".
Of course, I didn't find this out until after I had the problem with two
machines. Below is a link to the forum:
http://delltalk.us.dell.com/supportforums/board/message?board.id=insp_general&message.id=52179&page=1
>>> ** There's also a off-by-one bugfix in winmultiwindowclass.c, so no
>>> matter
>>> what that file's changes should go in... **
>>
>> Could you elaborate just a little on what this problem was? Do you
>> expect it to fix any crashes?
>
>
> Possibly some crash fixes, but definitely anything that looked at the
> res_name
> portion of the winMultiWindowGetClassHint() function would get an
> unterminated
> string in the heap...
>
> len_name = strlen ((char *) prop->data);
> (*res_name) = malloc (len_name + 1); <= allocated space for trailing 0
> if (!*res_name) { return 0; }
> strncpy ((*res_name), prop->data, len_name); <= won't copy that
> trailing 0!
>
> Just changing the strncpy to
> strncpy ((*res_name), prop->data, len_name+1); <= will copy that
> trailing 0
> is the patch.
>
This is good. This could be the cause of some crashes, especially since
most of those have been access violations, IIRC.
>>> 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...
>>
>> In the end I am probably not ready to code anyone into submission, so
>> I will probably just accept what works, which will become the defacto
>> standard, etc.
>
>
> You may still be correct with your worries, I'm sure there's a file
> descriptor
> that the OS is dup2()'ing there you don't want. FWIW I'm execl()'ing
> /bin/sh -c <command string>
>
Hmm... that is a good point. We have the Win32 message queue file
handle open, a feature Cygwin provides, so that we get bumped each time
a message hits the queue. After the fork shouldn't you be looping
through all file descriptors and closing all but stdin, stdout, and stderr?
>> Interesting. I like the point raised by David Fraser about maybe
>> making a substitutable %DISPLAY% variable for the config file so that
>> you can reference the current display. How hard would that be?
>
>
> That's just laziness on my part. The function HandleCustomWM_COMMAND
> in winmultiwindowprefs.c can do some peeking at the server setup (or
> it can be passed in in the LoadPreferences() call) and then do a
> strcpy followed by search-n-replace in the copied portion. The started
> app sees all ENV variables that XWin.exe saw at startup, so if you set
> your DISPLAY before starting XWin you don't need the -display x.x.x.x:y.y
> options.
>
Okay. Does this mean you are going to implement the search-n-replace or
not? Just want to know whether or not to wait for it.
Harold
More information about the Cygwin-xfree
mailing list