WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

WinBatch
Miscellaneous

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Console Applications with Winbatch

 Keywords: Console App STDOUT Applications Winbatch

Question:

After having used WB for years, I've started, very recently, to dabble in VB (.NET) and one thing that strikes me is how easy it is to create console apps in VB. You don't have to jump through the hoops that you have to jump through in WB - you just say "It's a console app" and it is. In fact, I think it is the default; for what it is worth, I don't know (yet) how to make a WinApp in VB other than by using VisualStudio (which does a lot for you behind your back).

As we all know, it's just not possible to do it in WB; there are several well-known kludges that get you pretty close (e.g., AllocConsole/AttachConsole and conwrap).

So, as a theoretical question, is there any particular reason why WB doesn't support creation of real console apps? Note that this question is theoretical for me at the moment, since I've let my subscription lapse (just nothing new in the last few years that got me very excited). Who knows, this might get me excited again...

Answer:

This comes back down to a discussion of the fundamental differences between scripts written in WIL and natively compiled applications [VB, C++, C#].

WIL is an interpreted scripting language where the language interpreter [the WIL run-time DLL] is being used by a GUI-mode application [WinBatch.exe]. In the case of "compiled" scripts, the .WBT file is effectively tokenized into a .WBC file which is then appended on to the end of a "stub" .EXE file that loads the WIL run-time DLL and tells it to process the embedded .WBC file that is part of the .EXE. At no point does a .WBT file get converted into native machine code instructions, and the same "stub" .EXE code is used regardless of whether WinBatch.exe is running or a "compiled" script is running.

Natively compiled applications written in VB, C++ and C# are built by a compiler that produces an executable file that is built to use either the GUI or console subsystems.

There are some major differences between applications that are written to use the console subsystem vs. the GUI subsystem.

  1. GUI applications have a funtion named WinMain() as their entry-point and have a message queue that receives incoming Windows messages which must be processed in a timely manner. If the main thread of a GUI application gets "busy" and doesn't process messages in a timely manner, the application becomes unresponsive.

  2. Console applications have a main() or wmain() [Unicode] entry-point function and do not have any sort of message queue. The main thread runs exclusively w/o any need to process messages. There is a limited form of asynchronous functionality that can be implemented to handle console control events, such as CTRL+BREAK and CTRL+C.

  3. Native NT services are something of a hybrid between Console and GUI applications. They can be built as either a Console application or a GUI application, but they must be written to poll for and respond to SCM [Service Control Manager] events in a timely manner. Polling for SCM events is analogous to processing the Windows message queue, but different functions are used and there are significantly fewer types of SCM events than their are types of Windows messages. Additionally, SCM events typically require the service to change its state and report the state change back to the SCM, where as Windows messages typically don't require any sort of response to be sent back to the source that sent the message.

  4. Just for completeness, there are also native NT environment programs that do not run on top of Win32... they execute directly on top of the NT kernel. An example would be the build of CHKDSK that is sometimes executed at system boot time after a system crash has occurred. Due to the lack of Win32 support at the time these programs run, there's no possibility of making WinBatch / WIL run in the native NT environment.
With all of that said, there are many parts of WinBatch and the WIL interpreter that are coded with the assumption that the code will execute in the GUI subsystem. Obviously, as the various "hacks" have demonstrated, even GUI applications can create console windows and manipulate them; the inverse is true, too, in that a Console application can start additional threads that create & use GUI windows.

In order for WinBatch and WIL to support running natively as a Console application while executing a script, it would be necessary to find all of the code that depends on being built in GUI mode and altering it to support both GUI and Console mode. This support would have to be implemented as a combination of several things, including building the scripting host [e.g. WinBatch.exe] such that it has 2 different .EXE files... one for the GUI subsystem and one for the Console subsystem. There may be other things necessary such as conditionally-compiled code that varies between the GUI and Console builds of the scripting host, as well as other code that may be selectively executed at run-time based on which subsystem the .EXE is running in.

Both GUI and Console applications run on top of Win32, so there's no technical reason that WinBatch & WIL couldn't be modified to support running in both GUI and Console modes. For the most part, it would simply take expending time & resources to complete the analysis, re-design and refactoring of code that would be required to implement. However, the cost of the development effort may not be offset by a ROI to justify making this a business priority. 

Article ID:   W17975

Filename:   Console Applications with Winbatch.txt
File Created: 2009:05:07:12:11:10
Last Updated: 2009:05:07:12:11:10