I was searching through google about Microsoft Component Object Model. Found only few normal articles and only 1 step by step example, which doesn't work. Is there any links/references/books/tutorials you know how to build simple COM component via VS C++? Any answer or help would be appreciated!
COM is generally considered antiquated technology these days. That's not to say nobody is still using it - there are plenty of legacy systems that are still invested in it - but it's rare to find someone approaching it as a newbie nowadays.
I'm not sure if things have moved on much but my recommendations would be Don Box's Essential COM and ATL Internals .
Actually my overriding recommendation would be to avoid it if you can :-)
Start with reading
Essential COM by Don box
a must read for anyone who wants to do COM development.
Inside Com - Dale Rogerson is a classic book and also code project has good examples on it:
http://www.codeproject.com/KB/COM/comintro.aspx
MSDN provides a tutorial for building com with ATL here:
http://msdn.microsoft.com/en-us/library/599w5e7x(VS.71).aspx
It should be good material for getting start.
If you don't have a really good reason to learn COM, I suggest getting into .NET instead. COM a legacy technology, which still lives with us, and sometimes we need to maintain software that use it, or interoperate with it. But there is no good reason to use it for brand new development, in my opinion.
Some COM weaknesses:
Message pumping
Reference counting (caused problems with circular references)
DLL hell
I read somewhere that .NET was first called COM 2.0 internally (sorry, I couldn't find a reference), but later on it has grown into a much more complete platform. It has overcome COM's weaknesses, and provides a great class library.
Related
Can I use the WRL library in C++ as a replacement for ATL to write a COM component? And if yes, would I be able to use it on older desktop Windows systems, like Windows XP?
I'm pretty sure that the answer to the first question is positive as I found this tutorial on MSDN:
http://msdn.microsoft.com/en-us/library/jj822931.aspx
but what about non-Windows 8 systems?
Well, sure you can. You can write a COM server in pure C++ code without any helper classes at all. You can write one in C if you really want to, although that's a violation of the Geneva Convention on Programmer's Rights in most jurisdictions.
What is probably not so visible is what is missing. WRL just doesn't make it any easier to write a server. Or maintain it. What you'll miss out on:
No help whatsoever to implement IDispatch. Obsoleted in WinRT but still quite important in regular servers. The only way to consume the server from a scripting language, IDispatch provides the late binding support.
No help whatsoever for registration. Obsoleted in WinRT, required for regular servers. Note how the DllRegisterServer() entrypoint is missing. The page you linked patches around the problem by requiring you to write a registry script by hand. That works, it is not exactly something you'd want to maintain or document so IT staff can get it right.
No wrappers for Automation types like BSTR, VARIANT and SAFEARRAY. Obsoleted in WinRT along with IDispatch. You can still fall back to <comutil.h> however.
No help whatsoever from the wizards that are built into Visual Studio that help you get it right. COM servers are awkward because definitions appear in multiple places in your code. And need to be an exact match. You get no help to ensure that CalculatorComponent is an exact match with the IDL, it is entirely up to you. Compiler errors you get from making small mistakes, particularly when maintaining it, can be painful.
And a whole bunch if smaller stuff not worth mentioning, like apartments, ActiveX, aggregation, error info, etc. Hurts pretty bad when you need it though. A possible advantage of WRL is that there's less mystical glue, ATL has a fair amount of it that considerably raises the abstraction level. That was intentional but it has to be learned. There's none at all when you use pure C++ of course, albeit that you have to write too much of it yourself.
Yes. You can write a standard COM component.
There is a sample for this directly in the docs.
And no: Such a COM component will only run on Windows 8 and later...
To better myself I am attempting to make my dll's COM compliant, I thought I'd just need to extend/implement a few interfaces and job done but now I am at a cross roads,
1) Should I learn MIDL?
2) Should I install the ATL (I am running VC++Express)?
3) Carry on reading the C++ tutorials (http://progtutorials.tripod.com/COM.htm) and hope my Express edition is too limited?
I was interested in transferring native C++ to Android and Java and read that the libraries would need to expose either static 'C' style functions or implement COM.
Android is Linux based operating system... It does not support DLLs and COM.
So no you can't go via COM. You need to learn how to use JNI.
1) Yes. If you are going to define new interfaces, you pretty much have to. It's not impossible to do without MIDL, but it's way harder than to learn basic MIDL.
2) Yes, please do. It'll hide much of the boiler plate code (which is tedious to write, and error prone).
3) I would recommend the book Essential COM by Don Box. It's awesome. Also, a great companion to that book is Essential IDL by Martin Gudgin.
As for VC++ Express - I have never used them. I guess it's possible to do COM with it, but with limited tool/library support.
Being a C#/Java programmer, I really need to know a fact: Has Windows Programming with Win32SDK/MFC/wxWidget become antiquated?
What is the status of popularity of these technologies in software industry now?
Being a C#/Java programmer, do I need to learn Win32SDK/MFC/wxWidget now?
I think that learning the Win32 SDK is useful because it helps you understand how Windows works internally. I found learning about hooks and subclassing very fascinating. So if it interests you then you should go for it. However, you probably don't need to know Win32. It's not yet antiquated today but it may be in the future.
I never had much interest in MFC because it requires the paid version of Visual Studio.
Yes, learn Win32, even if don't ever intend to write or maintain C/C++ apps.
No, don't bother learning MFC/wxWidget now. MFC does come with its source code, so you can study how some classes implement wrappers for Win32, but that is more interesting to C++ programmers. MFC is has decreased in popularity, though Visual Studio continues to support this older tech. Learn MFC/wxWidget only for an as-needed basis, if you need to maintain some older code.
With C#/Java, you can solve a lot of problems, but there are times when you will need to use Win32 directly to achieve some task. for a variety of reasons. Maybe some functionality is simply missing from .NET/Java, or has a bug that can be avoided by going directly to Win32. Maybe your particular problem to solve has unusual or strict requirements, and you would consider writing a portion of your app in native code using some Win32 calls as necessary. Lots of examples/situations really.
Another reason to learn Win32 is that both .NET/Java are higher level abstractions (which is in itself a good thing), but it really does help to understand the internals for these reasons:
You get an appreciation of how much work .NET/Java do for you. Of course, you can do the same things in C/C++, but it takes a lot more work. Consider these two compelling .NET technologies, WPF and WCF, which do a lot work for you.
You will better understand resource management. Specifically, both .NET/Java are garbage collected environments, but you must deterministically release OS resources (explicitly calling Dispose), for such things as network connections, window handles, kernel objects, and plenty more. You should never rely on the garbage collector to release these objects for you, since the GC is non-deterministic.
Debugging, knowing the internals seriously helps here.
Knowing Win32 can sometimes help explain the API design in .NET at least. Some parts of the .NET API are modeled on Win32 API, but some parts of the .NET API are extreme improvements over some truly heinous Win32 API designs (consider the API for using GDI for example).
Finally, knowing Win32 can help solve performance problems in your apps.
Win32 won't become antiquated, until the Microsoft's popular operating systems are based on something else. At one point, Microsoft was going to replace Win32/64 with .NET in Vista, but this didn't pan out. Even for whatever replaces Win32/64 is the future, you still need to understand the OS SDK. At the risk of sounding like a salesman, I will say that learning Win32 will in fact help you write more robust applications and will greatly aid your debugging skills, two important items to help you stay employed. I would never hire a windows programmer who doesn't have at least some experience with Win32.
I would suggest "Windows via C/C++" by Richter/Nasarre, as one example of a good book on Win32 (yes, it's obviously geared towards C/C++, but these authors do an excellent job explaining Win32).
Hope this helps.
I think Win32/64 SDK will never be antiquated, as drivers or other low level programs won't be written in .NET or Java because of the performance requirements. If you are going to develop in .NET, then MFC or wxWidget is useless for you.
I develop in .NET regularly, and sincerely, every program I've ever created in .NET called some Win32 API functions. So learning Win32/64 SDK isn't pointless, but is time-consuming.
I am an architect and I recommend that all new projects use newer technologies, like .NET or Java. The difference in productivity is tremendous, at least according to my own experience with C++ and .NET.
There are two exceptions:
- I work for a software company and we are bound by the requirements of our customer, usually including the programming environment. So, if a customer only has people knowing, say, MFC, we will make an MFC project. But this is becoming rarer and rarer. If we have the choice, we will go with .NET or Java.
- You have a team with expert people in these older technologies and they are quite productive with them.
There's plenty of work for people like you, so I'd advise not learning these for job purposes. We have some MFC apps, but that's partly because it's what we had and partly because we had more faith in C++ performance, and performance is very important for them.
I wouldn't call C++ or MFC antiquated, but there's relatively less new work in it. (I would very much like to never support another Win32 program, though.) The new C++ standard should be out in 200B, and people will continue to work on it, and Microsoft has been adding new classes to MFC, so obviously there's continued interest and continued work.
For professional development, I'd suggest you learn something different, but that would be something like Lisp or Haskell, rather than C++, and as far as I can tell there's no particular virtue in knowing MFC.
Realistically Microsoft forces business to use their latest and greatest technologies. There will always be work for someone who knows both technologies because someone has to port legacy code.
Many small devices (phones) or games require lighter solutions. If you intend to work in those areas you will definitely need those technologies.
You need to decide where you want to go. Once you have a map then you can lay in the right supplies for the journey.
I found Java horrendous to work with compared to Win32. Someone needs to cut about ninety percent of the inbuilt libraries.
I wouldn't call Win32 and such antiquated. As other people have said, it really depends on the app. As a game developer, I use Win32 less and DirectX a hell of a lot more. I could double or triple my Windows code, and it would still be an extremely small portion of the project.
However, if you're writing a primarily interface application with a relatively small and lightweight backend, .NET might well be a good choice for you.
As for Haskell, I just found that to be a truly terrible language in pretty much every respect. It seemed to me that it served some abstract mathematical definition of "functional", rather than a real definition of "programmable-in".
Win32 SDK is nowadays used in niche markets, where more modern technologies can't be used for some reasons (legacy Win32 systems, games, system drivers, Windows Embedded systems). If you aren't planning on pursuing a career on these markets, I wouldn't bother learning Win32 now. It is not that is useless and has no new things to teach you, but let's face it, there are so many new technologies coming out even at the time we speak. I have a dozen of technologies/languages in my waiting list to start learning and experimenting with. You can certainly find more interesting and more career favorable technologies to learn.
Performance critical apps (games) typically use C++ Win32 API.
C# and .NET are actually built on top of the Win32 API. To access some of the advanced features of Win32 that aren't exposed through C# and .NET you use Pinvoke to manually expose a C Win32 function to your C# app.
I am curious about COM+, DCOM. I know that MSFT does not encourage you to use this tools natively (meaning with C/C++, in fact there is not a lot of documentation available) but I want to learn to use these technologies, like embedding Internet Explorer into a C program.
I thought that maybe I could find people that worked with this or that knows about this technology.
Where to start? Any ideas? Any example (like Hello World DCOM)?
If you are serious about learning COM, Don Box's "Essential COM" is definitely an absolute "must read". COM can be confusing and in my humble opinion Don Box is one of the few people who actually "got it".
The example code in "Essential COM" is in C++. You won't find many books that support COM in C. You can write COM in C, but it will be very, very painful. COM is optimized for C++ development.
This book is not perfect nor "complete". There are some (granted, a bit esoteric) areas that the book skims over. For example, the book has like 1 1/2 pages on "monikers" (I have never seen a treatment of monikers that satisfies me). I consider this book to be THE fundamental book.
Second, in real life you are likely to want to use a supporting library such as ATL, rather than writing all the COM glue directly. There are too many ways to make subtle mistakes in COM even in the basic set up. ATL will give you good patterns and implement the boring code for you. In learning, you are better off using plain C++.
There are many books about ATL and several are quite good. I understand that ATL has changed quite a bit since the old days of VC++6, but I don't have first hand knowledge there: sadly, most of the COM code I work with is forever locked to the flavor of C++ in VC6.
Make sure whatever book you get is written for the version of Visual Studio and/or ATL you are planing on using.
Some background on COM books:
Note that there are a lot of books out there that misunderstand COM, or focus on the wrong things. The older books are worse in this respect. Some of the first few books treated COM as little more than a plumbing detail needed to make OLE work ("Object Linking and Embedding", that's what allows you to drag-and-drop a spreadsheet range into a Word document). Because of that, a lot of the material out there is very confusing. It took a while before people realized that OLE wasn't that important and that COM really was.
By the time Don Box published "Essential COM", the cracks on the foundation of COM had started to become evident. There isn't anything terribly flawed with COM, but the needs of the development community had evolved and outgrown what COM could do without serious revamping.
.NET was born out of that effort to address the limitations in COM, especially in the area of "type information". Just a few years after "Effective COM" was published, the attention of the community shifted away to .NET. Because of that, good COM training material is now and will likely remain forever limited.
So, COM is not broken, and it works great for the things it's used for (that's why Explorer still uses it). It's just not the best solution anymore for many of the problems that need solving today.
In summary:
I recommend "Essential COM" for the basics. Then, any of many good ATL books available (no strong preferences there), and then use other resources like MSDN or -- of course -- Stack Overflow, to cover areas that are of particular interest to you.
If you'd rather avoid relying on resources of the dead-tree variety, go ahead and learn ATL from the web. But some books are worth reading the old fashioned way -- and "Essential COM" is one of them.
Good luck.
COM, COM+ and DCOM are three completely different things. At this point, there is very little reason to learn COM and almost no reason to learn DCOM. The only reason I can think of is if you have to maintain or integrate legacy components. COM+ is still used because it allows for out of process hosting of components and nice things like distributed transaction management.
The best way to start writing up some COM is using ATL. In .NET COM+ is called Enterprise Services.
The best book I know on COM is Don Box's Essential COM and Tim Ewald's COM+ book is excellent too.
I compiled a list of books, which should be read in this order:
'Inside COM' from Dale Rogerson, This should be your first book. It explains the basics of reference counting, interfaces, IUnknown, components, idl, IDispatch, automation types and apartments. From this book you will notice that it takes quite some code to make components and that you can easily skip a 'Release', which leads to resource leaking. Also this books lacks some details.
'ATL Internals' from Tavares. ATL helps you with both client use as making COM components. With smart pointers (e.g. CComPtr) it's hard to get the reference counting wrong these days. ATL also facilitates in making components in c++. Unfortunately ATL hides many functionality in macro's and has a counter intuitive way to implement IUnknown. An alternative might be 'Inside ATL'.
'Essential COM' from Don Box. This book is mentioned frequently but it is not a good beginners book. It misses the overall picture, but is great in its details (e.g. the difference between 'size_is' and 'length_is' in idl).
'Understanding ActiveX and OLE: A Guide for Developers and Managers'. This books touches some of the more esoteric interfaces like IPersist, IStorage; IMoniker etc., but does not go into great detail.
Be aware that COM is somewhat of an old technology, though still viable especially for native developers.
COM is still useful if you want to work with, or extend, various Windows APIs, such as shell extensions, scripting host, and so on.
Essential COM (Box) and ATL Internals (Rector and Sells) are excellent sources. Effective COM (Box, et al) is also ok.
If you really want the full picture on COM, try and get a copy of the immense Inside OLE (Brockschmidt).
Distributed COM (Eddon, Eddon) is decent on DCOM, as is Inside COM+ Base Services (Eddon, Eddon) on COM+.
even some supposedly "pure" C++ books have bits on COM in them. Matthew Wilson's Imperfet C++ has some useful parts for seeing how it works on the inside, and his Extended STL book has a couple of chapters on how to adapt COM to STL collections.
If you want to know more about how to write COM servers, you'll probably need to bone up on ATL. The aforementioned ATL Internals is a must. Despite its humble sounding title, Beginning ATL COM has some useful stuff in it too.
Also helpful in the learning process might be to contrast COM with .NET. The .NET and COM Interoperability Handbook is a big swallow, but has some useful stuff in it. Also, I would check out Shared Source CLI Essentials, just to help contrast the two technoloqies.
HTH
Start with "Inside COM", then move on to "Inside DCOM" and then read the "Essential COM". You will get a grip on COM. Both the books Inside COM and Inside DCOM are Microsoft Publications. Excellent books for the one who wants to know COM/DCOM thoroughly.
Essential COM is especially for implementing or using COM components from C++, without using an IDE, framework, or library to help.
COM is trivial to use from VB or from Delphi, for example, which hide the COM-specific glue from the application programmer. In C++ you'd often use some class library that tries to abstract the details ... Essential COM will tell you what those details are (and kind of implements its own library/framework in doing so).
Actually, if you want to learn more about COM, Microsoft publishes a book about COM and how it works... http://www.amazon.com/Inside-Microsoft-Programming-Dale-Rogerson/dp/1572313498/ref=sr_1_2?ie=UTF8&s=books&qid=1243029018&sr=8-2
I do have to say I'm fairly inexperienced when it comes to C++, don't be too harsh on me.
Recently stumbled unto the wonders of the win32 API and have chosen to practice using it (I'd rather not use MFC/wxWidgets/etc at this point, just for educational purposes).
Well, my real question is:
How do you properly code your win32 GUI stuff into classes. I mean, sure, you can make a class that saves individual window handles, allows for easier modification of window properties, has a more simplified version of CreateWindow(). But as I understand it you will need a messagepump and several callback functions for your created windows. How does that work when combining them with classes?
Could anyone point me in the right direction here? I don't mind reading (a lot of) example code as long as it is commented.
PS: I'm also having trouble finding good (read: easy) documentation on using 'resource files' for my window decorations. Bonuspoints for that! :)
I program in C++ for a living. I like C++.
That said, your life will be so much easier if you do your windows GUI in something .Net, e.g., C#. Win32 is very low-level and you will be building tons of stuff that you will get for free with the .Net libraries. Win32 is not a wonder, anymore. :-)
If you want to learn C++, pick something other than a GUI to do with it.
I personally would use MFC instead of reinventing the wheel here. However, if you insist you need to have an application object that is instantiated when the program is run and contains the message loop and a mechanism for forwarding messages to the correct window objects.
That's the way MFC does it, at least. I'm not sure if the MFC source code is available for download, but if you have access to Visual C++ install disks (any version) you should be able to install the source code on your computer to review.
The biggest problem I faced back when I used the Win32 API (have since moved on to Linux and cross-platform solutions) were the callbacks. Especially the winproc one, AKA the message pump. I found this, which should be a good hint. I did what that page suggests when I rolled my own wrapper.
Look at MFC or ATL/WFC. If you want to re-invent the wheel, the best reference source for how to do so is the wheel itself, especially since the source code is readily available.
I would suggest reading Windows++ by Paul Dilascia. It takes you through the whole process of building a class library in C++ on top of the Windows API. It's written for 16-bit Windows, but all of the concepts presented in the book still apply. Plus, you can get it really cheap since it's "out of date".
And make sure you learn about message crackers (#include <windowsx.h>), they will keep you from pulling out too much hair. ;-)
The best way to learn this is to go and readCharles Petzold's original book. He does a good job of showing how to set up the base message loop and how to build statements for routing the various events to handlers. The real problem here is that by reinventing everything you are going to be spending hours and hours writing and debugging windows event hanlding code instead of writing your own application.
Unless you have a compelling reason for doing this yourself, you woudl be far better served using someone else's construct like MFC.
The only reason I see for coding all this yourself is if you want a basic understanding of how it works before you switch over to MFC or something similar. At least this way you would see how it works under the covers before you can forget it forever.
Many years ago, I developed a set of classes to encapsulate the API (various reasons why we couldn't use MFC). I learned a lot from the MFC source code.
The big key is that every window has a UserInfo data member - you can use it for whatever you want. What you'll want to use it for is the class's this pointer.
Now, the other tricky thing is that the message handler callback function cannot be a normal class member function, as Windows uses C calls and not C++. So your callbacks must be statics. However, since you've saved the class's this pointer, its just a matter of getting the class's userinfo, casting it to your class's this pointer and then calling whatever (non-static) class functions you need.
If you plan it correctly, inheritance will work well, including all of the inheritance that the windows themselves exhibit (ie, an Edit is a Control is a Window).
The only reason I would recommend not reinventing the wheel is you are neither an expert at C++ nor the Win32 API. Trying to learn two unrelated subjects at once will not be productive. If you want to become better at C++, write a library for a subject you know a lot about. If you want to learn the Win32 API, program it raw to understand how it works before creating (or using) a wrapper for it.
There is a pretty good C++ Windows API tutorial on the Reliable Software site.