It seems that the Win32 API (the C API for native Windows applications) is becoming more and more overtaken by more modern frameworks and toolkits, including Microsoft's own WPF and Qt.
If the programming language is not a concern -- if you're not set on a managed environment, or a functional programming style, etc. -- does Win32 API bring anything to the table? Is there any functionality that one can implement with Win32 API that's not available with WPF or other frameworks?
I know it's possible to mix Win32 code into WPF/managed software, so one doesn't have to choose one or the other. But what are some examples of needing to break out Win32 API when developing a program in a higher-level language/framework?
Another more specific example is "windows hooks".
I needed to hook some socket programs at some point and the only possible way was windows api.
To elaborate i wanted to receive all communication received on some listening socket on a different one. Doing this requires hooks
Certainly.
All the frameworks are written in terms of the Win32 API. The frameworks cover 80-95% of what programmers need to do, but if you need really low-level control over something, you'll need to drop to the underlying Win32 API. Some examples would be:
precise control over text rendering (via DirectWrite),
detailed control over speech recognition using SAPI (there are literally dozens of interfaces not exposed through System.Speech),
low-level networking code (i.e., anything not HTTP related),
Practically anything audio related, if you're interested in performance.
... and don't forget about direct hardware access like "WinUSB" and debugging functionality (writing programs that act as debuggers).
The Win32 API is nowhere close to be taken over by any framework at the moment.
If that was the case, most of the API would not be updated by Microsoft. Instead, lots of new interfaces are added and updated.
There are framekorks like Qt, but, unless what you need to create is trivial, you will eventually use the API, especially for new graphics libraries, audio, video, usb, ribbon, sockets, network, COM automation, biometrics, encryption, digital signatures, security, scripting, etc.
Actually, most libraries are quite outdated and, while you can create an application that relies mostly on worker threads and not on the interface, building a nice, modern and useful application today certainly requires the API. So investing on a framework that would only cover a minimum part of your application is not worth the learning curve, these frameworks mostly target really new and unexperienced windows developers.
Related
I was just thinking. C# has Winforms/WPF, Java has Swing and other frameworks, C++ has QT and so on; is it possible to create an application without using a Framework?
Putting aside the practicality of it, I'm just curious. How would one create an application that Just Works(tm) without needing external frameworks?
Two options come to mind:
Classical Win32 applications written in C. I don't know if standard Windows SDK API also counts as an "external framework" in your book, but that's as low as it gets.
DirectX/OpenGL games written from scratch with your own homebrew framework (not external, right?) There you get to do all the drawing yourself - although again, you use a pretty big library of primitive drawing functions.
If you want even less "framework", you'll have to code your own OS and drivers. :P
C# needs .NET Framework, not WinForms (which is an optional library used by some application). The same with Java.
Unmanaged (native) applications usually use some runtime library - the library of common functions. You can write a native application without any library - the compiler lets you do this, but you will need to (re)write lots of common functions, eg. for string manipulation etc..
Firstly, what is a framework?
Really a framework is just a bunch of code that is provided to you. You could, at least in theory, write the same code yourself. In that case you wouldn't be using a framework.
Your application can only do what the operating system allows it to do. Your program cannot directly manipulate the graphics card for example. So you have to use the APIs of your operating system in order to do anything.
So you are going to be calling into other code. (unless you write your own operating system). You will also being using another framework or api to get stuff done.
Yes. How: in the way that the frameworks you mentioned are implemented.
From a Windows point of view, you would register your window with Windows, then listen to window messages and react as required. Everything would be up to you - from drawing the window to building controls.
I don't see how Qt does the low level graphics work, in order to create its own custom GUI look/feel for each platform. Does it utilize each of the platforms APIs or something? I ask because I am really wondering how I could go about creating my own framework in order to make a custom GUI application with a unique graphical look.
"How does QT only use C++ to make custom GUIs for some many platforms?"
"Does it utilize each of the platforms APIs ... ?"
You answered your own question. It makes a common library for developers to write their applications with. The application developers write their application only once, not caring about platform specifics. Then, the library author puts out different versions of the library for each platform, which handles all the specific UI calls. This is called encapsulation:
http://en.wikipedia.org/wiki/Information_hiding#Encapsulation
If you were to write your own such library, you would need to figure out what is common between all of the platforms you target, or figure out what high-level concepts your application would need, and create that abstraction. Then, implement that abstraction for each of the platforms you wanted to support.
Edit:
Also see Juliano's comment. This seems like it might be closer to what you want to do, rather than the question you asked. I'd not re-do the work that Trolltech or the WxWidgets team or the Gtk guys or the Mono people did, if I could possibly avoid it.
The good people at Trolltech (now Nokia) write all the platform specific code for you. Only the interfaces to their library remains the same across platforms. You do have to make sure that you only use their classes and don't make any OS-specific calls.
If you want, you can modify the graphics and the handlers to extend the Qt library and create your own look and feel.
Your Qt application doesn't have to have the plain standard platform graphical look, but there are ways to design unique apps with Qt.
For instance, you can style your application with style sheets: http://doc.qt.io/qt-5/stylesheet.html, or even with a custom QStyle (which is not very easy): http://doc.qt.io/qt-5/qstyle.html
Qt Quick is a new technology we're introducing in the upcoming Qt 4.7 (check out the beta if you're interested). It allows you to easily define custom UI components from simple primitives, with custom animations, state transitions and other effects. See for example http://www.youtube.com/watch?v=8G4U7QWRajg.
On Windows there a few libraries that allow you to intercept calls to DLLs:
http://www.codeproject.com/kb/system/hooksys.aspx
Is it possible to do this on Mac OS? If so, how is it done?
The answer depends on whether you want to do this in your own application or systemwide. In your own application, it's pretty easy; the dynamic linker provides features such as DYLD_INSERT_LIBRARIES. If you're doing this for debugging/instrumentation purposes, also check out DTrace.
You can replace Objective-C method implementations with method swizzling, e.g. JRSwizzle or Apple's method_exchangeImplementations (10.5+).
If you want to modify library behavior systemwide, you're going to need to load into other processes' address spaces.
Two loading mechanisms originally designed for other purposes (input managers and scripting additions) are commonly abused for this purpose, but I wouldn't really recommend them.
mach_inject/mach_override are an open-source set of libraries for loading code and replacing function implementations, respectively; however, you're responsible for writing your own application which uses the libraries. (Also, take a look at this answer; you need special permissions to inject code into other processes.)
Please keep in mind that application patching/code injection for non-debugging purposes is strongly discouraged by Apple and some Mac users (and developers) are extremely critical of the practice. Much of this criticism is poorly informed, but there have been a number of legitimately poorly written "plug-ins" (particularly those which patch Safari) that have been implicated in application crashes and problems. Code defensively.
(Disclaimer: I am the author of a (free) APE module and an application which uses mach_inject.)
Window's COM allow us to wrap our application function for out-of-process invocation. If the COM interfaces are well defined and design, it is certainly great to consume the services via scripts and any programming platform that support COM/Automation/Active-X.
I am just wondering if there exist any alternate methods to design of what COM does? Or something close or similar methodology?
I am using Delphi in Win32 platform.
I'm not entirely sure, but it seems that you're talking about an alternate to COM for creating plug-ins for your software?
If so, there are myriad options:
TMS Software's Plugin Framework
RemObject's Hydra
Project JEDI's JVCL includes a plugin system
You can also roll your own. I wrote an article many years ago that provides the fundamentals (though the linked source is long since gone to the great bit bucket in the sky).
Corba
or
IBM's SOM
I'm sure there are others as well but those are the 2 others i can think of off the top of my head ...
If you want a TCP/IP (over the internet or over a LAN) interface for your objects, consider SOAP, and REST.
If you want to write plugins for your delphi app and not use COM/OLE-Automation, consider RemObjects SDK.
Is there any fundamental differences in the WinAPI/Win32? Is there any additional knowledge required to take advantage of new OS features?
Are there any pitfalls which someone who's coded Win32 apps in the past might fall in?
I'm not talking about Silverlight, that's a whole different ball of wax. (I don't have the VS that supports that at work yet.)
Edit:
Drew has a pretty good answer so far, but what's critical for a programmer to know?
i.e. What should be in an appendix to Charles Petzold's book? (Theoretically)
There are of course lots of new APIs that you should be aware of to make sure you have the tools you need. Beyond that, there are some changes to note.
Philosophical changes
Large parts of the old win32 APIs focused on C-style APIs where handles were passed around. Nowadays, many of the new APIs being developed are COM-based, so boning up on COM and ATL would be worthwhile.
You might also want to take note of the new API style if you're writing your own libraries, which is a bit more consistent and avoids things like hungarian notation.
Replacements
Generally, don't assume that the methods you knew about 10 years ago are still state-of-the-art; they all still exist, so you won't necessarily be told you're doing it wrong. Check MSDN to see if it refers you to something better, and use the latest SDK so that you'll get deprecation warnings for some functions. Especially, make sure string functions you're using are secure.
Specifically, one 'replacement' API is Direct 2d, which is a DirectX-style API for UIs. If you're writing graphics code for Windows 7, you should consider Direct2d over GDI, which has a programming model that is compatible with, but very different than, GDI's. Direct 2d may be ported back to Vista.
Also, instead of using win32-style menuing, consider using the Ribbon, which will be available for Vista as well as Win7.
If you're using the common controls library, make sure to use v6, not the default of v5.
Finally, make sure you're not unnecessarily calling things that require admin privileges, as that will prompt UAC.
All I can think of for now.
There are new API's for each.
There is additional knowledge, though it may not be required, you should be familiar with 64-bit and multi-threaded application development to name a few. The higher level constructs such as Direct2D, .NET etc., etc., are what require the adjustment in knowledge, not necessarily the lower level APIs.
You have the choice: traditional C/C++ or use the newer .Net framework languages (C# / VB.net / Python.net and more). For the latter, knowing the framework is more important than the implementation. You're isolated (in general) from pointers, threading, buffers and memory management and apart from a few differences in syntax once you know the framework it's portable between languages (ie, you could easily pick up VB.net programming if you're a C# guy as most of what your apps will do is call parts of the framework). You can create a class in C#, use it in a VB.net program and reference the same class out of a Powershell cmdlet for example.
The old-style C interfaces are still for Win32 there but unless you've got a specific need to use them (legacy code, Direct X, device drivers for example) I'd look at the newer stuff. As for things like WPF, there isn't even a direct route in via unmanaged code - you have to jump through all sorts of ugly interop hoops.
Nothing special. The old stuff pretty much works as it did.
There are some new APIs, but nothing earth shattering (and following the old Win32 conventions).
So everything you know from Vista is still true for Win7.
Now, there are some new guidelines regarding user experience (touch screen, libraries (user experience stuff, not programmer stuff)), but the API style is the same.
Integrity levels are also a good thing to learn about. Depending on the nature of your application, if it attempts to do anything involving other processes that are running on the OS, it is important to know about this. This technology prevents processes at a lower integrity level from interacting with processes that are running at a higher integrity level. This includes messaging, hooks, DLL injection, opening handles, and many other techniques.