[GRASS-dev] [GRASS GIS] #1891: wingrass: background dosbox from regular wxgui startup

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by hamish):

Replying to [comment:38 hamish]:
> Helmut wrote:
> > [can't test standalone cause of a nasty dll hell - aka interfering
installed
> > python vs. bundled python]
>
> at install time or run time? You should be able to change GRASS_PYTHON
to the
> exact c:\path\python.exe you want to use in %GISBASE%/etc/env.bat.

... and since %GISBASE%/etc/env.bat gets replaced at reinstall, you can
also create a personal env.bat in your %APPDATA%/GRASS6/ dir, which is
called after the system version, that way your local environment changes
survive reinstall.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:40&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by neteler):

Replying to [comment:38 hamish]:
> Replying to [comment:35 neteler]:
> > The current nightly winGRASS 6.4.3svn no longer starts:

I am using wingrass standalone on Windows8 (as before).

> - ''did you select the box for installing "Important Microsoft runtime
dll's"''?

No since I had done this already the last time.

> (again, if not selected I suspect we need an extra warning installer
page with [<Back<] [>Forward>] buttons to give the user a second
opportunity to select it)

I don't think so:
I guess I should select it only once (here, done 2 weeks ago, see ticket),
then
the machine should be ok? Otherwise we should always force to install it
if
*this* is the problem (cannot test right now).

> - can you recreate from the command line to see the error message?
right-click on the menu item, look at the properties to get startup dir
and command name, open a dosbox, cd into the startup dir and paste in the
startup command.

Will do later on.

> - the only recent change to relbr64's init.bat is r56104. (which works
fine for me, and should not affect the wxGUI startup at all, so I'm
doubtful it's the cause)
>
> or maybe there is some other dll missing. You're not using some exotic
C:\Program Files\ or Docs & Settings install location?

The entire purpose of my Windows8 installation which came with my new
laptop is
to test GRASS GIS. I simply download the standalone installer and run it.
No
other tricks done. Since the older installers worked while now broken for
me
I suspect some recent change.

> Helmut wrote:
> > [can't test standalone cause of a nasty dll hell - aka interfering
installed
> > python vs. bundled python]
>
> at install time or run time? You should be able to change GRASS_PYTHON
to the exact c:\path\python.exe you want to use in %GISBASE%/etc/env.bat.

As written, also the Tcl-Tk startup is broken for me at time.

I also deinstalled/reinstalled, no way.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:41&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by hamish):

Replying to [comment:41 neteler]:
> Replying to [comment:38 hamish]:
> > - ''did you select the box for installing "Important Microsoft
> > runtime dll's"''?
>
> No since I had done this already the last time.

you've got to do it every time. the needed msvcr70.dll & similar are al a
carte in the downloaded tarball, and get installed to C:\Program
Files\GRASS...\extralib, so are install specific, & need to be done for
each time, for each version. AFAIK only the 2010.exe installer puts the
msvcr100.dlls in C:\windows\system32 and so survives. I don't know what
the 2005.exe and 2008.exe installers actually install (but I'd like to).

So the three ms-$year.exe installers run, but also a number of dlls are in
the tarball and copied separately. The three ms-$year installers should
survive reinstall, but don't provide all the Microsoft-provided libraries
we need.

probably(?) there is some other ms redistributable installer which
installs the ones we need system wide, I don't know. note the 80 and 90
msvcr dlls are still missing (see #1428), probably causing breakage once
the fns that need them get called.

I don't like us installing to c:\windows\system32, I'd rather have ms's
installers do that with their full checks, registry registration, and
inside knowledge.

> > (again, if not selected I suspect we need an extra warning installer
page with
> > [<Back<] [>Forward>] buttons to give the user a second opportunity to
select it)
>
> I don't think so:
> I guess I should select it only once (here, done 2 weeks ago, see
ticket),

(nope, every time)

> then the machine should be ok? Otherwise we should always force to
install it

mmph. I don't think we can or should make it mandatory, but we might be
able to change the default on the download page to ticked instead of
unticked.

> if *this* is the problem (cannot test right now).

I'm pretty sure it will be #1428.

another idea is to have a tiny sacrificial osgeo4w program that runs with
a dependency on all dlls used by the core osgeo4w toolchain, and catch the
result so at least there is a nice error message telling you what to do
instead of the not very helpful vanishing box. Who c/would write it? no
idea.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:42&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by hamish):

Replying to [comment:42 hamish]:
> I don't think we can or should make it mandatory,

as per http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:43&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by neteler):

Replying to [comment:42 hamish]:
> Replying to [comment:41 neteler]:
> > Replying to [comment:38 hamish]:
> > > - ''did you select the box for installing "Important Microsoft
> > > runtime dll's"''?
> >
> > No since I had done this already the last time.
>
> you've got to do it every time.

... I omitted to say that I have done this only during the last but
one personal test round. Originally there was no need to install
these DLLs at all on my Win8 box. Hence uninstallation of GRASS should not
have changed that situation.

/me confused

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:44&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by hamish):

Replying to [comment:44 neteler]:
> ... I omitted to say that I have done this only during the last but
> one personal test round. Originally there was no need to install
> these DLLs at all on my Win8 box. Hence uninstallation of GRASS should
not
> have changed that situation.
>
> /me confused

older development versions of the installer were quietly shipping the MS
visual runtime dlls, and copying them to $GISBASE/extralib/ every time.
that is not allowed by the license, so a couple of weeks ago it was
changed to download them instead, at the user's request. so it depends if
your last install was older than a couple of weeks ago or not.

they were probably never installed system-wide on your computer, and
disappeared and reappeared within the current $GISBASE with every
uninstall and reinstall.

it also seems that in the last month or two there was another change in
the situation when whoever builds either python.exe &/or the osgeo4w stack
switched to a newer development environment which wanted the new msvcr100
dlls, while older programs shipping with those tools still want the older
versions of the runtime dlls.

the root of all this fun of course is that Microsoft makes them a standard
part of their compiler builds, but doesn't ship them as standard OS
libraries, and then makes installing them later by the end-user a total
pain in the neck. but there's not much we can do about that.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:45&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by neteler):

Replying to [comment:45 hamish]:
> Replying to [comment:44 neteler]:
> > ... I omitted to say that I have done this only during the last but
> > one personal test round. Originally there was no need to install
> > these DLLs at all on my Win8 box. Hence uninstallation of GRASS should
not
> > have changed that situation.
> >
> > /me confused
>
> older development versions of the installer were quietly shipping the MS
visual runtime dlls, and copying them to $GISBASE/extralib/ every time.
that is not allowed by the license, so a couple of weeks ago it was
changed to download them instead, at the user's request. so it depends if
your last install was older than a couple of weeks ago or not.

No, not the case.

I tested it by manually trying to start GRASS in cmd.exe. The error is not
the
DLL hell but that the path is not found, something like

"\GRASS not found bla bla"

(German language, I tried to capture the screenshot but the file
disappeared
while transiting back to Linux). In essence, the grass64svn.bat looks like
this:

{{{
Program Files (x86)\GRASS GIS 6.4.3svn\grass64svn.bat
@echo off
rem
#########################################################################
rem #
rem # File dynamically created by NSIS installer script;
rem #
rem
#########################################################################
rem #
rem # GRASS Initialization
rem #
rem
#########################################################################

set GISBASE=C:\Program Files (x86)\GRASS GIS 6.4.3svn

call "%GISBASE%\etc\env.bat"

cd "%USERPROFILE%"
"%GISBASE%\etc\Init.bat" %*
}}}

To me it looks like a problem of the unquoted GISBASE.

If anyone has winGRASS 6.4.3RC3 standalone installed, please compare if
this
bat file also contains an unquoted GISBASE path setting with white space.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:46&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by hamish):

Replying to [comment:46 neteler]:
> Replying to [comment:45 hamish]:
> > [...] shipping the MS visual runtime dlls,
>
> No, not the case.

ok,

> I tested it by manually trying to start GRASS in cmd.exe. The error is
not the
> DLL hell but that the path is not found, something like
>
> "\GRASS not found bla bla"
>
> (German language, I tried to capture the screenshot but the file
disappeared
> while transiting back to Linux).

alright. the exact message might be useful, next time you're there could
you
try again to get the screenshot?

> In essence, the grass64svn.bat looks like this:
>
  {{{
  Program Files (x86)\GRASS GIS 6.4.3svn\grass64svn.bat
  @echo off
  rem
#########################################################################
  rem #
  rem # File dynamically created by NSIS installer script;
...
  set GISBASE=C:\Program Files (x86)\GRASS GIS 6.4.3svn
  call "%GISBASE%\etc\env.bat"
  cd "%USERPROFILE%"
  "%GISBASE%\etc\Init.bat" %*
  }}}
>
> To me it looks like a problem of the unquoted GISBASE.

If you are thinking of the "set GISBASE=" line, AFAIK in batch files
anything to the right of the "=" becomes part of the string, so no need to
quote those. And if you do quote, they become a literal part of the string
as it doesn't parse them away.

> If anyone has winGRASS 6.4.3RC3 standalone installed, please compare if
this
> bat file also contains an unquoted GISBASE path setting with white
space.

(all works for me on 32bit XP, with no (x86) in the Program Files)

could you try adding some echo statements to $GISBASE/etc/env.bat and
$GISBASE/etc/Init.bat to see how far it gets?

thanks,
Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:47&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by neteler):

I have attached screenshots. The problem is in Init.bat
{{{
if "%PYTHONPATH%" == "" (
         set PYTHONPATH=%GISBASE%\etc\python
) else (
         set PYTHONPATH=%PYTHONPATH%;%GISBASE%\etc\python
)
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:48&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by hamish):

Replying to [comment:48 neteler]:
> I have attached screenshots. The problem is in Init.bat
  {{{
  if "%PYTHONPATH%" == "" (
         set PYTHONPATH=%GISBASE%\etc\python
  ) else (
         set PYTHONPATH=%PYTHONPATH%;%GISBASE%\etc\python
  )
  }}}

Hi,

I tried on Windows7 (instead of XP as earlier) and I could reproduce the
same error there. The English version of the error message is "`/GRASS was
unexpected at this time.`"

the method seems pretty much the same as the GRASS_WISH and GRASS_GUI ones
nearby, so I'm not sure what would be wrong with it, or why it matters in
7,8 but not XP, but it seems to be treating the forward-slash dirseps in
GISBASE as a switch(?).

try r56137,8.

an alternative solution might be to try to pass the 8.3 shortname version
of %GISBASE%. (`echo %~sI`)

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:49&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------
Changes (by neteler):

  * priority: blocker => major

Comment:

I tried with toda's binary snapshot: r56138 solved it for 6.4.3svn and
brought the startup back. The dosbox is minimized as desired.

Minor (new?) issue: The wxGUI start window should come to top, but it
hides behind this trac browser windows when starting.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:50&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by hamish):

Replying to [comment:50 neteler]:
> The dosbox is minimized as desired.

which is nice for the current condition of having an empty dosbox, but
just to restate the ideal goal: either present the GRASS> prompt in the
dosbox terminal(1), or don't present a terminal window at all(2) and use a
wrapper like .pyw to avoid the superfluous empty dosbox.

(1)current way in G7, some votes to do that in G6

(2)current way in G6, no votes so far to keep it

  --but not touching it without more feedback.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1891#comment:51&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by marisn):

Replying to [comment:51 hamish]:
> Replying to [comment:50 neteler]:
> > The dosbox is minimized as desired.
>
> (1)current way in G7, some votes to do that in G6

Current approach in G7 is broken by design.

When the user starts GRASS for the first time, grass70.py is printing in
the CMD window "Welcome to blahblah press RETURN to continue". As of
current nightly, CMD window is minimised thus user doesn't see that
message. From ~20 persons only one guessed correctly - hey, there could be
something important in that minimized window!

Potential solutions:
  * do not print a welcome message in CMD. Why it could not be a pop-up in
WXGUI?
  * do not minimize CMD window by default.

The GRASS configuration information is stored ONLY when user types into
CMD "exit" to close the minimized window. Out of ~20 users NONE knew the
necessity to maximize the CMD window and type in "exit" instead of just
closing the CMD window.

Potential solutions:
  * do not release CMD when starting gui. Thus on GUI exit it would be
possible to close CMD too and write out configuration data, clean up TMP
files etc. CMD could be provided by a separate icon - "GRASS GUI with
CMD".
  * do not minimize CMD window if one expects to type "exit" to close it.
  * or better - trap window close event and run "exit" part of code to
clean up on such event.

Adding to this ticket, as decision making process has been made here.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1891#comment:52&gt;
GRASS GIS <http://grass.osgeo.org>

#1891: wingrass: background dosbox from regular wxgui startup
----------------------+-----------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
     Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Default | Version: svn-releasebranch64
Keywords: wingrass | Platform: MSWindows 7
      Cpu: x86-64 |
----------------------+-----------------------------------------------------

Comment(by glynn):

Replying to [comment:52 marisn]:

> * do not print a welcome message in CMD. Why it could not be a pop-up
in WXGUI?

GUI? What GUI? :wink:

We should consider re-factoring the start-up script into separate scripts
for the GUI and command line.

If the script is run with pythonw.exe (rather than python.exe), the user
need never see a console window. However, this does require that the GUI
never writes to stdout/stderr, and that it ensures that those streams are
redirected for any child processes which might do so.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1891#comment:53&gt;
GRASS GIS <http://grass.osgeo.org>