I have generated an ATL COM object using VS2008 and the code contains references to a definition called _MERGE_PROXYSTUB (because I chose the 'Merge proxy/stub' option when I initially ran the wizard.)
What is the point of a proxy/stub? If I don't select the the merge option then I get a separate MyControlPS.DLL instead - when would this ever be used?
FWIW the control seems to register and work fine if I remove all the code surrounded by the _MERGE_PROXYSTUB defines. A debug build doesn't even define _MERGE_PROXYSTUB and it still works OK.
So, can I do without a proxy/stub?
You need a proxy/stub if you want your COM object to be called from an application using a different threading model than your COM object.
For example, we have a plug in that gets loaded by an application that uses a particular threading model (can't remember which), but our COM object is multithreaded apartment (MTA) - so the the proxy/stub is required to marshall the data between the objects when a function call is made, while still adhering to the rules of the threading model.
If these rules are broken, then COM will either throw an exception or return a failure HRESULT such as RPC_E_WRONG_THREAD
If you don't check the merge proxy/stub option, then visual studio produces a seperate project for the proxy/stubs which get build into a seperate dll. This makes things more difficult for deployment if they are required, but you can basically just ignore them if you are not affected by threading model issues.
So you can do without proxy/stubs if the application calling the COM object is using the same threading model as your object
Larry Osterman provides a readable introduction to threading models on his blog.
Also, if your interfaces contain only type-library-friendly types (BSTR, VARIANT, etc) and appear in the library block of your IDL, you can elect to have them "type library marshalled" meaning that a system-provided proxy/stub uses the meta-data from the type library.
When interfaces are put inside the library block, and DllRegisterServer is customized to register the type library (pass TRUE to XxxModule::DllRegisterServer, if I recall correctly) your interfaces will be marshalled by the system, if necessary, as described by John Sibly.
At that point, the proxy/stub isn't even used, so _MERGE_PROXYSTUB has no effect.
Related
I need to provide my users the ability to write mathematical computations into the program. I plan to have a simple text interface with a few buttons including those to validate the script grammar, save etc.
Here's where it gets interesting. These functions the user is writing need to execute at multi-megabyte line speeds in a communications application. So I need the speed of a compiled language, but the usage of a script. A fully interpreted language just won't cut it.
My idea is to precompile the saved user modules into objects at initialization of the C++ application. I could then use these objects to execute the code when called upon. Here are the workflows I have in mind:
1) Testing(initial writing) of script: Write code in editor, save, compile into object (testing grammar), run with test I/O, Edit Code
2) Use of Code (Normal operation of application): Load script from file, compile script into object, Run object code, Run object code, Run object code, etc.
I've looked into several off the shelf interpreters, but can't find what I'm looking for. I considered JAVA, as it is pretty fast, but I would need to load the JAVA virtual machine, which means passing objects between C and the virtual machine... The interface is the bottleneck here. I really need to create a native C++ object running C++ code if possible. I also need to be able to run the code on multiple processors effectively in a controlled manner.
I'm not looking for the whole explanation on how to pull this off, as I can do my own research. I've been stalled for a couple days here now, however, and I really need a place to start looking.
As a last resort, I will create my own scripting language to fulfill the need, but that seems a waste with all the great interpreters out there. I've also considered taking an existing open source complier and slicing it up for the functionality I need... just not saving the compiled results to disk... I don't know. I would prefer to use a mainline language if possible... but that's not required.
Any help would be appreciated. I know this is not your run of the mill idea I have here, but someone has to have done it before.
Thanks!
P.S.
One thought that just occurred to me while writing this was this: what about using a true C compiler to create object code, save it to disk as a dll library, then reload and run it inside "my" code? Can you do that with MS Visual Studio? I need to look at the licensing of the compiler... how to reload the library dynamically while the main application continues to run... hmmmmm I could then just group the "functions" created by the user into library groups. Ok that's enough of this particular brain dump...
A possible solution could be use gcc (MingW since you are on windows) and build a DLL out of your user defined code. The DLL should export just one function. You can use the win32 API to handle the DLL (LoadLibrary/GetProcAddress etc.) At the end of this job you have a C style function pointer. The problem now are arguments. If your computation has just one parameter you can fo a cast to double (*funct)(double), but if you have many parameters you need to match them.
I think I've found a way to do this using standard C.
1) Standard C needs to be used because when it is compiled into a dll, the resulting interface is cross compatible with multiple compilers. I plan to do my primary development with MS Visual Studio and compile objects in my application using gcc (windows version)
2) I will expose certain variables to the user (inputs and outputs) and standardize them across units. This allows multiple units to be developed with the same interface.
3) The user will only create the inside of the function using standard C syntax and grammar. I will then wrap that function with text to fully define the function and it's environment (remember those variables I intend to expose?) I can also group multiple functions under a single executable unit (dll) using name parameters.
4) When the user wishes to test their function, I dump the dll from memory, compile their code with my wrappers in gcc, and then reload the dll into memory and run it. I would let them define inputs and outputs for testing.
5) Once the test/create step was complete, I have a compiled library created which can be loaded at run time and handled via pointers. The inputs and outputs would be standardized, so I would always know what my I/O was.
6) The only problem with standardized I/O is that some of the inputs and outputs are likely to not be used. I need to see if I can put default values in or something.
So, to sum up:
Think of an app with a text box and a few buttons. You are told that your inputs are named A, B, and C and that your outputs are X, Y, and Z of specified types. You then write a function using standard C code, and with functions from the specified libraries (I'm thinking math etc.)
So now your done... you see a few boxes below to define your input. You fill them in and hit the TEST button. This would wrap your code in a function context, dump the existing dll from memory (if it exists) and compile your code along with any other functions in the same group (another parameter you could define, basically just a name to the user.) It then runs the function using a functional pointer, using the inputs defined in the UI. The outputs are sent to the user so they can determine if their function works. If there are any compilation errors, that would also be outputted to the user.
Now it's time to run for real. Of course I kept track of what functions are where, so I dynamically open the dll, and load all the functions into memory with functional pointers. I start shoving data into one side and the functions give me the answers I need. There would be some overhead to track I/O and to make sure the functions are called in the right order, but the execution would be at compiled machine code speeds... which is my primary requirement.
Now... I have explained what I think will work in two different ways. Can you think of anything that would keep this from working, or perhaps any advice/gotchas/lessons learned that would help me out? Anything from the type of interface to tips on dynamically loading dll's in this manner to using the gcc compiler this way... etc would be most helpful.
Thanks!
We have a executable compiled using Visual Studio 2008 version. Due to the 3rd party dependency we must compile this executable in visual studio 2008.
We also have another component which gets compiled in visual studio 2010. Now we need to get one COM component dll from this component (which is compiled in 2010 compiler version) accessed by the executable which is compiled using 2008 compiler version.
My question here is, would it work fine. Would there be conflicts in the runtime used by the executable (which is 2008 runtime lib) and runtime used by the COM component (which is using 2010 runtime).
We actually tried to load this COM dll in executable which actually worked fine. But I have concern that in later time due to multiple runtimes it may crash/fail.
Please let me know how the multiple runtimes would get handled here. Is it safe to load the different runtime in single executable. Would there be any conflicts in later part of execution due to different runtime available?
Anyway a solution we are looking to solve this problem to make the COM component as a OUT proc Server, which anyway will work. But that will involve a lot of work to do.
Please let me know.
Many Thanks
You should have no problem mixing COM objects that are linked with different runtime libraries, since the memory allocation and deallocation of each object will be done behind the DLL boundary.
You need to be careful that all your methods have proper COM signatures, i.e. all pointers should be COM pointers.
COM is designed for binary interop. By design the framework is implementation agnostic. The intent is that COM servers can be implemented in one language/runtime, and consumed by a COM client implemented with a different language/runtime.
There are absolutely no constraints over the languages and runtimes that are used by different parties.
This has been answered a few times in several contexts.
As long as you don't handle and/or pass around C runtime (CRT) data structures between modules, you're fine. If you do any of the following between modules that depend on different CRTs, you'll have trouble, and in this specific case, you're not implementing COM objects properly:
malloc memory in one module and realloc or free in another
fopen a FILE* in one module and fread, fwrite, fclose, etc. in another
setjmp in one module and longjmp in another
Note that there are things you can do:
Use memory malloced by another module, keeping the responsibility of reallocating and freeing on the originating module
Use some interface that interacts with files fopened by another module, keeping the responsibility of its use on the originating module
Don't use setjmp/longjmp across unrelated or losely coupled modules, define callbacks, aborting error codes, whatever, but don't rely on unwinding techniques, even if provided by the OS
You can see a pattern here. You can use resources from another module for as long as you delegate managing those resources to that module.
With COM, you shouldn't ever have this kind of trouble, everything should be encapsulated in objects through their implemented interfaces. Although you can pass malloced memory as top-level pointer arguments, you're only supposed to access that memory in the callee, never reallocate or free it. For inner pointers, you must use CoTaskMemAlloc and its cousins, as this is the common memory manager in COM. This applies to handling files (e.g. encapsulate them in IStream, IPipeByte, a IEnumByte or something similar), and don't unwind across COM calls.
I have following problem to solve.
I have component A. This component has some sub-components - B,C,D. Using cmake I am building or not those B,C,D components. It depends on current platform configuration. My cmake system is making executable makefiles (for A component) for linking only those components, which were used in given cmake run. If component B was built, it is added to executable if not - is not linked. The same with other - C,D.
All those B,C,D components provide some implementations of interface used in A component. This A component shall manage objects created by B,C,D and keep those objects in some map, using proper object at proper time.
Question:
I want to achieve some simple and reliable mechanism for adding those objects implementing A interface automatically, the same as it is now with linking - linked are only modules, which were built. The same with those objects - I would like to have them registered in A component only when they were compiled.
It is hard for me to explain it. The idea is easy - build some map of those objects at compilation time. Only components compiled shall deliver their object to this map.
I have used designs similar to how Objective-C and Smalltalk implement methods.
In C++, methods == member functions and must be defined at compile time. So, even though the interface can be extended with mechanisms such is the preprocessor, the same configuration must also affect any clients of the class, or they simply won't link.
So I use a message passing system to invoke methods on objects. So if A is the main class, and you compile in C and D but not B, then the message processor of A will only respond to messages that have handlers registered by C and D.
This type of design does require having a messaging system of some sort. There are numerous existing systems such as Google Protocol Buffers and Apache Thrift. I chose to design one since I wanted even more runtime configurability than most existing systems allow (many of these messaging systems have IDL compilers involved).
However, it did allow me to get closer to the OO realm than the mixed-paradigm language C++ typically permits.
I need to implement a bare-bones COM object in straight C++ (no ATL) that is used by a legacy web application to check that my application exists. The web application does something like this (JavaScript):
var object = new ActiveXObject("My.Application");
I want to ensure that the above succeeds but thats all I need to do - I do not need to implement any methods/properties on this object as they are never called.
Obviously I need to ensure that my object is registered by adding the necessary registry settings, etc. My application is a DLL so I guess I also need to implement a handful of exported functions (DllRegisterServer, DllUnregisterServer, DllCanUnloadNow and, the one that has to so something, DllGetClassObject).
I'm pretty sure that simply returning S_OK from DllGetClassObject won't cut it.
How can I go about implementing a basic interface without using ATL? I am using the MS compiler if that helps.
It's not sufficient to build a bare-bones COM object. For starters, that would be so bare-bones that there's no name associated with it. You've already discovered that you need an object factory, too.
So, yes, implement DllGetClassObject. You'll have to check the input rclsid argument. This is an interface identifier. If you don't recognize it, return CLASS_E_CLASSNOTAVAILABLE. Apparently, because of hackerish approaches (like the unconditional S_OK you suggested) Microsoft now passes at least one invalid class ID.. If you lie, and claim you can do it, Windows will not believe anyhting else you say.
So, what interfaces should you claim? Obviously IUnknown - it's the very root of the system. The most bare-bone COM object doesn't do anything else. You need more interfaces, though - the web app is asking for an ActiveX object. That requires more interfaces. Possibly the easiest approach would be to just see what Windows is asking for. I suspect you'll need at least IDispatch.
Next, you'll have to implement a few methods. "Wait", you may say, "they're not called". Well, IDispatch is a kind of meta-interface for scripting langauges. It's used to enumerate which methods are available. Hence, your IDispatch interface should support such enumeration as well, even though it would return zero scriptable methods.
There's a lot more detail, but this should already be sufficient to help convince you to use ATL and grab its ActiveX code. That's going to be far more complete than anything I can list here.
There is nothing bare-bones about a COM server that supports late binding from Javascript running inside IE. If you don't know how to implement DllGetClassObject() then you need all the help you can get. You get a lot of help from ATL and the wizards built into Visual Studio. The vast majority of the fugly plumbing code is auto-generated, including those 4 exports. And IDispatch, the interface that the Javascript needs.
Start the project with the ATL + ATL Project template. The defaults are good. Right-click the project, Add, Class and select ATL + ATL Simple Object. Switch to Class View, locate your interface type and right-click it to add methods and properties.
I'm new to COM programming. I've got a COM object (and associated IClassFactory) all ready to go, but I can't quite figure out how to go about registering the resulting DLL for use by other programs. The number of GUIDs I need to sling around is also unclear to me.
The COM object I'm trying to register implements the IAudioSessionEvents interface.
I have come across the DllRegisterServer and DllUnregisterServer functions, but I haven't found any clear demonstrations of their usage. What keys do they deal with, how are they invoked, by what and when, etc.?
Thanks,
-Kevin Montrose
I'm not sure from this post whether you are implementing or consuming the DLL that supports IAudioSessionEvents. If you're consuming this DLL, then you can register the component using the comment line utility regsvr32. To register use:
regsvr32
To unregister:
regsvr32 /u
regsvr32 should be on your path, so this command will work from any directory.
If you are implementing the DLL in question, then you must provide an implementaion of the DllRegisterServer and DllUnRegisterServer functions. These functions must set up and clean up registry entries for your component. The purpose of the registry entries is to provide a ProgID, map it to a CLSID, and provid interface ID for the interfaces that the component supports. For example, the interface ID for IAudioSessionEvent. If you're implementing the DLL, you'll have to provide code to perform all of these tasks.
Note: these functions are called by regsvr32 in order to register the component.
If very unusual to actually write this code, generally you'll want to use a framework like ATL, which takes care of the busywork for you. It is a good exercise to write this code at least once if you really want to know COM from the ground up.
You need one GUID for every class you expose to COM and one GUID for every new interface you introduce and want to make available through COM.
DllRegisterServer/DllUnregister server are called when you use regsvr32 utility (ships with Windows) to register your COM-exposed classes. It adds/removes keys to HKCR/CLSID branch for every class you expose to COM. These keys are used by CoCreateInstance() to find out which DLL to load for creating an instance of a class with a given GUID.
If you use ATL or something similar usually don't need to completely implement DllRegisterServer/DllUnRegisterServer but use the implementation provided with the library.
Quite often the easiest way to implement self registration is to use the ATL server classes, have a global variable that derives from CComModule (or some other similar class) and define a COM_MAP in your module. You then ask the com module to handle the registration based on the .rgs files that you have added to your project.