We have a C++ desktop application using an old MFC GUI; we would like to move it to a Windows App.
We use some sdk (for GigE cameras, CameraLink grabbers, vision libraries) that need msvcrt and shared mfc dlls. Including <afx.h> in a Windows App does not work.
Could be a solution packing everything in WinRT components or there are simpler ones (or none at all, and we must stay within desktop apps)?
MFC cannot be used in a Windows Store app. The only option is to eliminate use of MFC from the components that you would like to use in a Windows Store app.
Related
Currently I'm working on a simple game engine project. I would like it to be independent from the platform, so for started I've taken only classical Windows Desktop application and Metro Style app.
From this picture:
Windows APIs
We can see that the C/C++ blocks are common for both parts. In other words, I would like to easily switch between platform configurations. I've created simple WinAPI static library that you can easily include in the project, as well as DirectX game-engine and it works perfectly. However, I'm having issues to do the same with WinRT (used in Metro Style apps).
Is it possible to have one Visual Studio project that can use WinAPI or WinRT? It would be perfect if I could have like one single entry point for a game and just switch underlying APIs.
No. A single VS project that either generates a classic win32 exe and a WinRT (nowadays Universal) applications is not possible.
In theory they could have made it possible, like you can have a single project that generates a console application or gui application. The difference between the two boils down to one (or two) flags.
The difference between a classic exe and a WinRT app is quite big: There are manifests and packaging and special sauce signing not to mention the resources (icons, etc) are specified differently.
In the Visual studio UI this is manifested by a different set of property pages, besides the common core of compiler + linker ones of course.
The other reason is one of strategy. Microsoft wants you to move forward and embrace the WinRT API. That is the API set that works across all Windows devices (if you ignore the Win7 elephant in the room). Supporting a dual mode will send the wrong signal to developers.
As a side note that the very windows headers (windows.h) are annotated by API family. CreateNamedPipe is #ifdef out in a WinRT application, or for example there is CreateFile for classic apps and CreateFile2 for modern apps.
Currently we have a legacy client/server system written in MFC(server) and Java(client). This system cant not run on Internet because of various reason. So, we are developing a small system (very few functionalities of this legacy system) in cake php etc to fullfill customer requirement.
Now, one functionality in legacy system needs in this new system. We are thinking of making a DLL of that code and then integrate it with cake php (to save time) but this DLL will not work on Linux where this new system will sit.
So, is there any way to generate a dll so that it works with php in Linux system using QT etc?
OR
we have to rewrite the whole thing? In this case, what would be the most appropriate framework to develop cross platform dll. I would prefer to use Windows to write it.
Also, can we run dll with cake php?
Thanks
So, is there any way to generate a dll so that it works with php in Linux system using QT etc?
No, Linux doesn't support the DLL file format. You may want to compile a shared object file in the ELF format from your source code.
I think, the two most prominent cross platform GUI libraries are wxWidgets and Qt.
You cannot use a Windows DLL as a part of a Linux application. That is simply not possible, because of the different object formats.
So, the only option is to rewrite or port it in some form.
A guide for porting your application might be Porting MFC applications to Linux, which uses wxWidgets.
Another one using Qt, could be MFC to Qt Migration - Walkthrough.
I want to build a DLL plugin for a 3rd party MFC-based application. The "official" way to do this is to build the plugin using MFC as well. I'm looking to see if it's possible to use any other gui toolkits to ease my development. I've played around with Qt's MFC Migration Framework (http://doc.qt.nokia.com/solutions/4/qtwinmigrate/) for which I have had some success but I've run into a road block with it. Now I'm considering alternatives. Does wxWidgets have any support for building a DLL that will integrate with an MFC host application?
Normally there is no need to build a plugin using MFC even if the main application does use it so I'm not sure what are your exact requirements. All I can say is that it is possible to use wxWidgets and MFC together as the mfc sample included in wxWidgets distribution shows. But it's still better to avoid mixing two different frameworks if you can.
I love that Qt is cross-platform but I want to make an application that will call into some Windows specific .dll's. Kinda like Google Chrome does with the glass on Windows Vista/7 (I know Chrome isn't written using the Qt framework just thought it was a good example).
How can I do this in Qt? Is it feasible?
Yes, this is no problem. You just go ahead and do it! Qt itself is just a DLL you call into, it just happens to be the same across different platforms. Just link against the DLLs you like and call them.
There is nothing wrong with using Qt to make a Windows-only application if you like.
As long as you have the relevant Windows SDK headers to hand, and can link with the appropriate libs, then it is easy to mix and match Qt and Win32 code. I use Qt Creator for C++ development which ships with MinGW and includes all the most common Win32 SDK headers and libs. You can even wrap the Windows specific parts of your code with suitable #ifdefs in case you ever come to build for a different platform, e.g.:
#ifdef Q_OS_WIN
#include <windows.h>
void someWindowsSpecificFunc()
{
...
}
#endif // Q_OS_WIN
You can of course call WinAPI functions directly from your Qt code, then it's better to include qt_windows.h not windows.h.
If you just want to add the cool new Windows 7 features to your application then you are better of using a dedicated Qt add-on. There is one called Q7Goodies.
Fearlessly go ahead an write your Win-specific app. You can utilize all the Windows DLLs you want. In this sense, Qt has no limitations. You will still be gaining the advantages of those nifty Qt layout components and customizable skinning. In terms of skinning there is no better framework that Qt. Your users will love all the resizable dialogs you provide them with.
I have built a windows C++ application that I'd like to port to linux. The main reasons to do this is ease of system maintenance for our IT staff. Apart from the one windows machine that runs this application we're a linux only operation.
The reason this application was built in-, and runs on- windows is that it uses a windows API (dll and header) to connect to a server belonging to an external party. This connection uses some proprietary protocol that I don't really want to mess with, (and I think I'm contractually not allowed to) so I'm stuck with the .dll.
This dll is windows only because of (I suspect) windows sockets specific code in the dll. Apart from that it doesn't do a whole lot of advanced stuff. Is there a way somewhere between just running the app on linux in WINE and sniffing out the protocol and reimplementing the DLL myself that will allow me to get this application to run on a linux machine?
This idea got inspired by this item about QT creator so any solution that allows me to play with that would be extra cool.
The most obvious middle ground would be to use Winelib. I do not know if it can link directly to a native DLL, but if not you probably could load it with LoadLibrary().
You could then split your application in two parts: a wrapper which only calls the DLL, and the rest of the code talking to your wrapper. You could have both in separate processes, and thus only the wrapper would have to be compiled with Winelib. The rest of the application could then use whatever framework you want.