My company has many old projects that are written in vb6. We have some reusable software components which are written in ATL/C++. We're now considering to rewrite our app with UWP but it seems that UWP apps do not support the old COM technology. I am researching if there is a way to implement a COM object which also supports UWP. I understand that porting our old components to UWP Components would definitely work. But we do not want to maintain two version of common components because we have shipped many old software and we still provide software support. Some of those software have been used by our customers for more than 10 years. It is impossible to upgrade all software we have shipped.
I have come up with few possible solutions:
Desktop Bridge
I have found a phrase called "Packaged COM" which can be used by UWP apps with Desktop Bridge. This article, COM Server and OLE Document support for the Desktop Bridge, gives an example of calling an exe COM server from an UWP app. It seems to be a good solution if it also supprts InProcessServer. I did found something suspicious, InProcessServer, but it turns out that it is for WinRT components.
I have also tried to add the COM reference to the UWP project. The code can successfully refer to the COM object. However, it doesn't work at runtime. The UWP app has its own registry hive, therefor is won't load the COM object which is registered to the system registry. I'm thinking that if I add the registration information to the private hive of the UWP app and pack the COM dll along with the app, this may work. Just couldn't find any example.
ATL/COM
Since we have implemented our business logic into COM objects. The most viable solution would be upgrading our COM object to support UWP applications. WinRT components still use COM technology but implement the new interface IInspectable, I assume that the old ATL based COM object can be modified to support the calling convention of UWP if it implements IInspectable interface. I just don't have any clue to do this.
WRL
I found an MSDN article, How to: Create a Classic COM Component Using WRL, talking about using WRL project template to implement classes COM object which can be used in Win32 application as well as UWP apps.
It says:
You can use the Windows Runtime C++ Template Library (WRL) to create basic classic COM components for use in desktop apps, in addition to using it for Universal Windows Platform (UWP) apps
But I soon realise that WRL project template is no longer supported by Microsoft. All the download links of the project template I found on the web are no longer available.
C++/WinRT
This technology seems to be the successor of WRL. It seems promising but unfortunately have not yet been released.
To clarify few things from #Peter Torr:
(1) Do you want your app / COM object to be "pure" UWP (runs on all
devices) or are you OK with fullTrust UWP (aka Desktop Bridge) that is
Desktop-only? And (2) are the COM objects only for use with the app
that ships them, or are they supposed to be used by other apps?
My company uses Windows platform to provide PC-based industrial automation services(both hardware and software). So the answer is yes, we are happy with fullTrust UWP. Our products will only run on desktop. We just want to embrace the new technology and leverage the great UI framework of UWP.
COM objects are for both new apps(UWP) and old software(some are vb6 based). We are happy with packaging COM objects with UWP apps and using system registered COM for old software as long as those COM objects are the same(built from the same code base).
Related
I was wondering either it is possible to run an external application inside a QT widget under windows operating system. For example, if I were to write a Qt gui application, where in one of the dialogs user could write some text, I could use a textbox there or something similar. But instead, would it be possible to run Notepad++ or windows notepad application in that dialog?
I would appreciate all help.
It is not really practical to do what you describe at the application level, embedding an entire process into a window of another. (It would be technically difficult and the user experience would likely be pretty bad if you could pull it off.)
Fortunately, this very problem of application components has already been solved!
So it is possible to get the end result you describe via a slightly different mechanism. Many applications expose COM interfaces for automation and embedding, and it is possible to embed COM objects within a Qt application.
(Older technologies such as DDE, OLE and ActiveX provided various aspects of this but are all basically deprecated in favour of COM AFAIK.)
Hopefully you can find a COM object from a third party, or find an app that exposes its components via COM and assemble your app that way.
Have a look at the Qt documentation:
Active Qt - ActiveX and COM support for Qt
I am developing an application on Windows 10 that interacts with custom device drivers, the NTFS filesystem and DirectX 12. The app is a Windows Universal App written in C++, WRL, XAML and DirectX. For DirectX I have chosen a SwapChainPanel control and the DirectX portion of the app works great. The app is Sideloaded so I have a bit more freedom than an app that needs to go through the store
Unfortunately the Windows Universal Apps have a number of restrictions with regards to API calls. WinRt APIs are favored.
Here are a list of WinRt APIs to call to replace Win32 APIs:
https://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
In addition Windows Universal Apps can call Win32 APIs that are partitioned to the application (however not the ones partitioned to the desktop) as indicated in the documentation of each function and in the header file. Here is a link:
https://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
In addition the Winsock APIs are now allowed from Windows Universal Apps
However I am still left without my favorite (and necessary APIs)
CreateFile()
ReadFile()
WriteFile()
DeviceIoControl()
CloseHandle()
In particular I need to read and write files to all locations without user interaction (and not to the locations restrict by the Windows Universal App Sandbox). In addition I need to send IOCTLs to my multiple device drivers.
I could abandon Windows Universal Apps and go with WPF. However I have a touch intensive application and I need touch to work really well. In addition I have to wonder about the lack of fixes and commitment to WPF on the behalf of Microsoft. I have considered other UI frameworks but none have been as promising as a Windows Universal App.
Microsoft has allowed two paths in Windows 10 for Universal Apps that will allow calling all Win32 functions (For side loaded apps).
Brokered Windows Runtime Component
and IPC though TCPIP
I have written a brokered windows runtime component and it works well. However the solution requires a C# app to be in the mix and I do not need/want that as I need fast load times of the app and do not want to pull the CLR in.
The next option is IPC through TCPIP. I would use Fast TCP Loopback as explained in the blog post: Fast TCP Loopback Performance and Low Latency with Windows Server 2012 TCP Loopback Fast Path. I would link to it but I am at my (very generous) two link limit for a first post.
I have a couple of questions:
1) If I go this route should I place the IPC between the XAML controls/buttons and the rest of the App? This would allow the rest of the app to be strictly Win32. Or should I just place the IPC between the app and calls to the specific functions I need that fall outside of the those allowed by Win32.
2) I have looked for a library or paper that has code and/or ideas for implementing IPC with TCPIP. However so far the papers that talk about IPC with TCPIP seem to simply describe winsock programming which is something I already know how to do. I would enjoy coding up IPC but would prefer a solution that has been tested. This needs to work flawlessly and I would rather have code with some time on it. Has anyone used or heard of code and or a design for IPC over TCPIP that is available to share?
I'm trying to attempt to build a UI similar to the ones coming out of Microsoft these days. Particularly those targeting the Windows 10 operating system (a la Office 2016).
Currently I use WinAPI, but all of the controls provided by Windows.h and CommCtrl.h appear to be legacy/old style UI elements. I'm particularly looking for the titlebar/menu/status bar elements (the main clientarea will consist of a GDI/Direct2D context, so nothing special necessary there).
I found some information pointing to XAML, but I don't think that's what I want. WPF seems to be a more likely candidate, but I'm not sure if that's the case either.
I would like for this to be 100% native (WinAPI/C&C++), but if there's absolutely no other option I can use C# for the UI and stub in the native code.
You use XAML and either C++, C# or JavaScript to write a Windows Store (previously Metro) app. If you use C++, the app is 100% native, but if you use C# or JavaScript, of course the required virtual machine is used.
The API that your code calls is WinRT, which looks like Silverlight. In addition, your app can also call some, but not all, Win32 API's similar to how .NET apps can call Win32 (e.g. By using P/Invoke). However, even if you use C++ and thus your app is 100% native, it is still sandboxed like a browser. Meaning it cannot do things like access the entire disk or write to HKLM in the registry. This is for security; a Windows Store app needs to be safe, and thus more limited, like a mobile app you buy from the Apple AppStore. This means that you can't call e.g. CreateFile. This says:
Minimum supported client
Windows XP [desktop apps only]
When MS mentions 'Desktop Apps' as above, they mean Win32 apps. This excludes Windows Store Apps. But this is confusing, because on Win 8/8.1, these Windows Store apps are full screen, but on Windows 10 they are resizeable and overlapping, appearing next to, and mixed in with traditional Win32 apps like Explorer and Task Manager. So even though they appear on the same desktop as Desktop apps, they are not Desktop apps.
I believe if a Windows Store app also targets Windows Phone 10, Windows IoT, etc. then it is called a Windows Universal app.
I'm having to use an SDK modeled on Microsoft's COM. I'm developing for Windows in C++.
I found this article that implies one can "use COM in Qt", but it is not clear whether they mean to register my own, new COM interface or whether they mean I can use an existing one that wasn't created in Qt (they speak of "creating a COM server").
The question is whether this is possible in Qt and whether this is somewhat of a hack or standard practice. If it is possible, would it make a difference if Qt is using the MinGW or VS compiler?
You can read in the Qt documentation about Active Qt module :
Qt's ActiveX and COM support allows Qt for Windows developers to:
Access and use ActiveX controls and COM objects provided by any ActiveX server in their Qt applications.
Make their Qt applications available as COM servers, with any number of Qt objects and widgets as COM objects and ActiveX controls.
So the answer is that you can easily use existing com objects and activex controls created with any language in your Qt application with the API provided by the Active Qt module. You can either use VS compiler or MinGW.
How do you develop UI in MFC?
do you use any free libray, or usually develop from scratch?
There are always so many DLL files in a C++ developed software, what are them used for ?
What's the difference between MFC ActiveX Control and MFC DLL ?
Visual Studio 2008 enhances MFC by adding the 'Feature Pack'. This allows you to create MS Office 2007 style GUIs (amongst others), complete with a Ribbon Bar.
http://msdn.microsoft.com/en-us/library/bb982354.aspx
I cut my C++ teeth using MFC, but I'd recommend you look at Qt instead - it's a much more modern framework plus you get cross-platform support (Linux, Mac, etc.) for free. MFC is pretty much a dead framework IMHO (the Feature Pack was bought in and is actually a cut-down version of the BCG library.)
http://www.bcgsoft.com/
If you want to stick with MFC there is another popular GUI framework, by CodeJock:
http://www.codejock.com/products/overview.asp?platform=mfc
MFC (Microsoft Foundation/Frustration Class) is an old approach of Microsoft to provide an Framework to C++ developers. In those days it was the only framework offered by Microsoft so the approch is very old (Win95 I think).
The MFC is a toolbox consisting of String, Gui, Controls etc...
CString, CWindow, CTreeControl, ...
In addition it contained an component framework (ActiveX) and Gui based component framework
ActivX Controls that may include all of the parts of the toolbox.
All the functionallity is hosted in the mfc??.dll and other dll taht have become part of the Microsft OS itself and contains a lot of compatibility stuff of Windows. (Most of the applications including Word Excel, ... are implemented using MFC).
Today I wouldn't suggest to start using MFC anymore. If you have to care about MFC you are doomed but I would suggest to use one of the newer hype things of MS or use Qt or whatever Gui based toolbox.
Most of them are more modern than MFC.
Get yourself a good book to begin with. There are still some third parties controls if you do not mind spending a bit of money. Finally, codeproject has hundreds of MFC examples.
The standard book for learning MFC is this one.
Since you don't list the DLLs that are troubling you, I can't comment on them. However in native code it's common practice for frequently-used functions to be separated out into DLLs.
An ActiveX control is a COM (Component Object Model) "chunk" of functionality, designed to be accessible from multiple languages. COM has no specific connection with MFC, other than the fact that MFC can use COM components like any other MS product.
MFC DLLs come in two types, extension and regular. Regular DLLs are just like any other DLL. An extension DLL is more tightly integrated with MFC, can only be used with MFC applications, and can export MFC classes and functions.
How do you develop UI in MFC?
More often than not the MFC GUI will be defined as a Windows resource file that is compiled using the Windows resource compiler and edited using the MFC specific resource file editor that is built into Visual Studio.
But since the resource file is just plain text it can also be created and edited by hand inside any text editor.
What's the difference between MFC
ActiveX Control and MFC DLL ?
MFC is nothing more than a set of C++ library classes designed to wrap around existing Windows technology.
So for example the MFC ActiveX control is nothing more than a Windows ActiveX Control written in MFC and likewise the MFC DLL is a Windows DLL written in MFC.
I would also recommend taking some time to also learn a little about the underlying Win32 layer. In reality MFC is only a very thin layer over the top of standard Win32 so any knowledge of Win32 always comes in handy.