Introduction

In this part of the tutorial, we will cover:

• Basic differences between bare-bones DOS and Windows programs
• Console and GUI applications, and message boxes
• Unicode

Differences between DOS and Windows programs

At the basic level, there are few differences between the bare DOS and Windows programs. In fact, if you're writing a console Windows application, the two are very close.

The first thing to notice is that when writing for 32-bit Windows, you're freed from the curse of 64k segments, far and near pointers, 16-bit integers and general limitations. You have long filenames, Unicode support (see below) and multithreading, to name a few. For once, you can do

int a[3000000];

and your program will compile and run.

With this power, though, comes responsibility: you no longer have exclusive control over the machine. In fact, you don't have direct access to anything: no interrupts, no video ports, no direct memory access. This, believe it or not, is a good thing: do you really think you can write a better video driver than that provided by the hardware manufacturer, or by Microsoft? Probably not. (If you do, you can try writing drivers yourself - but that's outside the scope of this tutorial.) However, you have to allow other applications time and resources to run. Even though you can allocate a 128Mb buffer, you probably wouldn't want to use an application that did - there would be little memory left for other applications to run.

Without further ado, let's proceed to writing our first Windows program.

#include <stdio.h> 

int main(void) 
{
	printf("Hello world!\n");
	return 0; 
}

Now, any DOS or UNIX programmers out there are probably saying, 'Hey - that's not a Windows program! That's a DOS/UNIX program'. Indeed, this program would run if you compiled it with a DOS compiler. However, when compiled with a Windows compiler, it is not a DOS program - it is a 'console' Windows program.

Console and GUI applications

You can write a program with main() and it will behave as a console program. When you link, you use the /SUBSYSTEM:CONSOLE flag. The linker will recognise this switch and set a flag in the executable program that causes Windows to ensure the program has a console available when it starts. It's still a Windows application - it just has a console as well. To prove this, let's introduce a Windows API function, MessageBox:

#include <windows.h> 

int main(void) 
{
	MessageBox(NULL, "Hello world!", "Sample", MB_OK);
	return 0; 
}

If you're running VC++, select 'Win32 Console Application' when you select 'New Project'.

If you compile and run this, it will open a console window - it's still a console application, remember - but it will pop up a distinctly Windows-like message box.

How do we flag this as a GUI (non-console) application? We simply use a different entry point. Instead of main(), we use WinMain:

#include <windows.h> 

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) 
{
	MessageBox(NULL, "Hello world!", "Sample", MB_OK);
	return 0; 
}

You can look up WinMain in MSDN to tell you what the parameters are. 

When you compile this, you will need to compile it as a Win32 Application. See the FAQ for more details.

The important thing is that now, when we run the program, we get no console window.

For now, we will retain the console window, as it provides a useful method of outputting debug information. We will discard it later, as it is a hangover from DOS, however useful - it has no place in a commercial application.

Unicode

Before we delve too deeply into Windows, a few words about multi-language support are in order.

The Unicode consortium was formed to solve the problem of character encoding. The standard ANSI character set only covers the major Western European languages - ASCII only covers English. In their own words:

Unicode provides a unique number for every character,
no matter what the platform,
no matter what the program,
no matter what the language.

A noble statement... but useless without application support. Fortunately for non-Western people across the world (billions of them!) Unicode support is widespread. For our purposes, it's most important to notice that it's the native character set of Windows NT.

In Windows NT, you can choose either ANSI (8-bit) or Unicode (16-bit) characters. However, all Windows APIs use Unicode internally. Therefore, when you call any Windows API function (or a C library function that calls the Windows API) it has to translate the input strings from ANSI to Unicode, and back on return. This is slower than just using Unicode natively - so it's important that Windows NT applications should run on Unicode.

What's the catch?

The catch is that Windows 95 and 98 do not support Unicode APIs. This is due to their 16-bit Windows heritage. So if you call the Unicode APIs directly, you will lose the ability to run on Windows 9x.

The way around this is to make a program that can be compiled for either Unicode or ANSI without loss of functionality. You could use a lot of conditional code; fortunately, much of it is done for you. You can make your applications Unicode-compliant by:

• using Unicode in your data structures;
• using the _t forms of C library functions; and
• using the _T macro for inline strings.

Since we should all promote the use of Unicode, I will use these conventions from now on. When conflicts appear, I will note them. For now, I will rewrite our console Windows program to use Unicode-compliance:

#include <windows.h> 
#include <tchar.h>

int _tmain(void) 
{
	MessageBox(NULL, _T("Hello world!"), _T("Sample"), MB_OK);
	return 0; 
}

You can compile for Unicode by defining the symbols UNICODE and _UNICODE in your compiler definitions, and for ANSI by not doing so.

Where Next

Move on to the next tutorial, or go back to the home page.

Copyright © David McCabe, 1998 - 2001. All rights reserved.

You will need to download and install the m-math control to display any equations on this Web site. Without this control, you will not see most of the equations. Please do not e-mail me asking why the equations do not display!