Re: XWinrc configurable server (menus/icons)

[Harold L Hunt II <huntharo at msu dot edu>]

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