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.
Related
This question already has answers here:
How do I build a graphical user interface in C++? [closed]
(8 answers)
Closed 6 years ago.
is there a way of creating a classic GUI with cpp like for the case of JavaFX? I want to create elements like floating buttons, tables, graphs, etc. I know of tools like qt but I'm not ok with it. I tried win32 API but it's only for Windows.
GUI libraries are generally called "widget toolkits", and there are a variety of cross-platform GUI widget toolkits available, however they are rarely a good idea for a great UX because different operating-system environments have different UI paradigms (e.g. how macOS and Ubuntu has a single always-on menu-bar at the top, whereas Windows and other Linux desktops do not).
So you have two fundamental choices to make:
Use a single cross-platform GUI toolkit - which means creating a single GUI project, but restricting you to that toolkit's selection of controls and functionality, and generally subjecting your users to a (relatively) poorer user-experience, either because your toolkit does not use native widgets (e.g. Java, WPF, Qt) or because you cannot use a platform's native paradigms.
Write a new native GUI for each platform. This means more work, but a better user-experience.
For cross-platform GUI toolkits, the main options are:
Qt
GTK+
WxWidgets
For a comparison between the three, see this QA: Which, if any, achieves Windows native look: GTK+, wxWidgets, Qt, FLTK?
(TL;DR: WxWidgets uses native controls but is difficult to develop with; Qt offers the best developer experience but has many other bullet-points which you need to be aware of)
For a native UI for each platform you need to target, you'll need to familiarize yourself with each API:
Win32:
MFC (the API is ugly by modern standards, but does encapsulate the main Win32 UI paradigms and APIs, such as Common Controls. However, be prepared for an uphill fight to support latter-day UI features, such as High-DPI, bi-directional text and high-quality 2D rendering. GDI/GDI+ is on the way out, which means using Direct2D - which is fun because MFC assumes GDI)
UWP/XAML: If your application can be sandboxed (and run only on Windows 10) then you should take a good look at UWP/XAML (it's all native, so the CLR is not involved).
WPF: Using WPF makes it easier to create a high-quality user-interface, if you're comfortable with your application taking a dependency on the .NET Framework and writing UI code in C# - however the visual aesthetic of un-skinned WPF apps took a nosedive with Windows 10 (i.e. they're ugly) and WPF's default control set is very aneamic - but if you have the means (i.e. time, money, people) then you can get great results - and as a bonus the XAML for WPF is generally portable to UWP.
macOS: Cocoa - you will have a hard time doing this in C++. If you're targeting macOS I strongly suggest writing your UI layer in Swift (or Objective-C if you have to) and then linking-in to the rest of your application code using C++ bridges.
Linux: As Linux is just a kernel the set of "native" widgets depends on the desktop environment of the user - but most desktop programs seem to use GTK. And if you're going to use GTK then you might as well use GTK's cross-platform features to support Windows and macOS.
In conclusion: it's difficult and a lot of work. :) - and explains why many software titles today (mid-2017) often built as web-applications either on the web directly (e.g. Facebook, StackOverflow, SalesForce) or hosted webviews using Electron (e.g. Slack, VS Code, Atom) or some other hosted-webiew (PhoneGap apps, Spotify, etc).
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.
I need to write an application that will be visually indistinguishable from something written natively for Windows XP/Vista/7 using whatever comes by default with the most modern Visual Studio. But I'm developing using MinGW and Vim (in C++).
In particular, I want the following controls to be native on the above three versions of Windows: form chrome, buttons, check boxes, menus, combo boxes, progress bars, scrollbars, rich text boxes. This will be enough for me.
I know that if you load GdiPlus and other things like riched32.dll as needed, and use Windows API to instantiate controls, then the OS will substitute its version of GdiPlus or other library, so it will look like XP style controls on XP, Vista on Vista, etc.
But I don't want to use plain Windows API, because even retrieving the default font takes half a page of code, and similar stories whatever I want to do. So I'd like to use a toolkit.
wxWidgets, Qt, GTK+, FLTK seem like the most widely used. But they are all cross-platform. I've used cross-platform applications, and many of them have foreign GUI controls (I call them widgets). So my question is: which of these toolkits can be made to produce true native-looking UI controls listed above, appearing correctly on the three versions of MSWin listed above?
I've typed each of them +" windows" into Google Images, but it's hard to tell, except that FLTK probably can't do it. Many of you must know the answer off the top of your head...
I won't talk about FLTK as I don't know it.
wxWidgets uses the native toolkit of the platform, (GTK on Linux, Win32 GUI API
on Windows, Cocoa on MacOS X).
GTK uses a theming API to fake the look and feel of the platform (custom theming engine on GTK2, CSS-based engine on GTK3).
Qt uses styles to fake the look and feel of the platform.
wxWidgets API is quite ugly from my own experience, because it had too many method just available on one or the other platform making stuff non-portable unless you'd workaround it. Unlike GTK+ and Qt, it also adds its own layer of bugs above the toolkit it uses as a backend. However, it tries hard to have the platform's native look as it uses the native toolkit.
GTK+ 3 still has some rough edges on Windows, which it officially supports since GTK+ 3.6. The GTK+ project delegates to the MSYS2 project the distribution of Windows binaries. As you're already using MinGW, that's pretty much the same kind of environment. They have good C++ bindings with GTKmm. However, you may have some work to get the theming right for your version of Windows.
Qt is a good choice for cross-platform C++ development with the main target being Windows, tries to mimic the native look and feel of the platform but has its own theming limitations too.
To sum up, there are only 2 approches:
toolkits that provide their own widgets and try to look like the native platform by providing theming (GTK+ and Qt)
toolkits that use the native widgets but hide their API behind a layer of abstraction (wxWidgets)
Both have their pros and cons.
Implementation details aside, wxWidgets philosophy is, and has always been, to look as natively as possible. We, wxWidgets developers, don't always achieve the goal of looking indistinguishably from the native applications but we always strive to do it and. AFAIK this is not such an important goal for Qt and definitely not for GTK+, so in my (obviously biased) opinion, wxWidgets is your best choice if you are serious about providing the best experience for your users, especially under OS X.
To answer your question more precisely, everything you list above is implemented using native controls in wxWidgets for Windows (rich text control is not available natively under the other platforms though).
IUP - Portable User Interface library uses native widgets, C API and Lua bindings.
i used java for native cross-platform without changing the code, used c/c++ wxwidgets for exclusively cross-platform if you want go to little up performance and standalone executable, used c/c++ winapi for windows and x11 for gnu linux native platform and terminal console, used python for scripting console and platform if you want your software up to date fast, and used assembly for a little simple purely console. And sometimes i combined them all with shared library .dll on windows and .so on gnu linux. And i liked doing for do comparative performance on programming studies with small hardware requirements.
Imagine you are on Windows 7 and you have to write a GUI for a GRAPHIC application, (like a terrain editor, mesh viewer ..) which involves a great use of DirectX and OpenGL (so written in native C++).
If your goal is a multi-platform software then you should go for wxWidgets, but imagine you're doing a Windows' only app...what would your choice be? and why?
I'm supposing that the application would work on both XP and Vista/7 and obviously in the WPF case the UI will be managed, but it will call native functions by a C++/CLI proxy-like class
( will "bouncing" from managed-native and native-managed cause performance issues? ).
RAD Studio can also make the job
Enhanced in 2010! VCL (Visual
Component Library) for rapidly
building Microsoft Windows
applications now includes seamless
Windows 7 support, and graceful
fallback compatibility with Windows
Vista, XP, and 2000
Enhanced in 2010! Windows Vista and
Windows 7 API headers to fully
exploit the latest Windows
capabilities
New in 2010! Support for Windows 7
Direct2D API
you can also make WPF with Delphi Prism and wxWidgets with twinforms
If you are comfortable with your C++ skills, I recommend WTL. It is very lightweight and results in lean machine code. The Windows version of Google Chrome was written with WTL.
To minimize development time and maximize performance I would definite go with Delphi 2010 (Rad Studio 2010). You get native execution, direct interfaces with Windows 7 Direct2D API, and arguably one of the best IDE/Development environments available on Windows 7. What else do you want?
Larry Drews
TheSoftwareRonin
You might consider using Qt, even for a Windows-only app, simply because the Qt C++ API is so nicely done. Qt supports OpenGL and can be used in conjunction with DirectX.
In WPF, you can actually use DirectX Shaders to apply effects on interface objects, (here's a CodeProject article detailing development aspects) and it is expected that the support for this will continue to grow, so I would choose WPF as a development platform. Furthermore, it focuses on creating attractive user interfaces with a reasonable amout of effort, and I think this is quite important in building a Graphics oriented aplication.
will "bouncing" from managed-native and native-managed cause performance issues?
definitely, but since you write just editor (not a game, in general) it's not a thing you should worry about
WPF applications rendered by DirectX subsystem as i know. so if you using only DirectX it will be a good choice.
I would personally use http://sourceforge.net/projects/win32-framework/ to create any Windows based applications in C++. Otherwise I would just use VB.Net or C# because you can easily port code between both and the form designer is very useful.
MFC :: Just say NO for any kind of project.
Win32 :: Well, I can not really recommend using it.
wxWidgets :: I have used it and seen no problem, good choice.
WPF :: I have not and never will use it as it is .Net bound.
FLTK :: Also look at http://fltk.org/, probably has better OpenGL support.
Be sure to check out WDL ("whittle") by the Cockos team (headed by Justin Frankel of Nullsoft/Winamp fame).
It's an extremely lightweight C++ library that includes "WDL Virtual Window system."
I personally haven't used it, but I can vouch for some great software that's been made with it. Extremely efficient and lightweight apps.
Link: WDL
I can't really comment on wxWidgets, but WPF is vastly superior to MFC and good old Win32 API. WPF uses DirectX for rendering and there are some 3D support in WPF. Unfortunately this support is still somewhat rudimentary and not the most performant. You can actually get better 3D performance if you host a Windows Forms control that renders OpenGL (at least we had to do that in a recent project I worked on). If you want to do 3D rendering in a WPF application you could have a look at the XNA Framework. The next version of the .NET framework will also include improvements to WPF and I'm sure there will be better support for 3D.
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.