[MASM32] Console API's

[Joe[x86]]

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 Select Expand

.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

[Kp]

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

[MyndFyre]

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

[rabbit]

Only if you want to spawn a new console window.

[Yoni]

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

Sounds more like subsystem:console and not subsystem:windows

but I don't know how to use the console that's already being shown.

Don't call AllocConsole. GetStdHandle(STD_OUTPUT_HANDLE), which you are calling anyway, should return the stdout handle for the console that exists already.

[Kp]

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

Sounds more like subsystem:console and not subsystem:windows

but I don't know how to use the console that's already being shown.

Don't call AllocConsole. GetStdHandle(STD_OUTPUT_HANDLE), which you are calling anyway, should return the stdout handle for the console that exists already.

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.

[rabbit]

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.

[Joe[x86]]

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.

What happens a lot? =p

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

[rabbit]

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

[Kp]

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.

What happens a lot? =p

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

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

[Joe[x86]]

How?

[Skywing]

How?

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.

[Kp]

How?

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.

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\+/.

[Mephisto]

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

[Skywing]

How?

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.

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

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).