; TEST program
; ---------------------------------------------------------------------------------------------------------
.686P
.model flat, stdcall
.stack 4096
; ---------------------------------------------------------------------------------------------------------
ExitProcess PROTO,
dwExitCode:DWORD
GetStdHandle PROTO,
dwWhich:DWORD
ReadConsole EQU <ReadConsoleA>
ReadConsole PROTO,
hConsoleInput:DWORD, ; input handle
lpBuffer:PTR BYTE, ; pointer to buffer
nNumberOfBytesToRead:DWORD, ; number of chars to read
lpNumberOfCharsRead:PTR DWORD, ; ptr to number of bytes read
lpReserved:DWORD ; (not used)
; ---------------------------------------------------------------------------------------------------------
; Constants
STD_INPUT_HANDLE EQU -10
; ---------------------------------------------------------------------------------------------------------
.data
hStdIn DWORD 0
buf byte 0 dup (100)
num dword 0
; ---------------------------------------------------------------------------------------------------------
.code
main proc
invoke GetStdHandle, STD_INPUT_HANDLE
mov hStdIn, eax
mov edx, offset buf
INVOKE ReadConsole, hStdIn, edx, 100, ADDR num, 0
invoke ExitProcess,0
ret
main endp
end main
; ---------------------------------------------------------------------------------------------------------
Is it because it links in kernel32.dll?
buf byte 0 dup (100)
try this, you can place it in the .DATA? section
buf byte 260 dup (?)
the ReadConsole function likes to have 256 bytes, plus a couple extra for termination
we make it 260 so it's evenly divisable by 4
as for the memory usage, i doubt it uses 900 K
however, CMD.EXE might use quite a bit :biggrin:
oh - and don't define a stack
use this....
.686p
.MODEL Flat,StdCall
OPTION CaseMap:None
Windows is generous: by default, all programs get about one megabyte.
For further reading, Mark Russinovich has a nice series starting with Pushing the Limits of Windows: Physical Memory (http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx)
...Oh, yes,...and speaking of Mark Russinovich, he has an excellent FREE utility: Process Explorer v16.05, TechNet (https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)
Quote from: CCurl on October 31, 2015, 07:38:48 AM
Is it because it links in kernel32.dll?
yes, among others. However that are unavoidable costs, because you can't create any useful program without these APIs.