Console app + networking: a suggestion

Hi,

A problem, a hack to solve it, and a suggestion for a better solution:

I've been having difficulty making a deployed console app that uses simple
TCP/IP streams.

The app just sends some data to a server, waits for the response, and prints it
out.  I have a GUI version of the app that works pretty-much OK, but the
console version failed to open the socket -- or rather it failed to create
WinAsynchSocket>>default as part of SocketAbstract>>allowAsyncEvents called
from #connect.

My first thought was that it needed the "normal" windows event loop running (as
Blair has said in the past), so I did a #forkMainIfMain, but that didn't help.
So I also explicitly sent #onStartup to WinAsynchSocket as part of my startup
(before #forkMainIfMain), but that didn't help either.

I still have no idea how to do asynch processing on a socket in a command-line
app, but I realised I didn't need it for this application, so I tried a
different tack.  There's no easy way of turning off the call to
SocketAbstract>>allowAsyncEvents as the socket is connected (especially as the
part of my code that handles the socket stuff doesn't know it's in a deployed
app at all, let alone that it's a console app) so I hacked it.  I just put:
    "turn off ability to do asynch socket ops"
    SocketAbstract basicCompile: 'allowAsyncEvents'
into the #preStripScript for the image stripper.  That's a shocking hack, I'll
admit, but it does work.  It removes the attempt to allow asynch ops on any
socket in that deployed application.

So my little app now works fine.

However there should be a less hacky way of making sockets aware of their
context.  I suggest doing a double-dispatch during Socket connection, something
like having the socket send:
    SessionManager current onSocketConnected: self.
which would be implemented (by default) to send back #allowAsyncEvents by
GUISessionManagers and be ignored by ConsoleSessionManagers.

BTW, does anyone know how to allow asynch processing in a Console app ?  As I
said I, couldn't get it to work, but even if I had been able to initialise a
WinAsynchSocket properly, it seems to be using DesktopView>>current which
sounds dodgy for an application that might be invoked via Telnet for instance.

    -- chris

Chris,

> A problem, a hack to solve it, and a suggestion for a better solution:
>
> I've been having difficulty making a deployed console app that uses simple
> TCP/IP streams.

<lots of hacky stuff snipped>

Just for your info, we have added another Sockets library to D6 (the old one
is still present though) that makes use of overlapped calls and dispenses
with all of the asynchronous window nonsense.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Andy,

> Just for your info, we have added another Sockets library to D6 (the
> old one is still present though) that makes use of overlapped calls
> and dispenses with all of the asynchronous window nonsense.

Yea!

<salivates>

    -- chris

"Andy Bower" <[hidden email]> wrote in message
news:3ee62bd2$[hidden email]...
> Chris,
>
> > A problem, a hack to solve it, and a suggestion for a better solution:
> >
> > I've been having difficulty making a deployed console app that uses
simple
> > TCP/IP streams.
>
> <lots of hacky stuff snipped>
>
> Just for your info, we have added another Sockets library to D6 (the old
one
> is still present though) that makes use of overlapped calls and dispenses
> with all of the asynchronous window nonsense.

I should just add that Dolphin console apps are true console applications in
the sense that they are marked as such as far as Windows is concerned - yes
for some inexplicable reason Windows differentiates between GUI and Console
applications.

Since .exe's are explicitly marked as one thing or the other, it is quite
likely that a lot of GUI stuff won't work properly in console applications.
As Dolphin's current socket library is based on the asynchronous sockets
that use hidden windows to implement the notification mechanism, it may well
be that they will not work in a console application.

Of course you can always build a GUI application that to all intents and
purposes appears to be a console application by (a) not opening any windows,
and (b) using the standard I/O streams, which a Dolphin GUI application can
also do.

    SessionManager current stdout nextPutAll: 'Hmmm, I didn''t know it could
do that'; cr; flush

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:bc7oks$fagb2$[hidden email]...
> for some inexplicable reason Windows differentiates between GUI and
Console
> applications.

I've experimented with this distinction a bit, and as far as I can tell the
main difference is how the console input/output functions work.

A console application always launches with a console (what we used to call a
"DOS box") attached.  If you launch it from the explorer, Windows creates a
new console for it.  If you launch it from a command line in an existing
console, the application uses that console, and the console won't present
the next command prompt until the program exits.

A GUI application won't have a console unless it creates one explicitly.  If
you launch it from a command line, the console presents the next command
prompt immediately, allowing the program to run independently.

Both console and GUI applications can create windows and have GUIs and event
loops and all that.  GUI apps cannot use console I/O functions unless they
create a console explicitly.  And GUI apps cannot do I/O using the standard
input and output handles unless you redirect them.

It's easy to change a .exe file from a console app to a GUI app or vice
versa, using a utility such as EDITBIN which comes with Visual C++.

> Since .exe's are explicitly marked as one thing or the other, it is quite
> likely that a lot of GUI stuff won't work properly in console
applications.

This hasn't been a problem in my experience.  (My experience with this
involves languages other than Dolphin ST though, so I'm only speaking of the
basic Windows characteristics.)

> Of course you can always build a GUI application that to all intents and
> purposes appears to be a console application by (a) not opening any
windows,
> and (b) using the standard I/O streams, which a Dolphin GUI application
can
> also do.

But then your application won't have a console attached when it runs.  If
you try to use the standard I/O streams, Windows will report an error,
unless you've redirected them.  (But again, I don't know how this works in
Dolphin specifically.)

"Harry Chomsky" <[hidden email]> wrote in message
news:[hidden email]...
Dolphin will automatically open a console, hence my statement that Dolphin
GUI apps can also use standard I/O streams, and the inclusion of an
expression to evaluate in a workspace to demonstrates this.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:bc9bg0$gn5fa$[hidden email]...
> Dolphin will automatically open a console, hence my statement that Dolphin
> GUI apps can also use standard I/O streams, and the inclusion of an
> expression to evaluate in a workspace to demonstrates this.

OK, that makes sense.  Then I guess the only difference you'd see between
this kind of application and a "real" console application is the behavior if
you run them from a command prompt.  The Dolphin GUI app will open a new
console, allowing the original console to display its next command prompt
immediately.  The "real" console app will use the existing console and delay
the next prompt until the program exits.