I have several components (multiple .dlls, one .exe) which I need to use registration free. In my sxs manifest I've listed the dll files as;
<file name="xxx.dll"
<comClass
description="xxx component"
clsid="{xxx-xxx}"
threadingModel="Apartment" />
</file>
I have created and activated an Activation context and can call CoCreateInstance(); on these dll components without issue.
However, I also have a COM server singleton (as an .exe) that I need to run and I believe that you can only put dll files in the sxs manifest. I have its CLSID.
I'm restricted in that using regsvr is not an option for this, so is there an alternative way of being able to achieve this? Ideally having everything done programatically in the same place as where I am creating these other components.
That is a bridge too far...to try and do it through manifests. However, you can do it manually. But, what you have to do is what the OS does. You have to:
Call CreateProcess() with all the correct command line options
Call WaitForInputIdle() on the process
Make your COM calls
You'll probably also have to have entries for the interfaces you use if they are custom. I would probably recommend making them IDispatch compatible if at all possible.
To know what command line options are necessary, you'll have to register the server on your build machine and then look up the LocalServer32 registry key for the CLSID(s) and see what the arguments are. They can be a little different from each other if they are MFC or ATL, but usually ATL arguments are always the same unless you do something custom.
If for some reason the CreateObject() fails, then you probably will have to call TerminateProcess() on the process you created, otherwise you will have a bunch of orphaned processes. If you successfully create the object, the normal COM reference counting should be sufficient to shutdown the server process automatically.
Related
The question below is for educational purposes only and the discussed featured are not meant to alter registered DLLs or develop a malware but for learning and experiencing.
Recently I've been exploring few methods to load my own custom DLLs instead of an application's original DLLs.
One of the methods that came up was the <exe>.local method.
After experiencing with this method a little bit and after I removed the KnownDlls entry from the registry I managed to replace some system DLLs with my patched DLLs successfully.
These are the DLLs:
However, the DLLs are IN the local folder:
However, there are still some DLLs that insist loading from the system32 directory, although they are present in the local folder.
Is there any way I can force the DLL's to load from the local folder instead of the system32 folder?
This is not an answer so much as a rambling, unsourced, brain dump.
It does serve to explain why I am not surprised at your result. This boils down, for me, to the crucial difference between CreateProcess and LoadLibrary, and how Win32 processes work.
Normally, when using LoadLibrary, you are using it from within the process you want the dll to be loaded into. As such, it can take advantage of a whole bunch of in-process context information about activation contexts, dll search paths etc. including knowledge of things like the app.local flag.
All these values are specific to the current process and it is not the job of any other process (or even the Kernel) to track stuff like this.
But, if we look at CreateProcess we can see some problems. When it is initially called, it is called in the context of the launching, not destination, process, so it knows nothing of the destination processes activation context. In fact, the destination process does not exist yet.
The CreateProcess implementation needs to create a NT process, and execute some code in it asap to perform the process load as it doesn't make any sense to instantiate all that per process context stuff in the current process.
But, to do that, there needs to be at least some code in the destination process: The kernel code responsible for parsing the EXE files header, extracting the headers and building the activation contexts that will be used to load the remaining dlls.
This means that, unfortunately for you, kernel32.dll and some dependencies need to be mapped into a process long before that process is capable of building a dll search context, noticing the app.local flag etc.
You should look at how the Windows loader works. This is OS version dependent, but some of those DLLs load before your program and the loader always looks for them on a path provided by the system. Look at the sequence by starting your program with WinDbg.
I have a desire to write a Win32 executable (in C++) that performs all of its COM registration at startup so that its object(s) are then accessible via COM to client apps. When the executable terminates, it should then deregister with COM.
Is this kind of thing possible and if so, what are the steps involved?
I have been googling feverishly all afternoon without really finding any answers to this. Most solutions require up front registration (e.g. via a /register switch).
Thanks
I suspect that CoRegisterClassObject and CoRevokeClassObject are the functions you are looking for. You can find more information here.
There is no magic in the COM server registering regardless of in-proc or out-of-proc. Registering means writing to the registry deregistering means deleting registry keys.
Usual EXE COM server read command line arguments to handle install/uninstall request and provide separate subroutines or execution paths but you can freely include the install/uninstall process in every execution.
WinMain()
{
Install()
CoRegisterClassObject();
.. Message Loop ..
CoRevoveClassOBject();
Uninstall();
}
I have a Windows local service that may spawn off a process to execute a JScript script (in a .js file) via the Windows Script Host. The issue is that I need to notify my service of the results generated by the script in the .js file. A transfer or a simple 32-bit integer, or a string would suffice. What would be the way to do this?
PS. The code must run on Windows XP SP3 or later OS.
Your best bet is to create an out of process COM object that executes within your service. Just implement the necessary scripting interfaces and provide a member function to match the notification and call it from your script as such:
newObj = new ActiveXObject("localserver.mynotify");
newObj.Notify("finished");
Would the exit code of the process be enough?
Windows Scripting host has has a .Quit(errorCode) method that allows you to set the exit code.
You should be able to call WSH directly from the service and get the return code with GetProcessExitCode() by passing the process handle that you received after spawning it.
Note that almost everything you can do from a JScript file can also be done with native code.
Do you have to execute the .js file as an external process? Windows Scripting has COM objects that an app can use to run scripts within its own process. I use this to execute script files within my service processes, and it works fine. The hosting process can even implement its own IDispatch-based classes and pass them to the scripting engine to expose to scripts as global objects so the scripts can communicate with the hosting process without having to use new ActiveXObject or CreateObject() to access those objects.
I see your script is written in JScript and your app in C++.
Perhaps the easiest way to accomplish what you want is by writing a file, say, to programdata folder which your service should have access to. Maybe use a GUID for the particular request, pass that to the JScript so it's guaranteed to be a unique file. Not ideal.
Another way to get JScript output ... Can you call out to managed code (C#)? If so, you could use a .NET-based or .NET-callable JavaScript compiler/interpreter. This would allow you to avoid IActiveScript and also to grab the values right out of the script context or from function return. I've used Jurassic and JavaScriptDotNet, both very easy to use and extend.
This might open a problem if you heavily rely on ActiveXObject calls (ie: FileSystemObject) and don't want to write components. JuraScript wraps the Jurassic engine and add ActiveXObject support to it for COM automation.
I am a C++ newb, so I don't know how much of a leap this is for you although I know it's possible to interop between managed/C++.
Just thought I'd mention these scenarios as I didn't see them listed in answers.
I have a little problem with CoGetClassObject().
I have an application which must use some DLLs of a specific version,
but they are also present in the system, in a more recent version.
So I start hooking the CoCreateInstance() and loadLibrary(), which I guess are good.
The problem is that the DLLs in the two versions are loaded.
So I think that CoGetClassObject() is the problem/solution because it provides a pointer to an interface of an object associated with a CLSID containing a DLL that the application must use in an older version.
But I don't know what this function "does", so how can I "override" this function ?
thanks.
PS : I'm new in the COM programming.
CoGetClassObject() simply does half the job that CoCreateInstance() does. It returns a class factory. CoCreateInstance() then call IClassFactory::CreateInstance() and releases the IClassFactory. You would only use it if you have a need to create many objects of a certain coclass and want to optimize that. It avoids the cost of creating and releasing the factory over and over again.
You are possibly overlooking a far simpler solution to this problem. You can simply copy the new version of the COM server DLL into the same directory as the client EXE. And create a zero byte file with the name "app.exe.local" where "app" is the name of the EXE. That's enough to force that copied DLL to be loaded instead of the one that the registry points to. The MSDN Library article about DLL redirection is here.
The very simple explanation is CoGetClassObject() opens HKCR\CLSID\{ClassId} and looks at InProcServer32 or LocalServer32 depending on what CLSCTX_* value is passed - that is the COM server path.
Once it find a COM server file path is loads (LoadLibraryEx() with LOAD_WITH_ALTERED_SEARCH_PATH flag in case of in-proc or CreateProcess() in case of out-proc) the COM server. Then it locates and calls DllGetClassObject() for in-proc servers or waits until a class factory is registered for out-proc servers.
This of course ignores stuff like DCOM etc. You can get a better idea of how it traverses the registry using Process Monitor utility.
If you want to load a specific COM DLL regardless of whether there is a newer version installed, and regardless of where the older DLL is located, then simply ignore CoCreateInstance() and CoGetClassObject() altogether. Load the older DLL yourself via LoadLibrary(), then call its exported DllGetClassObject() function directly to get the DLL's IClassFactory interface, then call IClassFactory::CreateInstance() as needed. This is all CoCreateInstance() and CoGetClassObject() do internally anyway, but this bypasses the Registry lookups they perform to determine the DLL path to load.
One part of some software I have written is a COM dll.
Other software uses this COM dll.
My software has an update function where it will download a newer version of the dll, but the update will fail if the dll is in use because the file cannot be deleted or written to.
The question is, how can I update a COM dll that is in use?
I have considered popping up a message asking the user to close any applications that are using the DLL if it is in use, if this is the best solution how would I go about detecting if the COM dll was in use before popping up the message?
Thanks in advance.
You cannot update it in place for existing applications, but one way to do this would be to save it with a different file name or different folder and call DllRegisterServer on the DLL to register it under the new name. New applications which begin using your object should now use the new version.
If this is just a matter of detecting whether you can replace the file then it is easy. Just try to open it with a share flag that denies reading. That's going to fail if the DLL is loaded in another process. Use _fsopen() or CreateFile(). Beware of the race condition.
Detecting which processes have the file loaded is a harder problem, CreateToolhelp32Snapshot() and Process32First/Next plus Module32First/Next to enumerate processes and the DLLs they have loaded. Still tough to generate a good diagnostic for the user, the process name isn't that helpful.
When you have downloaded the update, you must launch a third program (which you write) that does not have any dependancies on your COM component, or any other piece that is to be updated. This launcher, or bootstrapper, must shut down all your pieces, uninstall them, and install the update. When the update is installed you may then re-launch your application.
If you need also to download updates to the updater itself, your main program can do that.
Here is a simple solution for you. Create a wrapper DLL, which will be used by the other processes. Inside that DLL you explicitly load/unload your DLL, which is subject to updates. Of course you will have to suspend all callers when an update process kicks in.