This topic provides information for UNIX users who are new to Visual
C++ and want to become productive with Visual C++.
Started on the Command Line
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.
If you open a command prompt with the
Visual Studio Command Line
Prompt from the Start
menu, then vsvars32.bat is run for you.
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++).
the Development Environment
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,
Managing Solutions, Projects, and Files and
Introducing the Visual Studio IDE (C++).
Your Existing Code
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.
a New Project
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
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
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
/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.
Porting from UNIX to Win32
When migrating applications from UNIX to Windows, you have several
Using UNIX libraries to port applications from UNIX to Win32
Porting applications from UNIX to Win32 natively
Running UNIX applications on Windows using the POSIX
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
The following list provides Microsoft and third-party
resources for porting and supporting UNIX migration to
UNIX Migration Guides
The UNIX Custom Application Migration Guide provides
technical help on code migration from UNIX to the Win32
The Unix Migration Project Guide supplements the UNIX
Custom Application Migration Guide by providing
high-level help on migrating substantial projects from
UNIX to Win32. The Guide provides advice on issues to
consider at each stage of project migration. The Guide
may be downloaded from:
Microsoft Windows Services for UNIX (SFU)
Microsoft Windows Services for UNIX (SFU) provides a
full range of cross-platform services for integrating
Windows into existing UNIX-based environments. Services
for UNIX provides file sharing, remote access and
administration, password synchronization, common
directory management, a common set of utilities, and a
Windows Services for UNIX
A third party site for a company providing software
supporting porting UNIX to Win32.
C++ Boost Web Site
UNIX applications directly to Win32
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
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
Windows supports DCE-compliant RPC, so RPC-based
applications are easily usable. See
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
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.