Une application Windows est une application qui utilise directement ou indirectement les fonctionnalités du système d'exploitation Windows.

GUI signifie Graphical User Interface c'est-à-dire Interface Graphique pour Utilisateur. Une "GUI Application" (terme anglais) est une application complètement intégrée dans l'environnement graphique de Windows. Une telle application possède généralement une fenêtre principale comportant éventuellement un menu, des boutons ainsi que d'autres gadgets graphiques mais elle peut également ne pas afficher de fenêtre. C'est le cas par exemple des applications qui tournent en tâche de fond. Parfois, on dit tout simplement une "Application Windows" pour dire en fait une "GUI Application", ce qui est généralement source de confusion.

Une application console est une application Windows qui s'exécute dans une console. Une console est une fenêtre qui sert d'interface entre une application dépourvue d'une interface graphique (qui se cache derrière la console) et l'utilisateur (qui est face à la console). Les entrées de l'utilisateur se font largement à l'aide du clavier.

Non. Une application console est une application Windows, elle ne peut pas être exécutée sous DOS.

En gros, une API (Application Programming Interface) est un ensemble de fonctions exposées par un logiciel pour fournir des services aux autres logiciels. Il arrive également très souvent qu'on utilise ce terme pour désigner une fonction de cette API ("une API") plutôt que l'API elle-même.

L'API Windows est l'ensemble des fonctions exposées par Windows pour permettre aux applications de lui demander un service (créer une fenêtre, l'afficher, la fermer, etc.). Ces fonctions sont contenues dans diverses DLLs. La plupart du temps, vos applications utiliseront (pas forcément toutes en même temps) kernel32.dll qui contient les fonctions permettant de s'intefacer avec le noyau, user32.dll qui contient les fonctions permettant de programmer l'interface utilisateur et gdi32.dll qui fournit l'interface des périphériques graphiques (GDI - Graphics Device Interface) pour les applications. Ces fichiers sont tous situés dans le répertoire système (system32). Selon la ou les DLLs que vous utiliserez, vous devez ajouter les fichiers d'importation correspondants dans les entrées du linkeur (kernel32.lib, user32.lib, gdi32.lib). En principe, cela est déjà effectué par votre environnement de développement dès que vous créez un projet d'application Windows.

Le premier Windows NT (Windows « New Technology ») de l'histoire, Windows NT 3.1, fut sorti en 1993, c'est-à-dire peu après la sortie de Windows 3.1 (1992). Windows NT est un système d'exploitation entièrement 32 bits (DOS était 16 bits) développé par Microsoft indépendamment de MS-DOS. Il n'y a donc aucun lien entre Windows NT et MS-DOS. Windows 1.0, 2.0 et 3.x (éditions 16 bits) ainsi que Windows 95, 98 et Me (éditions 32 bits) sont toutes des évolutions de MS-DOS. Windows 2000, XP et Vista quant à eux sont basés sur Windows NT. Il ne faut pas cependant croire que Windows 9x et Me n'ont eu aucune influence sur ces systèmes. Windows XP par exemple, bien que basé sur un noyau NT, inclut de nombreuses foncionnalités inspirées de Windows 98 et Me, en particulier en ce qui concerne l'interface utilisateur.

L'API Windows est la même quelle que soit la version du système ciblé (Windows 9x/Me, NT, 32 ou 64 bits) à part éventuellemet quelques types et/ou fonctions en plus spécifiques à chaque version. Vos programmes pourront donc généralement compiler aussi bien pour Windows 32 bits que pour Windows 64 bits.

Un sous-système d'environnement est un composant du système chargé de faire tourner les applications. Le plus important, et qui est à la base de tous les autres sous-systèmes, est le sous-système Win32 (csrss.exe). Il a pour rôle de faire tourner les applications spécifiquement conçues pour Windows (donc tant les applications consoles que les applications fenêtrées (GUI)). Ces applications utilisent donc l'API Win32 (l'API fournie par Win32).

Windows NT comprend également les sous-systèmes VDM (ntvdm.exe - Windows NT Virtual DOS Machine) et WOW (wowexec.exe - Windows on Win32) qui sont respectivement chargés de faire tourner les applications MS-DOS (ces applications s'exécuteront dans une console) et les applications Windows 16 bits. Etant donné que les éditions 16 bits de Windows n'étaient qu'une couche graphique avec un noyau MS-DOS, le sous-système Windows 16 bits lui même (WOW) a besoin de NTVDM pour fonctionner. Contrairement à Win32, le sous-système « naturel » des éditions 32 et 64 bits, les sous-systèmes VDM et Windows 16 bits ne sont lancés que lorsqu'on a besoin d'eux. Il ne faut pas non plus oublier que, ces sous-systèmes (en fait tous les sous-systèmes autres que Win32 lui-même) étant eux-mêmes des programmes de l'utilisateur, ils utilisent également l'API Win32 (inaccessible directement par les applications qu'ils font tourner) pour implémenter leurs propres APIs.

Avant l'arrivée de XP, Windows supportait également les sous-systèmes POSIX et OS/2, qui permettaient de faire tourner respectivement des applications Windows (.exe) basées sur l'API POSIX (fournie par le sous-système POSIX ...) et des applications basées sur OS/2. Il était donc possible de recompiler des applications POSIX ou OS/2 existantes et de les faire fonctionner ensuite sous Windows. De nos jours, des logiciels complets tels que Microsoft Windows Services for UNIX ou Microsoft Virtual PC et parfois même des émulateurs comme Cygwin remplacent avantageusement ces sous-systèmes.

Un sous-système d'environnement est également appelé un environnement d'exécution.

Win32 supporte une partie de l'API POSIX. Cette API est proposée en tant qu'extension de la bibliothèque standard du C. Consultez la référence de la bibliothèque d'exécution du C pour savoir si la fonction que vous voulez utiliser est supportée.

Le Shell désigne l'ensemble de tous les composants permettant à l'utilisateur d'interagir avec Windows. Le Shell comprend donc à la base la barre des tâches et tout ce qu'il comprend (menu démarrer et tout le reste ...) et bien sûr le bureau. Tout cela est en fait géré par un logiciel appelé explorer.exe, le Shell de Windows. Il se programme en utilisant ses fonctions ou ses interfaces COM qui, ensemble, forment ce qu'on appelle l'API du Shell.

En réalité, shell (coquille) est le nom donné au logiciel qui sert d'interface entre l'utilisateur et le système d'exploitation. Par exemple, dans un système en mode texte, le shell est tout simplement l'interpérteur de commandes. Pour certains, le shell n'est rien de plus qu'un logiciel qui tourne sur le système et ne fait donc pas partie du système. Pour d'autres, il tient quand même un rôle assez important et mérite d'être considéré comme faisant partie du système lui-même. Vous avez aussi sûrement votre propre point de vue ...

COM (Componnent Object Model) est une technologie orientée objets indépendante de tout système d'exploitation et de tout langage de programmation permettant de développer des composants utilisables depuis n'importe quel langage supportant cette technologie (C, C++, Visual Basic et même Java, etc.). COM est le fondement de nombreuses technologies Microsoft, incluant OLE (originalement Object Linking and Embedding), Automation (OLE Automation) et ActiveX.

COM n'est ni une bibliothèque ni un langage de programmation, mais une spécification d'un format binaire pour des objets appelés "composants", afin qu'ils puissent être utilisés depuis n'importe quel langage supportant ce format, peu importe le langage dans lequel ils ont été écrits. Etant donnée que COM utilise les principes de la programmation orientée objets, il est plus simple de développer des composants en utilisant un langage orienté objets comme C++ ou SmallTalk mais on peut aussi bien créer qu'utiliser de tels composants en utilisant un langage comme le C ou Pascal par exemple.

Dans vos applications Win32 qui utilisent OLE ou COM, n'oubliez pas de vous lier avec ole32.lib, oleaut32.lib et uuid.lib (bibliothèque (statique) des UUIDs des interfaces prédéfinies) sinon l'édition des liens ne passera pas. Un UUID (Universally Unique ID) est une valeur qui identifie de manière unique au monde une interface. Sous Visual C++, vous n'avez pas à vous soucier de ces fichiers car il le fait déjà pour vous.