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.
Related
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
I'm working on a multi-platform project that is composed of a service/daemon which runs on Windows, Linux, and Mac OSX.
The code I have is portable, and the application runs fine (from the command line) on all the systems. As this application is designed to run in the background, I made it a Windows service on Windows and a Linux daemon (with the appropriate scripts in init.d) for Linux.
Now my problem is Mac OSX: I have little experience with this operating system, and I am having hard times figuring out the best practices for it regarding my situation:
I'd like to have an installer for my project (I believe a .dmg file, that would likely install an .app; please correct me if there is a better alternative).
Here some information about this project of mine:
It is build entirely in C++ (it uses boost, curl, iconv)
The current build system is not XCode (however If there is a way of keeping my current code layout while integrating and building everything into XCode, I don't mind. I've done something similar for Windows anyway).
There is no graphical user interface
The daemon should start on startup automatically (or even better: make that a user's choice).
The daemon requires root access during its execution.
That's probably a lot of context to consider for a single question, so I will try to make it easier to read:
How would you package/create an installer for a pure-C++ daemon on Mac OSX ?
Since this doesn't have a UI, I wouldn't package it as a .app -- that's the preferred format for double-clickable GUI apps, not for daemons. If it's just a single binary (no support files except maybe things like config files, etc), I'd follow unix conventions and put the binary someplace like /usr/local/libexec (or wherever you put it on Linux). Note that /usr/local doesn't exist by default on OS X, so your installer will need to create it if it doesn't exist.
For getting it to execute: I'll agree with James Bedford's suggestion of using launchd. The launchd .plist file should be installed in /Library/LaunchDaemons (LaunchDaemons run as root at startup, while LaunchAgents run as normal users when that user logs in). Make sure the daemon does not drop itself into the background -- launchd keeps watch over the programs it launches, and if they background themselves it thinks they've crashed, and generally tries to relaunch them, which doesn't work very well. You can adjust the settings to work with background programs, but it's best to have it run in the foreground.
For packaging: Here, I agree with mah -- use an installer package. I actually still like the old GUI PackageMaker tool (deprecated, but it still works), but the new CLI tools are probably better to learn at this point. If you follow my recommendation about /usr/local/libexec, your package should actually contain the "local" directory (with libexec subdir and your binary in that), and install that into /usr -- if /usr/local already exists, it'll just merge with what's already there, but if not it'll create the entire thing. On the other hand, /Library/LaunchDaemons is guaranteed to exist, so your package only needs to contain the actual .plist file to put in it.
Packaging as a .app makes some sense if what you're distributing is more than just a command line (for example, if it has resources such as static configuration data, images, frameworks/dylibs) that need to come along with it).
Regardless of what exactly is getting distributed, you can create an installer using tools that you already have -- pkgbuild and productbuild, both in /usr/bin. Making OS X Installer Packages like a Pro - Xcode Developer ID ready pkg can get you started using these tools.
Have you checked out the Daemons and Services Programming Guide provided by Apple? I think that would be very helpful as an introduction to the platform and should point you in the right direction (if not show you how to do exactly what you want).
You should also check out launchd (which is discussed in that programming guide). launchd is the official deamon launcher/manager for OSX, and is heavily integrated with the operating system. It should be easy enough to wrap your existing cross-platform deamon into a launched deamon, and you can integrate with OS X so that the deamon will start up automatically.
I asked this question in a more general design context before. Now, I'd like to talk about the specifics.
Imagine that I have app.exe running. It downloads update.exe into the same folder. How would app.exe copy update.exe over the contents of app.exe? I am asking specifically in a C++ context. Do I need some kind of 3rd mediator app? Do I need to worry about file-locking? What is the most robust approach to a binary updating itself (barring obnoxious IT staff having extreme file permissions)? Ideally, I'd like to see portable solutions (Linux + OSX), but Windows is the primary target.
Move/Rename your running app.exe to app_old.exe
Move/Rename your downloaded update.exe to app.exe
With the next start of your application the update will be used
Renaming of a running i.e. locked dll/exe is not a problem under windows.
On Linux it is possible to remove the executable of a running program, hence:
download app.exe~
delete running app.exe
rename app.exe~ to app.exe
On Windows it is not possible to remove the executable of a running program, but possible to rename it:
download app.exe~
rename running app.exe to app.exe.old
rename app.exe~ to app.exe
when restarting remove app.exe.old
It's an operating system feature - not a C++ one.
What OS are you on?
In Windows see the MoveFileEx() function, on linux simply overwrite the running app ( Replacing a running executable in linux )
On Windows at least an application running is locking its own .exe file and all statically linked .dll files. This prevents an application from updating itself directly, at leads if it desires to prevent a re-boot (if re-boot is OK the app can pass in the MOVEFILE_DELAY_UNTIL_REBOOT flag to MoveFileEx and is free to 'overwrite' it's own .exe, as is delayed anyway). This is why typically applications don't check for updates on their own .exe, but they start up a shim that checks for updates and then launches the 'real' application. In fact the 'shim' can even be done by the OS itself, by virtue of a properly configured manifest file. Visual Studio built application get this as a prefab wizard packaged tool, see ClickOnce Deployment for Visual C++ Applications.
The typical Linux app doesn't update itself because of the many many many flavors of the OS. Most apps are distributed as source, run trough some version of auto-hell to self-configure and build themselves, and then install themselves via make install (all these can be automated behind a package). Even apps that are distributed as binaries for a specific flavor of Linux don't copy themselves over, but instead install the new version side-by-side and then they update a symbolic link to 'activate' the new version (again, a package management software may hide this).
OS X apps fall either into the Linux bucket if they are of the Posix flavor, or nowadays fall into the Mac AppStore app bucket which handles updates for you.
I would day that rolling your own self-update will never reach the sophistication of either of these technologies (ClickOnce, RPMs, AppStore) and offer the user the expected behavior vis-a-vis discovery, upgrade and uninstall. I would go with the flow and use these technologies in their respective platforms.
Just an idea to overcome the "restart" problem. How about making a program, that does not need to be updated. Just implement it in a plugin structure, so it is only an update host which itself loads a .dll file with all the functionality your program needs and calls the main function there. When it detects an update (possibly in a seperate thread), it tells the dll handle to close, replaces the file and loads the new one.
This way your application keeps running while it updates itself (only the dll file is reloaded but the application keeps running).
Use an updater 3rd executable like many other apps.
Download new version.
Schedule your updater to replace the app with the new version.
Close main app.
Updater runs and does the work.
Updater runs new version of your app.
Updater quits.
I came from gnu/linux world but recently I must to work on a windows system and I want to be able to compile my c/c++ console programs on it. The problem is I don't have administrative privilegies to install anything.
I looked for portable apps. I'd find gvim and mingw but I don't know how to make them work together on a flash drive. I'd found also a vim plugin called msysportable that's supposed to do the job but I don't know how.
So my question is: how can I make a portable windows c/c++ development environment using gvim?
(don't tell me to use code::blocks or visual studio, I've this installed but I want vim)
copy your development environment to your flash-drive. Create a batch file to setup environment variables for paths to include dirs ,lib dirs ,executables ,etc. Then use this environment in cmd session with console commands. If you have installed MSVC on your own system then there is a batch-file called vcdirs.bat thar does this on youre system, Take it as example how to make a portable environment. By the way ,INSTALLING youre tools at a vlient-site may be a license violation. The portable environment is not as long as you do not install it.
I am very disappointed with my school linux server when doing the homework on it.
The reason is: my homework requires to make GUI application.
All the tool that I have is:
- ssh from my local machine to school machine
- gcc/g++ in my school machine
I have been thinking and tried out different solutions for a week.
I still can't be able to figure out how to bring GUI to my application.
Here is some solutions I tried:
- Install some graphical library (sdl,ncurses...) but school computer does not allow to install because i'm not the root user
- Try to compile with /X11/ to produce X-GUI application. Then running it throgh ssh (tunneling). This does not work either because school computer does not have headers file located in X11.
So, What CAN I DO? Anybody has suggestion?
I will thank you million times if you could help for a solution.
Thanks you much.
tsubasa
It should be possible to install most things, like ncurses or even X11, in user space (in your home directory), if you install them from source. With a Gnu package, you just use --prefix= as an argument to configure, like this:
./configure --prefix=/name/of/directory/to/install/into
I'm not sure about the other packages.
Without a GUI library to link against, you won't be able to develop a C/C++ app on that server. It seems to me that you have a few options:
1) Develop this GUI app someplace else. If it has to be in Linux, and you're a Windows/Mac user, you can install Ubuntu (or some other Linux Distro) on a Virtual Machine and get a full featured environment.
2) Contact the Linux administrator to explain the homework assignment and convince them to install a GUI package for you. (It may help to have your professor also contact the Linux Administrator) (If you don't know who the linux admin is, try emailing root#linuxbox
3) Bend the rules on what a "GUI" environment is. For example, can your C/C++ app output HTML files for a GUI-like experience through a web-browser?
4) Try to install some sort of GUI package inside your account on the server. This will likely fail unless you are very, very good at administering a linux box, and you've hand-built packages before.
Could do it with ncurses
Perhaps you could ditch the school server and use Virtualbox to run a linux VM locally on your machine and develop on that. It's free.
From "INSTALL" file in ncurses source archive:
The package gets installed beneath the --prefix directory as follows:
In $(prefix)/bin: tic, infocmp, captoinfo, tset,
reset, clear, tput, toe
In $(prefix)/lib: libncurses*.* libcurses.a
In $(prefix)/share/terminfo: compiled terminal descriptions
In $(prefix)/include: C header files
Under $(prefix)/man: the manual pages
Note that the configure script attempts to locate previous
installation of
ncurses, and will set the default prefix according to where it finds the
ncurses headers.
Do not use commands such as
make install prefix=XXX
to change the prefix after configuration, since the prefix value
is used
for some absolute pathnames such as TERMINFO. Instead do this
make install DESTDIR=XXX
So I'd recommend using "make install DESTDIR=XXX" where XXX is the location where you have write persmissions.
HTH