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.
.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
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 from: Kp on January 08, 2006, 07:46 PM
This is most likely because your application is subsystem:windows not subsystem:console.
Sounds more like subsystem:console and not subsystem:windows :P
Quote from: Joe on January 08, 2006, 04:22 PM
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.
Quote from: Yoni on January 10, 2006, 12:27 AM
Quote from: Kp on January 08, 2006, 07:46 PM
This is most likely because your application is subsystem:windows not subsystem:console.
Sounds more like subsystem:console and not subsystem:windows :P
Quote from: Joe on January 08, 2006, 04:22 PM
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.
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 from: rabbit on January 11, 2006, 06:32 PM
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.
I just meant it's a waste of memory, not that it will change anything.
Quote from: Joe on January 11, 2006, 11:08 PM
Quote from: rabbit on January 11, 2006, 06:32 PM
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?
How?
Quote from: Joe on January 13, 2006, 05:03 PM
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.
Quote from: Skywing on January 13, 2006, 06:23 PM
Quote from: Joe on January 13, 2006, 05:03 PM
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\+/.
I love the absolute contrast of Windows & Linux specialists between Kp/Skywing. :) Such gifted programmers.
Quote from: Kp on January 13, 2006, 06:40 PM
Quote from: Skywing on January 13, 2006, 06:23 PM
Quote from: Joe on January 13, 2006, 05:03 PM
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).
I'm using MASM. I wrote my code in the MASM editor, and then Project-->Assemble ASM file and Project-->Link OBJ file.