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.
Related
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 new to windows phone development, and I need to create a control with C++ (basically it's a WebBrowser control) I would create with C# but the library I need to use for core is written in C++.
Conclusion: So the question is, Can I develop a control in C++ using external libraries and then compile it to use with any language of the CLR and use it in my windows phone 8 applications? If does, let me know about some resource any video, book, or whatever.
The general answer is "yes", although it comes with some caveats.
It's certainly possible to build a component in C++ using the Windows Phone Runtime APIs and then utilize it from another programming language, such as C#. The more "pure" the C++ code is in that it doesn't access native operating system features (that may not be present), the better off you'll be.
There's some general guidance on MSDN:
Native code for Windows Phone 8
Windows Phone Runtime API
Using Native C++ code in your Apps
That being said, if you're attempting to create an entirely new web browser for some reason, I'd strongly suggest you consider using the built in WebBrowser component. In Windows Phone 8, it's based on IE10, and in Windows Phone 8.1, it's IE 11. Those are both very capable browsers and designed to work well within the memory constraints of the platform.
Is it possible to open or to manage at all Windows 8 apps (e.g. the built-in Mail or News app) via WinAPI functions from a desktop program?
With 'manage', I mean to open, close, snap (to left and right) or to enumerate Windows 8 apps.
I know that apps can register for special URI schemes so they can be opened by a link (and probably via ShellExecute() and related functions), but what if they don't?
I've just found a blog post of Ashwin Needamangala in a Win8 App Dev blog which covers app activation and automating lifecycle states with C++, WinAPI and COM: http://blogs.msdn.com/b/windowsappdev/archive/2012/09/04/automating-the-testing-of-windows-8-apps.aspx
Enumeration works via the PackageManager class.
Opening an app is possible using the IApplicationActivationManager interface.
And if you're the one who opened it and you have a handle, you can probably call TerminateProcess on it, too, but I haven't tried that one.
Edit: we open-sourced our apprunner utility, it can install, run and uninstall packages and shows the use of PackageManager and IApplicationActivationManager.
Apart from that, other interaction (i.e. snapping/unsnapping) doesn't seem to be possible from the outside.
I have a service application (no frontend) that was converted from C# to CPP native code not implementing .net framework. This was done to speed the processing and to reduce the footprint.
I am investigating the move to support this service to Window tablet devices. How would I go about this and what obstacles might I meet along the way?
TIA
You shouldn't expect troubles, even Windows Phone 8 will introduce full support for the C++, there is no relevant news that can make you worried about Windows 8 and C++, the only relevant thing is the addition of the WinRT to the usual set of C++ libraries for Windows but is more like an extensions rather than a set of libraries that will suppress something that is already existing in the Microsoft environment.
The only real changes are in the GUI subsystem, as you can expect just looking at the Windows 8 products and in this case under Windows 8, if you want a GUI, you probably do not have other options than switch to the new WinRT.
There is also this link that can be useful.
I just wondering about this.It is said that .NET is better than MFC in a lot of aspects.But when I use my PEID to recursive scan my 'program files' directory,it turns out there are still a lot of programs written with 'Visual C++ 6'(esp. for security software),whose GUI should be written with MFC.
So my questions are:
Is MFC still the dominating framework
for windows desktop aplication?
What frameworks do IE,firefox,Microsoft office(or other famouse desktop applications,if you'd like to list some) use?
What frameworks do the desktop applications(e.g. explorer,card games) of Windows itself use?
thanks.
I say windows forms and WCF are pretty widespread. C#/VB.NET are well-entrenched in corporate america.
IE is COM-based.
Office is MFC/COM.
Windows Apps are usually native code to demo the platform.
For new projects I don't think MFC is the dominant platform, but mostly because newer platforms shield developers from the idiosyncrasies of Win32 and MFC itself and allow for faster development. MFC applications take longer to develop but are, imo, unmatched in responsiveness.
I will not deny that some parts of the platform are irrelevant in 2010 (for example CArchive and most of the Doc/View foundation); on top of that, the dwindling availability of 3rd party components (mostly GUI) is a bit worrisome. FP1/MFCNext was a step in the right direction, I'm anxious to learn about the new MFC functionality in VS 2010.
For optimal integration with the OS, imo C++/MFC is still the best choice because of the nature of C++ as low-level and the fact that Win32 is still the foundation of Windows and that it can most easily be accessed in C or C++.
By the way, I had to write code to change screen resolution and found that C# could only handle detecting screen resolution but not changing it.
To change resolution you had to do a lot of Interop gobbldygook which I tried but was too complex because the Win32 APIs to do that had too many old style arguments.
So, instead I wrote a quick MFC DLL that accessed Win32 API directly and wrapped all the calls to Win32 in a simple API. Then I did an interop call to my simple API in an MFC User dll.
Everything worked fine.
So, there's still no substitute for Win32 API. That has the ultimate power, and you have full access to it via MFC. So, yes MFC is still relevant and so is ATL and so is direct Win32 all of which I'm forced to use from time to time.
So, you may get 90 percent of your work done with .NET, but you have to go under the covers for a few things. Also, I've done a lot of Qt, and would never use it for quick jobs that are windows only. Qt also has become prohibitively expensive if you're doing anything commercial and also it is very very bloated. It's libraries take up gigabytes.