I have a somewhat strange request. Let me explain. I recently run into an issue when I needed to display my screensaver's configuration window by running the following command:
"C:\Windows\System32\mysvr.scr" /c
The problem is that my parent GUI application that calls it runs with High Mandatory Integrity Level, or S-1-16-12288, and due to this, when I run the following command via CreateProcess API the screensaver configuration (evidently?) tries to communicate with my app and fails because of its high integrity level.
So I'm trying to bypass this by having some other process run this command for me. I looked into possibly using RunDll32 but I don't know an API that I can use through it to start a process.
Any ideas?
Related
I have a program which, when installed, gets added to the RunOnce registry in Windows, so that it runs for the first time after Windows gets rebooted post installation.
This application installs a couple of Windows .NETservices using SC Create string passed in _wsystem. Unfortunately it fails to install at least one service..
To eliminate all other conditions, I'd like this application to run as an elevated, privileged user.
This application is in C++. Should I add a manifest or something to achieve this?
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?
When I run an application through a console, for example, $application start, how can I communicate with said application? So I can for example do $application load --/home/application/files/file.txt --warn=0 --notice=0 and that running instance of the application would react to this...
I do not want to keep listening to the console on the application side. I want to be able to close the console, reopen it, and still interact with the program.
The reason why I am doing this is because I want a master program that loads in different operations which it performs in the background. I want to be able to add operators, and remove operations.
Myself I have some experience with PHP and I know Apache has such behavior.
EDIT: After some comments of you guys, I concluded that I am required to use IPC. I have heard of this before but I never really understood how it works. After some Googling and the WikiPedia links you showed me I concluded that there are a sh-t tun of ways of handling IPC. I want to send packages of data to the main process, which one would be the best in my case? My personal favorite atm is a message queue but that only seems to work within the same process.
to be able to run application in background and have ability to close console where it was started, you may use nohup utility. then first instance of you app should create some ("well known") IPC resource (message queue, FIFO, whatever), so further instances will communicate over it with the first instance.
and it will be relatively easy, then to turn you app into a full functional daemon.
Since #LokiAstari pointed out, that you may don't have much experience with C++, I would recommend you to read: How to parse command line parameters.
I would then use a temporary file in /tmp to communicate with the main program, which run an infinite loop, waiting for modifications to the temporary file.
Personally I would do this in multiple stages.
As otherwise you are going to be trying to solve to many different problems at once.
What you are doing is writing a service (a long running application). Communication with the service by running a command usually involves running a different application that talks to the service (in apaches case the apache command starts the httpd service. Then subsequent commands talk to the httpd service).
But to get this up and running it is easier to go through a few steps first.
Write an application that on startup read commands from a directory
: So on startup you have a command directory.
: You open each file (in order execute the file if it is valid) then re-name the file to show it was done.
Modify your application to run as a continious loop.
All the loop does is look for events in job queue.
: if it sees them execute the job.
: If no job there then sleep for 10 seconds.
: On startup you just inject one job
-> : It reads the command directory and creates a job for each file.
-> : The file job executes the file then renames the file to show it is done.
Modify your service to use threading.
: Run the event loop in one thread.
: Use locks and semaphores so that added items to the queue is thread safe.
: When the application starts up you start the event loop (making sure it started then inject the job (as in 2). Then just waits for the event loop to finish (it will not).
Add a timer thread that fires very ten seconds to check the command directory
: All the timer should do is create a job and put it in the event queue.
: Now you don't need to inject a job at startup its the timers job.
Once you have all the above running you are ready to introduce a listener that will listen on a socket for indirect commands from another application.
: Doing all the above in one go to run the service is going to be long an error prone for a beginner. I advice you to fallow through all the steps above to get to this state then ask another question about how to do IPC.
: So add a new thread that listens on a socket (OK this is not the best technique but this is bootstrapping a beginner). When it receives input it creates a file in the command directory then places a job in the job queue.
You should now be able to test your command using the command line curl (or wget command) to send files to your service.
Once you have it working with curl.
You can write a standalone application that converts command line arguments into command files and sends them to your service.
Convert your application from using files to having all the information in the job object.
Thats it.
I have a program I want to run in batch. When running it interactively the code occasionally crashes (still working on figuring out why) and when it does this a popup window shows with the typical memory exception messages.
My question is - If I run the program in batch, will this popup still show? If it does it would prevent the execution of the next jobs until someone closes the window which I want to avoid.
The crash is intermittent and I don't want to break our nightly run by just making the change and seeing what happens. Alternatively, does anyone have code I can use that's guaranteed to cause a crash so that I can test it?
My environment is SAS V9 TS1M2 running on XP Pro.
If you're running in batch mode but running in an interactive Windows session (ie, not running via the scheduler on an account that's not logged in currently), then yes, you will see the popups when SAS.EXE crashes. It will be just like any other program crashing (ie, nothing particularly SAS specific).
If it's running on a 'nightly run' then you should be able to run it non-interactively, in which case it should not affect anything subsequent; this depends on the specifics of how you've set up the scheduler. I would normally schedule each SAS job as a separate process and then set them up as dependent on success of the prior run. You certainly should be able to run a specific process just to test your changes that could be scheduled to run after all of the 'critical' (production) runs.
I have a project that is being built using CruiseControl.NET. The project contains an 'MSBuild task' that runs the build for the project and also the unit tests. The unit test in turn is just a MSBuild 'exec' task that runs an executable.
The unit test involves some .NET remoting. And when the unit tests are run through the system command prompt, the software's window opens up, tests run and the process exits.
When I force a build through the web dashboard, the build hangs at the point where the unit test starts running. The software's window does not open up, but the executable is running. If the process is killed through the task explorer, the build goes through with a 'Failure' status. This happens when I run ccnet as a windows service.
If I run CCNet directly (not as a windows service) and force a build through the web dashboard, the build and unit tests go through fine as expected. (with the window of the software opening up.)
It looks like there is a deadlock in the case where CCNet is run as a windows service. I am guessing it is related to the standard output/error streams.
Is this is known problem?
What might be the problem going on?
Any suggestions on debugging this?
How can I get around it?
(I am using CCNet version 1.4.4 SP1)
When CCNet is running as a service it is not going to have access to the display, so don't expect to see anything on the screen in this configuration. The first thing I would check is the permissions - make sure the service runs as an account that has permissions to access whatever resources you need. You also have CCNet log files, which you can find via Dashboard.
On a side note, try TeamCity instead of CCNet, its 10 years ahead.
Maybe this answer will help :
delphi windows service can't download file from internet
You should know that when running CCNet as an application (the dosbox) it uses the environment variables and all rights from the logged account. So it may connect to a server, use cached passwords, get registry variables for this account.
BUT when ran as a service, the account is the one you provided : LocalSystem for exampe, where env. varibales are not the same.
So, what you can do is to change the CCNet service account for test. Change it to your user account (with password), and I'm sure it will work better !