What is a DLL?
Dynamic Link Libraries (DLL)s are like EXEs but they are not directly executable. They are similar to .so files in Linux/Unix. That is to say, DLLs are MS's implementation of shared libraries.
DLLs are so much like an EXE that the file format itself is the same. Both EXE and DLLs are based on the Portable Executable (PE) file format. DLLs can also contain COM components and .NET libraries.
What does a DLL contain?
A DLL contains functions, classes, variables, UIs and resources (such as icons, images, files, ...) that an EXE, or other DLL uses.
Types of libraries:
On virtually all operating systems, there are 2 types of libraries. Static libraries and dynamic libraries. In windows the file extensions are as follows: Static libraries (.lib) and dynamic libraries (.dll). The main difference is that static libraries are linked to the executable at compile time; whereas dynamic linked libraries are not linked until run-time.
More on static and dynamic libraries:
You don't normally see static libraries though on your computer, because a static library is embedded directly inside of a module (EXE or DLL). A dynamic library is a stand-alone file.
A DLL can be changed at any time and is only loaded at runtime when an EXE explicitly loads the DLL. A static library cannot be changed once it is compiled within the EXE.
A DLL can be updated individually without updating the EXE itself.
Loading a DLL:
A program loads a DLL at startup, via the Win32 API LoadLibrary, or when it is a dependency of another DLL. A program uses the GetProcAddress to load a function or LoadResource to load a resource.
Further reading:
Please check MSDN or Wikipedia for further reading. Also the sources of this answer.
As a simplification, it's like this:
About Cygwin
Cygwin is a compatibility layer that makes it easy to port simple Unix-based applications to Windows, by emulating many of the basic interfaces that Unix-based operating systems provide, such as pipes, Unix-style file and directory access, and so on as documented by the POSIX standards. If you have existing source code that uses these interfaces, you may be able to compile it for use with Cygwin after making very few or even no changes, greatly simplifying the process of porting simple IO based Unix code for use on Windows.
When you distribute your software, the recipient will need to run it along with the Cygwin run-time environment (provided by the file cygwin1.dll
). You may distribute this with your software, but your software will have to comply with its open source license. Even just linking your software with it, but distributing the dll separately, can still impose license restrictions on your code.
About MinGW
MinGW aims to simply be a port of GNU's development tools for Windows. It does not attempt to emulate or provide comprehensive compatibility with Unix, other that to provide a version of the GNU Compiler Collection, GNU Binutils and GNU Debugger that can be used natively in Windows. It also includes header files allowing the use of Windows' native API in your code.
As a result your application needs to specifically be programmed for Windows, using the Windows API, which may mean significant alteration if it was created to rely on being run in a standard Unix environment and use Unix-specific features. By default, code compiled in MinGW's GCC will compile to a native Windows X86 target, including .exe and .dll files, though you could also cross-compile with the right settings, since you are basically using the GNU compiler tools suite.
MinGW is a free and open source alternative to using the Microsoft Visual C++ compiler and its associated linking/make tools on Windows. It may be possible in some cases to use MinGW to compile something that was intended for compiling with Microsoft Visual C++ without too many modifications.
Even though MingW includes some header files and interface code allowing your code to interact with the Windows API, as with the regular standard libraries this doesn't impose licensing restrictions on software you have created.
Other considerations
For any non-trivial software application, such as one that uses a graphical interface, multimedia or accesses devices on the system, you leave the boundary of what Cygwin can do for you and further work will be needed to make your code cross-platform. But, this task can be simplified by using cross-platform toolkits or frameworks that allow coding once and having your code compile successfully for any platform. If you use such a framework from the start, you can not only reduce your headaches when it comes time to port to another platform but you can use the same graphical widgets - windows, menus and controls - across all platforms if you're writing a GUI app, and have them appear native to the user.
For instance, the open source Qt framework is a popular and comprehensive cross-platform development framework, allowing the building of graphical applications that work across operating systems including windows. There are other such frameworks too. In addition to the large frameworks there are thousands of more specialized software libraries in existence which support multiple platforms allowing you to worry less about writing different code for different platforms.
When you are developing cross-platform software from the start, you would not normally have any reason to use Cygwin. When compiled on Windows, you would usually aim to make your code able to be compiled with either MingW or Microsoft Visual C/C++, or both. When compiling on Linux/*nix, you'd most often compile it with the GNU compilers and tools directly.
Best Answer
There are many closely-related concepts involved, and related terms are often misused, even in the official documentation.
Important types of windows:
top-level windows: Windows that have no parent window. The main window for an application is almost always a top-level window. It does not have anything to do with z-order.
child windows: Windows that are contained by a parent window. Their position is always relative to the parent window's area. Child windows are often "controls": UI things like buttons and edit boxes.
parent windows: Windows that have child windows. Top-level windows often have children. But note that child windows may also have children and thus be both parent and child windows.
owned windows: Windows that are controlled by a another window, but aren't necessarily children of the other window. An example is a floating tool palette: it's owned by another window in the application, but it's not locked to that other window's area.
owner windows: Windows that own an owned window.
Often the distinction between an owner/owned relationship and a parent/child relationship isn't important, so the parent and child terms are often used for both contexts, even in documentation. In some cases, parent fields and parameters are overloaded to mean parent and/or owner.
Important concepts:
top of the z-order: This literally means the window that displays above other windows.
active window: A fuzzy concept, but it typically means the top-level window the user would consider the "current" window. The active window is typically drawn with a distinctive border and its tile on the task bar is highlighted. The active window is usually at or near to the top of the z-order among all other top-level windows, and it is the parent or owner (perhaps indirectly) of the window with keyboard focus.
keyboard focus: Indicates the window that will receive the keyboard messages. Conceptually, there is one window with keyboard focus. Often the window with focus is a child (or grandchild, etc.) of the active window.
foreground: The active window is typically in the foreground. The name seems to suggest that it's at the top of the z-order, but it really means that the thread that created the window gets a slight priority boost. That active window is usually also the foreground window.
So let's say you've got this browser window open, and you've also got an instance of Notepad running. If you click on the document in Notepad, a whole flurry of messages and state changes occur. You're actually clicking on a big edit box, which is a child window of Notepad's top-level window. That click causes the edit box to get activated, but child windows can't really be the "active" window, so it just takes the keyboard focus and passes the activation message up through its ancestors until it gets to a top-level window. The top-level window "activates" by moving to the top of the z-order, highlighting its border, etc. It also becomes the foreground window, so its thread gets a little boost to make the UI a little more responsive than any other windows.
With these terms in mind, you can parse the MSDN descriptions for the functions you listed to tease out the subtle differences.
If you're trying to lay out your window's children, just use SetWindowPos (or MoveWindow, SizeWindow, and ShowWinow). Of the remaining functions, SwitchToThisWindow looks deprecated and essentially the same as SetForegroundWindow. (Note that, in many cases, SetForegroundWindow won't do what you want unless you're the active application or the active application has given you permission to use it.) BringWindowToTop is mostly about bringing a window to the top of the z-order (which you can do with SetWindowPos), with extra side effects that make it behave like SetForegroundWindow if you call it on a top-level window.
Update: Raymond Chen posted a clearer distinction between the active window and the foreground window. To quote: