By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,874 Members | 1,058 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,874 IT Pros & Developers. It's quick & easy.

WIN32 Windows Application Outputting to Command Prompt as if a Console Program - How?

P: n/a
Hi,

I am writting a windows application that I want to be able to act as if
it where a Console application in certain circumstances, such as error
logging.

Whilst I have nearly got it, it doesn't seem to write to the screen in
the way I would expect.

The output is:

C:\>Test.exe

C:\>Outputting Line 1
Outputting Line 2
Outputting Line 3
Outputting Line 4
Outputting Line 5
Outputting Line 6
Outputting Line 7
Outputting Line 8
Outputting Line 9
Outputting Line 10

Instead of:

C:\>Test.exe
Outputting Line 1
Outputting Line 2
Outputting Line 3
Outputting Line 4
Outputting Line 5
Outputting Line 6
Outputting Line 7
Outputting Line 8
Outputting Line 9
Outputting Line 10

C:\>

Code is as follows:

#include <Tlhelp32.h>
#include <cstdio>
#include <io.h>
#include <fcntl.h>
#include <iostream>
#include <ios>

BOOL RedirectIOToConsole(DWORD dwParent)
{
int hConHandle;
long lStdHandle;
FILE *fp;

// allocate a console for this app
BOOL bRet = AttachConsole(dwParent);
if (!bRet)
return bRet;

// redirect unbuffered STDOUT to the console
lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "w");

*stdout = *fp;
setvbuf(stdout, NULL, _IONBF, 0);

// redirect unbuffered STDIN to the console
lStdHandle = (long)GetStdHandle(STD_INPUT_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "r");
*stdin = *fp;
setvbuf(stdin, NULL, _IONBF, 0);

// redirect unbuffered STDERR to the console
lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "w");
*stderr = *fp;
setvbuf(stderr, NULL, _IONBF, 0);

// make cout, wcout, cin, wcin, wcerr, cerr, wclog and clog
// point to console as well
ios::sync_with_stdio();
return bRet;
}

int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);

// TODO: Place code here.
HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0
);
wchar_t buffer[2000+1] = { '\0' };
DWORD dwCallingProcessID = 0UL;
if (hSnapshot != (HANDLE)-1)
{
PROCESSENTRY32 pe;
pe.dwSize = sizeof(pe);
if (Process32First(hSnapshot, &pe))
{
DWORD MyPID = GetCurrentProcessId();
do
{
if (pe.th32ProcessID == MyPID)
{
dwCallingProcessID = pe.th32ParentProcessID;

if (RedirectIOToConsole
(pe.th32ParentProcessID))
{
//cerr << "Failed";
for (int i = 0;i < 10;i++)
printf("Outputting Line %d\n",i+1);

}
else
{
MessageBox(NULL,L"Failed",L"Attaching
Console",MB_ICONERROR);
}
}
} while (Process32Next( hSnapshot, &pe ));
}
CloseHandle(hSnapshot);
}
return 0;//Other code snipped for brevity
}
Jun 20 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"Peter Nimmo" <Pe********@newsgroups.nospamwrote in message
news:Xn**********************************@127.0.0. 1...
I am writting a windows application that I want to be able to act as if
Whilst I have nearly got it, it doesn't seem to write to the screen in
the way I would expect.

The output is:

C:\>Test.exe

C:\>Outputting Line 1
Outputting Line 2
...
Outputting Line 10

Instead of:

C:\>Test.exe
Outputting Line 1
Outputting Line 2
...
Outputting Line 10
Write a carriage return / line feed pair ( "\r\n") before the first line.

Regards,
Will
www.ivrforneginners.com

Regards,
Will
Jun 20 '07 #2

P: n/a

"Peter Nimmo" <Pe********@newsgroups.nospamwrote in message
news:Xn**********************************@127.0.0. 1...
Hi,

I am writting a windows application that I want to be able to act as if
it where a Console application in certain circumstances, such as error
logging.

Whilst I have nearly got it, it doesn't seem to write to the screen in
the way I would expect.

The output is:

C:\>Test.exe

C:\>Outputting Line 1
Outputting Line 2
Outputting Line 3
Outputting Line 4
Outputting Line 5
Outputting Line 6
Outputting Line 7
Outputting Line 8
Outputting Line 9
Outputting Line 10

Instead of:

C:\>Test.exe
Outputting Line 1
Outputting Line 2
Outputting Line 3
Outputting Line 4
Outputting Line 5
Outputting Line 6
Outputting Line 7
Outputting Line 8
Outputting Line 9
Outputting Line 10

C:\>
The command prompt waits for a console application to finish, but not for a
windows application (I think this behavior is new in XP, I definitely
remember having to do "start notepad" if I wanted to keep using my command
prompt).
>
Code is as follows:

#include <Tlhelp32.h>
#include <cstdio>
#include <io.h>
#include <fcntl.h>
#include <iostream>
#include <ios>

BOOL RedirectIOToConsole(DWORD dwParent)
{
int hConHandle;
long lStdHandle;
FILE *fp;

// allocate a console for this app
BOOL bRet = AttachConsole(dwParent);
if (!bRet)
return bRet;

// redirect unbuffered STDOUT to the console
lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "w");

*stdout = *fp;
setvbuf(stdout, NULL, _IONBF, 0);

// redirect unbuffered STDIN to the console
lStdHandle = (long)GetStdHandle(STD_INPUT_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "r");
*stdin = *fp;
setvbuf(stdin, NULL, _IONBF, 0);

// redirect unbuffered STDERR to the console
lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "w");
*stderr = *fp;
setvbuf(stderr, NULL, _IONBF, 0);

// make cout, wcout, cin, wcin, wcerr, cerr, wclog and clog
// point to console as well
ios::sync_with_stdio();
return bRet;
}

int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);

// TODO: Place code here.
HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0
);
wchar_t buffer[2000+1] = { '\0' };
DWORD dwCallingProcessID = 0UL;
if (hSnapshot != (HANDLE)-1)
{
PROCESSENTRY32 pe;
pe.dwSize = sizeof(pe);
if (Process32First(hSnapshot, &pe))
{
DWORD MyPID = GetCurrentProcessId();
do
{
if (pe.th32ProcessID == MyPID)
{
dwCallingProcessID = pe.th32ParentProcessID;

if (RedirectIOToConsole
(pe.th32ParentProcessID))
{
//cerr << "Failed";
for (int i = 0;i < 10;i++)
printf("Outputting Line %d\n",i+1);

}
else
{
MessageBox(NULL,L"Failed",L"Attaching
Console",MB_ICONERROR);
}
}
} while (Process32Next( hSnapshot, &pe ));
}
CloseHandle(hSnapshot);
}
return 0;//Other code snipped for brevity
}
Jun 21 '07 #3

P: n/a
Hi Peter,

Yes, I can reproduce out this behavior.

Normally, "console" applications (ones that begin with main/wmain) are
executed by cmd ¡°synchronously¡±, while ¡°windows¡± applications (ones
that begin with WinMain/wWinMain) are executed ¡°asynchronously¡±.

This is independent of whether said application writes to any consoles or
not.

So, your test program is a ¡°windows¡± app, so cmd.exe starts it up and
then immediately returns control to the user (printing a prompt for the
next command). The user can even use that prompt before test does
anything. (Put in a sleep statement in test.exe to observe this.) That¡¯s
because most ¡°windows¡± program launch a new GUI window and interact with
the user that way.

When your app now prints to the console, it just prints wherever the cursor
is (which means it starts at the end of the command prompt, and also those
messages would be intermixed with any commands the user types and any
results from those other commands), and when it gets done printing, cmd.exe
doesn¡¯t know that the appearance of its prompt has been trashed and needs
to be reprinted. [And if you were halfway through typing that command,
that command fragment is still there to be continued, even though you¡¯ve
spewed a whole bunch of stuff to the console.]

Now, the standard way to deal with this is:
1. Use a console app. Note that the cmd.exe prompt won¡¯t be available
again until your program exits.
2. Use a separate console instead of the one that launched your program.
3. Use windows GUI to show error messages.
4. Use a hybrid approach if this makes sense ¨C a small console app that
parses the cmd line and if it decides it wants to act like a console app,
it prints those messages, but otherwise spawns a GUI app (and exits) to
return the cmd prompt to the user. The GUI app then communicates to the
user via GUI windows, etc.

Regarding #4, if you do this, name the console app MyApplication.com and
the GUI MyApplication.exe. Cmd.exe will launch the .com file first, the
shell will launch the .exe first and everybody is happy:
MyApplication.exe ¨C This is a Windows Application, and performs no output
to the console.
MyApplication.com ¨C This is a Console Application, it calls
MyApplication.exe and returns output from the Windows Application to the
console via some kind of IPC.

See devenv.com/devenv.exe in Visual Studio as an example:
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv /?
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com /?
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe /?

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Jun 22 '07 #4

P: n/a
Additionally, if you are interested in option #4, you may read the 2 links
below for details:
http://msdn.microsoft.com/msdnmag/issues/04/02/CQA/
http://blogs.msdn.com/junfeng/archiv.../06/68531.aspx

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Jun 22 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.