Software Solutions Developed With
High Perfection & High Quality

Windows Development

Application Programming Interface for Windows

The Application Programming Interface for Windows (APIW) Standard is a specification of the Microsoft Windows 3.1 API drafted by Willows Software, Inc. It is the successor to previously proposed Public Windows Interface standard. It was created in an attempt to establish a vendor-neutral, platform-independent, open standard of the 16-bit Windows API not controlled by Microsoft.

History ( Solutions for heterogeneous environments )

By the end of 1990, Windows 3.0 was the top-selling software. The various graphical Windows applications had already started to reduce training time and enhance productivity on personal computers. At the same time, various Unix and Unix-based operating systems dominated technical workstations and departmental servers. The idea of a consistent application environment across heterogeneous environments was compelling to both enterprise customers and software developers.

On May 5, 1993, Sun Microsystems announced Windows Application Binary Interface (WABI), a product to run Windows software on Unix, and the Public Windows Interface (PWI) initiative, an effort to standardize a subset of the popular 16-bit Windows APIs. They proposed PWI to various companies and organizations including X/Open, IEEE and Unix International. The previous day, Microsoft had announced SoftPC, a Windows to Unix product created by Insignia Solutions as part of a program where Microsoft licensed their Windows source code to select third parties, which in the following year became known as Windows Interface Source Environment (WISE). Later that month, Microsoft also announced Windows NT, a version of Windows designed to run on workstations and servers.

ECMA gets involved

In February 1994, the PWI Specification Committee sent a draft specification to X/Open - who rejected it in March, after being threatened by Microsoft's assertion of intellectual property rights (IPR) over the Windows APIsand the European Computer Manufacturers' Association (ECMA). In September, now part of an ECMA delegation, they made an informational presentation about the project at the ISO SC22 plenary meeting in the The Hague, Netherlands. Their goal was to make it an ISO standard in order to force Microsoft to comply with it (in Windows) or risk not being able sell to European or Asian governments who can only buy ISO standards-compliant products.

In April 1995, Willows Software, Inc. (formally Multiport, Inc.) a company that had been working on Windows to Unix technologies (inherited from then defunct Hunter Systems, Inc.) since early 1993, joined the ad hoc ECMA group. This group became Technical Committee 37 in August (about the time Windows 95 was released). Willows vowed to complete a full draft specification by the end of the year. In October, the draft specification was completed under the name Application Programming Interface for Windows (APIW). This was accepted as ECMA-234 in December and was put on the fast-track program to become an ISO standard.

ISO delays the standard

Again, Microsoft claimed intellectual property over Windows APIs and ISO put the standard on hold pending proof of their claims. The delay lasted until November 1997, when, hearing no response from Microsoft, ISO announced they were pushing through with the standard. However, there is no record of it ever being approved as an ISO standard.

Windows API :

Windows API

The Windows API, informally WinAPI, is Microsoft's core set of application programming interfaces (APIs) available in the Microsoft Windows operating systems. The name Windows API collectively refers to a number of different platform implementations that are often referred to by their own names (for example, Win32 API); see the versions section. Almost all Windows programs interact with the Windows API; on the Windows NT line of operating systems, a small number (such as programs started early in the Windows startup process) use the Native API.

Developer support is available in the form of the Windows Software Development Kit (SDK), providing documentation and tools necessary to build software based upon the Windows API and associated Windows interfaces.


The functionality provided by the Windows API can be grouped into eight categories:

Base Services

Provide access to the fundamental resources available to a Windows system. Included are things like file systems, devices, processes, threads, and error handling. These functions reside in kernel.exe, krnl286.exe or krnl386.exe files on 16-bit Windows, and kernel32.dll on 32-bit Windows.

Advanced Services

Provide access to functionality additional to the kernel. Included are things like the Windows registry, shutdown/restart the system (or abort), start/stop/create a Windows service, manage user accounts. These functions reside in advapi32.dll on 32-bit Windows.

Graphics Device Interface

Provides functionality for outputting graphical content to monitors, printers and other output devices. It resides in gdi.exe on 16-bit Windows, and gdi32.dll on 32-bit Windows in user-mode. Kernel-mode GDI support is provided by win32k.sys which communicates directly with the graphics driver.

User Interface

Provides the functionality to create and manage screen windows and most basic controls, such as buttons and scrollbars, receive mouse and keyboard input, and other functionality associated with the GUI part of Windows. This functional unit resides in user.exe on 16-bit Windows, and user32.dll on 32-bit Windows. Since Windows XP versions, the basic controls reside in comctl32.dll, together with the common controls (Common Control Library).

Common Dialog Box Library

Provides applications the standard dialog boxes for opening and saving files, choosing color and font, etc. The library resides in a file called commdlg.dll on 16-bit Windows, and comdlg32.dll on 32-bit Windows. It is grouped under the User Interface category of the API.

Common Control Library

Gives applications access to some advanced controls provided by the operating system. These include things like status bars, progress bars, toolbars and tabs. The library resides in a DLL file called commctrl.dll on 16-bit Windows, and comctl32.dll on 32-bit Windows. It is grouped under the User Interface category of the API.

Windows Shell

Component of the Windows API allows applications to access the functionality provided by the operating system shell, as well as change and enhance it. The component resides in shell.dll on 16-bit Windows, and shell32.dll on 32-bit Windows. The Shell Lightweight Utility Functions are in shlwapi.dll. It is grouped under the User Interface category of the API.

Network Services

Give access to the various networking capabilities of the operating system. Its sub-components include NetBIOS, Winsock, NetDDE, RPC and many others. This component resides in netapi32.dll on 32-bit Windows.


The Internet Explorer web browser also exposes many APIs that are often used by applications, and as such could be considered a part of the Windows API. Internet Explorer has been included with the operating system since Windows 95 OSR2, and has provided web related services to applications since Windows 98. Specifically, it is used to provide:

An embeddable web browser control, contained in shdocvw.dll and mshtml.dll.

The URL moniker service, held in urlmon.dll, which provides COM objects to applications for resolving URLs. Applications can also provide their own URL handlers for others to use.

    • A library for assisting with multi-language and international text support (mlang.dll).
    • DirectX Transforms, a set of image filter components.
    • XML support (the MSXML components, held in msxml*.dll).
    • Access to the Windows Address Book.

  • .


    Microsoft has provided the DirectX set of APIs as part of every Windows installation since Windows 95 OSR2. DirectX provides a loosely related set of graphics and gaming services, including:

    • Direct3D for hardware accelerated 3D graphics.
    • Direct2D for hardware accelerated 2D vector graphics.
    • DirectSound for low level hardware accelerated sound card access.
    • DirectInput for communication with input devices such as joysticks and gamepads.
    • DirectPlay as a multiplayer gaming infrastructure. This component has been deprecated as of DirectX 9 and Microsoft no longer recommends its use for game development.

  • .

    Microsoft also provide several APIs for media encoding and playback:

    DirectShow which builds and runs generic multimedia pipelines. It is comparable to the GStreamer framework and is often used to render in-game videos and build media players (Windows Media Player is based upon it). DirectShow is no longer recommended for game development. Media Foundation a newer digital media API that is intended to replace DirectShow.

    Program interaction

    The Windows API mostly concerns itself with the interaction between the operating system and an application. For communication between the different Windows applications among themselves, Microsoft has developed a series of technologies alongside the main Windows API. This started out with Dynamic Data Exchange (DDE), which was superseded by Object Linking and Embedding (OLE) and later by the Component Object Model (COM), Automation Objects, ActiveX controls, and the .NET Framework. There is not always a clear distinction between these technologies, and there is quite a lot of overlap.

    The variety of terms is basically the result of grouping software mechanisms that relate to a particular aspect of software development. Automation specifically relates to exporting the functionality of an application or component (as an API) so that it can be controlled by another application instead of just by a human user, .NET is a self-contained general methodology and technology for developing Desktop and Web applications written in a variety of "Just in Time" compiled languages.

    Wrapper Libraries

    Various wrappers were developed by Microsoft that took over some of the more low level functions of the Windows API, and allowed applications to interact with the API in a more abstract manner. Microsoft Foundation Class Library (MFC) wrapped Windows API functionality in C++ classes, and thus allows a more object oriented way of interacting with the API. The Active Template Library (ATL) is a template oriented wrapper for COM. The Windows Template Library (WTL) was developed as an extension to ATL, and intended as a lightweight alternative to MFC.

    Also notable are some of Borland's offerings. Object Windows Library (OWL) was released to compete with MFC, and offered a similar object-oriented wrapper. Borland later deprecated it in favour of the Visual Component Library (VCL), which is written in Object Pascal and available in both Delphi and C++ Builder.

    Most application frameworks for Windows (at least partially) wrap the Windows API. Thus, the .NET Framework and Java, likewise any other programming languages under Windows, are (or contain) wrapper libraries.

    Windows API Code Pack for Microsoft .NET Framework is a .Net wrapper library for Windows API.


    The Windows API has always exposed a large part of the underlying structure of the Windows systems to the programmer. This has had the advantage of giving Windows programmers a great deal of flexibility and power over their applications. However, it also has given Windows applications a great deal of responsibility in handling various low-level, sometimes tedious, operations that are associated with a graphical user interface.

    Charles Petzold, writer of several books about programming against the Windows API, has said: "The original hello world program in the Windows 1.0 SDK was a bit of a scandal. HELLO.C was about 150 lines long, and the HELLO.RC resource script had another 20 or so more lines. (...) Veteran C programmers often curled up in horror or laughter when encountering the Windows hello-world program."

    Over the years, various changes and additions were made to the Windows Operating System, and the Windows API changed and grew to reflect this. The Windows API for Windows 1.0 supported fewer than 450 function calls, where in modern versions of the Windows API there are thousands. However, in general, the interface remained fairly consistent, and an old Windows 1.0 application will still look familiar to a programmer who is used to the modern Windows API.M

    An emphasis has been made by Microsoft on maintaining software backwards compatibility. To achieve this, when developing a new version of Windows, Microsoft sometimes had to implement workarounds to allow compatibility with third-party software that used the previous version's API in an undocumented or even (programmatically) illegal way. Raymond Chen, a Microsoft developer who works on the Windows API, has said: "I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure."

    One of the largest changes the Windows API underwent was the transition from Win16 (shipped in Windows 3.1 and older) to Win32 (Windows NT and Windows 95 and up). While Win32 was originally introduced with Windows NT 3.1 and Win32s allowed usage of a Win32 subset before Windows 95, it was not until Windows 95 that widespread porting of applications to Win32 began. To ease the transition, in Windows 95, both for external developers and for Microsoft itself, a complex scheme of API thunks was used that could allow 32 bit code to call into 16 bit code and (for the majority of Win16 APIs) vice-versa. Flat thunks allowed 32 bit code to call into 16 bit libraries, and the scheme was used extensively inside Windows 95's libraries to avoid porting the whole OS to Win32 itself in one chunk. In Windows NT, the OS was pure 32-bit (except the parts for compatibility with 16-bit applications), and only generic thunks were available to thunk from Win16 to Win32, as for Windows 95. The Platform SDK shipped with a compiler that could produce the code necessary for these thunks.


    Almost every new version of Microsoft Windows has introduced its own additions and changes to the Windows API.[16] The name of the API, however, remained consistent between different Windows versions, and name changes were kept limited to major architectural and platform changes for Windows. Microsoft eventually changed the name of the then current Win32 API family into Windows API, and made it into a catch-all term for both past and future versions of the API.

    Win16 is the API for the first, 16-bit versions of Microsoft Windows. These were initially referred to as simply the "Windows API", but were later renamed to Win16 in an effort to distinguish them from the newer, 32-bit version of the Windows API. The functions of Win16 API mainly reside in the core files of the OS: kernel.exe (or krnl286.exe or krnl386.exe), user.exe and gdi.exe. Despite the file extension of exe, these actually are dynamically linked libraries.

    Win32 is the 32-bit API for modern versions of Windows. The API consists of functions implemented, as with Win16, in system DLLs. The core DLLs of Win32 are kernel32.dll, user32.dll, and gdi32.dll. Win32 was introduced with Windows NT. The version of Win32 shipped with Windows 95 was initially referred to as Win32c, with the "c" standing for "compatibility", but this term was later abandoned by Microsoft in favour of Win32.

    Win32s is an extension for the Windows 3.1x family of Microsoft Windows that implemented a subset of the Win32 API for these systems. The "s" stands for "subset".

    Win64 is the variant of the API implemented on 64-bit platforms of the Windows architecture (as of 2011 AMD64 and IA-64.) Both 32-bit and 64-bit versions of an application can be still compiled from a single codebase, although some older APIs have been deprecated, and some of the APIs that were already deprecated in Win32 were entirely removed. All memory pointers are 64-bit by default (the LLP64 model), so the source code has to be checked for compatibility with 64-bit pointer arithmetic and rewritten as necessary.

    WinCE is the implementation of the Windows API for the Windows CE operating system.

    Other implementations

    The Wine project is an attempt to provide a Win32 API compatibility layer for Unix-like platforms. ReactOS goes a step further and aims to provide an implementation of the entire Windows operating system, working closely with the Wine project to promote code re-use and compatibility. DosWin32 and HX DOS-Extender are other projects which emulate the Windows API allowing the execution of simple Windows programs from a DOS command line. Odin is a project to emulate Win32 on top of OS/2, superseding the original Win-OS/2 emulation which was based on Microsoft code.

    Windows Interface Source Environment (or WISE) was a licensing program from Microsoft which allowed developers to recompile and run Windows-based applications on UNIX and Macintosh platforms. WISE SDKs were based on an emulation of the Windows API that could run on Unix and Macintosh platforms.

    Other minor implementations and/or standardisation efforts include the MEWEL and Zinc libraries which were intended to implement a subset of the Win16 API on top of DOS (see List of platform-independent GUI libraries), and ECMA-234 which attempted to subject the Windows API to binding standardisation.

    Compiler support

    To develop software that utilizes the Windows API, a compiler must be able to handle and import the Microsoft-specific DLLs and COM-objects. The compiler must either handle the header files that expose the interior API function names, or supply such files by itself. For certain classes of applications, the compiler system should also be able to handle IDL (interface definition language) files. Collectively, these prerequisites (compilers, tools, libraries, and headers) are known as the Microsoft Platform SDK. For a long time, the Microsoft Visual Studio family of compilers and tools and Borland's compilers were the only tools that could provide this (although at least in the case of Windows, the SDK itself is downloadable for free separately from the entire IDE suite, from Microsoft Windows SDK for Windows 7 and .NET Framework 4). Nowadays, the MinGW and Cygwin projects also provide such an environment based on the GNU Compiler Collection, using a stand-alone header file collection to make linking against Microsoft DLLs possible. LCC-Win32 is a "free for non-commercial use" C compiler maintained by Jacob Navia. Pelles C is another freeware C compiler maintained by Pelle Orinius. Free Pascal is a free software Object Pascal compiler capable of writing software based on the Windows API. The MASM32 package is a mature project providing support for the Windows API under Microsoft's Macro Assembler by using custom made or converted headers and libraries from the Platform SDK. FASM allows to build Windows programs without the use of an external linker, even when running on Linux.

    Windows specific compiler support is also required for the Structured Exception Handling feature (SEH). This system serves a dual purpose: it provides a substrate upon which language-specific exception handling can be implemented, and it is how the kernel notifies applications of exceptional conditions such as dereferencing an invalid pointer or stack overflow. The Microsoft/Borland C++ compilers had the ability to use this system as soon as it was introduced in Windows 95 and NT, however the actual implementation was undocumented and had to be reverse engineered for the Wine project and free compilers. SEH is based on pushing exception handler frames onto the stack, then adding them to a linked list stored in thread local storage (the first field of the thread environment block). When an exception is thrown, the kernel and base libraries unwind the stack running handlers and filters as they are encountered. Eventually, every exception unhandled by the application itself will be dealt with by the default backstop handler, which pops up the Windows common crash dialog.

    Microsoft Windows SDK :

    Microsoft Windows SDK

    Microsoft Windows SDK, Platform SDK, and .NET Framework SDK are software development kits from Microsoft that contain header files, libraries, samples, documentation and tools required to develop applications for Microsoft Windows and .NET Framework.

    The difference between these three SDKs lies in their area of specialization: Platform SDK specializes in developing applications for Windows 2000, XP and Windows Server 2003. .NET Framework SDK is dedicated to developing applications for .NET Framework 1.1 and .NET Framework 2.0. Windows SDK is the successor of the two and supports developing applications for Windows XP, Windows Vista, Windows 7, Windows Server 2008, .NET Framework 3.0, .NET Framework 3.5, and .NET Framework 4.0. It contains extensive documentation and around 800 samples.

    Obtaining the SDK

    Windows SDKs are available free on the Microsoft Download Center, in ISO and Web-download formats. Users can install the entire SDK or choose to install only some SDK components, such as code samples demonstrating only native development or only the tools for managed development. Some Windows SDK components are also included in Microsoft Visual Studio.


    Microsoft SDK version release history

    • Microsoft Platform SDK : April 1999 : 1999-04
    • Microsoft Platform SDK : September 1999 : 1999-09
    • Last Platform SDK to fully support Visual C++ 5.0
    • Microsoft Platform SDK February 2001 : 2001-02 ?
    • Microsoft Platform SDK June 2001 : 2001-06
    • Last Platform SDK to officially develop for Windows 95. (Does not officially install on Windows 95)
    • Microsoft Platform SDK August 2001 : 2001-08 : MSDN subscription CD-ROM disc.
    • Last Platform SDK to unofficially develop for Windows 95. (Does not officially install on Windows 95)
    • Microsoft Platform SDK July 2002 : 2002-07
    • Microsoft Platform SDK August 2002 : 2002-08
    • Microsoft Platform SDK October 2002 : 2002-10
    • Microsoft Platform SDK February 2003 : 5.2.3790.0 2003-02 Download (links on MSDN forum post) Last version with VC6 support
    • .NET Framework 1.1 SDK (included in Visual Studio 2003) : 1.1.4322.573 2003-03-29 Download Does not include the Platform SDK
    • Microsoft Platform SDK for Windows XP SP2 : 5.1.2600.2180 2004-08 Download (links on MSDN forum post)
    • Windows Server 2003 SP1 Platform SDK : 5.2.3790.1830.15 2005-05-02 Download
    • Windows Server 2003 R2 Platform SDK : 5.2.3790.2075.51 2006-03-14 Download Also suggested by MS to work with VS6
    • .NET Framework 2.0 SDK (Included in Visual Studio 2005 Professional) : 2.0.50727.42 2006-11-29 Download Does not include the Platform SDK
    • Microsoft Windows Software Development Kit for Windows Vista and .NET Framework 3.0 Runtime Components v6.0 6.0.6000.16384 2006-10-30 The Windows SDK for Vista has been finalized and is now available for download Now only Web Installer available The C++ compilers in this SDK release support the /analyze key.
    • Windows Vista Update & .NET 3.0 SDK v6.1 6.1.6000.16384.10 2007-03-22 Download First unified .NET and Platform SDK. Does not support Visual Studio .NET 2003 and Microsoft Visual C++ Toolkit 2003
    • Included in Visual Studio 2008 v6.0a 6.1.6723.1 2007-11-19 Download
    • Windows Server 2008 & .NET 3.5 SDK v6.1 6.0.6001.18000.367 2008-02-05 Download .NET Framework 3.5
    • Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP 1 v7.0 6.1.7600.16385 2009-07-24 Download
    • Included in Visual Studio 2010 v7.0a 6.1.7600.16385 2010-04-12 Download .NET Framework 4
    • Microsoft Windows SDK for Windows 7 and .NET Framework 4 v7.1 7.1.7600.0.30514 2010-05-21 Download
    • Microsoft Windows SDK for Windows 8 and .NET Framework 4.5 v8.0a 6.2.9200.16384 2012-11-15 Download .NET Framework 4.5, Windows Store apps and Integrated DirectX SDK

  • .

    Targeting Windows Vista development with the Windows SDK

    Starting with Windows Vista, the Platform SDK has been replaced by the Windows SDK. The change of name is to better reflect the content included, and to offer the documentation, samples, build environment and tools needed to develop Windows applications all in one place. Also, the SDK for .NET Framework 3.0 (previously known as WinFX) /.NET Framework 3.5 and .NET Framework 2.0 (which is also now a part of .NET Framework 3.0) is included in the Windows SDK. The Tablet PC SDK and the Windows Media SDK (Windows Media Player 11 SDK, Windows Media Format 11 SDK and the Windows Media Device Manager 11 SDK) are also included. Thus, all the APIs which ship with Windows Vista / Windows Server 2008 and the latest compilers are now integrated into the Windows SDK. However, the .NET Framework 1.1 SDK is not included since the .NET Framework 1.1 does not ship with Windows Vista. Also, the Windows Media Center SDK for Windows Vista ships separately.

    The Windows SDK allows the user to specify where the SDK will be installed and what components will be installed where. This new SDK integrates better with Visual Studio, so multiple copies of tools are not installed. Information shown can be filtered by content, such as showing only new Windows Vista content, Win32 development content, .NET Framework development content; or by language or a specific technology.

    SDK support for older operating systems

    A developer might want to use an older SDK for a particular reason. For example, the Windows Server 2003 Platform SDK released in February 2003 was the last SDK to provide full support of Visual Studio 6.0. Some older PSDK versions can still be downloaded from the Microsoft Download center; others can be ordered on CD/DVD.

    64-bit development

    The Platform SDK also contains the resources (tools, documentation, samples, etc.) and compilers needed for 64-bit development on x86, x64 and Itanium (IA-64) platform architectures.

    Tools, headers and libraries

    The Windows SDK contains the following.

    For Win32 development:

    • 1,915 headers
    • 348 libraries
    • 100 tools
    • For .NET (managed code) development:
    • 14 reference assemblies supporting .NET, Tablet PC, Windows PowerShell, MMC, etc.
    • 33 IntelliSense files
    • 70 .NET 2.0 tools + 10 .NET 3.0 tools + 35 .NET 4.0 tools
    • For Visual Studio 2005/2008/2010 integration
    • Utilities to enable Visual Studio 2005/2008 to easily use Windows SDK headers and libraries
    • Visual Studio 2005/2008 wizards for creating Windows Media Player applications
    • Some users may encounter problems with Visual Studio 2010 and recent Windows SDK in a non-English environment due to a bug in Windows SDK configurator.

  • .

    Standard Template Library :

    Standard Template Library

    The Standard Template Library (STL) is a software library for the C++ programming language that influenced many parts of the C++ Standard Library. It provides four components called algorithms, containers, functional, and iterators.

    The STL provides a ready-made set of common classes for C++, such as containers and associative arrays, that can be used with any built-in type and with any user-defined type that supports some elementary operations (such as copying and assignment). STL algorithms are independent of containers, which significantly reduces the complexity of the library.

    The STL achieves its results through the use of templates. This approach provides compile-time polymorphism that is often more efficient than traditional run-time polymorphism. Modern C++ compilers are tuned to minimize any abstraction penalty arising from heavy use of the STL.

    The STL was created as the first library of generic algorithms and data structures for C++, with four ideas in mind: generic programming, abstractness without loss of efficiency, the Von Neumann computation model, and value semantics.


    The STL implements five different types of iterators. These are input iterators (that can only be used to read a sequence of values), output iterators (that can only be used to write a sequence of values), forward iterators (that can be read, written to, and move forward), bidirectional iterators (that are like forward iterators, but can also move backwards) and random access iterators (that can move freely any number of steps in one operation).

    It is possible to have bidirectional iterators act like random access iterators, as moving forward ten steps could be done by simply moving forward a step at a time a total of ten times. However, having distinct random access iterators offers efficiency advantages. For example, a vector would have a random access iterator, but a list only a bidirectional iterator.

    Iterators are the major feature that allow the generality of the STL. For example, an algorithm to reverse a sequence can be implemented using bidirectional iterators, and then the same implementation can be used on lists, vectors and deques. User-created containers only have to provide an iterator that implements one of the five standard iterator interfaces, and all the algorithms provided in the STL can be used on the container.

    This generality also comes at a price at times. For example, performing a search on an associative container such as a map or set can be much slower using iterators than by calling member functions offered by the container itself. This is because an associative container's methods can take advantage of knowledge of the internal structure, which is opaque to algorithms using iterators.


    A large number of algorithms to perform operations such as searching and sorting are provided in the STL, each implemented to require a certain level of iterator (and therefore will work on any container that provides an interface by iterators).


    The STL includes classes that overload the function call operator (operator()). Instances of such classes are called functors or function objects. Functors allow the behavior of the associated function to be parameterized (e.g. through arguments passed to the functor's constructor) and can be used to keep associated per-functor state information along with the function. Since both functors and function pointers can be invoked using the syntax of a function call, they are interchangeable as arguments to templates when the corresponding parameter only appears in function call contexts.

    A particularly common type of functor is the predicate. For example, algorithms like find_if take a unary predicate that operates on the elements of a sequence. Algorithms like sort, partial_sort, nth_element and all sorted containers use a binary predicate that must provide a strict weak ordering, that is, it must behave like a membership test on a transitive, non reflexive and asymmetric binary relation. If none is supplied, these algorithms and containers use less by default, which in turn calls the less-than-operator.

    • Original STL implementation by Stepanov and Lee. 1994, Hewlett-Packard. No longer maintained.
    • SGI STL, based on original implementation by Stepanov & Lee. 1997, Silicon Graphics. No longer maintained.
    • libstdc++ from gnu (was part of libg++)
    • libc++ from clang
    • STLPort, based on SGI STL
    • Rogue Wave Standard Library (HP, SGI, SunSoft, Siemens-Nixdorf)
    • Dinkum STL library by P.J. Plauger
    • The Microsoft STL which ships with Visual C++ is a licensed derivative of Dinkum's STL.
    • Apache C++ Standard Library (The starting point for this library was the 2005 version of the Rogue Wave standard library)

  • .

    Windows Template Library :

    Windows Template Library

    The Windows Template Library (WTL) is a free software, object-oriented C++ template library for Win32 development. WTL was created by Microsoft employee Nenad Stefanovic for internal use and later released as an unsupported add-on to Visual Studio and the Win32 Framework SDK. It was developed primarily as a light-weight alternative to the Microsoft Foundation Classes and builds upon Microsoft's ATL, another lightweight API widely used to create COM and ActiveX libraries.


    WTL provides support for implementing various user interface elements, from frame and popup windows, to MDI, standard and common controls, common dialogs, property sheets and pages, GDI objects, and other common UI elements, such as scrollable windows, splitter windows, toolbars and command bars. WTL's main objective is to deliver small and efficient code, close in size and speed to "straight" SDK programs while providing a higher-level and more flexible object model to developers. Other classes such as a string wrapper that is syntax-compatible with MFC's CString and some templated collections are also included.

    Most of the WTL API is a mirror of the standard Win32 calls, so the interface tends to be familiar to most Windows programmers. Although no official documentation from Microsoft exists, the WTL Documentation Project is attempting to create a comprehensive reference for the library. The WTL is not supported by Microsoft Product Support Services.

    Microsoft Foundation Class Library :

    Microsoft Foundation Class Library


    MFC was introduced in 1992 with Microsoft's C/C++ 7.0 compiler for use with 16-bit versions of Windows as an extremely thin object-oriented C++ wrapper for the Windows API. C++ was just beginning to replace C for development of commercial application software at the time. In an MFC program, direct Windows API calls are rarely needed. Instead, programs create objects from Microsoft Foundation Class classes and call member functions belonging to those objects. Many of those functions share their names with corresponding API functions.

    One interesting quirk of MFC is the use of "Afx" as the prefix for many functions, macros and the standard precompiled header name "stdafx.h". During early development what became MFC was called "Application Framework Extensions" and abbreviated "Afx". The name Microsoft Foundation Classes (MFC) was adopted too late in the release cycle to change these references.

    MFC 8.0 was released with Visual Studio 2005. MFC 9.0 was released with Visual Studio 2008. MFC is not included in the free edition of Visual C++ 2005/2008/2010 Express. but is included in the commercial versions of Visual C++ 2010 and Visual C++ 2012.

    The Object Windows Library (OWL), designed for use with Borland's Turbo C++ compiler, was a competing product introduced by Borland around the same time. Eventually, Borland discontinued OWL development and licensed the distribution of the MFC headers, libraries and DLLs from Microsoft for a short time, though it never offered fully integrated support for MFC. Borland later released VCL (Visual Component Library) to replace the OWL framework.

    Microsoft's emphasis on MFC has been reduced in favor of its .NET Framework. MFC 7, 8 and 9 bridge elements of MFC with the .NET Framework to aid developers in migrating to the new framework. The MSVC++ compiler backend can emit managed and native object file(s). The linker can then build them together, generating mixed (both managed and native) applications, allowing existing native applications to use managed extensions in a seamless manner. Though Microsoft has de-emphasized MFC, it remains a widely used framework.

    A lightweight alternative to MFC is the Windows Template Library (WTL). C++ Express version compiles WTL applications (if Active Template Library is installed), but does not include the IDE support of the Standard, Professional and Team editions.


    This section needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (November 2011)

    At the time of its introduction, MFC provided C++ macros for Windows message-handling (via Message Maps), exceptions, run-time type identification (RTTI), serialization and dynamic class instantiation.

    The macros for message-handling aimed to reduce memory consumption by avoiding gratuitous virtual table use and also to provide a more concrete structure for various Visual C++-supplied tools to edit and manipulate code without parsing the full language. The message-handling macros replaced the virtual function mechanism provided by C++.

    The macros for serialization, exceptions, and RTTI predated availability of these features in Microsoft C++ by a number of years. 32-bit versions of MFC, for Windows NT 3.1 and later Windows operating systems, used compilers that implemented the language features and updated the macros to simply wrap the language features instead of providing customized implementations, realizing upward compatibility.

    Visual C++ 2008 Feature Pack

    On 7 April 2008, Microsoft released an update to the MFC classes as an out-of-band update to Visual Studio 2008 and MFC 9. The update features new user interface constructs, including the ribbons (similar to that of Microsoft Office 2007) and associated UI widgets, fully customizable toolbars, docking panes (like Visual Studio 2005) which can either be freely floated or docked to any side and document tabs. The MFC ribbon resource editor allows the developer to design the ribbon graphically instead of having to use the XML-based declarative markup like the RibbonX API in Microsoft Office 2007. Optionally, ribbon components may be programmed directly by calling a new set of ribbon class methods. The developer has given permission to mix graphical and programmatic ribbon development as is convenient. The MFC application wizard has also been upgraded to support the new features - including a check-box to select whether the application will use the ribbon or the Visual Studio 2005 user interface elements. The new functionality is provided in new classes so that old applications still continue to run. This update is building on top of BCGSofts BCGControlBar Library Professional Edition.

    MFC can be used by linking a Static Library or by adding the MFC DLL.

    Microsoft has also imposed additional licensing requirements on users of the ribbons. These include a requirement to adhere to Microsoft UI Design Guidelines, and a prohibition against using such a UI in applications which compete with Microsoft Office applications.

    Visual Component Library :

    Visual Component Library

    The Visual Component Library (abbreviated VCL) is a visual component-based object-oriented framework for developing Microsoft Windows applications. It was developed by Borland for use in, and tightly integrated with, its Delphi and C++Builder RAD tools (now owned by CodeGear, division of Embarcadero Technologies). It is written in Object Pascal.

    A cross-platform equivalent of the VCL, called CLX (Component Library for Cross Platform), was later developed for use in Delphi, C++Builder and Kylix. However, it was abandoned.

    VCL forms a class hierarchy with a common ancestor, the TComponent class (which inherits from TObject, the root class in Delphi Object Pascal). This is a common approach shared by the Java programming language, Smalltalk, C# and many other object-oriented programming languages.

    VCL components cover Windows controls like windows (TForm class), controls (e.g., TButton, TCheckBox, TLabel classes) as well as database access (e.g., ADO or IBX components) or Internet connections (Indy components). The component approach allows programmers to extend the VCL with many visual and non-visual additional components. There is a large number of free and commercial component packages. Among them are JEDI, TMS, Developer Express, Mitov Software, Raize Software, TurboPower, IOComp, SDL, DA-SOFT Technologies and many others.

    While not all VCL components are thread-safe, VCL supports multi-threading too. One example is the built in multi-threading support of the OpenWire VCL library.

    VCL provides native support for PME (Properties, Methods and Events) model at the .NET level.

    .NET is modeled after VCL, since one of the main architects of the first Delphi versions, Anders Hejlsberg, went to Microsoft and was one of the main architects of .NET there. and thus Libre Office contains an unrelated graphic library also called VCL.

    Object Windows Library :

    Object Windows Library

    The Object Windows Library (OWL) is a Borland C++ object-oriented framework originally designed for Windows API. It was used in Turbo Pascal for Windows, Borland Pascal and their Borland C++ package. It was a competitor to the Microsoft Foundation Class Library (MFC).

    OWL had incomplete support by the Borland C++ IDE and wasn't always upwardly compatible from release to release. It was eventually deprecated in favor of the Visual Component Library (VCL), which is written in Object Pascal and included in Delphi and C++ Builder Studios.

    An open source internet community has released OWLNext, a series of improvements and patches to the original OWL which also allows newer compilers (Borland C++ Builder 5 - 6, GCC, Microsoft Visual C++ 6, 2003 - 2010, BDS C++ 2006, CodeGear C++ 2007 - 2010).


    In the early 1990s, Borland dominated the C++ market. In 1991 Borland introduced Borland C++ 3.0 with 'Application Frameworks' which included Turbo Vision for developing DOS applications and OWL for the Windows platform. C++ was just beginning to replace C for development of commercial specially with the rising of Windows platform (and the complexity that involves) this allowed to OWL to gain some popularity.

    The first version implemented a proprietary extension called Dynamic Dispatch Virtual Tables (DDVT), this allowed objects to bind 'events' (windows messages) with 'methods' (functions). This mechanism avoided saturating the OO virtual function system with one function for each window message. In the next version of OWL, DDVT was replaced with a RESPONSE_TABLE, a macro based mechanism, which is maintained today. A conversion tool (OWLCVT) was included to migrate code from OWL1.0 to OWL2.0.

    In 1992, Microsoft launched MFC. A DOS version of MFC was short lived. The Windows version was simply a wrapper around Windows API, and was criticized for not being truly object oriented.

    In 1993, Borland launched Borland C++ 2.0 for OS/2 which included a version of OWL 2.0. OWL 2.0 used BIDS, the newer template library for 'container' or 'class library'.

    In April 1993, Borland and Novell settled an agreement to port OWL to Novell AppWare Foundation. AppWare Foundation was an API designed by Novell to be cross-platform, allowing deploy apps in Mac, Windows and Unix clients and with several Networks services. The main tools for developing in AppWare were OWL and AppBuilder (a visual tool to link Application Loadable Modules through an 'Application Bus').

    In January 1994, Borland launched Borland C++ 4.0 for Windows which also included OWL 2.0. It added Doc/View support, VBX controls, OLE. Win16, Win32s and Win32 was supported (Windows 95, the Win32 successor of Windows 3.x appeared in August 1995).

    Late in 1994, Novell CEO Raymond Noorda resigned. Novell expansion plans were reconsidered, AppWare development was stopped and so was OWL for AppWare. In 1995 a group of original team members bought AppBuilder. In the same year, Software UNO ( offered a commercial port for OWL 2.0, to several platforms: AIX 3.2.5, DEC OSF/1 AXP, HP-UX 9.03, Linux 1.2, Solaris 2.x, Sun OS 4.1.x, and SVR4 fox x86, it was called WM_MOTIF.

    Early in 1995, Borland C++ 4.5 with OWL 2.5 was launched. As it was launched before Win95, Borland promised a free upgrade for any incompatibility present in the final Windows 95 (when available). Versions 4.51 and 4.52 followed. OWL 2.5 also included the Object Component Framework (OCF) to ease OLE development.

    In August 1995, Microsoft released Windows 95 and Visual Studio 4.0. Contrary to popular belief, the inclusion of the MFC40.DLL with Windows 95 did not have a huge impact on the adoption of MFC. By 1995, Visual Studio 1.5 had already eclipsed Borland C++ in shipments, due partly to the volume and quality of documentation included with Visual Studio. The nearly seamless transition of MFC projects from Visual Studio 1.5 and Visual Studio 4.0 also contributed to its popularity. The instability of the original Borland C++ 4.5 and quirky treatment of OWL also persuaded many developers to drop Borland C++ and OWL in favor of Visual C++ and MFC.

    In 1996, Borland launched Borland C++ 5 for Windows, which included OWL 5, which was a major revamp of the library. In August 1997, Borland C++ 5.02 was introduced with slightly updated a version of OWL 5. A Japanese edition was also available. Additionally, the Borland C++ Builder has included OWL in the 'companion CD'. After that Borland concentrated development in the VCL framework which has been evolving alongside OWL since Delphi 1.0 launched two years before. VCL continues to be the main framework of Borland (now Codegear) for Windows and .NET platforms. Examples on how linkage OWL apps with VCL Forms (Dialogs) were included in the last version of Borland C++. Borland stopped selling Borland C++ 5.02 and OWL in late 1999.

    After Borland deprecated OWL, development was taken over by group and is called OWLNext which consists of patches to the original OWL source code. It was included in the partner discs of Borland C++ Builder 2007 and Borland C++ Builder XE.


    OWL applications supports (non-exhaustive list) Single/Multiple Document Interface (SDI/MDI), Doc & View Document Model, Drag&Drop, print and print-preview, GDI encapsulation, Windows Help (Winhelp), mail and messaging (MAPI), Internet (OwlSock/WinSock), OLE 1.0 and OLE 2.0 and other features. The "Borland Windows Custom Controls", an alternative to the standard widget set in Windows 3.1, were available in some versions of OWL, and this support propagated their unique look throughout many applications of the era.

    In OWL, all classes start with letter "T" (e.g. TApplication); there are several root classes, the most common is TWindow from which window classes (e.g. TFrameWindow, TDecoratedFrameWindow, TDialog, TInputDialog, TFileOpenDialog, etc.) and controls classes (TEdit, TStatic, TButton, TGlyphButton, TComboBox, etc.) are derived. VCL classes also has the same prefix, but in VCL, all classes are derived from TComponent. Applications made with OWLNext are compatible with DEP/NX feature which defend system against virus/internet attacks. OWLNext supports Unicode, even on the Unicode non-compliant Windows 9x.

    Well designed Object oriented framework, provides real encapsulation of Windows APIs, allows inheritance and polymorphism. C++ class for many common Windows resource-related data types that provide automatic closure of handles when the objects creating them go out of scope.
    • Provides a Document/View framework for creating Model-View-Controller-based architectures
    • OWL comes with BIDS (Borland International Data Structure) a template class library
    • OWLNext uses the Standard Template Library (STL), which simplifies ports to other platforms
    • String class included in OWL
    • Faster executables than Visual Basic P-Code Executables or java
    • Faster executables than those produced by the .NET Framework
    • OWLNext developers can use the IDE of their choice: Borland C++ 5.0, Visual Studio 6.0, 2003 - 2010, BDS 2006 - 2007
    • Windows API can be accessed directly from OWL based programs
      Small GUI executables:
    • Executables do not require the end-user to have the .NET Framework, which is a 22.4 MB download
    • Executables do not require VB runtime
    • Executables can use 'static' libraries
    • Several wizards are available for a variety of tasks, including third party tools, which reduced the work to generate the minimal working applications.
    • Fast compilation speed.
    • Ported to Linux, free and open-source solution.
    • Source code included. Developers can build an optimized version for a particular CPU.
    • Namespaces supported.
    • Windows 95 to Windows 7 compatible. Win 3.x supported until OWLNext 6.20.x

    • Disadvantages
    • Not ported to Mac OS X, Windows CE, or other not common platforms.
    • Alternatives such as VCL provide rapid application development (RAD).
    • Windows API is not completely covered, requiring deeper knowledge of it.
    • Significantly fewer users than MFC.
    • Poor third party support in the form of books, web sites, articles and third party libraries (such as Codejock Software)
    • No native support for JPEG or PNG files

  • .

    OWLNext :


    When Borland deprecated OWL in favor of VCL, a group of developers led by Yura Bidus started the project of maintaining the library in 1998. The original websites were, and Currently, the project is hosted by SourceForge: or The extension is open source, free and the license allows the development of commercial applications.

    The original name was OWL NExt, where the meaning of NExt was New Extensions. Later, it was joined to OWLNExt and currently, it is called OWLNext. The current version as of 2007 is OWLNext 6.20; the last version to officially support the Win16 platform.

    OWLNext supports Unicode, even allowing developers to deploy Unicode-based applications in Win95. Added support for HTMLHelp.

    OWL is still the property of Borland and is covered by several patents[citation needed], however the version included in the 'Companion CD' for C++Builder can be downloaded from the current CodeGear site. The CodeGear site also allows developers to download the version 6.04 of OWLNext, but the official site for OWLNext is SourceForge.

    Originally, OWL used BIDS (Borland International Data Structure) library as 'class library' (library for managing data structures like vectors, lists, etc.), OWLNext moved to STL (Standard Template Library), and also provides an emulation layer to minimize porting work for existing applications.

    Linux support was added to OWLNext in version 6.16 using WINELIB, and there are also private ports to Solaris. These ports are now being integrated into the upcoming OWLNext 6.40. Win64 support is planned for a future release. Currently there is no plan to support the .NET platform since native Vista will allow better performance.

    Base Class Library :

    Base Class Library

    The Base Class Library (BCL) is a Common Language Infrastructure (CLI) standard library available to all CLI languages. CLI includes the BCL in order to encapsulate a large number of common functions, such as file reading and writing, graphic rendering, database interaction, and XML document manipulation, which makes the programmer's job easier. It is much larger in scope than standard libraries for most other languages, including C++, and is comparable in scope and coverage to the standard libraries of Java. The .NET Framework, being the first implementation of CLI, is the origin of the BCL. It is sometimes incorrectly referred to as the Framework Class Library (FCL), but the FCL is actually a superset including Microsoft specific namespaces.

    The BCL is updated with each version of the .NET Framework.


    Some of the namespaces may or may not be officially considered part of the BCL by Microsoft, but all are included as part of the libraries that are provided with Microsoft's .NET Framework implementation of the CLI.

    Standardized namespaces

    These are the namespaces that are standardized as of the ECMA 335 and ISO/IEC 23271:2006 standards.


    This namespace includes the core needs for programming. It includes base types like String, DateTime, Boolean, and so forth, support for environments such as the console, math functions, and base classes for attributes, exceptions, and arrays.


    Defines many common containers or collections used in programming, such as lists, queues, stacks, hashtables, and dictionaries. It includes support for generics.


    Provides the ability to diagnose applications. It includes event logging, performance counters, tracing, and interaction with system processes.


    Provides help for writing internationalized applications. "Culture-related information, including the language, the country/region, the calendars in use, the format patterns for dates, currency, and numbers" can be defined.


    Enables reading from and writing to different streams, such as files or other data streams. Also provides a connection to the file system.


    Provides an interface "for many of the protocols used on networks today", such as HTTP, FTP, and SMTP. Secure communication is supported by protocols such as SSL.


    Provides an object view of types, methods, and fields; and "the ability to dynamically create and invoke types". It exposes the API to access the Reflective programming capabilities of CLR.


    Allows management of the runtime behavior of an application or the CLR. Some of the included abilities are interoperable with COM or other native code, writing distributed applications, and serializing objects into binary or SOAP.


    "Provides the underlying structure of the common language runtime security system." This namespace allows security to be built into applications based on policy and permissions. It provides services such as cryptography.


    Supports various encodings, regular expressions, and a more efficient mechanism for manipulating strings (StringBuilder).


    Helps facilitate multithreaded programming. It allows the synchronizing of "thread activities and access to data" and provides "a pool of system-supplied threads."


    "Provides standards-based support for processing XML," including reading, writing, schemas, serialization, searching, and transforming.


    The System.Diagnostics.CodeAnalysis namespace contains classes for interaction with code analysis tools. These tools are used to analyze code for conformance to coding conventions such as naming or security rules.


    Contains static classes for representing program contracts such as preconditions, postconditions, and invariants.


    Contains the classes used to instrument your application. The instrumentation, when enabled, logs the event data to the Event Tracing for Windows (ETW) tracing subsystem. For a complete description of ETW, see Event Tracing for Windows.


    Use the classes in this namespace to provide counter data. The counters are used to expose performance metrics to consumers such as the Performance Monitor. The namespace does not contain classes for consuming the counter data. For a complete description of the performance counters architecture, see Performance Counters.


    The System.Diagnostics.SymbolStore namespace provides classes that allow you to read and write debug symbol information, such as source line to Microsoft intermediate language (MSIL) maps. Compilers targeting the.NET Framework can store the debug symbol information into programmer's database (PDB) files. Debuggers and code profiler tools can read the debug symbol information at run time.

    Non-standardized namespaces

    These are the namespaces that are not standardized as of the ECMA and/or ISO standards and are specific to Microsoft implementation. However, even if implementing them is not mandatory, some of them may have been implemented completely or partially by other .NET implementations.


    This library provides the ability to create code and run it, at runtime.


    Provides the ability to implement the run-time and design-time behavior of components and controls. It contains the infrastructure "for implementing attributes and type converters, binding to data sources, and licensing components."


    Provides the infrastructure for handling configuration data.


    This namespace represents the ADO.NET architecture, which is a set of computer software components that can be used by programmers to access data and data services.


    Allows customization of the way applications upgrade when using ClickOnce.


    Provides easy access to Active Directory from managed code.


    Provides access to GDI+ graphics functionality, including support for 2D and vector graphics, imaging, printing, and text services.


    "Provides .NET objects with access to COM+ services making the .NET Framework objects more practical for enterprise applications."


    Defines the IQueryable interface and related methods, that lets LINQ providers to be plugged in.


    Allows Delegates and Lambda expressions to be represented as expression trees, so that the high-level code can be examined and processed at runtime.


    Allows querying for system information, "such as how much free space is left on the disk, what is the current CPU utilization, which database a certain application is connected to, and much more."


    Provides the ability to play system sounds and WAV files.


    Provides the ability "to connect to, monitor, and administer message queues on the network and send, receive, or peek messages." .NET Remoting is another name for some of the functionality provided. This namespace is being superseded by Windows Communication Foundation.


    Allows management of resources in the application in order to internationalize an application for different cultures and languages.


    Allows the creation of applications that run as a service within Windows.


    "Allows you to raise an event on a specified interval."


    Provides support for local or distributed transactions.


    Provides various web related functionality. It enables browser-server communication and the creating XML Web services. Most or all of these libraries are referred to as the ASP.NET architecture.


    This namespace contains the Windows Forms architecture which provides access to the native Windows interface elements by wrapping the existing Windows API. This allows for writing graphical applications for Windows from within managed code. This system is being superseded by the Windows Presentation Foundation.

    Text Object Model :

    Text Object Model

    The Text Object Model (TOM) is a Microsoft Windows API that provides developers with object-based rich text manipulation interfaces. It is implemented through COM, and can be accessed through Microsoft Word or additionally through the RichEdit controls that normally ship with Windows.


    When TOM was developed, it was influenced heavily by WordBasic, a macro language used within Word before VBA (Word 95 and previous releases). TOM has developed alongside the RichEdit technology, and has been present since version 1.0 of the RichEdit components. The API has been available as an option for Windows CE since the 2.5 release of RichEdit (Western Languages Only), which was at least used by Pocket Word at that time.

    Technical details

    To retrieve an implemented instance of ITextDocument interface (the top-level document interface), the EM_GETOLEINTERFACE message may be sent via the SendMessage API to obtain a pointer to an IRichEditOle object, which also implements the ITextDocument interface. TOM may operate differently depending on the version of the RichEdit control the interface is retrieved for (RICHEDIT50W windows provide more functionality than the standard RICHEDIT20W or RICHEDIT20A controls, like proper table support).

    COM Interfaces

    A top-level interface. Documents may be opened and saved through this interface. Some screen update control is achieved here as well. Undo/redo grouping is implemented here. Arbitrary text ranges (ITextRange) and a text range for currently selected text (ITextSelection) are provided, which are used to modify or review the document.


    Provides editing and data-binding tools to select text within a document, that can be examined, modified, or removed. Ranges exist within paragraphs, and the paragraph a range is within is accessible through a property of this object.


    Provides selection information, in addition to functionality provided by the ITextRange.

    ITextFont ( Dual Interface with ITextPara )

    A mechanism for inspection and modification of rich edit font attributes, that is considerably more extensive that the standard OLE interface used to describe a font (IFontDisp, StdFont).

    ITextPara ( Dual Interface with ITextFont )

    Provides extensive information about the position, formatting outside of fonts (e.g. first line indent), behavior (e.g. widow control), and purpose of a paragraph (it could be a normal paragraph, a list, a table, etc).

    Win32 Console :

    Win32 console

    Windows PowerShell using the Win32 console window on Windows Vista.

    GNU Midnight Commander using box drawing characters in the Win32 console.
    Win32 console is a text user interface implementation within the system of Windows API, which runs console applications. A Win32 console has a screen buffer and an input buffer, and is available both as a window or in text mode screen, with switching back and forth available via Alt-Enter keys.

    Win32 consoles are typically used for applications that do not need to display images but which might use color. Examples include command line interface tools; command line interpreters such as CMD.EXE, Windows PowerShell or Korn shell; file managers such as Far Manager and Midnight Commander; and editors such as the MS-DOS Editor.

    Window and full screen modes

    A Win32 console application may run in two modes.
    One mode places the text in a window and uses an operating system's font rendering. In this mode, an application's interaction with user is controlled by the windowing system. This is analogous to X Window System applications such as xterm.

    In a full screen mode Win32 console uses a hardware text mode and uploads a raster font to the video adapter. This is analogous to a text system console. Full screen uses Windows' built-in VGA driver, rather than any installed graphics drivers, unless another driver is VGA-compatible. Therefore, it only supports VGA-compatible text modes, giving it a maximum character resolution of 80 columns by 28 rows. This contrasts with comparable consoles in various other operating systems such as Linux, which are able to display higher resolutions through different drivers.

    An application can be instantly switched between these two modes with Alt-? Enter key combination. Text environments in Unix-like systems usually do not have such a feature.


    The input buffer is a queue where events are stored (from keyboard, mouse etc.). The output buffer is a rectangular grid where characters are stored, together with their attributes. A console window may have several output buffers, only one of which is active (i.e. displayed) for a given moment.

    The console window may be displayed as a normal window on the desktop, or may be switched to full screen to use the actual hardware text mode, if a video driver permits a chosen screen size. Unfortunately, the display mode is locked in background intensity mode, thus blinking does not work. Also, the underscore attribute is not available.

    Programs may access a Win32 console either via high-level functions (such as ReadConsole and WriteConsole) or via low-level functions (e.g. ReadConsoleInput and WriteConsoleOutput). These high-level functions are more limited than a Win32 GUI; for instance it is not possible for a program to change the color palette, nor is it possible to modify the font used by the console using these functions.

    Win32 console applications are often mistaken for MS-DOS applications, especially on Windows 9x and Windows Me. However, a Win32 Console application is, virtually, just a special form of a native Win32 application. Indeed, 32-bit Windows can run MS-DOS programs in Win32 console through the use of the NT Virtual DOS Machine (NTVDM).

    In earlier versions of Windows, there was no native support for consoles. Since Windows 3.1 and earlier was merely a graphical interface for MS-DOS, most text applications that ran on earlier Windows versions were actually MS-DOS applications running in "DOS boxes". To simplify the task of porting applications to Windows, early versions of Visual C++ were supplied with QuickWin, a library that implemented basic console functionality inside a regular Window (a similar library for Borland C++ was called EasyWin).

    Windows 9x and Me

    Windows 95/98/Me support is relatively poor compared to Windows NT, because the console window runs in the system virtual DOS machine and so keyboard input to a Win32 console application had to be directed to it by conagent.exe running in a DOS VM that are also used for real DOS applications by hooking the keyboard interrupt. conagent.exe then calls Vcond (which is a VxD). Vcond then had to pass the keyboard input to the System VM, and then finally to the Win32 console application. Besides performance, another problem with this implementation is that drives that are local to a DOS VM are not visible to a Win32 console application. This can cause confusion.

    Under Windows 95/98/Me, the screen buffer mirrors the structure of VGA text buffer, with two bytes per character cell: one byte for character code, one byte for attributes (the character must be in OEM character set, the attribute is with high-intensity background/no blinking). This speeds up operation considerably if the actual VGA text mode is used.

    Windows NT and CE based

    The Client/Server Runtime Subsystem is responsible for Win32 console windows on Windows NT based operating systems.
    Under Windows NT and CE based versions of Windows, the screen buffer uses four bytes per character cell: two bytes for character code, two bytes for attributes. The character is then encoded in a 16-bit subset of Unicode (UCS-2). For backward compatibility, the console APIs exist in two versions: Unicode and non-Unicode. The non-Unicode versions of APIs can use code page switching to extend the range of displayed characters (but only if TrueType fonts are used for the console window, thereby extending the range of codes available). Even UTF-8 is available as "code page 65001".

    Winsock :


    In computing, the Windows Sockets API (WSA), which was later shortened to Winsock, is a technical specification that defines how Windows network software should access network services, especially TCP/IP. It defines a standard interface between a Windows TCP/IP client application (such as an FTP client or a web browser) and the underlying TCP/IP protocol stack. The nomenclature is based on the Berkeley sockets API model used in BSD for communications between programs. Initially, all the participating developers resisted the shortening of the name to Winsock for a long time, since there was much confusion among users between the API and the DLL library file (winsock.dll) which only exposed the common WSA interfaces to applications above it. Users would commonly believe that only making sure the DLL file was present on a system would provide full TCP/IP protocol support.


    Early Microsoft operating systems, both MS-DOS and Microsoft Windows, offered limited networking capability, chiefly based on NetBIOS.

    In particular, Microsoft did not offer support for the TCP/IP protocol stack at that time. A number of university groups and commercial vendors, including the PC/IP group at MIT, FTP Software, Sun Microsystems, Ungermann-Bass, and Excelan, introduced TCP/IP products for MS-DOS, often as part of a hardware/software bundle.

    When Microsoft Windows 2.0 was released, these vendors were joined by others such as Distinct and NetManage in offering TCP/IP for Windows. The drawback faced by all of these vendors was that each of them used their own API (Application Programming Interface). Without a single standard programming model, it was difficult to persuade independent software developers to create networking applications which would work with any vendors underlying TCP/IP implementation. Add to this the fact that end users were wary of getting locked in to a single vendor and it became clear that some standardization was needed.

    The Windows Sockets API was proposed by Martin Hall of JSB Software (later Stardust Technologies) in a BoF (Birds of a Feather) discussion on the CompuServe BBS network in October 1991. The first edition of the specification was authored by Martin Hall, Mark Towfiq of Microdyne (later Sun Microsystems), Geoff Arnold of Sun Microsystems, and Henry Sanders and J Allard of Microsoft, with assistance from many others. There was some discussion about how best to address the copyright, intellectual property, and potential anti-trust issues, and consideration was given to working through the IETF or establishing a non-profit foundation. In the end, it was decided that the specification would simply be copyrighted by the five authors as (unaffiliated) individuals.


    The Windows Sockets API specification defines two interfaces: the API used by application developers, and the SPI, which provides a means for network software developers to add new protocol modules to the system. Each interface represents a contract. The API guarantees that a conforming application will function correctly with a conforming protocol implementation from any network software vendor. The SPI contract guarantees that a conforming protocol module may be added to Windows and will thereby be usable by an API-compliant application. Although these contracts were important when Windows Sockets was first released, since network environments required multi-protocol support (see above) they are now of only academic interest. Included in the Windows Sockets API version 2.0 are functions to use IPX/SPX, although the protocol was all but obsolete already at the time WSA 2.0 shipped. Microsoft has shipped the TCP/IP protocol stack with all recent versions of Windows, and there are no significant independent alternatives. Nor has there been significant interest in implementing protocols other than TCP/IP.

    Windows Sockets code and design are based on BSD sockets, but provides additional functionality to allow the API to comply with the regular Windows programming model. The Windows Sockets API covered almost all the features of the BSD sockets API, but there were some unavoidable obstacles which mostly arose out of fundamental differences between Windows and Unix (though to be fair Windows Sockets differed less from BSD sockets than the latter did from STREAMS). All function calls in the API begin with the moniker WSA, e.g. WSASend() for sending data on a connected socket.

    However it was a design goal of Windows Sockets that it should be relatively easy for developers to port socket-based applications from Unix to Windows. It was not considered sufficient to create an API which was only useful for newly-written Windows programs. For this reason, Windows Sockets included a number of elements which were designed to facilitate porting. For example, Unix applications were able to use the same errno variable to record both networking errors and errors detected within standard C library functions. Since this was not possible in Windows, Windows Sockets introduced a dedicated function, WSAGetLastError(), to retrieve error information. Such mechanisms were helpful, but application porting remained extremely complex. Many original TCP/IP applications had been implemented by using system features specific to Unix, such as pseudo terminals and the fork system call, and reproducing such functionality in Windows was problematic. Within a relatively short time, porting gave way to the development of dedicated Windows applications.

    Windows Management Instrumentation :

    Windows Management Instrumentation

    Windows Management Instrumentation (WMI) is a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF).

    WMI allows scripting languages like VBScript or Windows PowerShell to manage Microsoft Windows personal computers and servers, both locally and remotely. WMI is preinstalled in Windows 2000 and newer OSs. It is available as a download for Windows NT, Windows 95 and Windows 98.

    Microsoft also provides a command line interface to WMI called Windows Management Instrumentation Command-line (WMIC).

    Purpose of WMI

    The purpose of WMI is to define a proprietary set of environment-independent specifications which allow management information to be shared between management applications. WMI prescribes enterprise management standards and related technologies for Windows that work with existing management standards, such as Desktop Management Interface (DMI) and SNMP. WMI complements these other standards by providing a uniform model. This model represents the managed environment through which management data from any source can be accessed in a common way.

    Development process

    Because WMI abstracts the manageable entities with CIM and a collection of providers, the development of a provider implies several steps. The major steps can be summarized as follows:

    • Step 1 - Create the manageable entity model
    • Define a model
    • Implement the model

    • Step 2 - Create the WMI Provider
    • Determine the provider type to implement
    • Determine the hosting model of the provider
    • Create the provider template with the ATL wizard
    • Implement the code logic in the provider
    • Register the provider with WMI and the system

    • Step 3 - Test the provider
    • Step 4 - Create consumer sample code..

    • Importance of WMI providers

      Since the release of the first WMI implementation during the Windows NT 4.0 SP4 era (as an out-of-band download), Microsoft has consistently added WMI providers to Windows:

    • Under Windows NT 4.0, Microsoft had roughly 15 WMI providers available once WMI was installed
    • When Windows 2000 was released, there were 29 WMI providers as part of the operating system installation
    • With the release of Windows Server 2003, Microsoft included in the platform more than 80 WMI providers
    • Windows Vista includes 13 new WMI providers, taking the number close to around 100 in all
    • Windows Server 2008 includes more providers, including providers for IIS 7, PowerShell and virtualization
    • Many customers have interpreted the growth in numbers of providers as a sign that WMI has become at Microsoft the "ubiquitous" management layer of Windows, even if Microsoft has never made this commitment explicit.

  • .

    During these last years, due to a constant increasing exposure of management data through WMI in Windows, more and more people in the IT systems management field started to develop scripts and automation procedures based on WMI.[citation needed] Beyond the scripting needs, most leading management-software packages, such as MOM, SMS, ADS, HP OpenView for Windows (HPOV), BMC Software or CA, Inc. are WMI-enabled and capable of consuming and providing WMI information through various User Interfaces. This enables administrators and operators not capable of scripting or programming on top of WMI to enjoy the benefits of WMI without even learning about it. However, if they want to, because WMI is scriptable, it gives them the opportunity to consume WMI information from scripts or from any WMI-aware enterprise-management software.


    For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:
    Automation interfaces: Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out-of-the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate and test a scripting model as it is already available from WMI.

    .NET Management interfaces: Because the System.Management namespace relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all .NET applications independently of the language used (e.g. C#, VB.NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the .NET Framework as this support is already available from WMI for free.

    C/C++ COM/DCOM programming interfaces: Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and .NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre-defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience.

    Remoting capabilities over DCOM and SOAP: More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS-Management initiative led by Microsoft, Intel, Sun Microsystems and Dell. This initiative allows to run any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS-Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS-Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS-Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated.

    Support for Queries: WMI offers support for WQL queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider.

    Eventing capabilities: WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes.

    Code template generator: To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre-defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the -gaps- in the provider code to create the desired interfacing logic.

    Predictability: Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, .NET) whatever the manageable entity is.

    Protect existing customer investments: Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in-house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology.

    Provide a logical and unified administration model: As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF ( The CIM class-based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti-virus software and firewalls.

    WMI tools

    Some WMI tools can also be useful during the design and development phases. These tools are:

    The MOF compiler (MOFComp.exe): The Managed Object Format (MOF) compiler parses a file containing Managed Object Format statements and adds the classes and class instances defined in the file to the CIM repository. The MOF format is a specific syntax to define CIM class representation in an ASCII file (e.g. MIB are to SNMP what MOF files are to CIM). MOFComp.exe is included in every WMI installation. Every definition existing in the CIM repository is initially defined in an MOF file. MOF files are located in %SystemRoot%\System32\WBEM. During the WMI setup, they are loaded in the CIM repository.

    The WMI Administrative Tools: The WMI Administrative Tools are made of four tools: WMI CIM Studio, WMI Object Browser, WMI Event Registration and WMI Event Viewer. WMI Administrative Tools can be downloaded here. The most important tool for a WMI provider developer is WMI CIM Studio as it helps in the initial WMI class creation in the CIM repository. It uses a web interface to display information and relies on a collection of ActiveX components installed on the system when it runs for the first time. WMI CIM Studio provides the ability to:

    • Connect to a chosen system and browse the CIM repository in any namespace available.
    • Search for classes by their name, by their descriptions or by property names.
    • Review the properties, methods and associations related to a given class.
    • See the instances available for a given class of the examined system.
    • Perform Queries in the WQL language.
    • Generate an MOF file based on selected classes.
    • Compile an MOF file to load it in the CIM repository.

  • .

    WinMgmt.exe: WinMgmt.exe is not a tool; it is the executable that implements the WMI Core service. Under the Windows NT family of operating systems, WMI runs as a service. On computers running Windows 98, Windows 95 or Windows Me, WMI runs as an application. Under the Windows NT family of operating systems, it is also possible to run this executable as an application, in which case, the executable runs in the current user context. For this, the WMI service must be stopped first. The executable supports some switches that can be useful when starting WMI as a service or as an application. WMI provider developers who may want to debug their providers essentially need to run the WMI service as an application.

    WBEMTest.exe: WBEMTest.exe is a WMI tester tool, which is delivered with WMI. This tool allows an administrator or a developer to perform most of the tasks from a graphical interface that WMI provides at the API level. Although available under all Windows NT-based operating systems, this tool is not officially supported by Microsoft. WBEMTest provides the ability to:

    • Enumerate, open, create and delete classes.
    • Enumerate, open, create and delete instances of classes.
    • Select a namespace.
    • Perform data and event queries.
    • Execute methods associated to classes or instances.
    • Execute every WMI operation asynchronously, synchronously or semi-asynchronously.

  • .

    The WMI command line tool (WMIC): WMIC is a command-line tool designed to ease WMI information retrieval about a system by using some simple keywords (aliases). WMIC.exe is only available under Windows XP Professional, Windows Server 2003, Windows Vista, Windows 7 and Windows Server 2008. By typing -WMIC /?- from the command-line, a complete list of the switches and reserved keywords is available.

    There is a Linux port of WMI command line tool, written in Python, based on Samba4 called 'wmi-client'
    WBEMDump.exe: WBEMDump is a tool delivered with the Platform SDK. This command line tool comes with its own Visual C++ project. The tool can show the CIM repository classes, instances, or both. It is possible to retrieve the same information as that retrieved with WMIC. WBEMDump.exe requires more specific knowledge about WMI, as it doesnt abstract WMI as WMIC. However, it runs under Windows NT 4.0 and Windows 2000. It is also possible to execute methods exposed by classes or instances. Even if it is not a standard WMI tool delivered with the system installation, this tool can be quite useful for exploring the CIM repository and WMI features.

    WMI driver extensions

    The WMI extensions to WDM provide kernel-level instrumentation such as publishing information, configuring device settings, supplying event notification from device drivers and allowing administrators to set data security through a WMI provider known as the WDM provider. The extensions are part of the WDM architecture; however, they have broad utility and can be used with other types of drivers as well (such as SCSI and NDIS). The WMI Driver Extensions service monitors all drivers and event trace providers that are configured to publish WMI or event trace information. Instrumented hardware data is provided by way of drivers instrumented for WMI extensions for WDM. WMI extensions for WDM provide a set of Windows device driver interfaces for instrumenting data within the driver models native to Windows, so OEMs and IHVs can easily extend the instrumented data set and add value to a hardware/software solution. The WMI Driver Extensions, however, are not supported by Windows Vista and later operating systems.

    Windows Image Acquisition :

    Windows Image Acquisition

    Windows Image Acquisition (WIA; sometimes also called Windows Imaging Architecture) is a Microsoft driver model and application programming interface (API) for Microsoft Windows Me and later Windows operating systems that enables graphics software to communicate with imaging hardware such as scanners, digital cameras and Digital Video-equipment. It was first introduced in 2000 as part of Windows Me, and continues to be the standard imaging device and API model through successive Windows versions. It is implemented as an on-demand service in Windows XP and later Windows operating systems.


    WIA is a significant superset of the support for digital still imaging drivers that was provided by the Still Image Architecture (STI) in Windows 98. Whereas STI only provided a low-level interface for doing basic transfers of data to and from the device (as well as the invocation of an image scan process on the Windows machine through the external device), WIA provides a framework through which a device can present its unique capabilities to the operating system, and applications can invoke those features. According to Microsoft, WIA drivers are made up of a user interface (UI) component and a driver core component, loaded into two different process spaces: UI in the application space and the driver core in the WIA service space.

    Many scanners support WIA.

    Additional information

    In 2002, Microsoft released the Windows Image Acquisition Automation Library Tool, which provides access to WIA functionality through programming languages and scripting environments that support OLE Automation.

    In Windows XP, WIA runs in the LocalSystem context. Because of the security ramifications of running a service as LocalSystem whereby a buggy driver or malicious person would have unrestricted access to the system, the WIA service in Windows Server 2003 and Windows Vista operates in the LocalService context. This can result in compatibility issues when using a driver designed for Windows XP.

    In Windows XP, support was added for automatic document feeder scanners, scroll-feed scanners without preview capabilities and multi-page TIFF generation. For WIA video, a snapshot filter driver is introduced that allows still frames to be captured from the video stream.

    Windows Vista has the WIA Automation library built-in. Also, WIA supports push scanning and multi-image scanning. Push scanning allows initiating scans and adjusting scanning parameters directly from the scanner control panel. Multi-image scanning allows one to scan several images at once and save them directly as separate files. However, video content support is removed from WIA for Windows Vista. Microsoft recommends using the newer Windows Portable Devices API.

    Applications that use WIA
    • Photoshop
    • Paint.NET
    • ACDSee
    • Chasys Draw IES
    • Windows Scanner and Camera Wizard

  • .

    OLE Automation :

    OLE Automation

    In Microsoft Windows applications programming, OLE Automation (later renamed to simply Automation) is an inter-process communication mechanism created by Microsoft. It is based on a subset of Component Object Model (COM) that was intended for use by scripting languages - originally Visual Basic - but now are used by several languages on Windows. All automation objects are required to implement the IDispatch interface. It provides an infrastructure whereby applications called automation controllers can access and manipulate (i.e. set properties of or call methods on) shared automation objects that are exported by other applications. It supersedes Dynamic Data Exchange (DDE), an older mechanism for applications to control one another. As with DDE, in OLE Automation the automation controller is the "client" and the application exporting the automation objects is the "server".

    Contrary to its name, automation objects do not necessarily use Microsoft OLE, although some of Automation objects can be used in OLE environments. The confusion has its roots in Microsoft's earlier definition of OLE, which was previously more or less a synonym of COM.

    Advantages and limitations

    To ensure interoperability, automation interfaces are limited to use a subset of all COM types. Specifically, automation interfaces must use SAFEARRAY instead of raw COM arrays.

    Automation-compatible COM servers can, however, rely on the in-built OLE marshalling implementation. This avoids the need for additional proxy/stub projects for marshalling out-of-process.


    Automation was designed with the ease of scripting in mind, so controllers often provide languages such as Visual Basic for Applications to end users, allowing them to control automation objects via scripts. Automation objects are often written in conventional languages such as C++, where C++ attributes can be used to simplify development, Languages such as Visual Basic and Borland Delphi also provides a convenient syntax for Automation which hides the complexity of the underlying implementation.

    Type libraries

    In order to automate an application, the developer of an automation controller must know the object model that is employed by the target application exporting activation objects. This requires that the developer of the target application publicly document its object model. Development of automation controllers without knowledge of the target application's object model is "difficult to impossible". Because of these complications, Automation components are usually provided with type libraries, which contain metadata about classes, interfaces and other features exposed by an object library. Interfaces are described in Microsoft Interface Definition Language. Type libraries can be viewed using various tools, such as the Microsoft OLE/COM Object Viewer (oleview.exe, part of the Microsoft Platform SDK) or the Object Browser in Visual Basic (up to version 6) and Visual Studio .NET. Type libraries are used to generate Proxy pattern/stub code for interoperating between COM and other platforms, such as Microsoft .NET and Java. For instance, the .NET Framework SDK includes tools that can generate a proxy .NET DLL to access Automation objects using both early binding (with information about interfaces extracted from a type library) and late binding (via IDispatch, mapped to the .NET Reflection API), with the built-in .NET-to-COM bridge called COM Interop. While Java lacks built-in COM support, toolsets like JACOB and jSegue can generate proxy source code (consisting of two parts, a set of Java classes and a C++ source for a Java Native Interface DLL) from type libraries. These solutions only work on Windows.

    Microsoft has publicly documented the object model of all of the applications in Microsoft Office, and some other software developers have also documented the object models of their applications. Object models are presented to automation controllers as type libraries, with their interfaces described in ODL.

    Language support

    Automation is available for a variety of languages, including, but not limited to:

    • ABAP
    • C
    • C++ (with Compiler COM Support, or with libraries like MFC or ATL)
    • Visual Basic and Visual Basic for Applications
    • Delphi
    • Microsoft .NET languages
    • APL (most Windows versions)
    • Java (only with third-party tools)
    • JScript and VBScript
    • Open Object Rexx
    • Perl
    • PHP
    • PowerBuilder
    • Python
    • Ruby (via the 'win32ole' library included in the standard Ruby 1.8.x or later distribution)
    • Tcl
    • Visual DataFlex
    • WinBatch

  • .

    Telephony Application Programming Interface :

    Telephony Application Programming Interface

    The Telephony Application Programming Interface (TAPI) is a Microsoft Windows API, which provides computer telephony integration and enables PCs running Microsoft Windows to use telephone services. Different versions of TAPI are available on different versions of Windows. TAPI allows applications to control telephony functions between a computer and telephone network for data, fax, and voice calls. It includes basic functions, such as dialing, answering, and hanging up a call. It also supports supplementary functions, such as hold, transfer, conference, and call park found in PBX, ISDN, and other telephone systems.

    TAPI is used primarily to control either modems or, more recently, to control business telephone system (PBX) handsets. When controlling a PBX handset, the driver is provided by the manufacturer of the telephone system. Some manufacturers provide drivers that allow the control of multiple handsets. This is traditionally called "third-party control". Other manufacturers provide drivers that allow the control of a single handset. This is called "first-party control". Third-party drivers are designed to allow applications to see and/or control multiple extensions at the same time. Some telephone systems only permit one third-party connection at a time. First-party drivers are designed to allow applications to monitor and/or control one extension at a time. Telephone systems naturally permit many of these connections simultaneously. Modem connections are by nature first-party.

    TAPI can also be used to control voice-enabled telephony devices, including voice modems and dedicated hardware such as Dialogic cards.


    TAPI was introduced in 1993 as the result of joint development by Microsoft and Intel. The first publicly available version of TAPI was version 1.3, which was released as a patch on top of Microsoft Windows 3.1. Version 1.3 drivers were 16-bit only. Version 1.3 is no longer supported, although some MSDN development library CDs still contain the files and patches.

    With Microsoft Windows 95, TAPI was integrated into the operating system. The first version on Windows 95 was TAPI 1.4. TAPI 1.4 had support for 32-bit applications.

    The TAPI standard supports both connections from individual computers and LAN connections serving any number of computers. TAPI 2.0 was introduced with Windows NT 4.0. Version 2.0 was the first version on the Windows NT platform. It made a significant step forward by supporting ACD and PBX-specific functionality.

    In 1997, Microsoft released TAPI version 2.1. This version of TAPI was available as a downloadable update and was the first version to be supported on both the Microsoft Windows 95 and Windows NT/2000 platforms.

    TAPI 3.0 was released in 1999 together with Windows 2000. This version enables IP telephony (VoIP) by providing simple and generic methods for making connections between two (using H.323) or more (using IP Multicast) computers and now also offers the ability to access any media streams involved in the connection.

    Windows XP included both TAPI 3.1 and TAPI 2.2. TAPI 3.1 supports the Microsoft Component Object Model and provides a set of COM objects to application programmers. This version uses File Terminals which allow applications to record streaming data to a file and play this recorded data back to a stream. A USB Phone TSP (Telephony Service Provider) was also included which allows an application to control a USB phone and use it as a streaming endpoint. TAPI 3.0 or TAPI 3.1 are not available on operating systems earlier than Windows 2000 and Windows XP respectively.

    The Telephony Server Application Programming Interface (TSAPI) is a similar standard developed by Novell for NetWare servers.

    TAPI 2.x vs TAPI 3.x

    It is a common misconception that TAPI 3.0 (or TAPI 3.1) replaces TAPI 2.x.
    TAPI 2.x and earlier versions were written in C; the API uses pointers to structures. Consequently, TAPI 2.x is easy to access from C or C++ applications, but it can be awkward to use from many other programming languages.

    TAPI 3.x was designed with a Component Object Model (COM) interface. This was done with the intent of making it accessible to higher level applications such as developed in VB or other environments that provide easy access to COM but don't deal with C-style pointers.

    TAPI 3.x has a slightly different set of functionality than TAPI 2.x. The addition of integrated media control was the most significant addition. But TAPI 3.x doesn't include all functionality that TAPI 2.x does, like support for the Phone class.

    One very notable issue with TAPI 3.x is the lack of support for managed code (.NET environment). As documented in Microsoft KB Article 841712, Microsoft currently has no plans to support TAPI 3.x directly from .Net programming languages. However, Mark Smith has provided a Managed C++ library called ITAPI3 and other developers such as Mondago provide .Net libraries to work indirectly with TAPI enabled PBXs.

    One often overlooked reason an application developer might choose between TAPI 2.x and TAPI 3.x should be the hardware vendors recommendation. Even though TAPI provides an abstract model of phone lines, telephony applications are still heavily impacted by the specific behavior of the underlying hardware. Troubleshooting behavior issues usually requires both software and hardware vendors to collaborate. Because there is almost a 1:1 relationship between the TAPI Service Provider (TSP) interface and the TAPI 2.x interface, collaboration is often easier if the application is designed using TAPI 2.x. Experience with TAPI 3.x varies significantly between hardware vendors.

    Microsoft Speech API :

    Microsoft Speech API

    The Speech Application Programming Interface or SAPI is an API developed by Microsoft to allow the use of speech recognition and speech synthesis within Windows applications. To date, a number of versions of the API have been released, which have shipped either as part of a Speech SDK, or as part of the Windows OS itself. Applications that use SAPI include Microsoft Office, Microsoft Agent and Microsoft Speech Server.

    In general all versions of the API have been designed such that a software developer can write an application to perform speech recognition and synthesis by using a standard set of interfaces, accessible from a variety of programming languages. In addition, it is possible for a 3rd-party company to produce their own Speech Recognition and Text-To-Speech engines or adapt existing engines to work with SAPI. In principle, as long as these engines conform to the defined interfaces they can be used instead of the Microsoft-supplied engines.

    In general the Speech API is a freely-redistributable component which can be shipped with any Windows application that wishes to use speech technology. Many versions (although not all) of the speech recognition and synthesis engines are also freely redistributable.

    There have been two main 'families' of the Microsoft Speech API. SAPI versions 1 through 4 are all similar to each other, with extra features in each newer version. SAPI 5 however was a completely new interface, released in 2000. Since then several sub-versions of this API have been released.

    Basic architecture

    Broadly the Speech API can be viewed as an interface or piece of middleware which sits between applications and speech engines (recognition and synthesis). In SAPI versions 1 to 4, applications could directly communicate with engines. The API included an abstract interface definition which applications and engines conformed to. Applications could also use simplified higher-level objects rather than directly call methods on the engines.

    In SAPI 5 however, applications and engines do not directly communicate with each other. Instead each talk to a runtime component (sapi.dll). There is an API implemented by this component which applications use, and another set of interfaces for engines.

    Typically in SAPI 5 applications issue calls through the API (for example to load a recognition grammar; start recognition; or provide text to be synthesized). The sapi.dll runtime component interprets these commands and processes them, where necessary calling on the engine through the engine interfaces (for example, the loading of a grammar from a file is done in the runtime, but then the grammar data is passed to the recognition engine to actually use in recognition). The recognition and synthesis engines also generate events while processing (for example, to indicate an utterance has been recognized or to indicate word boundaries in the synthesized speech). These pass in the reverse direction, from the engines, through the runtime dll, and on to an event sink in the application.

    In addition to the actual API definition and runtime dll, other components are shipped with all versions of SAPI to make a complete Speech Software Development Kit. The following components are among those included in most versions of the Speech SDK:

    • API definition files - in MIDL and as C or C++ header files.
    • Runtime components - e.g. sapi.dll.
    • Control Panel applet - to select and configure default speech recognizer and synthesizer.
    • Text-To-Speech engines in multiple languages.
    • Speech Recognition engines in multiple languages.
    • Redistributable components to allow developers to package the engines and runtime with their application code to produce a single installable application.
    • Sample application code.
    • Sample engines - implementations of the necessary engine interfaces but with no true speech processing which could be used as a sample for those porting an engine to SAPI.
    • Documentation.

  • .


    Xuedong Huang was a key person who led Microsoft's early SAPI efforts.

    SAPI 1-4 API family
    SAPI 1

    The first version of SAPI was released in 1995, and was supported on Windows 95 and Windows NT 3.51. This version included low-level Direct Speech Recognition and Direct Text To Speech APIs which applications could use to directly control engines, as well as simplified 'higher-level' Voice Command and Voice Talk APIs.

    SAPI 3

    SAPI 3.0 was released in 1997. It added limited support for dictation speech recognition (discrete speech, not continuous), and additional sample applications and audio sources.

    SAPI 4

    SAPI 4.0 was released in 1998. This version of SAPI included both the core COM API; together with C++ wrapper classes to make programming from C++ easier; and ActiveX controls to allow drag-and-drop Visual Basic development. This was shipped as part of an SDK that included recognition and synthesis engines. It also shipped (with synthesis engines only) in Windows 2000.

    • The main components of the SAPI 4 API (which were all available in C++, COM, and ActiveX flavors) were:
    • Voice Command - high-level objects for command & control speech recognition
    • Voice Dictation - high-level objects for continuous dictation speech recognition
    • Voice Talk - high-level objects for speech synthesis
    • Voice Telephony - objects for writing telephone speech applications
    • Direct Speech Recognition - objects for direct control of recognition engine
    • Direct Text To Speech - objects for direct control of synthesis engine
    • Audio objects - for reading to and from an audio device or file

  • .

    SAPI 5 API family

    The Speech SDK version 5.0, incorporating the SAPI 5.0 runtime was released in 2000. This was a complete redesign from previous versions and neither engines nor applications which used older versions of SAPI could use the new version without considerable modification.

    The design of the new API included the concept of strictly separating the application and engine so all calls were routed through the runtime sapi.dll. This change was intended to make the API more 'engine-independent', preventing applications from inadvertently depending on features of a specific engine. In addition this change was aimed at making it much easier to incorporate speech technology into an application by moving some management and initialization code into the runtime.

    The new API was initially a pure COM API and could be used easily only from C/C++. Support for VB and scripting languages were added later. Operating systems from Windows 98 and NT 4.0 upwards were supported.

    Major features of the API include:

    Shared Recognizer. For desktop speech recognition applications, a recognizer object can be used that runs in a separate process (sapisvr.exe). All applications using the shared recognizer communicate with this single instance. This allows sharing of resources, removes contention for the microphone and allows for a global UI for control of all speech applications.

    In-proc recognizer. For applications that require explicit control of the recognition process the in-proc recognizer object can be used instead of the shared one.

    Grammar objects. Speech grammars are used to specify the words that the recognizer is listening for. SAPI 5 defines an XML markup for specifying a grammar, as well as mechanisms to create them dynamically in code. Methods also exist for instructing the recognizer to load a built-in dictation language model.

    Voice object. This performs speech synthesis, producing an audio stream from text. A markup language (similar to XML, but not strictly XML) can be used for controlling the synthesis process.

    Audio interfaces. The runtime includes objects for performing speech input from the microphone or speech output to speakers (or any sound device); as well as to and from wave files. It is also possible to write a custom audio object to stream audio to or from a non-standard location.
    User lexicon object. This allows custom words and pronunciations to be added by a user or application. These are added to the recognition or synthesis engine's built-in lexicons.

    Object tokens. This is a concept allowing recognition and TTS engines, audio objects, lexicons and other categories of object to be registered, enumerated and instantiated in a common way.

    SAPI 5.0

    This version shipped in late 2000 as part of the Speech SDK version 5.0, together with version 5.0 recognition and synthesis engines. The recognition engines supported continuous dictation and command & control and were released in U.S. English, Japanese and Simplified Chinese versions. In the U.S. English system, special acoustic models were available for children's speech and telephony speech. The synthesis engine was available in English and Chinese. This version of the API and recognition engines also shipped in Microsoft Office XP in 2001.

    SAPI 5.1

    This version shipped in late 2001 as part of the Speech SDK version 5.1. Automation-compliant interfaces were added to the API to allow use from Visual Basic, scripting languages such as JScript, and managed code. This version of the API and TTS engines was shipped in Windows XP. Windows XP Tablet PC Edition and Office 2003 also include this version, but with a substantially improved version 6 recognition engine and Traditional Chinese.

    SAPI 5.2

    This was a special version of the API for use only in the Microsoft Speech Server which shipped in 2004. It added support for SRGS and SSML mark-up languages, as well as additional server features and performance improvements. The Speech Server also shipped with the version 6 desktop recognition engine and the version 7 server recognition engine.

    SAPI 5.3

    This is the version of the API that ships in Windows Vista together with new recognition and synthesis engines. As Windows Speech Recognition is now integrated into the operating system, the Speech SDK and APIs are a part of the Windows SDK. SAPI 5.3 includes the following new features:
    Support for W3C XML speech grammars for recognition and synthesis. The Speech Synthesis Markup Language (SSML) version 1.0 provides the ability to mark up voice characteristics, speed, volume, pitch, emphasis, and pronunciation.

    The Speech Recognition Grammar Specification (SRGS) supports the definition of context-free grammars, with two limitations: It does not support the use of SRGS to specify dual-tone modulated-frequency (touch-tone) grammars. It does not support Augmented Backus - Naur form (ABNF). Support for semantic interpretation script within grammars. SAPI 5.3 enables an SRGS grammar to be annotated with JavaScript for semantic interpretation to supplement the recognized text.

    User-Specified shortcuts in lexicons, which is the ability to add a string to the lexicon and associate it with a shortcut word. When dictating, the user can say the shortcut word and the recognizer will return the expanded string.
    Additional functionality and ease-of-programming provided by new types.
    Performance improvements, improved reliability and security.
    Version 8 of the speech recognition engine ("Microsoft Speech Recognizer")

    SAPI 5.4

    This is an updated version of the API that ships in Windows 7.

    SAPI 5 Voices

    Microsoft Sam (Speech Articulation Module) is a commonly-shipped SAPI 5 voice. In addition, Microsoft Office XP and Office 2003 installed L&H Michael and Michelle voices. The SAPI 5.1 SDK installs 2 more voices, Mike and Mary. Windows Vista includes Microsoft Anna which replaces Microsoft Sam. Anna is designed to sound more natural and offer greater intelligibility. The Chinese version of Windows Vista and later Windows client versions also include a female voice named Microsoft Lili. Microsoft Anna is also installed on Windows XP by Microsoft Streets & Trips 2006 and later versions.

    Managed code Speech API

    A managed code API ships as part of the .NET Framework 3.0. It has similar functionality to SAPI 5 but is more suitable to be used by managed code applications. The new API is available on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.

    The existing SAPI 5 API can also be used from managed code to a limited extent by creating COM Interop code (helper code designed to assist in accessing COM interfaces and classes). This works well in some scenarios however the new API should provide a more seamless experience equivalent to using any other managed code library.

    However, major obstacle towards transitioning from the COM Interop is the fact that the managed implementation has subtle memory leaks which lead to memory fragmentation and exclude the use of the library in any non-trivial applications. Microsoft has acknowledged the problem but has so far refused to address it, and is instead trying to promote their newer API with incompatible voice engines.

    Speech functionality in Windows Vista
    • Windows Vista includes a number of new speech-related features including:
    • Speech control of the full Windows GUI and applications
    • New tutorial, microphone wizard, and UI for controlling speech recognition
    • New version of the Speech API runtime: SAPI 5.3
    • Built-in updated Speech Recognition engine (Version 8)
    • New Speech Synthesis engine and SAPI voice Microsoft Anna
    • Managed code speech API (codenamed SpeechFX)
    • Speech recognition support for 8 languages at release time: U.S. English, U.K. English, traditional Chinese, simplified Chinese, Japanese, Spanish, French and German, with more language to be released later.
    • Microsoft Agent most notably, and all other Microsoft speech applications use SAPI 5.

  • .

    Messaging Application Programming Interface :

    Messaging Application Programming Interface

    Messaging Application Programming Interface (MAPI) is a messaging architecture and a Component Object Model based API for Microsoft Windows. MAPI allows client programs to become (e-mail) messaging-enabled, -aware, or -based by calling MAPI subsystem routines that interface with certain messaging servers. While MAPI is designed to be independent of the protocol, it is usually used with MAPI/RPC, the proprietary protocol that Microsoft Outlook uses to communicate with Microsoft Exchange.

    Simple MAPI is a subset of 12 functions which enable developers to add basic messaging functionality. Extended MAPI allows complete control over the messaging system on the client computer, creation and management of messages, management of the client mailbox, service providers, and so forth. Simple MAPI ships with Microsoft Windows as part of Outlook Express/Windows Mail while the full Extended MAPI ships with Office Outlook and Exchange.

    In addition to the Extended MAPI client interface, programming calls can be made indirectly through the Simple MAPI API client interface, through the Common Messaging Calls (CMC) API client interface, or by the object-based CDO Library interface. These three methods are easier to use and designed for less complex messaging-enabled and -aware applications. (Simple MAPI and CMC were removed from Exchange 2003.)

    MAPI was originally designed by Microsoft. The company founded its MS Mail team in 1987, but it was not until it acquired Consumers Software in 1991 to obtain Network Courier that it had a messaging product. Reworked, it was sold as MS PC Mail (or Microsoft Mail for PC Networking). The basic API to MS PC Mail was known as MAPI version 0 (or MAPI0). MAPI uses functions loosely based on the X.400 XAPIA standard.

    MAPI includes facilities to access message transports, message stores, and directories.

    Service provider interface

    The full Extended MAPI interface is required for interfacing messaging-based services to client applications such as Outlook. For example, several non-Microsoft e-mail server product vendors created "MAPI service providers" to allow their products to be accessed via Outlook. Notable examples include Axigen Mail Server, Kerio Connect, Scalix, Zimbra, HP OpenMail, IBM Lotus Notes, Zarafa, and Bynari.

    MAPI also had a service provider interface of sorts. Microsoft used this to interface MS Mail to an email system based on Xenix, for internal use.
    Extended MAPI is the main e-mail data access method used by Outlook, to interface to Microsoft Exchange, via MAPI service providers shipped with Outlook.

    MAPI/RPC protocol details

    Microsoft has released full details of the MAPI/RPC protocol since August 2007.
    "MAPI protocol" is a colloquial name for the MAPI/RPC. At times, Microsoft has also called it "Exchange RPC" and "Outlook-Exchange Transport Protocol".
    Microsoft provides a sample MAPI/RPC based application called MFCMAPI to assist developers. It is also widely used as a diagnostics tool by both developers and Microsoft Exchange administrators.

    Open Source MAPI implementations

    Up until recently Open Source implementations of MAPI have been scarce. But there are at least three open source projects working on implementing the MAPI protocol in free open source software (FOSS) libraries for use in other open source applications. This list includes the OpenMapi project, the Zarafa's MAPI4Linux (also part of OpenMapi) and the libmapi subproject of the OpenChange project which is utilized in another OpenChange subproject called Evolution-MAPI. Evolution-MAPI is a connector provider that can be installed within the popular open source Evolution groupware client.

    Microsoft CryptoAPI :

    Microsoft CryptoAPI

    The Cryptographic Application Programming Interface (also known variously as CryptoAPI, Microsoft Cryptography API, MS-CAPI or simply CAPI) is an application programming interface included with Microsoft Windows operating systems that provides services to enable developers to secure Windows-based applications using cryptography. It is a set of dynamically linked libraries that provides an abstraction layer which isolates programmers from the code used to encrypt the data. The Crypto API was first introduced in Windows NT 4.0 and enhanced in subsequent versions.

    CryptoAPI supports both public-key and symmetric key cryptography, though persistent symmetric keys are not supported. It includes functionality for encrypting and decrypting data and for authentication using digital certificates. It also includes a cryptographically secure pseudorandom number generator function CryptGenRandom.

    CryptoAPI works with a number of CSPs (Cryptographic Service Providers) installed on the machine. CSPs are the modules that do the actual work of encoding and decoding data by performing the cryptographic functions. Vendors of HSMs may supply a CSP which works with their hardware.

    Cryptography API: Next Generation

    Windows Vista features an update to the Crypto API known as Cryptography API: Next Generation (CNG). It has better API factoring to allow the same functions to work using a wide range of cryptographic algorithms, and the inclusion of a number of newer algorithms that are part of the National Security Agency (NSA) Suite B. It is also flexible, featuring support for plugging in custom cryptographic APIs into the CNG runtime. However, CNG Key Storage Providers still do not support symmetric keys. CNG works in both user and kernel mode, and also supports all of the algorithms from the CryptoAPI. The Microsoft provider that implements CNG is housed in Bcrypt.dll.

    CNG also supports elliptic curve cryptography which, because it uses shorter keys for the same expected level of security, is more efficient than RSA. The CNG API integrates with the smart card subsystem by including a Base Smart Card Cryptographic Service Provider (Base CSP) module which encapsulates the smart card API. Smart card manufacturers just have to make their devices compatible with this, rather than provide a from-scratch solution.

    CNG also adds support to Dual EC DRBG, a pseudorandom number generator defined in NIST SP 800-90 that could expose the user to eavesdropping by the National Security Agency unless the user remembers to generate new random numbers with a different cryptographically secure pseudorandom number generator or a true random number generator and then publishing the generated seed in order to make it secure. It is also very slow. It is only used when called for explicitly.

    CNG also replaces the default PRNG with CTR_DRBG using AES as the block cipher, because the earlier RNG which is defined in the now superseded FIPS 186-2 is based on either DES or SHA-1, both which have been broken. CTR_DRBG is one of the two algorithms in NIST SP 800-90 endorsed by Schneier, the other being Hash_DRBG.

    Qt (framework) :

    Qt (framework)

    Qt is a cross-platform application framework that is widely used for developing application software with a graphical user interface (GUI) (in which cases Qt is classified as a widget toolkit), and also used for developing non-GUI programs such as command-line tools and consoles for servers.

    Qt uses standard C++ but makes extensive use of a special code generator (called the Meta Object Compiler, or moc) together with several macros to enrich the language. Qt can also be used in several other programming languages via language bindings. It runs on the major desktop platforms and some of the mobile platforms. It has extensive internationalization support. Non-GUI features include SQL database access, XML parsing, thread management, network support, and a unified cross-platform application programming interface (API) for file handling.

    Qt is available under a commercial license, GPL v3 and LGPL v2. All editions support many compilers, including the GCC C++ compiler and the Visual Studio suite.

    Qt is developed by Digia, who owns the Qt technology and trademark, and the Qt Project under open governance, involving individual developers and firms working to advance Qt. Before the launch of the Qt Project, it was produced by Nokia's Qt Development Frameworks division, which came into existence after Nokia's acquisition of the Norwegian company Trolltech, the original producer of Qt. In February 2011 Nokia announced its decision to drop Symbian technologies and base their future smartphones on Microsoft platform instead. One month later Nokia announced the sale of Qt's commercial licensing and professional services to Digia, with the immediate goal of taking Qt support to Android, iOS and Windows 8 platforms, and to continue focusing on desktop and embedded development, although Nokia was to remain the main development force behind the framework at that time.

    • Qt works on the following platforms:
    • Windows - Qt for Microsoft Windows XP, Vista, 7
    • OS X - Qt for Apple OS X; supports applications on Cocoa
    • Embedded Linux - Qt for embedded platforms: personal digital assistant, smartphone, etc.
    • Wayland - Qt for Wayland display server. Qt applications can switch between graphical backends like X and Wayland at load time with the
    • -platform command line option.

    • QNX / BlackBerry 10 - Qt for QNX and the QNX-based BlackBerry 10 platform.
    • Android (Technology Preview) - Qt for Android, formerly known as Necessitas.
    • iOS (Technology Preview) - Qt for iOS platforms (iPhone, iPad)

    • External ports

      Since Nokia opened the Qt source code to the community on Gitorious various ports have been appearing. Here are some of them:

    • Qt for OpenSolaris - Qt for OpenSolaris.
    • Qt for Haiku - Qt for Haiku.
    • Qt for OS/2 - Qt for OS/2 eCS platform.
    • Qt for webOS - experimental development of Qt for webOS on Palm Pre.
    • Qt for Amazon Kindle DX - experimental development of Qt for Amazon Kindle DX.
    • QMir - Plugin to Qt 5 to support the Mir display server.
    • Qt for AmigaOS - Qt for AmigaOS.

    • Deprecated ports

      Windows CE, Mobile - Qt for Windows CE and Windows Mobile.
      Symbian - Qt for the Symbian platform. Qt replaced Nokia's Avkon as the supported UI SDK for developing Symbian applications.


      There are three editions of Qt available on each of these platforms, namely:

    • GUI Framework - commercial entry level GUI edition, stripped of network and database support (formerly named "Desktop Light")
    • Full Framework - complete commercial edition
    • Open Source - complete Open Source edition
    • Qt is available under the following copyright licenses:
    • GNU LGPL 2.1 version with Qt special exception
    • GNU GPL 3.0 version
    • Commercial Developer License

    • Releases

      Qt 4

      Trolltech released Qt 4.0 on 28 June 2005 and introduced five new technologies in the framework:

    • Tulip A set of template container classes.
    • Interview A model - view - controller architecture for item views.
    • Arthur A 2D painting framework.
    • Scribe A Unicode text renderer with a public API for performing low-level text layout.
    • MainWindow A modern action-based main window, toolbar, menu, and docking architecture.

  • .

    Qt 5

    Qt 5 was originally expected to be released in June 2012 but the release was delayed several times. It was officially released on 19 December 2012. This new version marks a major change in the platform, with hardware-accelerated graphics, QML and JavaScript playing a major role. The traditional C++-only QWidgets continue to be supported, but do not benefit from the performance improvements available through the new architecture. Qt5 brings significant improvements to the speed and ease of developing user interfaces.

    Framework development of Qt 5 moved to open governance, taking place at It is now possible for developers outside Nokia/Digia to submit patches and have them reviewed.


    The innovation of Qt when it was first released relied on a few key concepts.


    Starting with Qt 4.0 the framework was split into individual modules. With Qt 5.0 the architecture was modularized even further. Qt is now split into essential and add-on modules.


    Qt Creator, a cross-platform IDE for C++ and QML
    qmake, a tool that automates the generation of Makefiles for development project across different platforms

    Use of native UI-rendering APIs

    Qt used to emulate the native look of its intended platforms, which occasionally led to slight discrepancies where that emulation was imperfect. Recent versions of Qt use the native style APIs of the different platforms to query metrics and draw most controls, and do not suffer from such issues as much.
    On some platforms (such as MeeGo and KDE) Qt is the native API.

    Metaobject compiler

    The metaobject compiler, termed moc, is a tool that is run on the sources of a Qt program. It interprets certain macros from the C++ code as annotations, and uses them to generate added C++ code with Meta Information about the classes used in the program. This meta information is used by Qt to provide programming features not available natively in C++: the signal/slot system, introspection and asynchronous function calls.

    QtScript ECMAScript interpreter

    QtScript is a cross-platform toolkit that allows developers to make their Qt/C++ applications scriptable using an interpreted scripting language: Qt Script (based on ECMAScript/JavaScript).

    From Qt 4.3.0 onward, the scripting API, which makes use of some concepts from the earlier QSA, is integrated as a core part of Qt. With Qt 5.0 it became an add-on module for Qt 4 compatibility.


    Haavard Nord and Eirik Chambe-Eng (the original developers of Qt and the CEO and President, respectively, of Trolltech) began development of "Qt" in 1991, three years before the company was incorporated as Quasar Technologies, then changed the name to Troll Tech and then to Trolltech.

    The toolkit was called Qt because the letter Q looked appealing in Haavard's Emacs font, and "t" was inspired by Xt, the X toolkit.

    The first two versions of Qt had only two flavors: Qt/X11 for Unix and Qt/Windows for Windows. The Windows platform was only available under a proprietary license, which meant free/open source applications written in Qt for X11 could not be ported to Windows without purchasing the proprietary edition.

    At the end of 2001, Trolltech released Qt 3.0, which added support for Mac OS X. The Mac OS X support was available only in the proprietary license until June 2003, when Trolltech released Qt 3.2 with Mac OS X support available under the GPL.
    In June 2005, Trolltech released Qt 4.0.

    Nokia acquired Trolltech ASA on 17 June 2008 and changed the name first to Qt Software, then to Qt Development Frameworks. Since then it focused on Qt development to turn it into the main development platform for its devices, including a port to the Symbian S60 platform. Version 1.0 of the Nokia Qt SDK was released on 23 June 2010.[59] The source code was made available over Gitorious, a community oriented git source code repository, to gather an even broader community that is not only using Qt but also helping to improve it.

    Clutter (toolkit) :

    Clutter (toolkit)

    Clutter is an open source graphics library for creating hardware-accelerated user interfaces. It relies upon OpenGL (1.4+) or OpenGL ES (1.1 or 2.0) for rendering, can be compiled on different platforms (X11, Wayland, Darwin and Win32) and has multiple bindings to other languages (including Mono, Perl, Python, Ruby and Vala). It also supports media playback using GStreamer and 2D graphics rendering using Cairo.

    Clutter was created by OpenedHand Ltd, now part of Intel. Licensed under the LGPL v2.1, Clutter is free and open source software.

    Programming languages

    Clutter is implemented using the C programming language with a design based on the GObject object system. Bindings are available for these languages:

    • C++ (cluttermm)
    • C# (clutter-sharp (aka Clutter#))
    • Haskell (clutterhs)
    • JavaScript (Seed and GJS)
    • Perl (clutter-perl)
    • Python (PyClutter)
    • Ruby (rbclutter)
    • Vala (clutter-vala)

  • .


    Clutter is developed on the X Window System (respectively on Wayland), using the GLX extension. It is also targeted to embedded environments, either using X or the native frame buffer. As of release 0.6, native support for Mac OS X has been added. A native Microsoft Windows backend is supported since the 0.8 release and Windows pre-compiled DLLs are available, however, you can build the latest DLL for Windows with MinGW and Bash shell for Windows.

    Clayland is a simple example Wayland compositor using Clutter.


    Clutter is a scene graph based canvas working in retained mode. Every object on the scene is usually a 2D surface inside a 3D space.
    Clutter abstracts the native windowing environment behind a backend, which is also responsible for creating the main container for the scene graph; this top level container is called the stage. Items on the stage are called actors.
    Instead of operating on matrices, as does OpenGL, the Clutter developer changes properties of each actor. Clutter will then notice the changes, and render the scene accordingly.


    Clutter allows implicit animations of every item on the canvas using special objects called behaviours: each behaviour can be applied to multiple actors, and multiple behaviours can be composed on the same actor. Behaviours handle animations implicitly: the developer specifies the initial and final states, the time (or number of frames) needed to complete the animation, the function of time to be used (linear, sine wave, exponential, etc.), and the behaviour will take care of the tweening. Clutter provides a generic base class for developers to implement custom behaviours, and various simple classes handling simple properties, like opacity, position on the Z axis (depth), position along a path, rotation, etc.

    Since Clutter 1.0, it is also possible to create simple, one-off animations using the ClutterAnimation class and the clutter_actor_animate() convenience function. The clutter_actor_animate() function animates an actor properties between their current state and the specified final state.

    Integration libraries
    • Clutter can be integrated with other libraries and toolkits, for instance:
    • GTK+ applications can embed Clutter stages using a special widget.
    • Clutter applications can embed GTK+ widgets using the 'client-side windows' feature since GTK+ 2.18.
    • Clutter applications can use GStreamer to play videos directly into a Clutter texture actor.
    • Clutter applications can use Cairo to draw onto a texture.

  • .

    Tk (framework) :

    Tk (framework)

    Tk is an open source, cross-platform widget toolkit that provides a library of basic elements for building a graphical user interface (GUI) in many different programming languages.

    Tk provides a number of (GUI) widgets commonly needed to develop desktop applications such as button, menu, canvas, text, frame, label etc. Tk has been ported to run on most flavors of Linux, Mac OS, Unix, and Microsoft Windows. Since Tcl/Tk 8, it offers "native look and feel" (for instance, menus and buttons are displayed in the manner of "native" software for any given platform). Tk was designed to be extended, and a wide range of extensions are available that offer new widgets or other capabilities.

    A new theming engine, originally called Tk Tile, but now generally referred to as "themed Tk" is included in the 8.5 release. Like Tcl, Tk supports Unicode within the Basic Multilingual Plane but it has not yet been extended to handle 32-bit Unicode. On *nix systems, Tk 8.4 and below still use bitmap fonts, but Tk 8.5 uses outline fonts (notably TrueType and OpenType fonts).


    Tk was developed by John Ousterhout as an extension for the Tcl scripting language. Bindings exist for several other languages, including Ada (called TASH), Perl, Python (called Tkinter), Ruby, and Common Lisp. Tk was first released to the internet in 1991. Tk versioning was done separately from Tcl until version 8.0.

    Tk was written originally for Unix/X11, and proved extremely popular with programmers in the 1990s by virtue of it being significantly easier to learn and use than Motif and other dominant X11 toolkits of the time. Tk also was ported to Microsoft Windows and Macintosh platforms, starting with Tk 4.2 and improved with native look and feel in Tk 8.0 (released 1997). The ease of use and cross-platform support, coupled with the ease of which Tk and its underlying Tcl interpreter could be embedded in other software, made it the de facto standard GUI toolkit among scripting languages.

    Interest in Tk waned significantly from the late 1990s and onward. The default look and feel on Unix still emulated Motif, despite the mainstream replacement of Motif by toolkits such as Qt and GTK+. Widgets that became commonly used in applications (e.g. trees, combo boxes, tabbed notebooks) were not available in the Tk core, but only via multiple, often competing add-ons.

    Tk 8.5, released in late 2007, corrected some of these problems by adding missing widgets to the core, introducing a new theming engine and modernizing the look and feel on Unix. However, because some code changes were required to incorporate these advancements, many existing applications retain the older Motif-inspired feel that Tk had become known for. Much of the older documentation found on the net was never updated to reflect the improvements, though the TkDocs site does offer an up-to-date tutorial focused on modern best practices.


    Tk is a platform-independent GUI framework developed for Tcl. From a Tcl shell (tclsh), Tk may be invoked using this command: package require Tk. The program wish (WIndowing SHell) provides a way to bring up a tclsh shell in a graphical window as well as providing Tk.

    Tk has the following characteristics:

    Platform-independent: Like Tcl, Tk is interpreted. It has been ported to multiple platforms and can easily run on all of them without modification.

    Customizable: Almost all of the features of a widget in Tk are customizable through options during the creation of the widget or later on through the configure command.

    Configurable: Many of the options can be stored in an option database, making it very easy to parameterize the look of an application (such as the color scheme). This also means that storing the application-specific options is only a matter of saving the option add commands and executing them on loading the application.

    There are several ways to use Tk from Perl: the Tcl::Tk and Tkx Perl modules, both of which use Tcl as a bridge to access Tk, and Perl/Tk, which provides native Perl access to Tk structures. The Python and Ruby bindings, as well as most other language bindings, use Tcl as a bridge to Tk.


    Tk provides the following widgets :

    • button
    • canvas
    • checkbutton
    • combobox
    • entry
    • frame
    • label
    • labelframe
    • listbox
    • menu
    • menubutton
    • message
    • li>
    • tk_optionMenu
    • panedwindow
    • progressbar
    • radiobutton
    • scale
    • scrollbar
    • separator
    • sizegrip
    • spinbox
    • text
    • treeview

    • as well as the following top-level windows :
    • tk_chooseColor - pops up a dialog box for the user to select a color.
    • tk_chooseDirectory - pops up a dialog box for the user to select a directory.
    • tk_dialog - creates a modal dialog and waits for a response.
    • tk_getOpenFile - pops up a dialog box for the user to select a file to open.
    • tk_getSaveFile - pops up a dialog box for the user to select a file to save.
    • tk_messageBox - pops up a message window and waits for a user response.
    • tk_popup - posts a popup menu.
    • toplevel - creates and manipulates toplevel widgets.
    • Tk also provides three geometry managers:
    • place - which positions widgets at absolute locations
    • grid - which arranges widgets in a grid
    • pack - which packs widgets into a cavity

  • .

    The most unusual and versatile features of Tk are its canvas and text widgets, which provide capabilities found in few, if any, other widget toolkits.

    Object-oriented widgets are available with incr Tk and Iwidgets. There are many other useful widgets built on top of Tk such as TkTreeCtrl, BLT (toolkit), Tix Mega-Widgets and TSIPP (a 3D Graphics Toolkit).

    Fox toolkit :

    Fox toolkit

    The FOX toolkit is an open source, cross-platform widget toolkit, that is, a library of basic elements for building a graphical user interface (GUI). FOX stands for Free Objects for X.

    It features a hard-wired Windows 95-style theme available for both Microsoft Windows itself as well as the X Window System (which is used on many UNIX and UNIX-like operating systems).

    The FOX toolkit has been released under the GNU Lesser General Public Licence. Development began 1997 by Jeroen van der Zijp while he was affiliated at CFDRC. Since then, Jeroen van der Zijp maintains the core library and test applications, with the help of a growing[citation needed] user community.

    The FOX toolkit is written in C++, with language bindings available for Python, Ruby and Eiffel. The FOX source code distribution supports building with many different (commercial and free) C++ compilers.

    Cross-platform compatibility

    FOX differentiates itself in the following way from other cross-platform toolkits: Tk is a cross-platform toolkit but does not have all of the widgets that FOX considers desirable.
    Qt had a different licensing model, which might have required a commercial license in some cases where FOX would not. (This is no longer the case starting with Qt 4.5.)

    wxWidgets promotes the use of native widgets on each supported platform.
    FLTK is a fast, low-footprint library that supports rapid application development, and requires less code to use, but lacks advanced widgets. All of these toolkits have some support for programming natively on Mac OS and/or Mac OS X platforms, which FOX currently does not support.

    FOX uses a technique similar to the Java Swing-style approach to display a graphical user interface to the screen, using only graphical primitives available on that platform, as opposed to the original Java AWT-style approach which used native widgets. This means that applications will have a similar look and feel across platforms. In theory, porting FOX to a new platform should also be easier than implementing support for native widgets.

    On the downside, it usually means that FOX applications will look and feel different from native applications for those platforms, which some users may find confusing. Also, certain native platform features may not be available immediately, such as comprehensive printing support or internationalized input handling, because they will need to be re-implemented in a cross-platform way before they can be used in FOX.

    Messaging system

    FOX offers a transparent bi-directional messaging system. Each Widget sends its message to a certain target. Each message is composed by a selector that identifies its kind and an id that is unique and provided by the widget's enumeration. The advantage is that each widget can call a target widget's method in a transparent manner, even if the method does not exist. Vice versa, in the implementation of the individual message handler, since the sender is known, the target can also dispatch a message to the sender. This is a particularly important feature in component oriented software, where components may be written by different people, or even different organizations.

    The FOX messaging system simplifies the GUI update strategy: during widget update, the widgets can ask from their targets to update them. This means that a command message does not also have to explicitly update any widgets as it is typical. In case an application implements N command messages each updating M widgets, then M*N updates must be executed and at most M*N messages must be implemented. On the other hand, if widgets request for update, only N command messages and at most M update messages are implemented. This strategy separates the GUI update from data changes, making the GUI a real-time reflection of the underlying data structures.

    Juce :


    JUCE is a free software, cross-platform C++ application framework, used for the development of GUI applications and plug-ins.

    The aim of JUCE is to allow software to be written such that the same source code will compile and run identically on Windows, Mac OS X and Linux platforms. It supports various development environments and compilers, such as GCC, Xcode and Visual Studio.

    It was first released to the public in 2004, and is maintained by Raw Material Software in the United Kingdom. It is covered by a dual GPL/commercial license.

    Official support

    JUCE is intended to be usable in exactly the same way on multiple platforms and compilers. Raw Material Software gives the following list of platforms and compilers on which support is officially confirmed; others may work, but have not been officially tested.

    Supported platforms
    • JUCE is supported on the following platforms.
    • Microsoft Windows XP and later
    • Mac OS X versions 10.5 and later
    • iOS versions 3 and later
    • Linux kernel series 2.6 and later
    • Android using NDK-v5 and later

    • Supported compilers
    • JUCE is officially confirmed to work properly with the following compilers.
    • GCC versions 4.0 and later
    • LLVM - LLVM Clang
    • Microsoft Visual Studio - Visual C++ 2005 and later

  • .


    Like many other frameworks (e.g. Qt, wxWidgets, GTK+, etc.), JUCE contains classes providing a range of functionality that covers user-interface elements, graphics, audio, XML and JSON parsing, networking, cryptography, multi-threading, and various other commonly-used features. Application developers needing several third-party libraries may thus be able to consolidate and use only the JUCE library, or at least reduce the number of third-party libraries they use. In this, the original inspiration was Java's JDK, and JUCE was intended to be "something similar for C++".

    A notable feature of JUCE when compared to other similar frameworks is its large set of audio functionality; this is because JUCE was originally developed as part of the Tracktion audio sequencer before being split off into a standalone product. JUCE has support for audio devices (such as CoreAudio, ASIO, ALSA, JACK, WASAPI, DirectSound) and MIDI playback, polyphonic synthesizers, built-in readers for common audio file formats (such as WAV, AIFF, FLAC, and Vorbis), as well as wrappers for building various types of audio plugin, such as VST effects and instruments. This has led to its widespread use in the audio development community.

    JUCE comes with wrapper classes for building audio and browser plugins. When building an audio plugin, a single binary is produced that supports multiple plugin formats (VST, RTAS, Audio Units). Since all the platform and format-specific code is contained in the wrapper, a user can build Mac and Windows VST/RTAS/AUs from a single codebase.

    Browser plugins are handled in a similar way: a single binary is produced that functions as both an NPAPI and an ActiveX plugin.


    The "Introjucer" is an IDE tool for creating and managing JUCE projects. When the files and settings for a JUCE project have been specified, the Introjucer automatically generates a collection of 3rd-party project files to allow the project to be compiled natively on each target platform. It can currently generate Xcode projects, Visual Studio projects, Linux Makefiles, Android Ant builds and CodeBlocks projects. As well as providing a way to manage a project's files and settings, it also has a code editor, an integrated GUI editor, and wizards for creating new projects and files.

    Ultimate++ :


    Ultimate++ is a C++ cross-platform development framework which aims to reduce the code complexity of typical desktop applications by extensively exploiting C++ features.

    • currently supports Unix/Linux/FreeBSD (X11), Microsoft Windows and Windows CE.
    • includes an IDE and a GUI designer.
    • uses the free BSD license.
    • uses heavily RAII and auto pointers-like mechanisms to avoid manual memory management and even to limit the use of pointers in the code
    • can emulate native widgets look and feel. On X11 systems, Ultimate++ supports GTK+ widgets look and feel.
    • numerous reference examples are provided.
    • standard distribution comes with ultimate++ sources included, even the IDE ones.
    • uses NTL as template system instead of STL.

  • .


    it doesn't use the Standard Template Library (STL)
    NTL template system semantics are difficult to understand at first since assignment operator in reality gets overloaded to perform a move operation and not a copy. This is done for performance reasons and to overcome some STL limitations, but new C++0x standard should enable even STL users to perform move operations with classes by introducing rvalue-references.

    since many C++ operators are overloaded to perform common tasks such as assigning callbacks, understanding the code can be a difficult at first there are no layouts handlers for widgets, although Ultimate++ has a system of logic coordinates to maintain relative coordinates of objects when resizing windows. Having three buttons properly aligned and resized on a row without layout managers still remains difficult, though. Ultimate++ IDE support for languages other than C++ is very limited. It provides some syntax coloring for SQL and little else.

    Software built on Ultimate++

    AWS Truewind openWind - an open-source wind farm design software
    Gastronomie Kontroll System, a point of sale system for restaurants
    WebMap, GIS application

    FLTK :

    The Fast, Light Toolkit (FLTK, pronounced fulltick) is a cross-platform graphical user interface (GUI) library developed by Bill Spitzak and others. Made to accommodate 3D graphics programming, it has an interface to OpenGL, but it is also suitable for general GUI programming.

    Using its own widget, drawing and event systems (though FLTK2 has gained experimental support for optionally using the cairo graphics library) abstracted from the underlying system-dependent code, it allows for writing programs which look the same on all supported operating systems.

    FLTK is free software, licensed under LGPL with an additional clause permitting static linking from applications with incompatible licenses. It includes FLUID (FLTK User Interface Designer), a graphical GUI designer that generates C++ source and header files.

    In contrast to libraries like Qt and wxWidgets, FLTK uses a more lightweight design and restricts itself to GUI functionality. Because of this, the library is very small (the FLTK "Hello World" program is around 100 KiB), and is usually statically linked. It also avoids complicated macros and separate code preprocessors, and does not use the following advanced C++ features: templates, exceptions, RTTI or, for FLTK 1.x, namespaces. Combined with the modest size of the package, this leads to a relatively short learning curve for new users.

    These advantages come with corresponding disadvantages. FLTK offers fewer widgets than most GUI toolkits and, because of its use of non-native widgets, does not have native look-and-feel on any platform.

    Meaning of the name

    FLTK was originally designed to be compatible with the Forms Library written for SGI machines (a derivative of this library called "XForms" is still used quite often). In that library all the functions and structures started with "fl_". This naming was extended to all new methods and widgets in the C++ library, and this prefix "FL" was taken as the name of the library. After FL was released as open source, it was discovered it was impossible to search "FL" on the Internet, due to the fact that it is also the abbreviation for Florida. After much debating and searching for a new name for the toolkit, which was already in use by several people, Bill Spitzak came up with "FLTK", which stands for the "Fast Light Tool Kit".

    Software built on it
    • TorApp.Info Online Security Printing Platform which is a google native client based on fltk.
    • Prodatum synthesizer preset editor (uses a lifelike interface design)
    • ITK-SNAP which is an open-source software application for medical image segmentation.
    • The open-source deep-paint software CinePaint is migrating from GTK+ to FLTK.
    • FLWM, an X window manager
    • miwm, an X window manager
    • Nuke, a digital compositing program. Until version 5, now replaced by Qt.
    • The Windows port of SmallBASIC
    • The open-source poster printing software PosteRazor (Windows, Mac OS X, Linux).
    • The BVH editor Avimator
    • Dillo web browser. Note that Dillo-2 was based on FLTK-2 and the abandonment of this branch, without an official release, has been a major factor in causing Dillo-3 to be started, using FLTK1.3.
    • Gmsh, an open-source Finite element mesh generator
    • EDE - Equinox Desktop Environment
    • Open Movie Editor
    • ZynAddSubFX, an open-source software synthesizer
    • The Agenda VR3 Linux-based Personal Digital Assistant's software was based on FLTK, as was much of the software developed for it by
    • third-parties
    • ForcePAD an intuitive tool for visualising the behavior of structures subjected to loading and boundary conditions
    • FlBurn optical disc burning software for Linux.
    • DiSTI's GL Studio Human-Machine Interface Development tool.
    • Amnesia: The Dark Descent a game by Frictional Games uses FLTK for its launcher application.
    • Fldigi, Amateur radio software that allows data transmission and text chat via digital modes such as PSK31.
    • Giada - Your Hardcore Loopmachine, a looper/micro-sequencer/sample player software
    • RoboCIM - Robotics software RoboCIM software simulates and controls the operation of a Servo Robot System and external devices
    • OpenVSP - NASA parametric aircraft sketching, recently open-sourced

  • .

    wxWidgets :


    wxWidgets (formerly wxWindows) is a widget toolkit and tools library for creating graphical user interfaces (GUIs) for cross-platform applications. wxWidgets enables a program's GUI code to compile and run on several computer platforms with minimal or no code changes. It covers systems such as Microsoft Windows, OS X (Carbon and Cocoa), iOS (Cocoa Touch), Linux/Unix (X11, Motif, and GTK+), OpenVMS, OS/2 and AmigaOS. A version for embedded systems is under development.

    wxWidgets is used across many industry sectors, most notably by Xerox, Advanced Micro Devices (AMD), Lockheed Martin, NASA and the Center for Naval Analyses. It is also used in the public sector and education by, for example, Dartmouth Medical School, National Human Genome Research Institute, National Center for Biotechnology Information, and many others. wxWidgets is used in many open source projects, and by individual developers. A wide choice of compilers and other tools to use with wxWidgets, allows development of highly sophisticated applications on a tight budget.

    It is free and open source software, distributed under the terms of the wxWidgets License, which satisfies those who wish to produce for GPL and proprietary software.


    wxWidgets (initially wxWindows) was started in 1992 by Julian Smart at the University of Edinburgh. He attained an honours degree in Computational science from the University of St Andrews in 1986, and is still a core developer.

    On February 20, 2004, the developers of wxWindows announced that the project was changing its name to wxWidgets, as a result of Microsoft requesting Julian Smart to respect Microsoft's United Kingdom trademark of the term Windows.

    Major release versions were 2.4 on 6 January 2003, 2.6 on 21 April 2005 and 2.8.0 on 14 December 2006.

    wxWidgets has participated in the Google Summer of Code since 2006.

    • Supported platforms
    • wxWidgets is supported on the following platforms.
    • Windows - wxMSW (Windows 95, 98, Me; NT, 2000, XP, Vista, 7, 8)
    • Linux/Unix wxGTK, wxX11, wxMotif
    • OS X - wxMac (10.3 using Carbon)
    • OS/2 - wxOS2, wxPM, wxWidgets for GTK+ or Motif can be compiled on OS/2
    • Embedded platforms - wxEmbedded
    • External ports

      Amiga - wxWidgets-AOS: AmigaOS port

      Supported compilers

      wxWidgets is officially confirmed to work properly with the following compilers.

    • wxMSW wxGTK
    • Microsoft Visual Studio - Visual C++
    • Borland C++
    • C++Builder
    • Watcom C++, OpenWatcom
    • CodeWarrior
    • Cygwin
    • MinGW
    • Digital Mars C/C++ compiler 5.0 +

    • RAD tools and IDEs for wxWidgets

      CodeLite under Windows XP

      Code::Blocks running under Ubuntu
      There are many Rapid Application Development (RAD) and Integrated Development Environment (IDE) tools available, among them:

    • Boa Constructor (Python)
    • Code::Blocks (via wxSmith plugin)
    • CodeLite (via wxCrafter plugin)
    • wxDev-C++ (Plugin)
    • wxGlade
    • wxFormBuilder
    • Philasmicos Entwickler Studio

    • Applications built using wxWidgets

      Notable applications that use wxWidgets:

    • 0 A.D. (video game) - a FLOSS video game similar to Empire Earth
    • Amaya - web authoring tool
    • aMule - peer-to-peer file sharing application
    • Audacity - cross-platform sound editor
    • BitTorrent - peer-to-peer file sharing application
    • Code::Blocks - C/C++ IDE
    • CodeLite - simple C++ Editor (Collection of free Tools, implemented by plugins)
    • Dolphin - Nintendo GameCube, Wii, and Triforce emulator
    • FileZilla - FTP client
    • RapidSVN - Subversion client
    • TortoiseCVS - CVS client

  • .

    gtkmm :


    gtkmm (formerly known as gtk-- or gtk minus minus) is the official C++ interface for the popular GUI library GTK+. gtkmm is free software distributed under the GNU Lesser General Public License (LGPL).

    gtkmm allows the creation of user interfaces either in code or with the Glade Interface Designer, using the Gtk::Builder class. Other features include typesafe callbacks, a comprehensive set of widgets, and the extensibility of widgets via inheritance.


    Due to the fact that gtkmm is the official C++ interface of the GUI library GTK+, C++ programmers can use the common OOP techniques such as inheritance, and C++-specific facilities such as STL (In fact, many of the gtkmm interfaces, especially those for widget containers, are designed to be similar to the Standard Template Library (STL)).

    Main features of gtkmm are listed as follows:
    • Use inheritance to derive custom widgets.
    • Type-safe signal handlers, in standard C++.
    • Polymorphism.
    • Use of Standard C++ Library, including strings, containers, and iterators.
    • Full internationalisation with UTF-8.
    • Complete C++ memory management.
    • Object composition.
    • Automatic deallocation of dynamically allocated widgets.
    • Full use of C++ namespaces.
    • No macros.
    • Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris (gcc, Forte), Win32 (gcc, MSVC++, .Net 2003), Mac OS X (gcc), others.

    • Applications
    • Some notable applications that use Gtkmm include:
    • Inkscape Vector graphics drawing.
    • K-3D 3D modelling and animation.
    • Workrave Assists in recovery and prevention of RSI.
    • GParted disk partitioning tool.
    • Gobby Collaborative text editor.
    • Nemiver GUI for the GNU debugger gdb.
    • Referencer document organiser and bibliography manager
    • MySQL Administrator Database GUI.
    • Ardour Open Source digital audio workstation (DAW) for Linux and MacOS.
    • Gnote desktop notetaking application.

  • .

    Windows Forms :

    Windows Forms

    Windows Forms (WinForms) is the name given to the graphical application programming interface (API) included as a part of Microsoft .NET Framework, providing access to native Microsoft Windows interface elements by wrapping the extant Windows API in managed code. While it is seen as a replacement for the earlier and more complex C++ based Microsoft Foundation Class Library, it does not offer a paradigm comparable to Model-View-Controller. Some after-market and third party libraries have been created to provide this functionality. The most widely used of these is the User Interface Process Application Block, which is released by the Microsoft patterns & practices group as a free download that includes the source code for quick start examples.

    History & future

    Just like Abstract Window Toolkit (AWT), the equivalent Java API, Windows Forms was an early and easy way to provide graphical user interface components to the .NET Framework. Windows Forms is built on the extant Windows API and some controls merely wrap underlying Windows components

    Windows Forms provides a cross-platform way to design graphical user interfaces. However Windows Forms is mainly a wrapper around the Windows API, and some of the methods allow direct access to Win32 callbacks, which are not available in non-Windows platforms.

    With the release of .NET 3.0, Microsoft released a second API for rendering GUIs: Windows Presentation Foundation (WPF), together with a GUI declarative language called XAML. However, even though both Windows Forms and WPF offer comparable functionality, Windows Forms has not necessarily been superseded by WPF, but is simply another tool for Windows desktop application that will continue to exist parallel to WPF.


    A Windows Forms application is an event-driven application supported by Microsoft's .NET Framework. Unlike a batch program, it spends most of its time simply waiting for the user to do something, such as fill in a text box or click a button.

    Alternative implementation

    Mono is a project led by Xamarin (formerly by Ximian, then Novell) to create an Ecma standard compliant .NET compatible set of tools.
    Mono's support for System.Windows.Forms as of .NET 2.0 is announced as complete; also System.Windows.Forms 2.0 works natively on Mac OS X. However, Windows.Forms is not actively developed on Mono, and full compatibility with .NET is not achieved and is not possible, because Windows Forms is mainly a wrapper around the Windows API, and some of the methods allow direct access to Win32 callbacks, which are not available in other platforms than Windows.

    GTK+ :


    GTK+ (GIMP Toolkit) is a cross-platform widget toolkit for creating graphical user interfaces. It is licensed under the terms of the GNU LGPL, allowing both free and proprietary software to use it. It is one of the most popular toolkits for the X Window System, along with Qt.

    The name GTK+ originates from GTK; the plus was added to distinguish an enhanced version. It was originally created for the GNU Image Manipulation Program (GIMP), a free software raster graphics editor, in 1997 by Spencer Kimball and Peter Mattis, members of eXperimental Computing Facility (XCF) at the University of California, Berkeley. It is now maintained by members of the GNOME Foundation.


    GTK+ is an object-oriented widget toolkit written in the C programming language; it uses the GLib object system for the object orientation. On the X11 display server, GTK+ uses Xlib to draw widgets. Using Xlib provides flexibility and allows GTK+ to be used on platforms where the X Window System is unavailable. While GTK+ is primarily targeted at the X Window System, it works on other platforms, including Microsoft Windows (interfaced with the Windows API), and Mac OS X (interfaced with Quartz). HTML5 and Wayland backends are in development.

    GTK+ can be configured to change the look of the widgets drawn; this is done using different display engines. Several display engines exist which try to emulate the look of the native widgets on the platform in use.

    • GTK+ consists of about 773,494 lines of code
    • Qt5 consists of about 7,605,264 lines of code
    • Clutter contains of about 133,471 lines of code

    • Programming language bindings

      A library written in one programming language may be used in another language if bindings are written; GTK+ has a range of bindings for various languages.

      GUI designers
    • There are several GUI designers for GTK+. The following projects are active as of July 2011:
    • Glade, supports GtkBuilder, which is a GTK+ built-in GUI description format.
    • Gazpacho, GUI builder for the GTK+ toolkit written in Python
    • Crow Designer, relies on its own GuiXml format and GuiLoader library.
    • Stetic, part of MonoDevelop, oriented towards Gtk#.

    • Uses

      A couple of desktop environments for the X Window System/Wayland (display server protocol) utilize GTK+ as widget toolkit.

    • Desktop Environments that use GTK+
    • GNOME is based on GTK+, meaning that programs native to GNOME use GTK+
    • Consort, the GNOME 3.4 Fallback Mode - Fork, from SolusOS
    • Cinnamon, which is a fork of GNOME 3, uses GTK+ version 3
    • MATE (desktop environment), a fork made of GNOME version 2 after the release of GNOME version 3
    • Xfce is currently based on GTK+ version 2 with support for and eventual plans for a migration to GTK+ version 3
    • LXDE (Lightweight X11 Desktop Environment) is based on GTK+ version 2
    • Sugar is a desktop environment oriented towards children's education, which uses GTK+, especially PyGTK ROX Desktop is a lightweight desktop, with features from the GUI of RISC OS
    • GPE Palmtop Environment
    • Access Linux Platform (successor of the Palm OS PDA platform)
    • KDE, though based on Qt, has integration with GTK+-based programs and themes (since version 4.2).
    • GTK+ programs do not require a desktop environment made with GTK+. If the required libraries are installed, a GTK+ program can run on top of other X11-based desktop environments or window managers; this includes Mac OS X if is installed (which is the default since the Leopard release). GTK+ can also run under Microsoft Windows, where it is used by some popular cross-platform applications like Pidgin and GIMP. wxWidgets, a cross-platform GUI toolkit, uses GTK+ for GNU/Linux operating systems. Other ports include DirectFB (used by the Debian installer, for example) and ncurses.

    • Window managers

      The following window managers use GTK+

    • Aewm
    • AfterStep
    • Amaterus
    • Consortium
    • IceWM
    • Metacity
    • Mutter
    • Sawfish
    • Wmg
    • Xfwm

    • Applications
    • Some notable applications that use GTK+ as a widget toolkit include:
    • AbiWord - Word processor
    • Anjuta - Integrated development environment (IDE)
    • Ardour - Digital audio workstation
    • Chromium - GNU/Linux version of the web browser developed in large part by Google
    • Ekiga (formerly GnomeMeeting) - VoIP and video conferencing application.
    • Web - Official GNOME web browser.
    • Evolution - Personal information manager
    • gconfig - Linux kernel source configuration utility.
    • GIMP - Raster graphics editor
    • Gnumeric - Spreadsheet application.
    • GRAMPS - Genealogy software
    • Inkscape - Vector graphics editor for SVG
    • LiVES - Video editor
    • Midori - Minimalistic web browser utilizing GTKWebKit as rendering engine and GTK+ as widget toolkit.
    • Pidgin - Instant messenger application.
    • Wireshark (formerly Ethereal) - network Packet analyzer application.
    • Geany - a light-weight cross-platform IDE and GTK+ text editor based on Scintilla.

    • History

      GTK+ was originally designed and used in the GNU Image Manipulation Program (GIMP) as a replacement of the Motif toolkit; at some point Peter Mattis became disenchanted with Motif and began to write his own GUI toolkit called the GIMP toolkit and had successfully replaced Motif by the 0.60 release of GIMP. Finally GTK was re-written to be object-oriented and was renamed GTK+. This was first used in the 0.99 release of GIMP.

      GTK+ 2.0

      The GTK+ 2.0.0 release series introduced new features which include improved text rendering using Pango, a new theme engine, improved accessibility using the Accessibility Toolkit, complete transition to Unicode using UTF-8 strings, and a more flexible API. Starting with version 2.8, GTK+ 2 depends on the Cairo graphics library for rendering vector graphics.

      GTK+ 3.0

      GTK+ version 3.0.0 included revised input device handling, support for themes written with CSS-like syntax, and the ability to receive information about other opened GTK+ applications.

  • SmartWin++ :


    SmartWin++ is a Windows GUI and SOAP programming library written in and for C++. It uses newer (C++98) language features such as templates, type-safe conversions and the STL. Like many GUI libraries for Windows, SmartWin++ essentially wraps functions from the C based Windows API in objects, arguably making GUI programming easier.


    Compared to other GUI toolkits (e.g. Windows Forms, MFC, wxWidgets and Swing), SmartWin++ generates very little overhead, in terms of RAM usage, and often requires less code to do the same thing. In addition, unlike many other libraries, it is licenced under BSD (i.e., free to use for all purposes without restrictions).


    SmartWin++ requires a relatively recent compiler, since it is written in C++98. It might lack some features present in other libraries. The library is not as widely used as some other libraries, although the user base is growing. One IDE - Sally - exists but it is relatively primitive. SmartWin++ is C++ and Windows only, unlike wxWidgets, Qt, etc.

    Quality Service

    There are no significant bugs in our released software that any significant number of users want fixed. I m saying we dont do a new version to fix bugs. We dont. Not enough people would buy it. You can take a hundred people using Microsoft Word. Call them up and say "Would you buy a new version because of bugs?" You won't get a single person to say they'd buy a new version because of bugs. We'd never be able to sell a release on that basis.
    -Focus Magazine No. 43

    Intelligent Quotes

    A solid working knowledge of productivity software and other IT tools has become a basic foundation for success in virtually any career. Beyond that, however, I don't think you can overemphasise the importance of having a good background in maths and science.....
    "Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)... A step in thr development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points. "
    "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change"
    "The ultimate measurement is effectiveness, not efficiency "
    "It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. "Architecture-centric methods and agile approaches." Agile Processes in Software Engineering and Extreme Programming.
    "Java is C++ without the guns, knives, and clubs "
    "When done well, software is invisible"
    "Our words are built on the objects of our experience. They have acquired their effectiveness by adapting themselves to the occurrences of our everyday world."
    "I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby. "
    "The best way to predict the future is to invent it."
    "In 30 years Lisp will likely be ahead of C++/Java (but behind something else)"
    "Possibly the only real object-oriented system in working order. (About Internet)"
    "Simple things should be simple, complex things should be possible. "
    "Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines."
    "Model Driven Architecture is a style of enterprise application development and integration, based on using automated tools to build system independent models and transform them into efficient implementations. "
    "The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. "
    "Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making. "
    "Ultimately, discovery and invention are both problems of classification, and classification is fundamentally a problem of finding sameness. When we classify, we seek to group things that have a common structure or exhibit a common behavior. "
    "Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world. "
    "The entire history of software engineering is that of the rise in levels of abstraction. "
    "The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist "

    Core Values ?

    Agile And Scrum Based Architecture

    Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration.....


    Core Values ?

    Total quality management

    Total Quality Management / TQM is an integrative philosophy of management for continuously improving the quality of products and processes. TQM is based on the premise that the quality of products and .....


    Core Values ?

    Design that Matters

    We are more than code junkies. We're a company that cares how a product works and what it says to its users. There is no reason why your custom software should be difficult to understand.....


    Core Values ?

    Expertise that is Second to None

    With extensive software development experience, our development team is up for any challenge within the Great Plains development environment. our Research works on IEEE international papers are consider....


    Core Values ?

    Solutions that Deliver Results

    We have a proven track record of developing and delivering solutions that have resulted in reduced costs, time savings, and increased efficiency. Our clients are very much ....


    Core Values ?

    Relentless Software Testing

    We simply dont release anything that isnt tested well. Tell us something cant be tested under automation, and we will go prove it can be. We create tests before we write the complementary production software......


    Core Values ?

    Unparalled Technical Support

    If a customer needs technical support for one of our products, no-one can do it better than us. Our offices are open from 9am until 9pm Monday to Friday, and soon to be 24hours. Unlike many companies, you are able to....


    Core Values ?

    Impressive Results

    We have a reputation for process genius, fanatical testing, high quality, and software joy. Whatever your business, our methods will work well in your field. We have done work in Erp Solutions ,e-commerce, Portal Solutions,IEEE Research....



    Why Choose Us ?

    Invest in Thoughts

    The intellectual commitment of our development team is central to the leonsoft ability to achieve its mission: to develop principled, innovative thought leaders in global communities.

    Read More
    From Idea to Enterprise

    Today's most successful enterprise applications were once nothing more than an idea in someone's head. While many of these applications are planned and budgeted from the beginning.

    Read More
    Constant Innovation

    We constantly strive to redefine the standard of excellence in everything we do. We encourage both individuals and teams to constantly strive for developing innovative technologies....

    Read More
    Utmost Integrity

    If our customers are the foundation of our business, then integrity is the cornerstone. Everything we do is guided by what is right. We live by the highest ethical standards.....

    Read More