Re: XWinrc configurable server (menus/icons)

["Earle F. Philhower III" <earle at ziplabel dot com>]

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.

> > ** 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.

> > 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>

> 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.

-Earle F. Philhower, III
 earle@ziplabel.com
 cdrlabel - ZipLabel - FlpLabel
 http://www.cdrlabel.com