Does any body know how can I use MS_MPI in my VC++ MFC project?
I already have a big MFC project and I only want to use parallel processing in a part of it with MPI.
(I know how to use MPI in a separate code, but I don't know how to integrate it with my VC++ MFC project)
Not sure about MS_MPI, but you wanna look at MPICH2 Windows documentation guide at the url at the bottom.
9.3 MPI apps with GUI
Many users on Windows machines want to build GUI apps that are also MPI
applications. This is completely acceptable as long as the application follows
the rules of MPI. MPI Init must be called before any other MPI function
and it needs to be called soon after each process starts. The processes must
be started with mpiexec but they are not required to be console applications.
The one catch is that MPI applications are hidden from view so any
Windows that a user application brings up will not be able to be seen.
mpiexec has an option to allow the MPI processes on the local machine
to be able to bring up GUIs. Add -localroot to the mpiexec command to
enable this capability. But even with this option, all GUIs from processes
on remote machines will be hidden.
So the only GUI application that MPICH2 cannot handle by default
would be a video-wall type application. But this can be done by running
smpd.exe by hand on each machine instead of installing it as a service. Log
on to each machine and run “smpd.exe -stop” to stop the service and then
run “smpd.exe -d 0” to start up the smpd again. As long as this process is
running you will be able to run applications where every process is allowed
to bring up GUIs.
:
http://www.mcs.anl.gov/research/projects/mpich2/documentation/files/mpich2-1.2.1-windevguide.pdf
It is possible. You use it the same way as any other MPI project.
In general, you can link against any C++ library from an MFC project. MFC is just a set of libraries, and doesn't restrict you from using other C++ libraries.
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 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 wanted to know if its possible to embed other .exe applications on a QT form.
Say i have an app called foo.exe. Now I want to lauch foo.exe through my application. I know I could do that using QProcess::startDetached() however I would like that program to run within my form.Is that possible ?
Believe what you want is a kind of "EMBED", there seems to be something done, but I can direct you to a few ways:
Cygwin
In X Window System we have o "X-Embed"
For Windows exists Cygwin/X (apparently to run "multi-threaded" in "google chrome" uses cygwin).
QT X11 Systems: http://qt-project.org/doc/qt-4.8/qvfb.html
Nice example: http://arstechnica.com/information-technology/2009/03/experimental-process-per-tab-browser-created-with-qt-xembed/ (outdated)
ActiveX
You can create Activex Controls, see example: http://qt-project.org/doc/qt-4.8/activeqt-server.html
In two suggestions that you spent the programs you want to add to your main program should be created by you, in other words, programs that are not compiled with "Cygwin" or is not an "ActiveX" (QT you can add controls ActiveX, such as Internet Explorer or MSExcel).
Believe both examples programs work as "servers" and its main program as a "client", in other words, other processes need not necessarily one graphical interface, I believe the main software is who works the GUI part.
For this reason the programs should be "embedded" created with the purpose of "embedding"
Alternative solution (DotNet and user32.dll)
See article:
http://www.codeproject.com/Articles/9123/Hosting-EXE-Applications-in-a-WinForm-project
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 have a Visual C console application (created in VC++2008EE) and I need to add GUI to it.
One idea was to invoke the console app as a subprocess and communicate with it using stdin and stdout. I tried to do that with Python subprocess module - but it deadlocks (probably because my console app is running continuously). As I understood from http://www.python.org/dev/peps/pep-3145/ it is not possible now to integrate continiously running console application with python subprocess module.
The other idea (more strait-forward probably) was to add a form to this console application project. But as I try to do it VS convers the project to one with "Common Language Runtime support" whatever it means, ads the form, a cpp file for form - and it's not compiling anymore saying:
Command line error D8016 : '/MTd' and '/clr' command-line options are incompatible
error BK1506 : cannot open file '.\Debug\Form_TEST.sbr': No such file or directory
No idea what it means. I have never dealed with C++, but I have used C and Python some time.
What would you recommend?
If you own the code for the console app, don't mess around trying to talk to it using input and output streams. Extract the logic of your console app into a library, and call that library from a GUI of your choice - either Windows.Forms from C#, Python GTK, ordinary GTK.
The reason that VS turns your application to CLR type is becuase it accidently thinks that you want to use winforms which are part of the .NET framework and the only way to use them is if your project is .NET as well.
You do have other options:
1. Add MFC GUI - native C++ GUI
2. better yet create a new .NET project (C#/VB.NET) with the desirect GUI and call your C/C++ dll using P-Invoke or COM interop