I've written a console program that "does stuff" - mainly using boost. How do I convert it to a Windows Service?
What should I know about Windows Services beforehand?
There's a good example on how to set up a minimal service on MSDN. See the parts about writing the main function, entry point and also the example code.
Once you've got a windows service built and running, you'll discover the next major gotcha: it's a pain to debug. There's no terminal (and hence no stdout/stderr) and as soon as you try to run the executable it actually launches the service then returns to you.
One trick I've found very useful is to add a -foreground option to your app so that if you run with that flag then it bypasses the service starter code and instead runs like a regular console app, which makes it vastly easier to debug. In VS.Net set up the debugging options to invoke with that flag.
There's a really good example on msdn here
It's a boiler plate C++ service project that has self install/uninstall functionality and logs service start and stop events to the windows event log. It can be stopped and started through the services app (snapin) like other services. You may want to initially give it LocalSystem rights to see it working , as on xp at least it doesn't have enough rights to start with the project provided rights of LocalService. The Visual Studio 2008 project otherwise runs out of the box despite the downloaded instructions implying otherwise.
A bit late but I hope this helps someone else.
You might be able to 'wrap it' using this tool from CodeProject:
http://www.codeproject.com/KB/system/xyntservice.aspx
Worth a look.
The simplest solution might be to create a new Windows Service project in Visual Studio and copy across your code to the new project.
If you refactor your code so that you've split the UI (in this case the console) from the logic you could create a library that does the work and then call that from both the Console project and the Service Project.
You can configure an application to run as a service by using the Srvany tool, which is a part of the Windows Server 2003 Resource Kit Tools.
Srvany allows only one service at same time. So I write my srvany (sFany) to make nginx and php-cgi run as windows service together. Here is the source https://github.com/stxh/sFany
Related
I am trying to get the code coverage for a Windows service written in C++ (let's call it hello.exe) with Visual Studio 2012 Premium tools. So far I have attempted to use the method outlined in the answer to this post: How to use MS code coverage tool in command line?
For your convenience, the steps given were to run:
vsinstr /coverage hello.exe
start vsperfmon /coverage /output:mytestrun.coverage
hello.exe
vsperfcmd /shutdown
I am able to instrument, test and get the .coverage file for hello.exe when I start it as an executable in the command prompt no problem. But if I instead try to start it as a service in step 3 (either through services.msc manually or win32serviceutil.StartService in Python), nothing registers and the coverage file is empty. Is there something i'm missing here?
Extra info: In an effort to solve this I came across what seems to be another code coverage utility called CodeCoverage.exe (Microsoft Visual Studio 11.0\Team Tools\Dynamic Code Coverage Tools). Is that what I'm supposed to be using for this task? Also, I found something seemingly related here https://msdn.microsoft.com/en-us/library/dd255408.aspx, but (forgive me for my ignorance) am not sure whether a .NET service is the same thing as a Windows service.
Answering my own question here, after a lot of trying and pouring through documents I found this:
https://blogs.msdn.microsoft.com/hilliao/2008/08/19/code-coverage-using-visual-studio-2008s-code-coverage-tools/
Basically, a windows Service is different from a process so we have to enable the cross session flag and specify the user when monitoring.
start vsperfmon /coverage /output:mytestrun.coverage /cs /user:”Everyone”
So just instrument the exe as usual, start monitoring with above command, start the service, do testing, stop the service, and shutdown the monitoring.
Hope it helps someone in the future.
I'm porting some Qt Windows/VC++ code to Linux/GCC. The application can add it's own shortcut to the Windows Autostart folder so the application starts after login.
I want to do the same in Linux. I'm using Kubuntu 15.10 but the solution should work for virtually all (or at least most) Linux variants out there. And it should work without super user rights (or it should request the rights automatically).
I searched the web and found two solutions:
Add a desktop entry file to $HOME/.config/autostart
Add a symbolic link to /etc/init.d/
Will they both work in all Linux distributions? What are the differences? Which is to be preferred?
Also I would like to know if I should do that by programmatically running a shell command or if there is some native API I could use in C/C++ (including easy error detection).
I have put project in GitHub for managing auto-start feature in different OS. It's written in Qt.
Please check it and let me know if you have any problem using it:
https://github.com/b00f/qautostart
You can add application in various ways.
Via linux init system. For newest linux OS systemd is a standard. In this case your need to create systemd unit for your application
Via desktop manager, such as gnome, kde and possible others. In this case you need also create specification for autostarting your app.
Via bash files
I think, prefered way via systemd unit, because now this is standard way for starting process at boot time and for special user, if need.
I have application written on C++, and I want to be able to update it like Google Chrome does:
Silently download new version from server,
replace original files and
restart app.
I also want to replace exe file, that locked as it in use now.
Couldn't find any solution for this type of autoupdate.
Maybe wxWidgets have such tools?
Or maybe you know, how to do this?
Make 2 programs. Your primary application, and a launcher. The launcher is what people should click on to start your program, and it is responsible for starting the primary application, and then can shut itself down. If you need to update while the primary application is running, you can download the updated program to a separate file, along with any other files necessary. Then the primary application can launch the launcher and shut itself down. The launcher then is responsible for deleting the old program and renaming the new one, and relaunching it.
Actually, this doesn't even have to be two different programs. It can be the same program operating in two different modes (selected through command line arguments, for example). You still need 2 copies of the executable file on disk though. Note that this is precisely what Google Chrome does.
The theory is described in the comment above. In practice, you should have a look at WinSparkle.
Package your program as an MSI file (Windows installer). Then download your new msi file and launch it. Windows installer takes care of updating your program and you can author the installer to relaunch your app.
Take a look at http://wixtoolset.org/ for how to build your installer.
We have an application that allows a user to drag a picture to a window and that window is a drop target (using OLE). When this code is run in the debugger and the Visual Studio instance is run as administrator (right click from desktop) then the target drop is not allowed.
If the exe is run on its own it works fine.
If the visual studio instance is run NOT as an admin the functionality works fine in the debugger. (Same solution/project files/etc)
Win7 OS. Visual Studio 2008. Unmanaged C++
I find it very odd. Not sure why it is happening. In fact I would have guessed the OPPOSITE regarding running VS as an admin.
Has anyone seen this or does anyone have links to workarounds or explanations?
This is most likely happening due to UIPI (User Interface Privilage Isolation).
In the case where you've launched your processes as Admin (due to the parent process (Visual Studio) being run as admin), UIPI isn't going to let non-elevated (admin) processes send any messages to your app. Drag and Drop between applications is implemented using Windows messages.
To work around this, you can use the ChangeWindowMessageFilterEx() API to opt into the appropriate drag and drop messages.
If you want to really and truly fix it, then you would need to
Detect when your process is running elevated
Spawn a non-elevated helper process which registers as the drop target
Pass the dropped data through IPC to the elevated process, using a method that's safe to use across privilege boundaries (i.e. no active objects which carry code)
This is a LOT of extra work when the workaround could be as simple as dropping from another elevated app (to get an elevated Explorer, just call up the File->Open dialog of any elevated app), but has the advantage that drag-and-drop will work properly if any of your customers ever run the app elevated.
Unfortunately this looks like a flaw in the OS:
http://blogs.msdn.com/b/patricka/archive/2010/01/28/q-why-doesn-t-drag-and-drop-work-when-my-application-is-running-elevated-a-mandatory-integrity-control-and-uipi.aspx
Oh well.
I find this whole issue appalling. MS has screwed up on this IMO. Essentially we can't debug an app correctly if I want to run MSVC in elevated mode (for example when I build the solution it registers COM servers).
http://social.msdn.microsoft.com/forums/en-US/windowsuidevelopment/thread/2fa935cf-be57-4bcc-9b96-7ee5a6b2b7a5/
all, I have a rather frustrating issue. The application in question has an MFC GUI that uses the classes available in the MFC Featurepack. This GUI uses an DLL that is developed in C++\CLI. Our company uses Cruise Control. NET (1.4.4 SP1) on Windows Server 2008 SP2 for continuous integration. Cruise Control is setup to use the version of MSBuild that comes with the 3.5 version on the framework.
The issue in question is that if I use the build that Cruise Controls creates, I receive the following error: "Unhandled exception at 0x7642fbae (kernel32.dll) in FormView.exe: 0xE0434F4D: 0xe0434f4d." After some digging, the issue seems to be that the GUI doesn't like the C++\CLI assembly.
The "gotcha" is that if I log on to the server, and, using PowerShell, execute the same MSBuild command, the build works. Any one have ideas?
The issue was how I was building the installer. It was a separate solution from the project's main solution, and was thus a separate task from the primary build. Therefore, the output assemblies got signed twice, and loader complained because the one the application wanted was no longer valid.
you could try and attach the process to the visual studio debugger.