Maybe I'm just missing something but I was thinking what do you call something like a Windows Form Application in Visual Studio where you can drag and drop and stuff like that. Do you call that an API or SDK or GUI or something else?
By the way, as I understand that Windows Form Application that I'm talking about is actually Visual Basic, correct me if I'm wrong. And if it possible to create applications by mostly drag and droping why use something like Win32 API?
1 Year Ago
Related Article:Adobe SDK Library? (C++ API)
is a C++ discussion thread by danny2000 that has 2 replies, was last updated 9 months ago and has been tagged with the keywords: adobe, sdk.
An API (Application Programming Interface) refers to a set of specifications on how you can make function calls to a library to perform certain operations (basically, a specification, from a programmer's point-of-view, on how to use a library).
An SDK (Software Development Kit) is a set of tools and documentation, or kit, that work together to help you use a particular library or develop a specific kind of software.
A GUI (Graphical User Interface) is the part of a software that allows the user to interact with the program through visual representations and controls (buttons, edit boxes, etc.).
So, Windows Forms, MFC and Win32 are basically different GUI libraries, specified and used by their respective APIs. Furthermore, they each have a number of tools to help you develop software with those libraries. Some of these tools are bundled into (downloadable) SDKs, but others come as plugins to an IDE (Integrated Development Environment). So, the whole drag-and-drop style tools would be most accurately described as a GUI Design Tool (or Environment). That's what I usually refer to them as, GUI designers or just GUI tools, or GUI makers. Sometimes, you might also hear people use the term "RAD tool" to name such tools, here, RAD stands for Rapid Application Development. Although, to be rigorous, this term could be used for other tools too, often, programming-based tools for specific application domains (like database apps, automation, etc.).
By the way, as I understand that Windows Form Application that I'm talking about is actually Visual Basic, correct me if I'm wrong.
You are wrong. Windows Forms is as a library is part of (or built upon) the .NET framework by microsoft (a managed, virtual and "uniform" running environment, similar to the Java Virtual Machine). There is no Visual Basic in that. The RAD-tool to do Windows Forms applications in similar in appearance to its predecessors in the microsoft family, which includes MFC, traditionally used through Visual Basic only (because the C++ version, or others, were problematic and poorly integrated). So, there is some relation in that sense. Furthermore, Windows Forms is usable on any .NET language, including VB.NET (Visual Basic for .NET). Finally, I'm no expert on Windows Forms, but it is possible that some parts of it are programmed in Visual Basic (I know some parts of MFC were written in Visual Basic).
And if it possible to create applications by mostly drag and droping why use something like Win32 API?
I don't think there is much rational reasons to use Win32 API anymore, at least, not to do a full-blown GUI. People will still use Win32 API for a lot of other smaller tasks (file I/O, sockets, message-boxes, etc.), because it is very easy to use directly (just include the windows header and call the functions you need).
I was going to say that people might stick to Win32 API for backward compatibility or maximum compatibility, but then I remembered that, in the world of Microsoft, backward compatibility is non-existent by design.
You also need to keep in mind that the extent to which you can do things with drag-drop tools is fairly limited. Writing a simple calculator app or even something more complex like a database app can probably be done fairly easily with mostly drag-drop design and some trivial bits of coding on event handlers. But as soon as things get a bit more complicated, with multiple work-spaces, menu configurations, plugins, embedded widgets, special widgets like a 3D rendering area, and so on, you quickly find that most of the GUI work is done with coding only. So, at that level, the gains in rapid application development that drag-and-drop tools give you for simple tasks are no longer as important as a lot of other factors to help you deliver good applications.
But yeah, most GUI libraries today offer very good RAD tools that allow you to do a lot with just drag-and-drop operations, that includes WinForms, VCL, Qt and many others. So, there isn't much reason to select one that doesn't give you a RAD tool to work with.
But then again, as always, Win32 API might be used purely for legacy reasons (you have already a large code-base that uses it, so might as well continue to use it, instead to overhauling the entire thing).