I'm trying to write to a console using MASM32, but theres a small problem. When I call AllocConsole, it creates a new console, not uses the one I'm running in. Then, when I call FreeConsole, that console is destroyed, and nobody can read my pretty output! I use Sleep(1000) to display it, so I know its printing to it, but I don't know how to use the console that's already being shown.

[code].486
.model flat, stdcall
option casemap :none

include \masm32\include\windows.inc

include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib

include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib


.data
msgHello      db "Hello World!", 0 ;Length: 13

.code
start:
    invoke AllocConsole
    ; Allocate a console

    invoke GetStdHandle, -11
    ; Get STD Handle
    ; We assume its returned in EAX. Warrior said so!
   
    invoke WriteConsoleA, eax, ADDR msgHello, 13, ecx, 0
    ; eax = STD Output handle
    ; ecx = Number of chars written

    invoke Sleep, 1000
    ; Sleep 1000 seconds
   
    invoke FreeConsole
    ; Destroy the console
   
    invoke ExitProcess, 0
    ; Exit
end start[/code]

This is most likely because your application is subsystem:windows not subsystem:console.

Do you even need to AllocConsole when you're in subsystem:console?

Only if you want to spawn a new console window.

[quote author=Kp link=topic=13843.msg141140#msg141140 date=1136771205]
This is most likely because your application is subsystem:windows not subsystem:console.
[/quote]
Sounds more like subsystem:console and not subsystem:windows :P

[quote author=Joe link=topic=13843.msg141111#msg141111 date=1136758974]
but I don't know how to use the console that's already being shown.
[/quote]
Don't call AllocConsole. GetStdHandle(STD_OUTPUT_HANDLE), which you are calling anyway, should return the stdout handle for the console that exists already.

[quote author=Yoni link=topic=13843.msg141299#msg141299 date=1136874436]
[quote author=Kp link=topic=13843.msg141140#msg141140 date=1136771205]
This is most likely because your application is subsystem:windows not subsystem:console.
[/quote]
Sounds more like subsystem:console and not subsystem:windows :P

[quote author=Joe link=topic=13843.msg141111#msg141111 date=1136758974]
but I don't know how to use the console that's already being shown.
[/quote]
Don't call AllocConsole. GetStdHandle(STD_OUTPUT_HANDLE), which you are calling anyway, should return the stdout handle for the console that exists already.
[/quote]

Possibly, but if he's in subsystem:windows he'd need to call AllocConsole for one to show up at all.  I presumed that's why he was calling AllocConsole, and then he just tacked on a FreeConsole because the docs told him to.

Not using FreeConsole after AllocConsole?  That's like declaring a large array and only using a tiny bit of it, and then never destroying the extra.

[quote author=rabbit link=topic=13843.msg141447#msg141447 date=1137025955]
Not using FreeConsole after AllocConsole?  That's like declaring a large array and only using a tiny bit of it, and then never destroying the extra.
[/quote]

What happens a lot? =p

EDIT -
Rhar. Not calling AllocConsole didn't help any.

I just meant it's a waste of memory, not that it will change anything.

[quote author=Joe link=topic=13843.msg141490#msg141490 date=1137042533]
[quote author=rabbit link=topic=13843.msg141447#msg141447 date=1137025955]
Not using FreeConsole after AllocConsole?  That's like declaring a large array and only using a tiny bit of it, and then never destroying the extra.
[/quote]

What happens a lot? =p

EDIT -
Rhar. Not calling AllocConsole didn't help any.
[/quote]

Have you checked yet what subsystem your program is running in?

How?

[quote author=Joe link=topic=13843.msg141707#msg141707 date=1137193409]
How?
[/quote]

You're telling the linker which subsystem to set in your linker parameters (or lack thereof).  Check for a /subsystem: line if you are using Microsoft link.exe.  You could also use dumpbin /headers exename if you are using Microsoft link.exe.

[quote author=Skywing link=topic=13843.msg141741#msg141741 date=1137198200]
[quote author=Joe link=topic=13843.msg141707#msg141707 date=1137193409]
How?
[/quote]

You're telling the linker which subsystem to set in your linker parameters (or lack thereof).  Check for a /subsystem: line if you are using Microsoft link.exe.  You could also use dumpbin /headers exename if you are using Microsoft link.exe.
[/quote]

Actually, that should work even if he linked it with the GNU toolchain. :)

Joe: if you're using GNU tools (or feel like using them in preference to Microsoft tools), use objdump -p exename to view the headers.  Look for /^Subsystem\s\+/.

I love the absolute contrast of Windows & Linux specialists between Kp/Skywing.  :)  Such gifted programmers.

[quote author=Kp link=topic=13843.msg141745#msg141745 date=1137199220]
[quote author=Skywing link=topic=13843.msg141741#msg141741 date=1137198200]
[quote author=Joe link=topic=13843.msg141707#msg141707 date=1137193409]
How?
[/quote]

You're telling the linker which subsystem to set in your linker parameters (or lack thereof).  Check for a /subsystem: line if you are using Microsoft link.exe.  You could also use dumpbin /headers exename if you are using Microsoft link.exe.
[/quote]

Actually, that should work even if he linked it with the GNU toolchain. :)
[/quote]Yes, though since dumpbin is a thin wrapper around link, it would make sense that if you had dumpbin, you would probably be using link.exe instead of the GNU toolchain (albeit not necessarily).

I'm using MASM. I wrote my code in the MASM editor, and then Project-->Assemble ASM file and Project-->Link OBJ file.