[GRASS-dev] Re: windows binaries

[Glynn Clements]

Michael Barton wrote:
> Moritz,
> 
> I looked at the script and you are indeed correct. I guess I'd forgotten
> about this. Why is the PNG driver not available in wingrass when immediate
> rendering works (AFAIK using the same underlying driver code and the PNG
> driver)? I could rewrite d.vect.thematic as a TclTk module, but am reluctant
> to do so because it would make it unavailable to people not using the TclTk
> GUI--and make it more work to port to a new GUI platform.

The following text is copied from one of my replies in the thread
"lib/pngdriver Mingw compile error".

  The main problem with monitors on Windows is the use of fork().
  
  "d.mon start=..." runs mon.start using system(). mon.start starts the
  driver using execl(), so the driver takes over the mon.start process. 
  The driver initialises itself then goes into the background by
  fork()ing and having the parent exit. At that point, the system() call
  in d.mon returns, and d.mon then runs mon.select (unless you used the
  -s switch).
  
  This all works because the system("mon.select ...") doesn't return
  until the driver has initialised itself and (the child version) is
  listening on the socket.
  
  On Windows, there are several problems with this:
  
  1. Native Windows doesn't have fork() or execl().
  
  2. Cygwin's versions didn't work correctly for this purpose on
  Win95/98/ME.
  
  3. Cygwin's versions won't work on any version of Windows for the
  libW11 driver, as the child process doesn't inherit the various
  Windows GUI objects created by the parent (cf X11, where the the only
  system object is the connection to the X server).
  
  4. Replacing the execl() with spawnl(_P_DETACH,...) and having the
  driver run in the foreground eliminates the above issues, but the
  result is that system("mon.start ...") returns before the driver has
  initialised itself, so the subsequent mon.select fails.
  
  To make the monitor startup work correctly on Windows, we either need
  to add some kind of signalling mechanism, or add code to mon.start
  which polls the driver until its ready to accept connections.
  
  That still leaves one more problem:
  
  5. Native windows doesn't support PF_LOCAL (Unix-domain) sockets.
  
  > b) try and get some simple monitor view window working that reads the 
  > output from the PNG driver
  
  All of the above issues except #3 apply to all drivers, not just the X
  driver (or W11 driver). Using direct rendering will suffice for simple
  cases, but you can't combine multiple commands. Also, both the PNG
  driver and direct rendering have the limiation that modules which use
  the mouse won't work.

IOW, the way that display drivers work relies upon several
Unix-specific features. Porting them to Windows would be a fair amount
of work, the utility of which is debatable given that most modules
with direct rendering.

-- 
Glynn Clements <glynn at gclements.plus.com>