Prev: Application Error, The memory could not be "read". How to debug?
Next: IOCTL_DISK_ONLINE on longhorn
From: "Ivo Beltchev" ivo _ on 21 Nov 2007 13:05
I think you are looking at a different function. This is the current page: http://msdn2.microsoft.com/en-us/library/ms681952.aspx
and says it requires Vista, XP, Server 2003 or Server 2008.

I'm pretty sure I tried AttachConsole on 2000 back in the day and it didn't work...

"Pops" <dude(a)nospamnospamnospam.com> wrote in message news:uA6BNXGLIHA.2268(a)TK2MSFTNGP02.phx.gbl...
> Martin Irman wrote:
> > Ivo Beltchev wrote:
> >
> >> Note that AttachConsole works only on Windows XP and up.
> >
> > Thanks. I didn't notice. Yes, that would be a problem.
>
> hmmmm, I don't recall that OS limitation. I know for sure it worked
> because our products started on WIN95/NT 4.0 systems.
>
> Let me check something ....
>
> ok, VS6.0 MSDN APRIL 2001 requires Windows NT 3.1 and Window 95/98/ME.
> We know this is true.
>
> But the current Microsoft MSDN web site says:
>
> Requires Windows Vista, Windows XP, or Windows 2000 Professional.
>
> Of course, we should not be surprise because Microsoft no longer has any
> interest in promoting the ideas that Windows 95 or NT 4.0 is still
> supported. Also note it also lacks saying Windows 2003 :-)
>
> But if 95/NT/2000 is still a OS you support, AllocConsole will work.
>
> --
> HLS
From: Pops on 21 Nov 2007 13:08
Oh, Attach!! Sorry, my bad, I was thinking AllocConsole. Yes,
AttachConsole is XP and up!

--

Ivo Beltchev wrote:
> I think you are looking at a different function. This is the current page: http://msdn2.microsoft.com/en-us/library/ms681952.aspx
> and says it requires Vista, XP, Server 2003 or Server 2008.
>
> I'm pretty sure I tried AttachConsole on 2000 back in the day and it didn't work...
>
> "Pops" <dude(a)nospamnospamnospam.com> wrote in message news:uA6BNXGLIHA.2268(a)TK2MSFTNGP02.phx.gbl...
>> Martin Irman wrote:
>>> Ivo Beltchev wrote:
>>>
>>>> Note that AttachConsole works only on Windows XP and up.
>>> Thanks. I didn't notice. Yes, that would be a problem.
>> hmmmm, I don't recall that OS limitation. I know for sure it worked
>> because our products started on WIN95/NT 4.0 systems.
>>
>> Let me check something ....
>>
>> ok, VS6.0 MSDN APRIL 2001 requires Windows NT 3.1 and Window 95/98/ME.
>> We know this is true.
>>
>> But the current Microsoft MSDN web site says:
>>
>> Requires Windows Vista, Windows XP, or Windows 2000 Professional.
>>
>> Of course, we should not be surprise because Microsoft no longer has any
>> interest in promoting the ideas that Windows 95 or NT 4.0 is still
>> supported. Also note it also lacks saying Windows 2003 :-)
>>
>> But if 95/NT/2000 is still a OS you support, AllocConsole will work.
>>
>> --
>> HLS
From: Martin Irman on 21 Nov 2007 13:22
Norman Diamond wrote:
> Maybe try the following ugly workaround.
>
> No, wait a minute. First make sure you haven't eaten lunch yet. Set
> that coffee cup down in a safe place. Get some goggles. Then try the
> following ugly workaround.
>
> Definitely not guaranteed. If it doesn't work, you have to pay me double.
>
>
>
>
>
> hWndCons = GetConsoleWindow();
> ShowWindow(hWndCons, SW_SHOWNA);
> ShowWindow(hWndCons, SW_HIDE);
>

Nope. Doesn't work. But the following ugliness works:

if special treatment for windows vista
{
for( int i = 0 ; i < hide_console_retry_attempt_count ; ++i )
{
::Sleep( hide_console_retry_sleep_miliseconds ) ;

if ( ::ShowWindow( hWndCons, SW_HIDE ) )
break ;
}
}

Cheers,
Martin.
From: Pops on 21 Nov 2007 16:15
Martin Irman wrote:
> Norman Diamond wrote:
>> Maybe try the following ugly workaround.
>>
>> No, wait a minute. First make sure you haven't eaten lunch yet. Set
>> that coffee cup down in a safe place. Get some goggles. Then try the
>> following ugly workaround.
>>
>> Definitely not guaranteed. If it doesn't work, you have to pay me
>> double.
>>
>> hWndCons = GetConsoleWindow();
>> ShowWindow(hWndCons, SW_SHOWNA);
>> ShowWindow(hWndCons, SW_HIDE);
>>
>
> Nope. Doesn't work. But the following ugliness works:
>
> if special treatment for windows vista
> {
> for( int i = 0 ; i < hide_console_retry_attempt_count ; ++i )
> {
> ::Sleep( hide_console_retry_sleep_miliseconds ) ;
>
> if ( ::ShowWindow( hWndCons, SW_HIDE ) )
> break ;
> }
> }

Hmmmm,

Curious, what kind of values are you using for the sleep and attempts?

If the above works for you, it surely sounds like a timing problem.
VISTA CreateProcess() is doing alot more with validating process
priverledges and other things.

I wonder if the parent (vista) is also calling WaitForIdleInput().

Try poking the system;

Sleep(0) or SwitchToThread();

Also write a quick console that does absolutely nothing:

int main(char argc, char *argv[])
{
return 1;
}

and see if VISTA opens a console. If not, then it sounds like it is
waiting for "something" like some console output before creating a
console for the new process.

To test this theory, try several runs with different sleep values:

int main(char argc, char *argv[])
{
Sleep(0); <-- Try increasing values.
return 1;
}

If after some point vista create the console, then it has a timeout
before it creates a process console.

That is what I would explore if I ran into this and had to add a loop
before ShowWindow() was successful.

--
HLS



From: Martin Irman on 22 Nov 2007 10:15
Pops wrote:
> Martin Irman wrote:
>> Norman Diamond wrote:
>>> Maybe try the following ugly workaround.
>>>
>>> No, wait a minute. First make sure you haven't eaten lunch yet. Set
>>> that coffee cup down in a safe place. Get some goggles. Then try
>>> the following ugly workaround.
>>>
>>> Definitely not guaranteed. If it doesn't work, you have to pay me
>>> double.
>>>
>>> hWndCons = GetConsoleWindow();
>>> ShowWindow(hWndCons, SW_SHOWNA);
>>> ShowWindow(hWndCons, SW_HIDE);
>>>
>>
>> Nope. Doesn't work. But the following ugliness works:
>>
>> if special treatment for windows vista
>> {
>> for( int i = 0 ; i < hide_console_retry_attempt_count ; ++i )
>> {
>> ::Sleep( hide_console_retry_sleep_miliseconds ) ;
>>
>> if ( ::ShowWindow( hWndCons, SW_HIDE ) )
>> break ;
>> }
>> }
>
> Hmmmm,
>
> Curious, what kind of values are you using for the sleep and attempts?

I use 5 attempts, waiting 50 msec.

>
> If the above works for you, it surely sounds like a timing problem.
> VISTA CreateProcess() is doing alot more with validating process
> priverledges and other things.

Yep, definitely a timing problem. But the problem happens only the
first time after login, so it does not seem that the problem is caused
by something my process is doing or not doing (not producing output)
but rather by something that the parent (Vista) is doing the first
time after login before calling ShowWindow() on the console.

>
> I wonder if the parent (vista) is also calling WaitForIdleInput().
>
> Try poking the system;
>
> Sleep(0) or SwitchToThread();
>
> Also write a quick console that does absolutely nothing:
>
> int main(char argc, char *argv[])
> {
> return 1;
> }
>
> and see if VISTA opens a console. If not, then it sounds like it is
> waiting for "something" like some console output before creating a
> console for the new process.
>
> To test this theory, try several runs with different sleep values:
>
> int main(char argc, char *argv[])
> {
> Sleep(0); <-- Try increasing values.
> return 1;
> }
>
> If after some point vista create the console, then it has a timeout
> before it creates a process console.
>
> That is what I would explore if I ran into this and had to add a loop
> before ShowWindow() was successful.

The return value of ShowWindow() does not indicate success.
ShowWindow() returns a bool that indicates whether the window was
shown before. So the loop runs until ShowWindow() returns "true"
indicating that Vista has already done its job and shown the console
window. Once the window is shown, we can happily hide it ;)

Cheers,
Martin.
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Application Error, The memory could not be "read". How to debug?
Next: IOCTL_DISK_ONLINE on longhorn