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. |
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. |
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. > |
In reply to this post by Ben Coman
Hi Torsten,
On Fri, Mar 10, 2017 at 7:40 AM, Ben Coman <[hidden email]> wrote:
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).
_,,,^..^,,,_ best, Eliot |
Free forum by Nabble | Edit this page |