Issues in Console Programming

Pages: 123
---------- Issues in Console Programming ----------

In this series of articles I intend to cover both the "how-to" of programming console applications but also the reasons that things are done the way they are.

The purpose of these articles is threefold:

First, this information is rather scattered about the internet. It sure would be nice to have it all in one spot. I don't aim to cover every possible issue, but I do intend to have a complete primer.

Second, some of these issues are a constant sore spot for forum regulars (on forums everywhere). These questions get asked so often that people tire of answering them, and start giving simple answers just to shut the asker up. Answering a question takes a fair amount of energy, and when someone shows up two days after some brilliant answer to ask some simple variation, it makes us want to unplug his computer with a pair of wire-cutters. These articles aim to provide an easy, canned answer that makes everyone happy.

Third, I intend to encourage people to think properly about how they are programming. Too often these days programmers fall into the trap of believing that the computer will help them program. This is true of all other computer activities, but not programming. Programming the computer requires careful thought and insight. Simple answers are simply the Wrong Thing. It is better to get a good, comprehensive answer that makes you more capable, skilled, and valuable -- a better programmer than the average wannabe. Don't be a liability to your software!

-------------------- For The Brain --------------------

Why system() is evil

How to set up a nice console-programming environment
-- todo --

Types and purposes of console applications
-- todo --

Issues when reading user input
-- todo --

Making your application well-behaved
-- todo --

Windows and Linux issues
-- todo --

Getting started with Curses
-- todo --

Using <conio.h>
-- todo --

Using Win32
-- todo --

-- todo --

-------------------- For The Body --------------------

Keep the console open long enough to see your program's output

Flush stdin
-- todo --

Clear the screen

Read a password
-- todo --

Read arrow keys and other fancy stuff
-- todo --

Know whether or not a key is pressed
-- todo --

Read a single key for input (without having to press Enter)
-- todo --

Use timeouts or delays when getting input
-- todo --

Change the text colors
-- todo --

Change the console window's title
-- todo --

Cursor position
-- todo --

Mouse input
-- todo --

Determine if there is a human interacting with the program
-- todo --

------------------- Actualization -------------------

Console Functions Source Code (Win32 and POSIX)
-- todo --

-------------------- Boilerplate --------------------

First off, I wrote all this code. The articles are designed to be as cut-n-paste as possible so that you can get along with your life and not worry too much about making things work. That said, though, in many cases the code, while relatively simple, is still way above your heads. I don't care if you graduated last spring, with honors. Or if you've been working in C or C++ for the past five years. I don't care if your IQ is greater than mine. If you knew this stuff you wouldn't need me. Learn from it. But don't present it as your own. Professors and professionals alike hate cheaters. Be honest and enjoy the code, and share it with others.

For students, remember that your professor is more interested in seeing you solve problems than write amazing code. Amazing code and cool solutions are nothing more than a bonus. Code you wrote and understand, and that does what it is supposed to do is the goal. Always. (That truth never changes!)

This is obviously a work in progress. If I haven't answered your question yet, either post on the beginner's forum or ask me to write it next. You can also spend time looking through the following:
Steve Summit's comp.lang.c FAQ

Things to Avoid in C/C++ by WaltP

The Linux Keyboard and Console HOWTO

Windows Console Functions

Comments, suggestions, clarifications, corrections, and tactful critisisms are, as always, welcome.

Hope this helps

-- DĂșthomhas
Last edited on
Yeah! This is the sort of thing I've been wanting to see. I can't wait for this article to progress more! Better keep hitting refresh :P

Excellent work Duoas!

Now I might not suck as bad at programming.


Hey don't worry I know the feeling :P - Either way this guide will be awesome!
Can't wait for it to come out! Thanks man.
Any idea when the next update will be :D
Wow I would love to have this guide. Thanks Duoas.
It would be nice to get an update sometime soon, maybe something on working with directories in win32 or posix, now thats over my head!
Wow. great idea.
Excellent work.
Any updates?
Thanks Duoas! Your posts have been quite helpful, as well as clear and succint. This will definitely be good.
Here's a link to some win32 console tutorials.
This article is looking good. Hope to see more soon, especially reading the keyboard.
This article is looking good. Hope to see more soon, especially reading the keyboard.

Don't hold me to this, but the following could work:
You'll need an OS in real mode though :)
I think windows automagically runs .COM files in virtual real mode... so try compiling it to a .COM...

int getcharASM() {
    int c = 0;
    asm volatile
        "movl $0x0, %%ah" // Read from keyboard
        "int $0x21"        // Call interrupt to get keypress
        "movl %%al, %0"   // Store result in output operand
        :"=r"(c) // Output operand
    return c; // Return character

I'm not entirely sure I put the right value in AH, though. If it prints "ERROR!" to the screen and your BIOS chip explodes, it's not my fault.
Last edited on
It could be either mov ah, 1 int 0x21 or mov ah, 0 int 0x16 if you want to directly read a key.
Last edited on
Yeah... Don't do that.

I'll post more soon enough. If you want to get individual key presses, see the stuff I've already posted here
Cool; when you finish this, it is going to be a great help for all of us.

Another way of reading a key with inline asm would be to use inb (in byte) to read from the keyboard port (0x60 I think)... but I think I'll quit while I'm ahead.

I'm interested in the hard drive most of all at the moment.
Reading key presses from ports 60 and 61 are for interrupt handlers to do in response to a hardware interrupt. Application programs should not do that.
I'll post more soon enough.

Mouse input

Would that be still in the command prompt box or are you moving visual?
It is still command prompt box in Windows see
Pages: 123