Is it possible for a Win32 Console Application to be used as a Windows service?
Normally this wouldn't be an issue using C#, .NET, and Visual Studio 2010 or higher, but this is a legacy application that was written in C++ using the Visual C++ 6 environment.
Mainly for the ability to restart itself after a crash.
Is it possible for a Win32 Console Application to be used as a Windows service?
Yes. In fact, many services are written as console apps. Even MSDN examples are.
The app's main() simply needs to call StartServiceCtrlDispatcher() to establish a link to the Service Control Manager:
Writing a Service Program's main Function
Mainly for the ability to restart itself after a crash.
The correct way to handle that is to just let it crash. Use ChangeServiceConfig2() to configure the service's SERVICE_CONFIG_FAILURE_ACTIONS info. One of the available actions is SC_ACTION_RESTART.
Related
I'm building ASP.NET web apps in VS 2017. Start Without Debugging runs the application, however I can't tell when VS decides to kill the exe. How is that managed? I'm not encountering a problem; all behavior is per documentation. Just curious.
I have 2 application running on the same machine.
Editor, is a Windows 8 application developed with WinRT and is sand-boxed. (Client)
Integrator is a C++ application for reading hardware devices over serial COM ports. (Server)
I have done a lot of searches about how to get client/server communication to work on Windows 8,
and can only find posts that say it is not possible using standard WinRT classes, etc.
What I need is a solution where by the Windows 8 application works as a client, and the standalone
executable works as a server.
Can someone please suggest a mechanism that can be used to do client/server communication.
If we cannot find a good solution for this, then we will have to resort to using files, which
I would rather not have to do.
Clarification: I am aware of the many mechanism that can be used to do client/server communication.
What I am looking for is a workaround to the problem, where the these techniques will not work on
a Windows 8 application, developed with WinRT. As the sand-boxing explicitly prohibits the client
and server being on the same host machine.
Well, the posts stating that such communication is not possible, are mostly right. There are 2 reasons, why this is prevented:
Being able to communicate to an application outside the sandbox effectively breaks the sandbox. The Windows Store app is now suddenly able to do everything the desktop application can do: access file system, registry... Windows Store apps live in a sandbox for reason - to be safe for the user.
The Windows Store app won't work after it is installed from the the store or from a package. It needs to have a desktop application installed and set up correctly as well.
I would suggest you try to move your server part to a different machine and make it a proper server. If for some reason you really can't do that, you still have the following options available:
You can use TCP/IP to connect local network resources if you remove the isolation for your Windows Store app. You will need to use CheckNetIsolation.exe, but since you already need to separately install the desktop application, this shouldn't be that much of a problem.
You can create files with a specific extension. Then register the desktop app for one extension and the Windows Store app for another extension. You can now shell execute files with these extensions to use them as a message for the other app.
I am attempting to get the QBSDK running on my Windows 7 machine. I am trying to run the sample program called EventHandler. It is run in conjunction with the sample EventSubscribe. I have compiled these in Visual Studio 2008. The EventHandler has a option in the File menu called Register Call Back Interface. When I run that it indicates that the COM connection has been created, however when I try to subscribe to an event in the EventSubscribe sample program it gives me the error “The callback application cannot be found from the CLSID or ProgID provided in the subscription request.”
On my Windows 7 machine after I did the Register the Callback Interface I noticed that the Unregister command was not highlighted. I also compiled this on a Windows XP machine with Visual Studio 2008 and I noticed the Unregister was highlighted. I do not have Quickbooks on the Windows XP machine though.
I have tried many things to get this to work… Any idea what is happening?
I am using C++
Thanks,
Jim
This may not directly describe your situation but the concept is similar. Starting with Vista, there were quite a few workarounds with QuickBooks SDK (and other COM-based technology) that required "Run As Administrator" to configure due to Windows UAC restrictions.
From the SDK documentation:
After you subscribe your menu extension events and
register them as documented, you need to run QB
using "Run As Administrator." This only has to be
done ONCE, after running QB as admin once, your
menu items will continue to show up and menu
events will be received by your event handler without
running QB as admin.
The general principle is that even if you are running Windows under an Administrative account, you may need to "Run As Administrator" both the QuickBooks UI, and your application that uses QBSDK, during the configuration process. Once all the registration and configuration is done it should work as a normal user.
I'm writing an SNMP extension agent DLL for Windows.
Is there a way to automatically attach the DLL to the SNMP service each time I want to test/debug?
This is a very tedious and time consuming process, as I currently have to stop the SNMP service, compile, restart the service and then attach the process. I'm trying to automate it more.
This may be what you want to have a look at.
Visual Studio debugger offers some command line option to attach to running process. You can probably write a Python script to enumerate running processes and attach the debugger to the service. I think you need admin priviledge to do that.
.Net has a convinient Debugger.Launch(), but I can't find an equivalent for the native.
I'm am developing a Firefox extension which interfaces with an underlying Windows service (which I have already made).
During the development so far I encountered one bug in the installer program (which installs the FF extension AND the service). This was due to the security model on Vista requiring elevated privileges to be able to install and start the service. I adjusted the installer and now it installs fine (just with additional Vista'esque warning dialogs being displayed to end-users - which I can live with !)
I am now in the process of developing an XPCOM component that will install along with the XUL stuff I have already made. There will be a XUL javascript interface to the XPCOM which will try to do things like stop and start the service (e.g when user-configuration data is changed).
My question: Since FF will normally be run under a user account, will I run into any difficulties on Vista or other Windows flavors trying to start or stop my own service via XPCOM?
(When users run the installer I don't mind security dialogs popping up in Vista. But I certainly don't want this to happen whenever they try to change their info in the XUL interface.)
What is the correct way to go about this?
Yes, if your service is running as an Administrator then the Firefox process, running as a normal user will not be able to start or stop it. However, it appears that you can use the "sc" command to set access controls on your service from your installer, which means you can allow non-admin users to start and stop your service.
You'll need to use "sc sdset", which is documented (lightly) here:
http://technet.microsoft.com/en-us/library/cc742037%28WS.10%29.aspx
However, to use that, you'll need to read up on the "Security Descriptor Definition Language", which looks kind of complicated:
http://msdn.microsoft.com/en-us/library/aa379567%28VS.85%29.aspx
This blog entry appears to have some human-readable information on it:
http://blogs.dirteam.com/blogs/jorge/archive/2008/03/26/parsing-sddl-strings.aspx