Basic console input and output example

[Todd]

Greetings! I am posting this here because it was something I was looking for when I first wanted to do some assembly language programming in the Windows platform. The file attached to this post is assembly language source code that demonstrates how to write text to the console and get input from the console keyboard, all using just Win32 API system calls. Hutch has done a great job with his Masm32 package, and he has simplified this task for you. However, being the stubborn guy I am, I wanted to do it the hard way. The reality is that I cannot get comfortable with a processor's instruction set until I can get at least some output to the screen and some input from the user (typically me). Another thing this source code will show you is how to create and call subroutines in your programs. Lastly, I wanted to know how to do pure assembly language programming projects using Microsoft's Visual Studio Pro 2008 (since I already have that package). The directions for doing this are in the comments of the attached assembly language source code. The assembly language book I am using is Detmer's Introduction to 80x86 Assembly Language and Computer Architecture, second ed., and that's the development environment he is using. While there are some negatives to using such a heavy duty development environment, one of the pluses is being able to single-step through the assembly source code and watch register values and variables - an invaluable aid in debugging programs, or just seeing how different assembly language instructions behave. By the way, the same directions for doing pure (no high level language) assembly language in Visual Studio work for MS's free Visual Studio C++ Express.

You may use or modify the attached source code any way you wish. Hopefully, you will find it useful in getting you started in API calls.

Cheers!
~todd

[Vortex]

Hi Todd,

Thanks for posting your code. Is there a specific reason to use decorated symbols in your code?

Code Select Expand

extern  _ExitProcess@4:near

include kernel32.inc is more preferable as it provides you the ready function prototype :

Code Select Expand

ExitProcess PROTO STDCALL :DWORD

Please don't get me wrong as you are free to choice your own programming style. Writing a lot of decorated symbols in a big project would cost you more time and this method can cause errors as you can mistype the API functions. Using the invoke macro is safe as it checks the number of parameters passed to the stack.

[Todd]

Hi Vortex, no specific reason. I didn't think to look for kernel32.inc and see if it was around somewhere. Despite a hearty background in programming, it's been at least 20 years since I've done anything with assembly language - my all time favorite. So in reality, I'm a newbie to today's current design trends and certainly to doing asm in a Windows world. My experience with MASM is limited to the 16 bit DOS days. You're right, invoke is better to use for API calls. I needed to start somewhere, so you can think of my source code as a rough draft. My focus in this small project has been on the difference between the world I use to know and what the world is today in terms of using system calls for terminal-based IO. Most newbies will tell you that one of the first obstacles to overcome is where to start.  I started by Googling for Windows asm programming information. That's how I found the MASM32 project, and very impressive it is! Clearly, this project proves that asm can be done smartly and cleanly in Windows. But how does MASM32 do it? Being the stubborn rascal I am, I wanted to know how to at least do console input and output without relying on anything beyond kernel32.lib. The source code posted is the result. The search for Windows asm programming has been very instructive. That's how I know MASM32 is very impressive. Much of the information out there is outdated, unorganized, the documentation incomplete, pertains to higher level languages, and so on. Obviously the team here at MASM32 has done a lot of hard work synthesizing that mess into a usable platform for the rest of us. I hope at some point to be able to contribute to the effort.

Thank you for your reply!
~todd