I'm implementing a COM shell-extension interface that may be instantiated by different applications. For example, File Explorer might call it during folder navigation, and then my own application might directly call it from an .exe. I was hoping to share some simple and temporary state information across all instances of the interface (perhaps just a string or a vector of strings). I was hoping it would be like a static member variable, except accessible across all applications.
So I was wondering if this is possible, and if so, how to go about doing it. I've been reading about Windows inter-process communications, and it seems like having simple clipboard functionality might suffice, such that each instance could read or write information to a known memory location. But I wouldn't want to use the clipboard specifically, since that's supposed to be called by the user, and I wouldn't want to interfere with the standard copy-and-paste. Also, I'd like to avoid writing to a file because I think that would slow things down too much. Is there another type of IPC that's suited to sharing a variable across all COM instances? Thanks in advance.
There are many methods to choose. Refer to this. You can try to implement the function of simple clipboard. And other methods refering to this.
Related
I need the main form of the application to perform ClientToParent() and unsuccessful because I'm in a dll and the Application variable is nil. I appreciate anybody's help.
You can't do anything with a form reference across a module boundary. The host application, even assuming it is a Delphi application, has a different instance of the VCL. So you cannot use a TForm instance from the app in the DLL. You could do so if you were using packages.
You could perhaps enumerate top level windows and find the one in your process. That could work but is messy.
Far better would be to expose functionality to allow the host to provide such services. When the host loaded your DLL it would supply an interface which provided the necessary services. It could convert the coordinates as you need, and perhaps offer other services.
One thing I would query though is that you intend to call ClientToParent. This suggests that you have client/parent relationships between controls in different modules. That is only viable if you are using packages. I do wonder whether you are fully aware of the restrictions relating to VCL usage across modules.
I recently stumbled across something called pipe (all small letters) and fork (also all small letters). Apparently pipe "is a method of connecting the standard output of one process to the standard input of another". What I do not understand is what does standard input output of a process mean here. I already know that functions can call other functions and use the values returned by them so what is special about pipe, why do we need pipes? I have never come across these in my C/C++ books, what mystery is this? A simple way to communicate between two applications (I am not using the word process here) is that one application creates a file, calls another application and let it open this file and process its data and create a new result file and than terminate itself. Than the original application can continue processing and read from the result file and delete the file it created first. This is a simple way for two applications to communicate, I think that in the age of .Net framworks and complex operating systems, this must be even easier right?
Also, what is a fork? is it something specific to C++? I remember reading somewhere on internet that by using fork we can open another application from out C++ application. However, I do not know of the limitations and implications of this approach and any drawbacks that it may have. Why do we need fork? What does it do?
I do not wish that anyone has to write several pages of information. I just wish to understand what these things are, what do they do, why do we need them, and how come my C/C++ book did not cover these two?
These are unix system calls. They are not part of the C++ language or standard libraries, but are specific to unix-like operating systems.
fork creates a new process, and pipe creates a one-way communication channel. pipe and fork are often combined and used for inter-process communication.
I need to do an object browser/manipulator, similar to the one available in TestComplete, that is, list all the objects and their properties in any running foreign application, and being able to alter their properties, all of this during runtime, of course.
While MSAA/IAccessible can read objects, it can only return the visible objects, and not alter their properties as far as I know.
Using the WinAPI I couldn't read objects with no handles, in example, labels.
Ideally, I would like this done in Delphi, but any other language suggestions are acceptable.
Example of what I want to be able to do (This was done in TestComplete):
The task is not an easy one. If you want to do this, you need to use specific approaches of getting the data for every application framework you want to work with (.NET, MFC, VCL, etc.). While some of these approaches are quite plain (e.g. Reflection for .NET and Java), some other can be more complex and not documented like in case of VCL. TestComplete loads its own hooks into the target process memory and retrieve information about this application via these modules.
Besides, as far as I know, TestComplete can read various types of debug information for tested applications and use it when exposing objects along with their members.
Using IAccessible and Win API is an easier way, though not so effective in some cases. You mentioned that you were unable to get any information from labels using Win API. This happens because TLabel objects in VCL applications are not window objects.
I would like to create events for certain resources that are used across various processes and access these events by name. The problem seems to be that the names of the events must be known to all applications referring to them.
Is there maybe a way to get a list of names events in the system?
I am aware that I might use some standard names, but it seems rather inflexible with regard to future extensibility (all application would require a recompile).
I'm afraid, I can't even consider ZwOpenDirectoryObject, because it is described as needing Windows XP or higher, so it is out of question. Thanks for the suggestion though.
I am a little unsure about shared memory, because I haven't tried it so far. Might do some reading in that area I guess. Configuration files and registry are a slight problem, because they do tend to fail with Vista due to access problems. I am a bit afraid, that shared memory will have the same problem.
The idea with ProcessExplorer sounds promising. Does anyone know an API that could be used for listing events for a process? And, does it work without administrative rights?
Thank you for the clarification.
There is not really a master process. It is more of a driver dll that is used from different processes and the events would be used to "lock" resources used by these processes.
I am thinking about setting up a central service that has sufficient access rights even under Vista. It will certainly complicate things, but it might be the only thing left facing the problems with security.
No, there is not any facility to enumerate named events. You could enumerate all objects in the respective object manager directory using ZwOpenDirectoryObject and then filter for events. But this routine is undocumented and therefore should not be used without good reason.
Why not use a separate mechanism to share the event names? You could list them in a configuration file, a registry key or maybe even in shared memory.
Do not mix up the user mode ZwOpenDirectoryObject with the kernel mode ZwOpenDirectoryObject -- the kernel mode API (http://msdn.microsoft.com/en-us/library/ms800966.aspx) indeed seems to available as of XP only, but the user mode version should be available at least since NT 4. Anyway, I would not recommend using ZwOpenDirectoryObject.
Why should configuration files and registry keys fail on Vista? Of course, you have to get the security settings right -- but you would have to do that for your named events as well -- so there should not be a big difference here. Maybe you should tell us some more details about the nature of your processes -- do they all run within the same logon session or do they run as different users even? And is there some master process or who creates the events in the first place?
Frankly, I tend to find the Process Explorer idea to be not a very good one. Despite the fact that you probably will not be able to accomplish that without using undocumented APIs and/or a device driver, I do not think that a process should be spelunking around in the handle table of another process just to find out the names of some kernel objects. And, of course, the same security issues apply again.
ProcessExplorer is able to enumerate all the named events held by some specific process. You could go over the entire process list and do something similar although I have now clue as to what API is used to get the list...
Is there anything similar on Windows what would achieve the same as the InputManager on OS X?
If you are looking to inject code into processes (which is what Input Managers are most commonly used for), the Windows equivalents are:
AppInit_DLLs to automatically load your DLL into new processes,
CreateRemoteThread to start a new thread in a particular existing process, and
SetWindowsHookEx to allow the capture of window events (keyboard, mouse, window creating, drawing, etc).
All of these methods require a DLL which will be injected into the remote process. C would be the best language to write such a DLL in as such a DLL needs to be quite light weight as to not bog the system down. RPC methods such as named pipes can be used to communicate to a master process should this be required.
Googling for these three APIs will turn up general sample code for these methods.
I'm pretty sure Windows has an API that developers can use to create new kinds of text input systems. I gather there are a wide variety of text input systems in use in non-Roman-derived markets, many of which are provided by third parties.
It's unclear if that's what you were really asking about, though, because you just assumed everyone knows what you would want to use an Input Manager for on Mac OS X.
If you want to create a new type of input method, ask how to do that.
If you want to get your own code running inside other applications, ask how to do that.
Don't just assume people can read your mind when asking questions, and don't assume that they have the same experience that you do and will recognize all the same platform-specific terminology.