You can use Visual C++ from the command line in a similar way that you would use a UNIX command-line environment. You compile from the command prompt with the command-line C and C++ compiler (CL.EXE) and tools, including NMAKE.EXE, the Microsoft version of the UNIX make utility.

In UNIX, commands are installed in a common folder, such as /usr/bin. In Visual C++, the command-line tools are installed in your installation directory at VC\bin (on a typical installation at Program Files\Microsoft Visual Studio 8\VC\bin). To use the command-line tools, run vsvars32.bat, which is located in your installation directory at Common7\Tools. This adds your bin directory to your path and sets up other paths that are necessary to compile Visual C++ programs from the command line.

To take advantage of more powerful features, such as the debugger, statement completion, and so on, you need to use the development environment. For more information, see Building on the Command Line and Compiling a Native C++ Program from the Command Line (C++).

If you use the command line and run your applications on your development workstation, you will see that a dialog box to run the Visual Studio debugger is displayed when your code encounters a memory access violation, unhandled exception, or other unrecoverable errors. If you click OK, then the Visual Studio development environment is started, and the debugger will open to the point of failure. It is possible to debug your applications this way, and, in this case, your source code would only be available if you compiled with the /Z7, /Zi, /ZI (Debug Information Format) switch. For more information, see Debugging Native Code and Introducing the Visual Studio IDE (C++).

It is easier to use the development environment to edit and build your source code in a project. A project is a collection of source and related files that will be compiled into a single unit, such as a library or executable. A project also contains information on how the files are to be built. Information about projects is stored in a project file with the extension .prj.

An application that consists of multiple libraries and executables, each potentially built with a different set of compiler options or even in a different language, are stored in multiple projects that are part of a single solution. A solution is an abstraction for a container to group multiple projects together. Information about solutions is stored in a solution file with the extension .sln. For more information, see Managing Solutions, Projects, and Files and Introducing the Visual Studio IDE (C++).

You can use Visual C++ to use existing code that is set up to compile with or without a makefile and put it into a Visual Studio project. For more information, see the Create Project From Existing Code Files Wizard. For more information, see How to: Create a C++ Project from Existing Code.

You can create new projects in the development environment. Visual C++ provides numerous templates that provide standard code for various common projects. You can use application wizards to generate projects with code outlines for various application types.

You can start with an empty project by using the Console Application (Win32) Wizard. Select the Empty Project check box. You can then add new and existing files to the project later.

When you create a project, you must name the project. By default, the project name equals the name of the dynamic-link library (DLL) or executable that is build from the project. For more information, see How to: Create Solutions and Projects.

Visual C++ contains several extensions to the standard C++ programming language. These extensions are used to specify storage class attributes, function calling conventions, and based addressing, among other things. For a complete list of all Visual C++ extensions, see Microsoft-Specific Modifiers.

You can disable all Microsoft-specific extensions to C++ by using the /Za compiler option. This option is recommended if you want to write code to run on multiple platforms. For more information on the /Za compiler option, see /Za, /Ze (Disable Language Extensions). For more information on Visual C++ conformance, see Compatibility and Compliance Issues in Visual C++.

The Microsoft C and C++ compilers provide options for precompiling any C or C++ code, including inline code. Using this performance feature, you can compile a stable body of code, store the compiled state of the code in a file, and, during subsequent compilations, combine the precompiled code with code that is still under development. Each subsequent compilation is faster because the stable code does not need to be recompiled.

By default, all precompiled code is specified in the files stdafx.h and stdafx.cpp. The New Project wizard will automatically create these files for you unless you deselect the Precompiled header option. For more information on precompiled headers, see Creating Precompiled Header Files.

One option UNIX programmers normally consider is using third-party UNIX-like libraries to let their UNIX code compile as a Win32 executable. Several commercial (and at least one public domain) libraries do this. This is an option for some applications. The advantage of these porting libraries is that they minimize the initial porting effort. The main disadvantage, for a competitive software product, is that a native Win32 port of an application will generally be faster and will inevitably have more functionality. It can be awkward for the application to step outside of its UNIX shell if it needs to make Win32 calls to get more power from Windows.

The following list provides Microsoft and third-party resources for porting and supporting UNIX migration to Visual C++:

UNIX Migration Guides

Microsoft Windows Services for UNIX (SFU)

InteropSystems.com

C++ Boost Web Site

Another option is porting UNIX applications directly to Win32. Using ANSI C/C++ libraries, and commercial C compiler libraries, many of the traditional system calls relied on by UNIX applications are available in Win32 applications.

The output model of stdio-based applications does not need to be changed, since the Win32 console APIs mimic the stdio model, and versions of curses exist that use the Win32 console APIs. For more information, see SetConsoleCursorPosition.

Berkeley socket-based applications need very few changes to work as Win32 applications. The Windows Sockets interface was designed for portability with BSD sockets, with minimal changes that are noted in the introductory sections of the WinSock specification.

Windows supports DCE-compliant RPC, so RPC-based applications are easily usable. See RPC Functions.

One of the largest areas of difference is in the process model. UNIX has fork; Win32 does not. Depending on the use of fork and the code base, Win32 has two APIs that can be used: CreateProcess and CreateThread. A UNIX application that forks multiple copies of itself can be reworked in Win32 to have either multiple processes or a single process with multiple threads. If multiple processes are used, there are multiple methods of IPC that can be used to communicate between the processes (and perhaps to update the code and data of the new process to be like the parent, if the functionality that fork provides is needed). For more on IPC, see Interprocess Communications.

Windows and UNIX graphical models are very different. UNIX uses the X Window System GUI, while Windows uses GDI. Though similar in concept, there is no simple mapping of the X API to the GDI API. However, OpenGL support is available for migrating UNIX OpenGL-based applications. And there are X clients and X servers for Windows. See Device Contexts for information on GDI.

Basic UNIX applications, including many CGI applications, should port easily to Visual C++ running on Windows. Functions like open, fopen, read, write and others are available in the Visual C++ run-time library. Also, there is a one-to-one mapping between C UNIX APIs and Win32 APIs: open to CreateFile, read to ReadFile, write to WriteFile, ioctl to DeviceIOControl, close to CloseFile, and so on.

Another option UNIX programmers look at is the Windows POSIX subsystem. However, it only supports POSIX 1003.1, which was the only POSIX version standardized when Windows NT was created. Since then, there has been little demand for extending this subsystem, because most applications have been converted to Win32. The 1003.1 system is of limited interest for fully featured applications, because it does not include many capabilities (such as those in 1003.2, network support, and so on). Full featured applications run under the Windows POSIX subsystem do not have access to Windows features available to Win32 applications, such as memory-mapped files, networking, and graphics. Applications such as VI, LS, and GREP are the main targets for the Windows POSIX subsystem.