[GRASS-user] Help reqired

[Glynn Clements]

Brad Douglas wrote:

> > I am trying if I can use the source code for GRASS and compile in VC++
> > (Windows.) so that I can run from Windows platfrom without Cygwin. The
> > desire is to run it just as a VC++ workspace.
> > Can any one please help me in ths regard. 
> 
> GRASS uses a number of UNIX conventions that are not present in Windows.
> Cygwin provides the majority of missing functionality.
> 
> Unfortunately, a native[1] Windows port would involve a rewrite of most
> of the code.  IMO, the only realistic approach is to emulate object
> orientation so that each OS could provide low level hooks to generalize
> the code sanely (this approach will not cluttering the code with
> preprocessor macros, long branches, etc.).
> 
> It would be nice to provide a native Windows port, but I don't see this
> happening anytime soon.  There is too much code and not enough
> entrenched developers to provide such Whiz-Bang features.
> 
> [1] Cygwin is *not* native Windows.  WIN32 API *is*.

MSVCRT is also "native"; that's enough for most of GRASS.

The main thing which doesn't work natively is the display drivers,
along with the corresponding portion of the raster library. This
applies to both the PNG and X drivers; we even have an X11 emulation
library so that the rendering portion of XDRIVER can use native
Windows GDI functions instead of requiring an X server.

The main problems with using monitors are the use of Unix-domain
sockets, and the startup (the driver fork()s into the background once
it has initialised and is ready to accept connections; mon.start is
closely tied to this behaviour).

Direct rendering still works, and gis.m works with a native Tcl/Tk
implementation. The new v.digit should work, as will the Tcl/Tk
implementation of d.rast.edit. NVIZ also works.

Consequently, anything which won't work with direct rendering but
requires an actual monitor (i.e. anything using R_get_location_with_*)
won't work natively on Windows. This includes i.[v]points and
i.ortho.photo.

Programs which make "ancilliary" use of the mouse functions will work
but the features which use the mouse won't work. E.g. d.barscale will
compile and run using direct rendering, but the -m switch isn't
meaningful without a monitor.

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