Joseph,
>> redistribtable by the terms of the license. In practice we probably
>> won't be too upset providing your application isn't a derivative
>> devlopment tool that would compete with Dolphin itself.
>
> Sorry, I didn't want to upset you,
I think some of this is a language barrier; Andy's use of "we would not
be upset" could be restated as "we would not object". He is saying that
with a clear understanding of what your program is and does, Object Arts
will consider giving you permission to include in your exe some classes
that are ordinarily not allowed in deployed programs.
They are quite wise to protect themselves from having Dolphin turned
against them, and have always been willing to grant waivers when
appropriate.
> I simply want that my application
> runs. I took the risk to write it, for the company where I work, in
> Dolphin Smalltalk Professional and it doesn't run and I have no way to
> find out what the problem is except doing some black magic with the
> deployment.
I would not characterize it as black magic. It is true that after the
image creates an exe file, puts the stub in it, and then begins tearing
itself apart and diving into the file after the stub (which is pretty
much what happens), one cannot expect the same level of debugging and
browsing that was the norm prior to deployment.
Have you found Ian's news archives and either his search tool or DSDN?
If not, obtain them; they will help you. In this case, you will
probably want to use the global Trace and DebugView (available from
www.sysinternals.com) to add trace messages to bracket the problem, as
it sounds like a startup failure. Also look for the appName.errors file
which frequently contains a lot of good information. Once an exe gets
beyond startup, things can be much easier to diagnose. It will never be
quite as slick as the IDE, but there are ways to get close to it.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]
Locked
