UI VM vs. Consol VM on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

UI VM vs. Consol VM on Windows

Torsten Bergmann
 
Hi,

for the virtual machine on Windows we have a UI VM and a headless console version. For instance "Squeak.exe"/"Pharo.exe"/... (UI VM) and
"SqueakConsole.exe"/"PharoConsole.exe"/... (Console version to access stdin, stdout and stderr)
 
IMHO there is no need for a separate and special console version on Windows. Maybe it was the easiest/quickest way to implement this
but usually one should be able to access/create and redirect the std handles even in a UI application. See
 
http://dslweb.nwnexus.com/~ast/dload/guicon.htm

for a start. Maybe it is possible to get rid of a separate "XXXConsole.exe" version so the VM on Windows behaves like on other platforms.
Maybe that als unifies/eases the build.

Side note:
Maybe there is also a difference when you start an executable with Explorer (double click) where you might need to create a new console vs.
starting the executable from an already existing console command line (where it might be possible to catch an existing handle). But this
could be evaluated with a simple C executable and (if working) transformed to the Open Smalltalk virtual machine.

Bye
T.
Reply | Threaded
Open this post in threaded view
|

Re: UI VM vs. Consol VM on Windows

Ben Coman
 
On Fri, Mar 10, 2017 at 10:49 PM, Torsten Bergmann <[hidden email]> wrote:

>
> Hi,
>
> for the virtual machine on Windows we have a UI VM and a headless console version. For instance "Squeak.exe"/"Pharo.exe"/... (UI VM) and
> "SqueakConsole.exe"/"PharoConsole.exe"/... (Console version to access stdin, stdout and stderr)
>
> IMHO there is no need for a separate and special console version on Windows. Maybe it was the easiest/quickest way to implement this
> but usually one should be able to access/create and redirect the std handles even in a UI application. See
>
> http://dslweb.nwnexus.com/~ast/dload/guicon.htm

As I understand that article, to get stdio from a GUI app you'll be
popping up that awful black window on screen...
"its possible for your GUI application to
explicitly create a  **console window**
and then manually associate standard C I/O handles (FILE*) with the
appropriate Win32 handles"

The following dance might be more what you're looking for...
"How to make an application as both GUI and Console application?"
https://blogs.msdn.microsoft.com/junfeng/2004/02/06/how-to-make-an-application-as-both-gui-and-console-application/


btw, I found these interesting...

"What’s the difference between the COM and EXE extensions?"
https://blogs.msdn.microsoft.com/oldnewthing/20080324-00/?p=23033

"Difference between .com program and .exe program in c programming language"
http://www.cquestions.com/2011/02/difference-between-com-program-and-exe.html

cheers -ben

>
> for a start. Maybe it is possible to get rid of a separate "XXXConsole.exe" version so the VM on Windows behaves like on other platforms.
> Maybe that als unifies/eases the build.
>
> Side note:
> Maybe there is also a difference when you start an executable with Explorer (double click) where you might need to create a new console vs.
> starting the executable from an already existing console command line (where it might be possible to catch an existing handle). But this
> could be evaluated with a simple C executable and (if working) transformed to the Open Smalltalk virtual machine.
>
> Bye
> T.
Reply | Threaded
Open this post in threaded view
|

Re: UI VM vs. Consol VM on Windows

David T. Lewis
 
If I understand what Ben is saying about opening a console window, then
"OSProcess thisOSProcess openConsole" might be doing what you want,
implemented with <primitive: 'primitiveAllocConsole' module:
'Win32OSProcessPlugin'>

I don't know if it still works though, I have not checked it recently.

Date

>
> On Fri, Mar 10, 2017 at 10:49 PM, Torsten Bergmann <[hidden email]> wrote:
>>
>> Hi,
>>
>> for the virtual machine on Windows we have a UI VM and a headless
>> console version. For instance "Squeak.exe"/"Pharo.exe"/... (UI VM) and
>> "SqueakConsole.exe"/"PharoConsole.exe"/... (Console version to access
>> stdin, stdout and stderr)
>>
>> IMHO there is no need for a separate and special console version on
>> Windows. Maybe it was the easiest/quickest way to implement this
>> but usually one should be able to access/create and redirect the std
>> handles even in a UI application. See
>>
>> http://dslweb.nwnexus.com/~ast/dload/guicon.htm
>
> As I understand that article, to get stdio from a GUI app you'll be
> popping up that awful black window on screen...
> "its possible for your GUI application to
> explicitly create a  **console window**
> and then manually associate standard C I/O handles (FILE*) with the
> appropriate Win32 handles"
>
> The following dance might be more what you're looking for...
> "How to make an application as both GUI and Console application?"
> https://blogs.msdn.microsoft.com/junfeng/2004/02/06/how-to-make-an-application-as-both-gui-and-console-application/
>
>
> btw, I found these interesting...
>
> "What’s the difference between the COM and EXE extensions?"
> https://blogs.msdn.microsoft.com/oldnewthing/20080324-00/?p=23033
>
> "Difference between .com program and .exe program in c programming
> language"
> http://www.cquestions.com/2011/02/difference-between-com-program-and-exe.html
>
> cheers -ben
>
>>
>> for a start. Maybe it is possible to get rid of a separate
>> "XXXConsole.exe" version so the VM on Windows behaves like on other
>> platforms.
>> Maybe that als unifies/eases the build.
>>
>> Side note:
>> Maybe there is also a difference when you start an executable with
>> Explorer (double click) where you might need to create a new console vs.
>> starting the executable from an already existing console command line
>> (where it might be possible to catch an existing handle). But this
>> could be evaluated with a simple C executable and (if working)
>> transformed to the Open Smalltalk virtual machine.
>>
>> Bye
>> T.
>


Reply | Threaded
Open this post in threaded view
|

Re: UI VM vs. Consol VM on Windows

Eliot Miranda-2
In reply to this post by Ben Coman
 
Hi Torsten,

On Fri, Mar 10, 2017 at 7:40 AM, Ben Coman <[hidden email]> wrote:

On Fri, Mar 10, 2017 at 10:49 PM, Torsten Bergmann <[hidden email]> wrote:
>
> Hi,
>
> for the virtual machine on Windows we have a UI VM and a headless console version. For instance "Squeak.exe"/"Pharo.exe"/... (UI VM) and
> "SqueakConsole.exe"/"PharoConsole.exe"/... (Console version to access stdin, stdout and stderr)
>
> IMHO there is no need for a separate and special console version on Windows. Maybe it was the easiest/quickest way to implement this
> but usually one should be able to access/create and redirect the std handles even in a UI application. See
>
> http://dslweb.nwnexus.com/~ast/dload/guicon.htm

As I understand that article, to get stdio from a GUI app you'll be
popping up that awful black window on screen...
"its possible for your GUI application to
explicitly create a  **console window**
and then manually associate standard C I/O handles (FILE*) with the
appropriate Win32 handles"

The following dance might be more what you're looking for...
"How to make an application as both GUI and Console application?"
https://blogs.msdn.microsoft.com/junfeng/2004/02/06/how-to-make-an-application-as-both-gui-and-console-application/


btw, I found these interesting...

"What’s the difference between the COM and EXE extensions?"
https://blogs.msdn.microsoft.com/oldnewthing/20080324-00/?p=23033

"Difference between .com program and .exe program in c programming language"
http://www.cquestions.com/2011/02/difference-between-com-program-and-exe.html

Ben is quite right (as usual).  Remember the use case is piping input to and output from the VM.  e.g.

   > PharoConsole.exe PharoCommand.image <input.txt >output.txt
   > foo.exe | PharoConsole.exe PharoCommand.image | bar.exe


This *does not work* for a GUI app.  So yes, we do need the separate versions.  Now, one *can* reduce the overhead by packaging the VM proper as a DLL and loading it into two very small Pharo,exe and PharoConsole.exe programs (as was done with VisualWorks), but the need for two separate programs remains and is "baked into" the "design" of Windows(tm).



cheers -ben

>
> for a start. Maybe it is possible to get rid of a separate "XXXConsole.exe" version so the VM on Windows behaves like on other platforms.
> Maybe that als unifies/eases the build.
>
> Side note:
> Maybe there is also a difference when you start an executable with Explorer (double click) where you might need to create a new console vs.
> starting the executable from an already existing console command line (where it might be possible to catch an existing handle). But this
> could be evaluated with a simple C executable and (if working) transformed to the Open Smalltalk virtual machine.
>
> Bye
> T.



--
_,,,^..^,,,_
best, Eliot