One key part of a project's software requirement is deciding which operating system you want to develop for, and which compiler you are going to use.
It is customary to develop any substantial program within a graphically interfaced environment where you select your compiler and linker settings from dialog boxes, edit your code with word-processing tools, and edit your resources with graphics tools. An IDE (Integrated Development Environment) is also expected to have online help and a full array of debugging tools. Sometimes people also call an IDE a compiler, though really it's more than that.
We are going to write code which can be used to build programs for the ever-more-numerous Microsoft Windows platforms: Windows 95, Windows 98, Windows NT, Windows 2000, Windows Millennium Edition, Windows XP, and so on.
In order to build the kinds of Windows applications we're going to discuss, you need a C++ compiler which has libraries for implementing the many special Windows functions. These special functions are called the Windows API. The standard compiler for this purpose is the compiler from Microsoft, which their marketeers have variously called Visual C++, Visual Studio, and Visual Studio.NET. Visual Studio.NET can also be called Visual Studio, Version 7.0.
Various smaller companies give Microsoft some competition in this market, but the Microsoft compiler has overwhelmingly become the industry standard. If you're serious about wanting to write Microsoft Windows programs you should use the Microsoft compiler. Writing Windows programs is not the place for anti-monopolistic scruples. The competing compilers tend not to be so well tested and supported as is Visual Studio. And if you ever want a job as a Windows programmer, it's going to be Visual Studio your employer expects you to know. Time spent wrestling with other manufacturers' compilers for the Windows platform is time down the drain.
Microsoft often releases different versions of Visual Studio at different price levels. Sometimes the less-expensive packages will in fact be an older release; you need to look at the fine print on the box to see what's actually in there. For the purposes of the code in the Pop Framework, any version from the older Version 6.0 or the newer Version 7.0 (also known as Visual Studio.NET) is acceptable. If you are working with a team, you will improve your code compatibility by all using the same release.
One issue to keep in mind is that Visual Studio.NET makes more hardware demands upon your machine than does Visual Studio, Version 6.0, so it may not be possible for you to run Visual Studio.NET until you eventually get a more powerful computer.
Visual Studio.NET is marketed in the following increasingly expensive editions: 'Academic,' 'Professional,' 'Enterprise Developer,' 'Enterprise Architect.' For the purposes of working with the C++ code of the Pop Framework we discuss in Software Engineering and Computer Games, all of these editions are equivalent. In particular, note that the Academic edition is exactly the same as the Professional edition, but with some additional sample code. The Enterprise Architect comes with some UML modeling tools that could be useful. The Academic version may only be readily available at college and university bookstores to students with valid student IDs.
[Visual Studio 6.0 was marketed in a 'Learning' version, a 'Professional' version, and an 'Enterprise' version. Here the Learning version was 'crippled,' that is, it lacked two commercially important features. (a) The Professional and Enterprise versions included more code optimization features, so that you could better instruct it to build a faster, or smaller, version of your program. And (b) the Professional and Enterprise versions allowed you to build programs with either the static MFC library or the dynamic MFC library, while the Learning version only offered the dynamic MFC library. The ability to use the static MFC library has the effect of making programs able to run on a wider range of Windows platforms. We'll explain more about this point later. Feature (a) is important if you write a program where you want to get as much speed as possible, and feature (b) is important if you plan to give (or sell!) your program to others, or plan to run it on a variety of machines. Note again, however, that in the case of Visual Studio.NET, the Academic edition does have both feature (a) and feature (b), in other words the Visual Studio.NET Academic edition is not crippled.]
All this varies from release to release and from year to year, so you may need to study the fine print on the box to be sure exactly what you're getting.
At commercial software stores there is a substantial (hundreds of dollars) price difference between the different versions of Visual Studio. It may not be worth the extra money to get anything other than the least expensive version if you're just starting to learn programming.
Another factor to be aware of is that, as mentioned above, many college and university bookstores sell lower cost versions of Visual Studio. The Academic version of Visual Studio.NET seems at this time to be a good choice in terms of being a complete and non-crippled package. But if your store has a higher-end version for the same or only a bit more money, you may want to get that.
Another option available at some college or university bookstores is for registered students to rent the install disks for some version of Visual Studio for a few days at some fairly low price, with the understanding that the rental gives them a Microsoft-authorized license to install and register the software on a computer.
As well as being a C++ compiler, the Microsoft Visual Studio includes a special set of classes called the MFC. The purpose of using these classes is to make it easier to develop full-featured Windows programs. We're going to use MFC in all the programs in this book. In principle we could avoid using MFC, but MFC makes the programmer's life a bit easier and gives you a bit more leverage over the code. Code size is isn't as much of an issue as it used to be ? at least not for personal computers. Of course if you were to write a game for a very small platform such as a cell phone, then you'd need to strip things down as much as possible. And some game companies prefer not using MFC because they perceive it as adding unnecessary complexity.
Speaking of MFC, note that Microsoft allows competing compiler manufacturers to distribute the MFC libraries and documentation, so theoretically you can also make MFC Windows programs with a non-Microsoft compiler. But, as already mentioned above, this isn't a wise investment of your time and energy.
Deciding which compiler and which libraries to use is something that can be debated very intensely at the beginning of a team software project. A reality is that people are usually going to push to use the compiler that they are familiar with. If you need to switch to a new compiler or a new version, do it quickly and quietly instead of wasting energy fighting the inevitable. It's not necessary to be the first to upgrade to the new version of Visual Studio as soon as it comes out, as it will be buggy. But some six months after the first release of the compiler, the customary Service Patch 1 will be out, and the worst bugs will be fixed. This is the time to upgrade and get it over with for a year or two. Always remember that change is a fact of life in software engineering. Being a software engineer is like being an athlete who has to continually train to stay in shape.
At some point in your programming career you will not only have to switch compiler packages, you'll have to switch to a completely new operating system as well ? maybe Linux will take over next, or maybe something else. The best strategy is to get to work and just do it. When switching compilers or operating systems, try and find a person you can talk to face to face and ask the inevitable 'dumb questions' that somehow fail to be addressed in any of the available documentation. A fair amount of software engineering knowledge seems to be transmitted orally, rather than being communicated in any written form.
Remember that if you act enthused about the change rather than resentful or depressed, people will be more likely to help you. People who resist and grumble about change are correctly viewed as losers. The essence of being a software engineer is this: grow or die.
The author has worked a fair amount with Visual Studio.NET, Version, 7.0 now, and would like to advise the reader that there is in fact no pressing need to switch to this product from Visual Studio, Version 6.0.
First and foremost, Version 6.0 is more stable. As of spring, 2002, one can expect any prolonged session with Visual Studio.NET to end in a crash. This is because Version 6.0 has been out for a long time and now has five service patches. Once enough service packs for Visual Studio.NET are available, it too will be stable.
Visual Studio.NET lacks some nice features that came with Version 6.0. In particular there is no Profiler. And, to the author's eyes, the .NET Properties dialogs for resources aren't as nicely designed, nor do they include as much useful help. But switching to .NET is inevitable.
A galling negative about Visual Studio.NET is the following gotcha. Any executable built with Visual Studio.NET must be able to find the oleacc.dll file on the host computer, or it will not run. And, unlike the situation with the MFC libraries that you can link in, linking in the oleacc.lib to your project file will not remove this problem! Older machines don't have oleacc.dll, and your executable won't run on them.
The oleacc.dll has to do with 'Object Linking and Embedding Access.' This file will be on computers with newer versions of Windows, and on computers with older versions of Windows that have appropriate upgrade patches installed. You won't have a problem on newer machines.
Given that the Pop framework doesn't use OLE, it's annoying to have the Visual Studio.NET compiler produce an executable that demands it. In a few years, this problem won't matter much, because by then there won't be many machines left with old, unpatched versions of Windows. But for now, if you want to distribute an executable that will painlessly run on everyone's Windows machines, build it with Version 6.0, and not with Visual Studio.NET.