Converting a Console app to a Windows app - pitfalls to watch out for

I've now seen several articles that discuss converting a Console app to a Windows app without addressing outstanding issues that need to be addressed. I thought this would be a good place to do so.

But first, why did the authors intend to do this? Seems that when starting up a Console app, even if you try to hide the Console window, there is a brief (and annoying) flash.

I suggested the following:







Apparently, there is a warning in the Microsoft docs suggesting to avoid GetConsoleWindow() in that this wont work in future version in Remote Desktop/Terminal Services. 

I would counter that if that's the concern, converting to a Windows app makes things worse because stdin, stdout and stderr are closed, which make the application interaction impossible.

So let's follow this then and see what issues need to be addressed if we pursue this course of action:

1) stdin, stdout and stderr are sent to devnull. This isn't just a question of command line parsing, many console apps act as "filters" (think Unix/Linux type apps like grep). These need to be rewritten to handle input/output.

2) That being said, a Console app allocates a Console window. A Windows app does not, but can attach to one. Important when writing a Console app that interacts with Remote Desktop/Terminal Server.

3) Windows app always start in an STA thread (they have to for the Dispatcher to work). Console apps start in an MTA thread. This matter is Console app create COM objects, as the default behavior would rely on MTA cross-COM calls. Suddenly finding oneself in an STA thread would create opportunities for errors and memory corruption. The COM objects would either need to be converted to run in an STA thread, or would require marshaling code i.e. this becomes a DCOM app which adds a host of complexity.

Even if you don't explicitly create COM object, many OS calls are wrappers around COM objects e.g. Shell services for interacting with the underlying file system which would properly show in the Windows Explorer.

4) Thread creation would by default be MTA, since the foreground is MTA in a Console app. Once changed to a Windows app, these additional threads need to change how communicate to the foreground thread. Same issues apply as in (3).

Can all of this be addressed? Of course, if you, Joe/Jane developer are careful and judicious about the approach. That's what's missing from the article, and should be added to avoid error prone code and apps from be let out into the wild.

My suggestion, however, would be instead to convert the Console application to a Windows Service. In addition to solving this in a best practices approach, it also allows the developer to add fine grained privilege settings as well.

 

Comments

Post a Comment

Popular posts from this blog

Representing C/C++ unions and bitfields in C#

Image
You are a seasoned C++ applications or embedded programmer, and you need to access an integer bitfield as a set of specific bits. You know how to do this: union   myUnion { unsigned   int   info ; struct { unsigned   int   flag1   :   1 ;   // bit 0 unsigned   int   flag2   :   1 ;   // bit 1 unsigned   int   flag3   :   1 ;   // bit 2 unsigned   int   flag4   :   1 ;   // bit 3 unsigned   int   flag5   :   1 ;   // bit 4 unsigned   int   flag6   :   1 ;   // bit 5 // . // . // . unsigned   int   flag31   :   1 ;   // bit 31 }; }; Supposing, however, you are a C#/.NET programmer. What do you do then? There is no provision or direct support in the language to do this. What tools do you have at your disposal? Well, you do have: [ StructLayout ( LayoutKind . Explicit, Size  =   1 , CharSet  =   CharSet . Ansi)] That will give you the ability to control the byte packing. You also have: [ FieldOffset ( x )]             Where: x
Read more

Implementing the try/catch/finally pattern in C++ using lambdas, or why cant this be as easy as it is in C#?

Image
My very first programming 'language' was Z-80 assembler, even before I had learned to program in interpretive BASIC. So you would think I would be used to doing things the hard way, used to pain... =P When I first saw the C language, I fell in love right away. I already had several CPU dialects under my belt, and the idea of pointers was already an easy notion to grasp -- I had already been using VARPTR in BASIC. The idea of a language that was graceful, provided native pointers, language constructs, NO LINE NUMBERS, who could ask for more? Then came C++. Well, not exactly. My first exposure to C++ was via the Glockenspiel "compiler", which was really a glorified C preprocessor. No matter, eventually Borland and Microsoft released C++ compilers, and I never looked back. Until around 2000, when Microsoft released .NET and C#. By this time, we had COM/DCOM, the STL, and boost. Writing custom allocators, IUnknown for custom COM objects, RAII patterns
Read more

Dispatch? I'd like to make a call. The difference between Synchronization Context, Task Scheduler and Dispatcher

Image
I recently had to deal with cleaning up  Dispatcher   based UI update code in a WPF application. I am struck after so many years that like garbage collection (think  IDisposable ) and threading, there still does not exist a clear understanding or explanation of how to marshal across threads, the benefits of using constructs like the  SynchronizationContext  to do so, and what problem(s) it solves. I thought it might be instructive to demonstrate the various techniques available to developers using the WPF framework for illustrative purposes. Keep in mind that the concepts outlined here apply not just in WPF, but anywhere where business logic code meets UI presentation. Given a  Dispatcher  object and the  SynchronizationContext  object, which one should you choose, and what are the compelling reasons for doing so? Note: This post was inspired from an answer I posted on  StackOverflow  to this very question. Perhaps it would help to explain what problem the  SynchronizationCo
Read more