Am working on VC++ application
Its a background application that runs on background even on PC restart
Am trying to open the application as say - some antivirus like mcafee, which runs on background but if we click on the exe icon it comes up front of the screen
WinExec("application.exe", SW_SHOW);
exit(1);
Does anyone can help me ?
Sounds like your application is a good candidate for a Windows Service. A Service runs in the background with no GUI, starts when Windows starts, can re-start automatically if it fails, etc. For a GUI, you would write a separate application which would attach to the Service via some type of inter-process-communication for the purposes of configuration/control.
Related
I've developed an Accessibility API console application in C++ for High Sierra (and lower) - uses AXUIElementCopyAttributeValue etc.
I've disabled SIP to give me a chance here to write to the Accessibility database using tccutil.
So, the application runs as expected in Xcode, given that I've enabled 'Xcode' in System Preferences->Security & Privacy->Privacy->Accessibility.
I've wrapped my console application into a .app so I can drag and drop into this Accessibility panel.
If I run the application outside of Xcode in a Terminal window, I have to also give Terminal.app Accessibility rights for the application to use the API otherwise nothing is extracted. This then seems that you must give the calling application the rights.
I'm trying to launch the application on startup via a LaunchAgent with root privileges, /usr/bin/sudo being the calling application. Launching a script instead to run the application seemed the better method. The application launches fine, infact the console application inside the .app is also added now to the Accessibility panel.
Unfortunately, the Accessibility side of things is still not working and I've run out of ideas?
Any help will be appreciated.
Many thanks in advance.
I am writing a code which launches browser on click of a button but during launch of Internet Explorer or be it any browser the application hangs producing the window attached with this message.IE ERROR. In the given pic appfthook.dll is used in my application
You can launch it as
system("START iexplore.exe");
assuming that it's in your path. You can avoid using appfthook.dll that way.
Im using this guide "automating the testing of windows 8 apps" to test my windows store app
http://blogs.msdn.com/b/windowsappdev/archive/2012/09/04/automating-the-testing-of-windows-8-apps.aspx
Unfortunaltely Ive run into a problem, I need to know when my app closes (crashes) or when it goes into suspended mode, to log that info, and I want the launcher to be able to know the application has stopped , unfortunately iApplicationActionManager, does not have that method. And IPackageDebugSettings which is used to change the application suspend and resume states does not have a readable current state property (afaik)
Is there any way to do this?
Problem
I am attempting to find a window object handle inside a remote terminal that is run though Citrix Remote with ZenApp. My problem is I can see the parent window of Citrix Remote but no children. I have tried WinSpy, WFP Inspector, and a few other API spy utilities; none of which could view the Citrix Remote properties.
Question
What can I do to view these objects though this remote terminal?
EXAMPLE
No utility will be able to see the window handles for an application run over Citrix. The application is running on the Citrix server. The Citrix remote client presents only an image of the screen on the the client application.
The window handles that you are looking for are on the Citrix server, not the client machine you are running from.
You'll never be able to get the window handles, as they don't exist; however, you may be able to use UI Automation to get the accessibility properties (name, position, etc.) Certainly this works for Windows Remote Desktop on Windows 8 & above; it may or may not work for Citrix. It's worth a try.
I have a MFC application with ATL support, the idea is when someone creates an instance of my interface declared in the mfc application, this instantiation creates and displays a window.
This all works fine if the com client is the cmd.exe, i made a quick com client that instance the interface and when this instances occur the window is displayed as desired.
But if this instantiation is done in another com objects (for example atl server objects (services)) the window is not displayed. Note that the mfc process is created under the DcomLaunch process but no window is displayed. Everything works fine but the window is not show in my desktop.
Two questions:
1) why my window is not displayed in this situation?
2) when i create the same interface with my console app, only one process of the mfc application is created, no mater how many console app i start, and if the service try to instantiate more than one object, more than one mfc process are created! why is this, how can i avoid this. How can i make that the first mfc process is allways the same one that responds to the client calls?
(i think this is all due to security settings... but i already try to change some and nothing...)
Thanks
Nuno
In general a service cannot create windows. Pre-Vista you can enable a service to interact with the desktop (for example, open a window) via the "Allow service to interact with desktop" check-box on the "Log On" tag of the given services properties. If you're targetting Vista, this isn't an option.
However, given this is the DcomLaunch service you're dealing with, you clearly don't want to do that.
Even if it was your own service you wrote most anyone would advise against you doing this anyway for a few reasons (in no particular order):
The UI created would be only accessible in session 0
Creating a window creates an attack service into your (probably) privileged process since any other process the user runs can interact with the service's window.
Again, since the above only works pre-Vista, and is a Bad Idea anyway, the generally accepted "best practice" for a service that wants to expose a UI is to have a separate application that contains the UI which communicates with the service using whatever IPC mechanism you choose to use.