> I just tracked down the source of the `Cannot create a process' error.
> This is seems to be a bug in WordPerfect.
> 
> The FIFO mentioned in your ktrace output is used to communicate with
> the WP print daemon.  When `xwp' tries to open the FIFO for writing
> and fails, it forks another process to start the daemon.  The error is
> displayed because `wpexc60' exits with a status of 1, indicating
> failure.  The reason it fails is that it tries to open the FIFO with
> O_RDWR (which doesn't make sense), apparently expecting it to be
> equivalent to opening it with O_RDONLY|O_NDELAY but leaving the FIFO
> in blocking mode, and instead gets EINVAL.
> 
> I suppose we could kluge around this in the FIFO code, but I'm not
> convinced that's a good idea.

This is just one instance of a more general problem.  Whenever we
provide binary compatibility with a buggy OS, we'll have to deal
with this problem.   Clearly, there are advantages to providing
the correct functionality, especially in the case of ibcs2 which
is supported by many OSes.

On the other hand, the purpose (I assume) behind ibcs2 compatibility
is to run exactly this kind of stuff, and have it run exactly the way
it would run on the target OS.

I don't think this kind of bug duplication should be a global option.
Bugs should only be duplicated when they are needed.

I propose the following:  Somehow, associate a number of compatibility
flags with each executable.  Each time a foreign executable is
launched, the corresponding flags are also loaded, and used to
optionally enable certain questionable features.

The only part I can't decide on is where to store these flags.  Three
options come to mind:

- Somehow imbed the flags in the executable.  This has the obvious
  advantage of following the executable around, but if the executable
  decides to read itself for some reason it might cause problems.
  If we go this route, I'd recommend appending them to the end somehow.
  Perhaps just add a special magic number plus the flags.
- For executable <dir>/<exec>, put them in <dir>/<exec>.ext
  Nice in many ways, but some fussy programs might not
  like having unexpected files lying around.
- Have a central database indexed by executable filename/pathname.
  Filenames would generally be preferable so you can move around
  the executables without updating the database, but I think pathnames
  should be offered as well, to allow multiple executables with the
  same name but different flags.

I don't particularly like the last option.  First of all, there's the
complex question of how to control access of the database, which get
a bit complex in this case.  Non-root users should be able to modify
the database.

Some options might open security holes, and thus should only be allowed
by root.  This is one advantage to the second approach, since you can
require that the file is owned by root in order to set certain flags.

On the other hand, the second approach isn't good if you have an
executable directory with mode 1777.  Users could add these option
files to executables that don't belong to them.

Also, all of these approaches add a certain overhead to the launch
time.  If there's a free bit in the executable that we could set,
or if we can use an alternate magic number, then we need only check
the database or whatever for the executables that need it.  This would
also fix the above security problem.

Thoughts, anyone?

	Mark
--------------------------------------------------------------------
Email: Mark_Weaver@brown.edu           | Brown University
PGP Key: finger mhw@cs.brown.edu       | Dept of Computer Science