I wrote a UNIX daemon, in C, which I want to port to Windows.
My target is Windows 10.
When I search on how to create a Windows service, I am met by an approach using .NET and C# which I both want to avoid at all cost.
How can I make a simple straightforward service in C, without kitchen sinks that Microsoft tries to unload on me? If I really have to, I would consider C++, but C# and .Net are simply taking it too far.
I'm fine with switching to a different compiler too, if this is easier outside of VisualStudio. (Currently I am using Visual Studio 2019, latest update.)
NOTE: My Linux daemon just has one dependency: libhidapi which is available for Windows.
UPDATE
No C++ templates available.
This comes down to creating two different applications (.exe)
One to run the service using StartServiceCtrlDispatcher() where the dispatching function calls RegisterServiceCtrlHandlerEx() to register a controller.
One to install the service using CreateService()
It is possible to skip on the installer, and use the sc command line utility for that, which is part of the OS.
See full example.
Related
Goal
I'd like to write C/C++ applications and provide an API for them to communicate directly with systemd-managed services. Effectively, I'd like my applications to be able to do the equivalent of systemctl start service_name#unit_number.service without using system(), popen(), or exec() calls (hard requirement).
Question
Is there a simple C/C++ API for communicating with systemd, assuming systemd version 219 (i.e. CentOS v7.4, also a hard requirement)?
Work So Far
I've scoured online for examples of controlling systemd-managed services in C/C++ and found the odd discussion on the topic, but haven't found any good examples.
I could always reverse-engineer systemctl version 219 from source, but then I potentially run afoul of GPL licensing.
Since I'm stuck with CentOS v7.4, which means I can't get at version 221 or later of systemd, I can't use the newer "SD Bus" API. Nobody would allow manually upgrading libsystemd just for an application-specific benefit, and I'm apparently not the first person to raise this concern.
I'm hesitant to use the low-level C API for DBUS, since the maintainers themselves state "If you use this low-level API directly, you're signing up for some pain.".
Hard Requirements
systemd v219.
CentOS v7.4
C/C++.
No system()/popen()/exec() calls to the systemctl CLI utility.
Non-propagating license (i.e. LGPLv2 is OK, though BSD/MIT is preferred).
Question (Redux)
Is there a simpler API that I could use on CentOS v7.4 (even if I have to supply the shared library myself) that can be used to communicate with systemd in a simple, reliable manner directly via C/C++ code? If the existing libdbus-1.so API is complicated but still reliable, and I can create a reliable/stable wrapper library around it, I'm open to exploring that option. Also, if it's possible to manually build and deploy the SD-BUS components independent of systemd and use them without having to modify/upgrade the systemd library/daemon already on the system, I could potentially go that route too.
Edits & Comments
I would be open to using a mature C++ library, so long as it doesn't require total release of all source.
Thank you.
As you already figured out, you should only interact with systemd using a dbus library, there is no other supported way to do so.
Even if you lifted the requirement of no execution of binaries, it will remain frowned upon, as the *ctl tools are command line user interfaces not intended or designed to be called from other programs.
I really want to use the libpostal library as part of my Java application via the jpostal binding. While I can work around the fact that jpostal uses Gradle instead of Maven, I'm not sure where to proceed after I've cross compiled a libpostal DLL using a Linux machine.
According the answer to this question, the process of installing a DLL on Windows is very convoluted.
If anyone has good idea as to where I can put the DLL so that my Java application using jpostal can find it, please tell me.
P.S: My Java application will run on a CentOS machine in production but for development, testing, and demoing I'm using my laptop and desktop which run Windows. Of course if I can't get libpostal to work on Windows, then I can always go the virtual machine route.
Well, I wrote a code for File I/O with Win32 API.
(I'm using Visual studio 2013)
It just gets two file name(one for source, one for destination) and duplicate one to another.
I used CreateFile, ReadFile, WriteFile.
It's functionally simple. It's not problem. But..
I wanna SEE the system call in these function being called in debugger.
How can I do this?
with Call stack? Disassembler?
So you want to be able to debug not only your own code but also the API itself.
There are different ways to do that.
At the simplest level, just use the debugger from VS2013. You won't be able to trace into kernel code, but all the user level code in the API. But of course as you will use a non debug version of Windows with no symbol table you will only see low-level machine code (*).
If you really want to go deeper, you will have to use the Debugging Tools for Windows. As you say you want to debug system calls, my advice would be to use the Windows Driver Kit, the Windows Symbols, and if you really go down to kernel mode the Windows Remote Debugging Client for Windows (all those tools are available from Windows Dev Center).
All those tools integrate nicely in VisualStudio, but be prepared to hard low level work :-)
(*) You can also use the Microsof Symbol Server to access windows symbolic information - thanks to IInspectable for his comment. But I've never tested.
I have written a small custom web server application in C running on Linux. When the application receives a request it calls fork() and handles the request in a separate process, which is chrooted into a specific directory containing the files I want to make available.
I want to port the application to Windows, but neither fork() nor chroot() are available on this platform, and there don't seem to be any direct equivalents. Can you point me to a simple (and preferably well written) example of code that will provide this functionality in Windows? My C isn't all that good, so the simpler the better.
First of all, the Windows equivalent of chroot is RUNAS which is documented here. If you need to do this from a program, then studying this C++ source code should help you understand how to use the Windows API. It is not precisely the same as chroot() but Windows folk use it to create something like a chroot jail by creating a user with extremely limited permissions and only giving that user read permission on the application folder, and write permission on one folder for data.
You probably don't want to exactly emulate fork() on Windows because it doesn't sound like you need to go that far. To understand the Windows API for creating processes and how it differs from fork(), check Mr. Peabody Explains fork(). The actual current source code for Cygwin's fork implementation shows you the current state of the art.
The Microsoft documentation for CreateProcess() and CreateThread() are the place to look for more info on the differences between them.
And finally, if you don't want to learn all the nitty-gritty platform details, just write portable programs that work on Windows and Unix, why not just use the Apache Portable Runtime library itself. Here are some docs on process creation with some sample code, in C, to create a new process.
There's no such thing as fork() on Windows. You need to call CreateProcess() - this will start a separate process (mostly equivalent to calling fork() and then immediately exec() for the spawned process) and pass the parameters to it somehow. Since you seem to have all the data to process in a dedicated directory you can make use of lpCurrentDirectory parameter of CreateProcess() - just pass the directory path you previously used with chroot() there.
The absolutely simplest way of doing it is using Cygwin, the free Unix emulation layer for Windows. Download it and install a complete development environment. (Choose in the installer.) If you are lucky, you will be able to compile your program as is, no changes at all.
Of course there are downsides and some might consider this "cheating" but you asked for the simplest solution.
Without using a compatibility framework (Interix, Cygwin, ...) you're looking at using the Windows paradigm for this sort of thing.
fork/vfork is a cheap operation on UNIXes, which is why it's used often compared to multi-threading. the Windows equivalent - CreateProcess() - is by comparison an expensive operation, and for this reason you should look at using threads instead, creating them with CreateThread(). There's a lot of example code out there for CreateThread().
In terms of chroot(), Windows doesn't have this concept. There's libraries out there that claim to emulate what you need. However it depends why you want to chroot in the first place.
Reading comments, if it's simply to stop people going up the tree with ../../../../(etc), chroot would do the job, but it's no substitue for parsing input in the first place and making sure it's sane: i.e., if too many parents are specified, lock the user into a known root directory. Apache almost certainly does this as I've never had to create a chroot() environment for Apache to work...
Using fork/chroot is simply not how things are done on Windows. If you are concerned about security in subprocesses, maybe some form of virtualization or sandboxing is what you want to use. Passing complex information to the subprocess can be done by some form of RPC-solution.
It sounds to me as if you have designed your application in the Unix way, and now you want to run in on Windows without having to change anything. In that case, you may want to consider using Cygwin, but I'm not sure if/how Cygwin emulates chroot.
Consider SUA ( aka Windows Services for Unix ). It has nearly everything you need to port applications.
man chroot(interix)
As it seems there is no scripting language for Windows mobile devices that gives access to phone (sms, mms, make a call, take photo). I wonder how complex it would be to make a Python library that would enable that (write something in C, compile, and import in PythonCE).
Question: Where shall start to understand how to compile a PythonCE module that will give additional functionality to Python on Windows mobile. Also, what is the required toolkit. Is it at all possible on Mac (Leopard)?
As the first step, you should try to create executable programs that invoke the functions you want. For example, to send SMS, it appears you need to call MailSwitchToAccount, passing "SMS", and so on - familiarize yourself with the C API on the platform.
To create executables, you need Visual Studio, and the Windows Mobile SDK. Those run on Windows. For cross-compilation, there is CeGCC (http://cegcc.sourceforge.net/docs/using.html), but using it probably makes things more complicated than using the Microsoft tools.
When you have executables that perform the functions you desire, creating Python extension modules out of them should be easy. Just follow the extending-and-embedding tutorials.
MSDN has plenty of samples for C++ development on Windows Mobile, and the SDK comes with several sample application. Unfortunately VS Express editions (the free ones) do not come with compilers for Smart Devices. The only free option is the older eMbedded Visual C++ (eVC), which is now something like 8 years old and not supported (though it can still create apps for devices at least up through CE 5.0).
just tried establishing an environment to get pythonce modules compiled (http://pythonce.sourceforge.net/Wikka/SConsBuild) but seems that I can only use 2003 PPC SDK and it has no recent functions available. Even when I followed all the steps in tutorial, sample spammodule.c does not compile :(
Is there any good tutorial I can utilize to startup C (C++) programming for Windows Mobile?
Also is it possible using free version of VisualStudio (Express version)?