I write a graphics engine based on COM. Also I really love C#-style events and I plan add to API something like "events". As far as I know in COM events can be implemented with the so called "connection points" but it looks awful! Also in C++/CX we have key word "event" and the same normal way to use events as in C#. But I did not find any examples of using C++/CX in COM. Is it possible?
Yes, you can combine the two but depending on how your customers use your engine, they might not like it; using WinRT events from C is not pretty.
C++/WinRT would be a better choice than C++/CX now that it's available; it is smaller, faster, and 100% standards-compliant. You will still need to create Windows Metadata (WinMDs) by writing IDL though.
Related
I am going to develop an AudioUnit software synth component for use in Logic Pro, GarageBand, etc.
In Apple's tutorial, they use C++. Is this mandatory, or could I use Objective C as well?
I think you cannot avoid C++ completely. According to the documentation, you can create a new AudioUnit by subclassing Core Audio SDK’s C++ superclasses. This is, I think, mandatory.
However, you are free to mix C++ and Objective-C, so you should be able to create the C++ subclass and full-fill the requirements of an AudioUnit interface, but implement (most) of the functionality in Objective C.
Yet, the central part of audio functionality (the low level rendering callback) consists of procedures, which are mostly written plain C, as you may see in much of the sample code and open source examples. For me it worked best to write this part as stand-alone first, only upon making sure it does its job as desired -robustly and properly, to take care of defining classes, instances, methods and code reusability.
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.
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.
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.
How can I get UI framework independent (WinForms, WPF, other frameworks) way to filter windows messages?
Thank you.
Windows messages are framework dependent.
WPF actually tries to hide this away from you but it depends on the old win32 message loop still for much of it's behaviour. WinForms is just a paper thin (and badly incomplete) wrapper on win32 too.
The techniques for sharing them are probably useful in terms of writing a common filter function and hooking that up to all the different frameworks.
Note that, as the framework distances itself further from the win32 model the set of messages that are meaningful to intercept becomes fewer and fewer.