Stop an .exe?

Is there a command to stop an .exe something like a self halt except
without walkback?  This could be useful for exiting loops like the
"show" command from within the program instead of requiring the user to
exit the window.

The halt command goes to a ProcessorScheduler.  Would it be better to
send a interruptWith: its killInterrupt 9 or kill: whatever?

The real thing I need is for the loop to actually let go of its files
so another .exe can look.  Is there any way to do that without
terminating the Dolphin .exe?  A file close doesn't seem to do that -
maybe it does it at a file buffer level but not the OS level.

Knowledgable comments please...

Thanks,
Kirk Fraser

Kirk,

> Is there a command to stop an .exe something like a self halt except
> without walkback?  This could be useful for exiting loops like the
> "show" command from within the program instead of requiring the user to
> exit the window.

Do you mean in the development environment or a deployed application?

In the development environment the Ctrl-Break can usually get out of a
loop.  In a deployed application you can close the top level shell by
sending it a #close message (or is it #exit?).

> The real thing I need is for the loop to actually let go of its files
> so another .exe can look.  Is there any way to do that without
> terminating the Dolphin .exe?  A file close doesn't seem to do that -
> maybe it does it at a file buffer level but not the OS level.

Closing a FileStream seems to close the File straight away, at least in
the simple tests I've just done i.e. create a text file, write to it and
the close it in a Dolphin workspace - I can immediately open the file
using NotePad.

I think there are situations where Windows might be doing a bit of
buffering and make a saved file unavailable for a short length of time
but I don't know the details.  Opening/closing a dll is also a bit
problematic as Windows does (did?) buffer those - perhaps it does the
same to exe files <shrug>.

FWIW, the only problem in this area that I can recall is when I update
the files properties (author etc) before closing the file.  I have to
insert a delay of a couple of seconds between closing the file and
attempting to update the properties.


--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Thank you Ian.  I'm still working on trying to get a Dolphin .exe to
communicate with a VB .exe using file polling.  The VB side seems to
release files for Dolphin to access  but not the other way around -- at
least not within milliseconds.

Based on your advice I'll try both shutting down the .exe and putting
in a delay after the file close.  Both of those will slow down an
animation.  I guess I could also try a delay within a seperate file
handling process.

Ian,

Exit is the correct shell command but whew it sure is slooww.  It
terminates the screen display fast enough but the calling .exe takes a
long time to regain control from the Dolpin .exe compared to a VB .exe
in the same task.  This was shown by calling it twice within the
VB.exe.  The good news is the correct answer was delivered back to the
caller via file polling and I didn't have to add any delays.  Any
suggestions on how to speed it up -- i.e. speeding up the Dolphin .exe
termination?  Thanks.

Kirk

Ian,

Since you were interested in testing...

> Closing a FileStream seems to close the File straight away, at least in the simple tests I've just done i.e. create a text file, write to it and the close it in a Dolphin workspace - I can immediately open the file using NotePad.

...I can send you a set of files that prove Dolphin has a problem in
this area if you want.  Comparing the speed of completing an automated
call to a Dolphin .exe which does file polling in a few minutes to a
vb.exe which does it in milliseconds should be more enlightening than
manual testing in the development environment.

Kirk

Overcomer,

Before I start, you are going about this the wrong way. You should not
be using file polling to communicate between two running EXEs. It is
the sort of thing that people did back in the 1980s when DOS didn't
have any interprocess communication facilities. What you should be
doing is using sockets. Both VB and Dolphin have perfectly adequate
socket facilities so why don't you use them?

> Is there a command to stop an .exe something like a self halt except
> without walkback?  This could be useful for exiting loops like the
> "show" command from within the program instead of requiring the user
> to exit the window.
> The halt command goes to a ProcessorScheduler.  Would it be better to
> send a interruptWith: its killInterrupt 9 or kill: whatever?

I don't understand any of this. What is this "show" command that starts
a loop requiring the user to exit a window?

> The real thing I need is for the loop to actually let go of its files
> so another .exe can look.  Is there any way to do that without
> terminating the Dolphin .exe?  A file close doesn't seem to do that -
> maybe it does it at a file buffer level but not the OS level.

Have you actually taken a look at what File>>close does?

File>>close
        self free; beUnfinalizable

File>>free
        handle notNull
                ifTrue: [self basicFree]

File>>basicFree
        | fh |
        fh := handle.
        self handle: nil.
        (KernelLibrary default closeHandle: fh) ifFalse: [self

KernelLibrary>>closeHandle: aHandle
        <stdcall: bool CloseHandle handle>
        ^self invalidCall

So, close calls free, calls basicFree, calls closedHandle: which then
calls the Windows CloseHandle API. Dolphin does not do pre-emptive
scheduling so no process switches will be happening during the
sequence. Hence, unless the Dolphin message sending suddenly decides to
slowdown during this period the time between your calling File>>close
and Dolphin calling out to the Windows API will be microseconds. If
there is a problem with close not releasing file handles (which,
frankly, I doubt) then I suspect you may have to talk to Microsoft
about it.

Regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Overcomer,

> Exit is the correct shell command but whew it sure is slooww.  It
> terminates the screen display fast enough but the calling .exe takes a
> long time to regain control from the Dolpin .exe compared to a VB .exe
> in the same task.  This was shown by calling it twice within the
> VB.exe.  The good news is the correct answer was delivered back to the
> caller via file polling and I didn't have to add any delays.  Any
> suggestions on how to speed it up -- i.e. speeding up the Dolphin .exe
> termination?  Thanks.

Sounds like more FUD to me. The correct way to terminate an EXE is to
call:

SessionManager current exit

or if you really want to get out quickly:

SessionManager current quit

Regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Overcomer,

I very much doubt it. Since running a Dolphin EXE is virtually
identical to running an image within the development environment it
would be much better to test it in the latter where you have tools
available to do a thorough investigation. Why don't you post some
source (a workspace or package file) to the newsgroup that illustrates
how Dolphin is the thousands of time slower than VB at file polling
that you say it is?

Regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> I don't understand any of this. What is this "show" command that starts
a loop requiring the user to exit a window?

The "show" command is what starts anything under Presenter such as your
example EtchASketch and under Shell such as Calculator.

> Have you actually taken a look at what File>>close does?

In the past when attempting to write an OODB, yes.  The actions within
Smalltalk may be brief enough but the actions of the Dolphin virtual
machine (VM) which communicate with the OS may not be sufficient
requiring the OS to make assumptions -- they are invisible to
inspection.  Thus my earlier suggestion that you rewrite the VM in VB
is still good, to insure you are doing everything in it upto the state
of the art.

Sincerely,
Kirk Fraser

Andy,

> Why don't you post some source (a workspace or package file) to the newsgroup that illustrates how Dolphin is the thousands of time slower than VB at file polling
that you say it is?

File polling requires communication between two programs seperated by
the OS.  Within Dolpin, the OS can buffer files and may not write
anything to disk until after the end of the program, giving the
benefits of cache over many opens and closes of the same file name.
This is very advanced to expect of Microsoft but I can't explain
Smalltalk's file behavior (actual behavior) as opposed to visible
programming any other way.

So to create a sample fully within Dolpin I think would require
creating at least one Dolphin .exe and then calling it in a loop from a
workspace.  But to demonstrate the slowness compared to VB, requires
calling both a VB .exe and a Dolphin .exe for comparison.  What I
offered Ian is my actual application but for general posting I'd have
to rewrite the Dolphin code which could be posted here but the VB.exe
cannot as far as I know how.  Still if you think it of value, tell me
and I'll work on it and I'll upload the VB.exe to a website.

Sincerely,
Kirk Fraser

Andy,

What is "FUD"?

Thanks for the correct way to terminate an .EXE, that solved the speed
problem.

Sincerely,
Kirk Fraser

Andy,

I guess I should have answered top down instead of bottom up on this
thread.  Anyway, thanks again for the speedy .exe exit help.

The reason I'm currently trying to use polling instead of sockets is
mainly I have a contractor doing the VB and polling was his choice.  I
have to be flexible to get work done at my pitifully low ability to
pay.  I wanted to stay in Dolphin but the very smart remote programmer
I have insisted on VB and I needed to get my new language developed.
I'm now certian it was the best choice at the time since LogicTalk was
developed far beyond my request and your tip makes it feasible to
continue my GUI work in Dolphin, at least until I really need sockets
to communicate without exiting.

Sincerely,
Kirk Fraser

Overcomer,

> What is "FUD"?

"Fear, Uncertainty And Doubt". People who engage in FUD cast aspersions
on (usually) software indicating that it is deficient in some way
without having hard proof that this is the case.

--
Andy Bower
Dolphin Support
www.object-arts.com

Overcomer,

> The actions within
> Smalltalk may be brief enough but the actions of the Dolphin virtual
> machine (VM) which communicate with the OS may not be sufficient
> requiring the OS to make assumptions -- they are invisible to
> inspection.  Thus my earlier suggestion that you rewrite the VM in VB
> is still good, to insure you are doing everything in it upto the state
> of the art.

FUD and, what's more, nonsense. The VM is currently written in a
combination of Microsoft C++ and Microsoft assembler. I can tell you
right now that if we rewrote it in VB then all your tests would go at
least 1000x slower. In a previous thread you wrote:

---/nonsense-on
"I have to appologize (sic) in advance since this suggestion is kind of
counter-intuitive but since you wrote the .dll I proposed won't work
and there have been other occasional problems communicating with the OS
and other languages, here it is.

Since Dolphin is committed to Windows platforms, I suggest the hidden
components of Dolphin (perhaps only the StdCall primitive and the like)
be written in Visual Basic, which has the intimacy with Windows which
Dolphin currently doesn't quite have, judging by the .dll problem.  It
is also likely VB will maintain that intimacy.  VC++ may also."
---/nonsense-off

There is no DLL problem. It was a design choice not to make Dolphin
deploy to C-style function DLLs. A DLL function call has to run on the
thread of the caller. The Dolphin VM works in a separate process and
would need parameter marshalling to move arguments from the calling
thread/process and to return results back again. COM provides this
marshalling automatically which is why we can support this method of
DLL function calling.

In short, we could no doubt do it if we wanted to but we don't believe
that the effort involved would justify the gain. It is nothing to do
with any level of intimacy between the language the Dolphin VM is
written in and the Windows OS.

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

More of the same then.  I remember years ago (perhaps when D98 was new)
you wrote against supplying a Dolphin which creates an .exe.  I
patiently waited and behold, you now have done it. (I didn't buy until
you did.)  More recently when you released D5 you wrote you wouldn't be
updating your documentation and now you say you are (for D6).  So
judging by your past design decisions and improvements thereto, perhaps
someday you'll get around to fixing your choice on .DLL's.

Based on lessons learned on other forums, I think FUD is fine.
1) It creates attention for a problem that others who can help may not
answer without it.
2) It directs negative attention to the software instead of the
designer.
3) Directing negativity toward the man or his decisions can get one
tossed off moderated newsgroups. In a case in the archives of this
newsgroup around when I was complaining about insufficient
documentation, a request by the other designer that I go away.

It would be nice if people had no need for FUD but as long as
personalities are fragile, I think FUD will remain a way of dealing
with them.  To everyone interested in strengthening your personality
beyond need for FUD, I suggest going to a church where everyone is
expected to speak instead of a lecture-format church.  

Kirk

Overcomer,

> More of the same then.  I remember years ago (perhaps when D98 was
> new) you wrote against supplying a Dolphin which creates an .exe.  I
> patiently waited and behold, you now have done it. (I didn't buy until
> you did.)  More recently when you released D5 you wrote you wouldn't
> be updating your documentation and now you say you are (for D6).  So
> judging by your past design decisions and improvements thereto,
> perhaps someday you'll get around to fixing your choice on .DLL's.

More nonsense:

Your first appearence in the newsgroup was in September 1998 on the
topic of DLL parameters. You don't mention EXEs util 9th June 1999.

You said:

> 3) Add a more expensive commercial product such as a $99 version which
> does full .exe and .dll generation like apparenlty MT does for much
> more.

I said: "The $129.95 Application Deployment Kit (ADK) is effectively our
"professional development" option. At present this only allows for EXE
generation but we hope to be able to provide DLL facilities in future."

So I never wrote against supplying a Dolphin that would create an EXE,
in fact, I just said that we already had one.

More recent nonsense:

In November 1999 in a thread entitled "Education Centre for Dolphin 5"
I wrote:

"Given my stance about method comments, I don't think anyone (including
myself and possibly even Beck) would disagree that having full
help/printed documentation/class comments/method comment *would* be
desirable if there was no associated cost.  However, the cost of this
stuff is high; not just in the writing but in the maintenance of it.
It's like static typing. sometimes it can be useful but the costs (in
writing/maintenance/flexibility)are just too onerous".

Also in that same thread I wrote:

"Currently, we are struggling with the formatting of the help produced
by the Doc2Help documentation tool that we use. However, apart from one
new section on COM and some descriptions of the new tools (like the
System Browser and Flipper) the new documentation is pretty much like
the old version 4 stuff."

So, far from saying there would be no future document updates, I
actually said we were working on them although the process was time
consuming and high cost.

> Based on lessons learned on other forums, I think FUD is fine.
> 1) It creates attention for a problem that others who can help may not
> answer without it.

That is true. But you are less likely to get a helpful answer. If you
persistently deal in FUD you are less likely to get any answer at all.
You (in your various guises as Kirk Fraser, True Christian and now
Overcomer) have already alienated and been spam-binned by a significant
number of readers of this newsgroup.

> 2) It directs negative attention to the software instead of the
> designer.

Well, I can tell you that the designers of Dolphin Smalltalk are
passionate enough about it to intensely dislike negative comments about
it that have no grounding in truth (FUD), Also, I think you'll find
that FUD actually directs negative attention towards the purveyor.

> 3) Directing negativity toward the man or his decisions can get one
> tossed off moderated newsgroups. In a case in the archives of this
> newsgroup around when I was complaining about insufficient
> documentation, a request by the other designer that I go away.

I now second that request.

> It would be nice if people had no need for FUD but as long as
> personalities are fragile, I think FUD will remain a way of dealing
> with them.  To everyone interested in strengthening your personality
> beyond need for FUD, I suggest going to a church where everyone is
> expected to speak instead of a lecture-format church.  

Certainly, if you think your personality could be strengthened beyond
the need for FUD, then I think you should go to such a church. Why not
try it and return when you think you can conduct a reasoned and
constructive discussion?

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy, Andy, Andy,

Actually it's you who has the problem with requiring FUD from users in
order to answer questions.  Note even in this thread, you did not
answer my first plain reasonable request until a lot of FUD developed.
Ian supplied an answer which worked but not well.  Then I had to pile
on the FUD before you supplied the best answer.  A decent set of
documentation would help end this problem.  Face it, you have been lazy
and FUD helps motivate you, often in the correct direction -- since you
hate it, FUD helps you express truth.  I didn't want to say this
directly as it is offensive but your above remarks require being direct
now instead of supplying more FUD.  It would be more reasoned and
constructive to help you overcome your laziness in making the software
easy to comprehend so fewer help requests are needed than to blame the
software which cannot improve itself.

I obviously don't know as much as you about Dolphin but I know far more
than many about church.  I repeat my suggestion that you find a church
which requires the audience to speak so you can learn to overcome your
weak personal attributes which caused you to ignore my first post in
this thread and those of many other users until FUD piles up. And I
reiterate that suggestion for the weaker still who you say have been
alienated and spam-binned me.  It is the perfect solution or near to it
as available today.

As for me, I have overcome the FUD -- I don't need to use it as seen in
this post, and will eventually have a language that is easier thus more
productive than Smalltalk, some of which will be in the form of a
Dolphin .exe for now -- then everything in the language will be
something I easily understand.

There has been another occasion when I blamed the designer for not
doing his job every time Dolphin presented undocumented bad behavior to
me by not accepting packages.  I was not given help on that but
eventually learned my way around them on my own, mostly by reloading
Dolphin as needed and not generating packages that caused conflicts,
and carefully checking for the best code when there are conflicts.  On
this thread I found FUD more productive than that direct reasoned and
constructive approach which resulted in no help. Next time only God
knows for sure.

Kirk Fraser

Kirk, Kirk, Kirk,

> Face it, you have been
> lazy and FUD helps motivate you, often in the correct direction --
> since you hate it, FUD helps you express truth.  I didn't want to say
> this directly as it is offensive but your above remarks require being
> direct now instead of supplying more FUD.  

True, you have been offensive; not just in this correspondence but in
virtually every thread you've entered into on this newsgroup. But then
trolls often are offensive because, as you say, it's the easiest way of
engendering a response.

> It would be more reasoned
> and constructive to help you overcome your laziness in making the
> software easy to comprehend so fewer help requests are needed than to
> blame the software which cannot improve itself.

Ah, now I Have Seen The Light. Henceforth, I resolve to improve myself
by refraining from troll baiting and return to the job in hand which
(as it happens) is finishing off the documentatiopn for D6. Following
that, I will probably return to my lassitude but, either way, you will
not be receiving any more replies from me on this newsgroup.

Is that a win for FUD tactics or not? You tell me.

Regards

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy Bower wrote:
> that, I will probably return to my lassitude but, either way, you will
> not be receiving any more replies from me on this newsgroup.
I assume you'll not be the only one ....

CU,

Udo

> Knowledgable comments please...

Here is my knowledgable comment:

It's time for you to find a new alias fella.