XWinrc configurable server (menus/icons)

[Earle F. Philhower III]

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