ToGo Applications gnreated under VMWare fail to run

Hi,

I'm trying to rebuild the ToGo executable from an application I built. The
environment is Windows 2000 Professional running under VMWare 4.5.2. Win2k
has all the current patches applied. Dolphin Pro is at patch level 5.1.3.
VMWare is running on Windows XP - all current patches.

I thought something was broken in the startup of my application, and
struggled for some time. Went back to basics to make sure I knew that the
base system was functioning. I created a new Win2k VM -
    * Clean install of Win2k applied all patches,service packs etc.
    * Clean install of Dolphin Pro 5.1
    * Applied dolphin patches up to level 3 => 5.1.3
    * Built the ToGo executable for the Bouncing Balls MVC Sample.

The balls.exe fails to run in apparently the same way as my application.  I
get about 1 sec of hour-glass cursor - then nothing.

Etch-A-Sketch         fails
Calculator                 runs
HelloWorld               runs
NotePad                    runs
PersonalMoney         fails
PlayGround             fails
RegEdit                   runs
Scribble                 fails
fatigue                    wins

Hopefully this pattern indicates what is failing...

Applications I built some time ago on WinXP run ok in the same environment -
but can't build new apps that run.

Any ideas?

--Peter Goodall

On Thu, 23 Dec 2004 05:42:54 +1100,
peterg <[hidden email]> wrote:

> VMWare is running on Windows XP - all current patches.
> ...
> Applications I built some time ago on WinXP run ok in the same environment -
> but can't build new apps that run.

Did the change in behaviour coincide with applying SP2 to your XP
system?

s.

Peter,

Perhaps nothing more than cross-talk in that mass of neurons I call a
brain, take a look at some past discussion of M$ testing tools and their
suboptimal interaction with Dolphin.  IIRC, Blair built a new VM to
compensate for a change in return value from a hooked something or
other.  Maybe VM Ware does something similar, or as Stefan suggests, it
might be an sp2 "feature".

Also, look at the idle loop, use of #keepAlive, and the mode of waiting
on the message queue.  Perhaps something isn't happening when expected,
and some of the apps clobber themselves before they get going.  When
running on the VM Ware win2k, which OS does Dolphin think is in charge?
  NT/2k/xp should have the same basic idle loop (at least at D5.1.4), so
I doubt that is the problem, unless the machine thinks it is running
Win9x.  More likely would be that the WaitFor*() functions don't work
quite as expected.  The suggestions below will help you get to the
bottom of it.

Also, see the recent thread on shutdown; startup is just essentially
shutdown thwarted, so a detailed reading of Chris' post can't hurt.


> Applications I built some time ago on WinXP run ok in the same environment -
> but can't build new apps that run.

While it is not particularly fun, you can use #outputDebugString: and
DebugView from http://www.sysinternals.com/ to see what is happening.
You _might_ need to cr/lf terminate your strings to avoid buffering
problems; make a point of that if you don't see any output.  Then, the
debugging process is much like your printf()-compile-link-run days in C :(

Another option that I have not yet needed to try would be forcing crash
dumps, and using Ghoul to view the output.  If that works, it should be
a lot less tedious and perhaps much more informative too.

Good luck!

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Stefan,

Just to be clear: VMWare is running on XP, I am running Dolphin on Win2K
within VMWare. Dolphin is not running within XP.

Yes XP SP2 was applied but months before I tried rebuilding - so I don't
have a test either side of applying SP2. So I'd have to rate your suggestion
as a possible.

Should XP2 affect the Win2K Guest? I have the latest patches for VMWare,
which allegedy support WinXP Hosts.

--Peter G

----- Original Message -----
From: "Stefan Schmiedl" <[hidden email]>
Newsgroups: comp.lang.smalltalk.dolphin
Sent: Thursday, December 23, 2004 11:05 AM
Subject: Re: ToGo Applications gnreated under VMWare fail to run


> On Thu, 23 Dec 2004 05:42:54 +1100,
> peterg <[hidden email]> wrote:
>
> > VMWare is running on Windows XP - all current patches.
> > ...
> > Applications I built some time ago on WinXP run ok in the same
environment -
> > but can't build new apps that run.
>
> Did the change in behaviour coincide with applying SP2 to your XP
> system?
>
> s.

All the guys that run implement their own session manager.
I implemented one one for BouncingBalls and it ran....

Something missing/not functioning in the default heirarchy

--PG

"peterg" <[hidden email]> wrote in message
news:41c9c00a$0$7078$[hidden email]...
> Hi,
>
[...]
> The balls.exe fails to run in apparently the same way as my application.
I environment -
> but can't build new apps that run.
>
> Any ideas?
>
> --Peter Goodall
>
>

Peter,

> All the guys that run implement their own session manager.
> I implemented one one for BouncingBalls and it ran....
>
> Something missing/not functioning in the default heirarchy

Look at startup/shutdown behavior, but having a unique session manager
for each app strikes me as being almost a requirement anyway.  In fact,
it is a requirement given the way I deploy executables and wrap them
with installers.  Of course, OA might see it differently, in which case
they might have a bug to patch.

What did you write for BouncingBalls?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Bill,

See below, meant to reply sooner - but had some config probs with news
reader...

----- Original Message -----
From: "Bill Schwab" <[hidden email]>
Newsgroups: comp.lang.smalltalk.dolphin
Sent: Thursday, December 23, 2004 12:13 PM
Subject: Re: ToGo Applications gnreated under VMWare fail to run


> Peter,
>
> > I thought something was broken in the startup of my application, and
> > struggled for some time. Went back to basics to make sure I knew that
the
> > base system was functioning. I created a new Win2k VM -
> >     * Clean install of Win2k applied all patches,service packs etc.
> >     * Clean install of Dolphin Pro 5.1
> >     * Applied dolphin patches up to level 3 => 5.1.3
> >     * Built the ToGo executable for the Bouncing Balls MVC Sample.
> >
> > The balls.exe fails to run in apparently the same way as my application.
I
> > get about 1 sec of hour-glass cursor - then nothing.
>
> Perhaps nothing more than cross-talk in that mass of neurons I call a
> brain, take a look at some past discussion of M$ testing tools and their
> suboptimal interaction with Dolphin.  IIRC, Blair built a new VM to
> compensate for a change in return value from a hooked something or
> other.  Maybe VM Ware does something similar, or as Stefan suggests, it
> might be an sp2 "feature".

<sound of brain frying  LOUD >

I ran filemon from SysInternals while my ToGo app was starting. Seemed to
read the image, bind to a bunch of dlls, get to  RichEd20.dll & then do some
sort of
orderly exit - meaning there are no errors. Which perhaps points to
something to do with
some of the things you mention below. I will take a deep breath and
investigate - will take some time.
>
> Also, look at the idle loop, use of #keepAlive, and the mode of waiting
> on the message queue.  Perhaps something isn't happening when expected,
> and some of the apps clobber themselves before they get going.  When
> running on the VM Ware win2k, which OS does Dolphin think is in charge?

VMWare is running Win2K - Its a full-blown install into VMWare, could have
installed Linux or DOS. I'm pretty sure Dolphin can only see Win2K

>   NT/2k/xp should have the same basic idle loop (at least at D5.1.4), so
> I doubt that is the problem, unless the machine thinks it is running
> Win9x.  More likely would be that the WaitFor*() functions don't work
> quite as expected.  The suggestions below will help you get to the
> bottom of it.

Can't try 5.1.4 because source management has changed - won't find my
packages & sees more circular dependencies.

>
> Also, see the recent thread on shutdown; startup is just essentially
> shutdown thwarted, so a detailed reading of Chris' post can't hurt.
>

Hmm  - -perhaps its falling through to shutdown - thanks

>
> > Applications I built some time ago on WinXP run ok in the same
environment -
Thanks, good advice.  #outputDebugString: and Ghoul should get me there...

>
> Good luck!
>
> Bill
>
>
> --
> Wilhelm K. Schwab, Ph.D.
> [hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:cqdf98$15vg$[hidden email]...
My real application has its own ImageStripper and SessionManager, though
these
are not very complicated. I figure that the samples from OA would be an
approriate
test to see that basic mechanisms worked.  There does seem to be something
wrong there.

I'll get to with the debug print etc - should be able to find it. Thanks for
your advice!

>
> What did you write for BouncingBalls?

!BallSessionManager methodsFor!

main
 self mainShellClass show! !
!BallSessionManager categoriesFor: #main!public! !

!BallSessionManager class methodsFor!

mainShellClass
 "Answer the class of the application's main window (a <Shell> presenter).
 This should be overridden by subclasses, and would be a subclass
responsibility
 method if it were not for the need to support instance based deployment."

 ^BouncingBallView
! !

>
> Have a good one,
>
> Bill
>
> --
> Wilhelm K. Schwab, Ph.D.
> [hidden email]

--Peter Goodall

Peter,

Looking at this, one might conclude that the OA samples which do not
have a session manager never create a shell, and would probably shut
down as a result.  Or they might remain in memory.  They are probably
not single-instance apps, so you would have to look rather than error
messages on subsequent runs.

I would confirm or refute the above before doing too much brain frying.

Ok, so what's all this shutdown or maybe remain running stuff?  Chris
did a nice job of describing startup/shutdown.  He might not have
mentioned that the #keepAlive mechanism was hobbled for a while.  IIRC,
OA later fixed it, but not until after I had worked around it, at which
point I was not going to revert because I had changed so much other
stuff, and because "it wasn't broke".

OA's original idea (and perhaps the current reality) was that a COM or
TCP server would be spared the indignity of its host process being
terminated while it was active; ditto for any shells that happened to be
open in the image.  Since users' wishes need to be considered, there was
also the ability to force a shutdown.  However, especially in light of
the Windows style guide (not that I have any respect for such
things<g>), anything that forces the use of a unique shell has design
troubles, hence my preference for the original (current??) behavior.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

peterg wrote:

> > Also, see the recent thread on shutdown; startup is just essentially
> > shutdown thwarted, so a detailed reading of Chris' post can't hurt.
> >
>
> Hmm  - -perhaps its falling through to shutdown - thanks

My /guess/ is that you are falling foul of Dolphin's automatic
shutdown-when-there-are-no-windows-left behaviour activating itself too soon.
You may well need to override SessionManager>>keepAlive as discussed briefly in
the recently 'How to quit an application properly' thread, or check the
archives for keepAlive to find a great deal more discussion of this point.

BTW, there seems to have been a change to the code in this area in patch 5.1.4
(see
    http://www.object-arts.com/Lib/Update/Dolphin/5.1/Professional/PL4.htm
Bug #1451).  Is there any special reason you are avoiding using PL4 ?

    -- chris

Thanks Chris - have been on vacation - hence slow reply.

Got the build to work - a number of small changes - I am not definite as to
which are necessary...

1.)     I had my custom ImageStripper and SessionManager in a separate
'Deployment' package - I moved them into the application's main package
after noticing that the image stripper looks in the deploying package for
the default SessionManager - I had already specified the SessionManager in
the Lagoon wizard.

2.)    I explicitly defined the #defaultSessionManagerClass in my
ImageStripper. (NB my ImageStripper only specifies a single heirarchy of
required classes - nothing else)

3.) Put an explicit #main in my SessionManager - self mainShellClass show.

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
[..]
> Bug #1451).  Is there any special reason you are avoiding using PL4 ?
>
I can't get access to packages to work properly in PL4 - I had an earlier
post on this topic.

The Stripper fails when removing unwanted packages. (also can't access them
after saving from development) . Package manager ignores the path to the
packages & looks for everything in the image directory. Too many freaky
protected blocks to step through. Does the source manager really need to be
this complicated?. Something changed in PL4 that broke all my packages. I
also noticed it rejects some circular dependencies which were not rejected
in previous patch-levels.

>From the deployment report:
"
Removing unwanted packages
'C:\Documents and Settings\Administrator\My
Documents\Dev\ResolvePL4Issues\GenreTool.pak' - The system cannot find the
file specified.
"

Deployment crashes at this point...

The path to this package is actually
'C:\Documents and Settings\Administrator\My
Documents\Dev\ResolvePL4Issues\Objectech\Oasis Data
ClassificationTools\GenreTool.pac'

So 2 levels of directory path have been dropped - In the words of Richard M.
Nixon: 'expletive deleted'.

--Peter Goodall

peterg wrote:

> [all snipped]

To me, this all sounds as if you've got your packages into a screwed state
somehow, and that (some of) your deployment difficulties and the problems you
are experiencing with patch level 4, come down to the same problem.

Also, the steps you've taken to make the app run under VMware don't sound
sufficient to me to avoid the potential problem with Dolphin's automatic
shutdown -- however that was only ever a guess, so maybe the problem was
elsewhere (e.g. something being stripped that shouldn't have been).

Personally, I'd look /hard/ at my packages (both in an inspector and using a
text editor on the .pac files) and find out what was so wrong that it stops PL4
from working correctly.

    -- chris

Thanks Chris, I'll have a look. I'm dreading the time spent. No problems
with save, load and build with previous patch levels. Not convinced that its
something I've done (yet)... Haven't seen complaints from others, so I'll
assume I've got something wrong.

--peter g

> Personally, I'd look /hard/ at my packages (both in an inspector and using
a
> text editor on the .pac files) and find out what was so wrong that it
stops PL4
> from working correctly.
>
>     -- chris
>
>