Related
As SO returns "4,476 search results for posts containing "win32 gui applications""... I'll have to ask a question that has probably been asked before but is lost in the midst of all those questions.
Currently, what are the options to write GUI applications for Win32, that have a big-enough following so that the environment offers enough and well-supported third-party tools?
I could come up with:
C++
Delphi, and possibly
RealBasic (although the fact that it's originally a Macintosh tool could result in small but noticeable issues in look 'n feel).
Besides their relative lack of well-supported third-party tools, solutions like Python + wxWidgets, or [Power|Pure|Free]Basic aren't good options: The former has too many 1.0 widgets (couldn't find a business-grade grid, for instance), and the latter are procedural languages so requires writing apps like Petzold's book with the lower productivity it entails.
Are there other solutions available?
Thank you.
Edit: Sorry for not having been precise enough: Big tools like .Net and Java are not options. I'm looking for tools that can either build a whole EXE statically (eg. Delphi) or provide a light enough runtime (VBClassic).
If you are new to programming I would suggest C# as well if you are only looking to make this app for the Windows Platform however with tools like Mono it can be ported to OS X and Linux Platforms.
Windows has their own IDE just for this called Visual Studio Express C#
Visual Studio's C#
As well as a version for C++ if you are wanting to say in that programming language.
The Mono project allows you to use C# in Linux and Mac as well as port the apps to iOS and Android
http://www.mono-project.com/Main_Page
You Can use C++ or You can even use the .net framework to develop your windows applications. .Net framework have lots of opensource contributed modules and paid modules and well as number of resources all over the internet to speed up the development compare to other options you have mentioned.
If you are going for a windows 32 gui application, I would prefer to go with .net framework, C++.
Java Swings also another best options which is platform independent as well.
You can use Lazarus as a free alternative to Delphi. Potentially you will have a very high possibility to check its "write once, compile anywhere" motto if you later decide to port your Win32 application to Linux or MacOS. In ideal case it will just work, but in reality you would probably need some conditional defines sections.
I would like to build a graphical application that must work on at least Windows, Linux and MacOS. I would like to know what do you suggest I should use.
I have some experience with Java and C++ but I thought about using Java Swing first. What do you think or further suggest (like maybe tools or frameworks)? I also may be needing to connect to a PostgreSQL database to store data.
Java is probably the simplest way to get your application working on all 3 platforms as well as to add database support. All of these are equally possible in C++, but it definitely involves more work because you need to learn to use a cross-platform widget toolkit. Also, C++ database drivers usually have wildly varying designs but Java presents a unified interface via JDBC - this also means that you can change your underlying DB at any time without having to change your code.
I would use the Qt platform from Nokia. It supports all the OSes that you've mentioned and has also database connectors for PostgreSQL but also for MySQL, SQLite, etc.
It also has a very nice IDE, the QT Creator that you can use should you pick Qt.
I would suggest Qt too. Qt has seen very good development recently, their examples and documentation base is quite large, and the LGPL license is flexible too, for creating proprietary software. It has a good Qt Creator IDE, a Qt GUI Designer. Plus is has quite a number of modules, enabling it to be used in conjunction with other language developed apps/libraries. And, it is used in commercial/public apps like Google Earth, Skype (maybe only the linux version). So, it has a good history of reliability. And yeah, for Database, it has modules, like Qt-Sql. Another advantage you get over java is speed.
wxWidgets does cross-platform easily enough, using available native toolkits. You could probably use a ORM for the database part, but I don't have enough experience using them under C++ to provide an actual informed opinion there.
GTK is cross-platform. Pidgin uses it and manages to get away with being generally considered a fully-cross-platform app. The installer size is a problem, though.
I am attempting to write a cross-platform GUI application that would be deployed to Windows, Mac OS X, and Linux. My requirements are:
Single code base for all three deployment platforms, without a large amount of conditional logic for handling differences between platforms.
Looks as close to "native" as possible on all three platforms.
Easily distributable to all three platforms, in the sense that it could be easily installed by end users and does not suffer from extreme bloat (as discussed in this ArsTechnica article.)
Based on these requirements, I've narrowed down the selection of toolkits to Qt and wxWidgets, since none of the other toolkits that I know about (including Java's Swing and SWT, Flex, AIR, etc.) satisfy the "native-looking" requirement. Among these two final contenders, Qt appears to offer better support for applications that look and feel native on all three of my deployment platforms, but I'm willing to consider opinions to the contrary.
I would prefer not to use C++ as the implementation language, but I'm not sure if there are any practical alternatives. My biggest concern about using an implementation language other than C++ is the deployment problem. As discussed in the Ars Technica article, PyQt does not meet the "easy deployment' requirement in any practical sense, and I suspect that most other language bindings for Qt would suffer from the same deployment problems (at least on Mac OS X). Java (or Scala) with QtJambi? QtRuby? wxPython?
Does anyone know of any combination of language and toolkit that satisfies all three of the above requirements?
It depends on your needs. But in general Qt Framework (with any language) and Java SE (with any language) is much more better because it has not only cross-OS GUI libraries but also cross-OS networking, threads, ... wxWidgets is GUI only.
Both Qt and wxWidgets are nice. In my experience Qt is better. Swing is... Well, not so nice.
Both Qt and wxWidgets applications written in C++ and Java Swing applications are not so hard to deploy on Windows, Mac and Linux. The rule is that the deployment is simple when you are programming in "native" language. By "native" language I mean the language a framework itself is written in.
PyQt does not meet the "easy deployment' requirement in any practical sense...
Python (and any other language with the default implementation as interpreter) apps is hard to deploy in the usual sense (I mean in form of standalone executables).
So probably you have 2 choices:
C++/Qt or C++/wxWidgets.
Java/Swing if native look & feel is not very strict requirement.
wxWidgets is quite good, and does contain some non-GUI code (contrary to what kemiisto said): threads, sockets etc.
The nice thing about wxWidgets is that wxPython actually should be pretty easy to deploy on OS X. There are some other language bindings for wx, but wxPython is probably one of the oldest ones.
At my day job I've been developing cross-platform (Windows / MacOS / Linux) using perl and wxWidgets. The combination is pleasant to use for development (I'm a perl hacker) and I rarely have to include specialized code per platform. There are some perl modules that help out with this (e.g. File::HomeDir that knows about the canonical locations for document directories etc on the various platforms).
For release, I don't rely at all on the system perl installation and instead build a perl installation that is included in the release. This way I can completely control the runtime environment of the app. I ship a windows installer package via innosetup, an mac os .dmg file with a .app included that the user can just drag to their /Applications, and for linux I build debian and redhat packages.
Have you looked at Xojo? It definitely meets all three of your requirements and it is much simpler to learn and use than C++.
About a decade ago or so, it was fashionable to model a GUI in a cross-platform flavor of XML (like XUL) and then have a platform-specific rendering engine process that XML-file to display a layout. It is no longer fashionable to do this, however. Today, in 2017, the trend is to build your apps on platforms that allow you to write everything in HTML, CSS and/or JavaScript, no matter what environment your code is supposed to run in.
The "first generation" of this type of tools produced what are basically "hybrid" applications, where web applications run on top of browser-like & platform-specific WebViews. This technique is rather inefficient, however. Your apps don't feel very "native", are rather bloated and they tend to be rather lacking in performance. However, it's relatively easy to have a consistent look-and-feel in different environments. Phonegap / Cordova is the most popular platform for mobile environments and NW.js for desktop environments.
The "second generation" is different : they compile everything to fully "native", platform-specific binaries. Instead of relying on WebViews, "native" widgets are used when possible. This gives your app a more "native" look-and-feel, typically has less bloat and is much better for performance. However, you'll have more differences between the different platforms. Examples are NativeScript, React Native & Tabris.js (all for mobile environments).
Unfortunately, there are no "second generation" tools for desktop just yet. So, right now, if you want to build a cross-platform desktop app, you're stuck with "first generation" tools. NW.js has a longer track record than Electron and has support for various features not present in Electron, but it also comes with its drawbacks. AppJS is still older, but it's not as mature - and not nearly as popular - as the other two.
Anyway, their reliance on WebViews means that your application will feel more like a web app than a desktop app. And bloat and performance drawbacks are inevitable with this kind of solution. This means you'll never get the same performance as code you write directly in Java or C++ nor the same performance you'd get in "second generation" platforms, and it will never feel equally "native". However, it can still be the best solution eg. when a consistent look-and-feel across different platforms is more important or when you have a background as a web developer.
If performance, lack of bloat and your application getting that "native" feel are important criteria, you might want to wait a little longer until the first "second generation" platforms appear for desktop. It's really but a matter of time before platforms for desktop apps follow the same evolutionary path as platforms for mobile apps, although it might actually come in the form of "desktop extensions" to existing mobile platforms.
The way it's currently looking, it looks like you'll soon be able to write "native" apps for desktop & mobile alike with the exact same codebase. With React Native already having plugins that add support for Windows 10 and support for MacOS, I would personally go with React Native and give their dev team some time until they support all desktop environments I need to support and those extensions for desktop are mature enough for production environments.
If you can't wait that long, you don't want to bet on what's to come in the future or if these criteria aren't that important for whatever application you want to build today, you might want to try some of the "first generation" platforms currently available and see which is most suitable for you. Just be aware of the drawbacks!
As always, choose wisely...
Popular platforms
First generation platforms for mobile environments (iOS & Android)
Meteor (built on top of Cordova)
Ionic (built on top of Cordova)
Second generation platforms for mobile environments (iOS & Android)
NativeScript (AngularJS eco-system).
React Native (React eco-system)
Tabris.js
Platforms for desktop environments (Windows, Linux or MacOS)
Electron
NW.js
AppJS
Platforms for smart home and IoT devices
iViewer
Iridium mobile
.Net (C# or VB.Net) is what I would use for this (in fact, it is what I use for my own application). Thanks to the Mono project, .Net applications can run on Mac and Linux as well as Windows without any modifications to the code (unless you're calling Windows API functions). You don't even have to compile different versions of your program: the same EXE will run on all platforms.
Java/SWT is one of the good choices. You can find a lot of information about it here.
Java does support "native-looking" applications by using the SystemLookAndFeel. The quickest way to try is to invoke the following at application start up.
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
Take a look at this for more information on the available Look and Feels in Java.
http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html
I'm trying/thinking of making CppCMS - C++ Web Framework project little bit more cross platform.
Today I can easily support Linux, OpenSolaris, FreeBSD and even Cygwin. But when it comes to Native Windows it becomes really painful:
The overview of the situation:
I'm POSIX/Linux developer and I'm barely familiar with Native Windows development tools like Visual Studio and Win32 API. However I do some work for this platform so I understand the limitations and the fact that Windows is totally different world.
This is web project that uses APIs that popular in Unix world, like: CGI, FastCGI and SCGI that implemented in most UNIX web servers; but I understand that I would not be able to use it with IIS because it does not support FastCGI over TCP/IP (only Windows pipes).
So even when it would work it would probably run only with Windows port of Apache.
I relay heavily on POSIX API:
Pref-forking allows be keep high survivability in case of crashing (not supported under windows) so this feature would be missing.
I use some file-locking facilities (but I can probably give them up without forking)
I have intensive use of native pthreads, even I can replace them with Boost.Thread
I probably would never be able to support Visual Studio (maybe 2010 with C++0x support), because I relay on C++0x decltype/auto feature or typeof/__typeof__ extension that is supported by most compilers I worked with: gcc, intel, sun studio. (To be honest: I can work without them but it makes the life much easier to framework user.
I relay heavily on autotools and I can't replace them with CMake, bjam or friends, because when it comes to support of internationalization, cross copiling, package management, they just does not give me a solution.
There are many annoying points like missing gmtime_r, or localtime_r under windows and many others that just require from me to rewrite them or replace them with 3rd part libraries.
There are still many "UNIX like" libraries that ported to Win32 like: iconv, gcrypt and some others that are barely ported like libdbi that have many limitations on windows.
Bottom line:
There is lots of non-trivial work to do, and even when it would be complete, it would probably work only with MingW tools and not "native" tools that Windows programmers are
familiar with.
So, my questions are:
Does such MingW port worth an effort? Would this help to build bigger community?
Does anybody have experience on how painful porting big projects from POSIX environment to
Win32 API is?
Would it be useful for Windows developers at all?
Edit:
It is also important for me to understand, how many of windows developers prefer to use
Open source development tools, MingW over Microsoft development solutions like VS.
Edit #2: Clearification about "native" windows solusions and IIS.
In fact, running framework with IIS is really hard problem. I explain:
The project relates to standard web server API as FastCGI or SCGI that allows to accept many requests over sinlge socket. Thus, on application side, I accept new request proceed it and returns the answer. Sometimes several threads process several requests.
Thus, implementing one or two standard protocols I open communication with any existing server: Apache, lighttpd, nginx, cherokee... or any other servers; with small exception of IIS
IIS has implementation of FastCGI, but... It supports only 1 connection per local process only that controlled by web server...
So... there is absolutely no standard way to connect my application to IIS.
Please note, I implement standard Web server API, I do not implement Neither IIS proprietary ISAPI nor Apache proprietary API, even the second is more important as for targeting UNIX world.
So, just Windows IIS Web world is just not really ready for cooperation for such project, so if anybody would use it under Windows it would use it with more open web servers.
You should base your decision on user demand. Have users ever requested using the framework on Windows? If so, did they explain why they wanted to use Windows (e.g. what additional constraints they had, what webserver they wanted to use, etc.)?
Typically, Windows users do expect that things work the Windows way. That means Visual Studio support, IIS support, MSI installer, and so on. If something still feels like being Unix, I would rather use Unix proper, instead of fighting with a half-working port.
As a windows client app developer it sort of hurts me that the development environment division currently is essentially Win32 and everything else and that they are mostly incompatible. That's why I'm preparing to move to MinGW for my personal windows app projects and to try to make them cross-platform.
I would suggest gradually moving to more cross-platform libraries like, as you suggested, refactoring pthreads to boost::thread, or going from fork() to multi-process with IPC, probably also using boost's facilities. Date/time stuff can be dealt with Boost libs as well. As for database support, there are
Microsoft compiler support is not that important I think, as MinGW provides a decent build environment with all the IDEs that support it, Eclipse CDT and Dev-C++ being among the most popular. But if you are going to make your project msvc-compatible, make sure users will be able to use Express editions of Visual Studio 2010 (as soon as thay come out) - that way no one will have to fork out for a Visual Studio 2010 (upgrade) just to use your project and there will be no problem for you to require the latest in Microsoft technology.
Most likely you won't avoid some amount of ifdefs for a code base of your project's size, but surely the effort might be worth it, if not only for gaining valuable experience and expanding the community with a few new happy and grateful members.
Your saying that you can support Cygwin quite easily reminds me that I've seen commercial Windows software that simply bundled in cygwin1.dll to support some originally-Unix code. If adding cygwin1.dll to your installer is all it takes, try it out.
I think you only have to look at the questions asked on SO to work out that MinGW users on Windows (of which I am one) are in a minority in the development community - the vast majority of Windows developers are using MS tools. Anyway, the compiler is only half (or less) of the issue - if your architecture depends on forking lots of processes, using MinGW is not going to help you. My advice is, if you really want to do cross platform development:
look at how Apache do it
consider using the Apache libraries as your base
don't use very new or compiler-specific language features
use multi-threading rather than multi-process
Does such MingW port worth an effort? Would this help to build bigger community?
I am still working myself on this issue with my own large POSIX project and my conclusion is that if you need to later interface with Microsoft products, then its worth while, however then I would only use MingW if project is medium small, if it is very large, then I would go all the way with MSDN Microsoft development tools - Huge amount of help will be available there - however it will cost
Does anybody have experience on how painful porting big projects from POSIX environment to Win32 API is?
sofar my own conversion of my POSIX project have been constantly put on hold, because of the amount of time each issue takes to handle is enormous - not finished converting yet - If I ever will be
Would it be useful for Windows developers at all?
Sure working inside the Microsoft IDE using tools from MSDN will definately decrease development time, however it will increase your dependence on Microsoft libraries - something you need to decide from beginning if that is an issue
**
Actually you could just add the necessary cygwin dlls to your projects make and then you would beable to run it in windows
I managed to make my POSIX project run when I added following dlls
cygboost_filesystem.dll
cygboost_system-mt-1_53.dll
cygboost_thread.dll
cyggcc_s-1.dll
cygstdc++-6.dll
cygwin1.dll
Probably your project will have different dependencies, however if you think conversion is not worth it, then perhaps this is a solution for you
You could also add your libs as static, then you would end up with only having to provide the last cygwin1.dll
Have a quick project I need to put together for windows that can have no external references or dependencies; the stalwarts like C are obvious but if you are a .NET developer and need to build something like this very quick what language/tool would you use?
EDIT: Ultimately I want to be able to take JUST the exe produced by the compiler and put it alone on a windows machine and have the app run.
If you're a .net developer, you could consider something like using Remotesoft's Salamander or another similar tool that compiles everything into a single executable (including the framework).
This option lets you develop in .net, but not install the .net framework on your client's systems. If you're deploying on non-MS systems, you can use the Mono's deployment tools to accomplish the same thing for free.
In general, I'd say stick to the tools and languages you know. It's easier to build an installer to install the .net framework then it is to learn a new suite of tools, libraries, etc.
You can do it for practically any language (I'm excluding the obvious C/C++)
You can bundle the .NET runtime into your .exe and write the app in C#
You can write the app in Python and bundle everything into a single .exe using a tool like py2exe. I do this regularly. One can create great-looking and powerful applications with Python and PyQt, bundle everything into a single no-dependencies executable and deploy to users w/o a need to install anything else. The executable is a few MB large (~9 with PyQt), and loads and runs quickly.
Etc.
It's more important which language / environment do you currently know well. Focus on that, because the tools do exist for anything you'd want to use.
Delphi has always been the best product for producing stand-alone .EXEs for Windows. No Microsoft product has ever come near it in that regard.
I think a good allround answer to this is Free Pascal via the Lazarus IDE.
Free Pascal applications are native and dependency-free, and a lot of platforms are supported. Too many to list here! Free Pascal itself is a free and open source compiler.
For better convenience, I strongly recommend using the Lazarus IDE. Now you even get a RAD IDE for cross-platform GUI applications (as well as console), with a sizable set of builtin features, like database support. Really a pretty lovely all-in-one, often underestimated or even unknown, platform that produces self contained, native executables. There aren't all too many of those tools if you think about it. You can even cross-compile from it, for example to compile a GUI application for Linux on Windows, no virtual machines necessary.
One day, I wish .NET Native could get this far, but it is currently far from capable and I'm not sure if Microsoft even intends to go there. Google's Go language is also nice in that it compiles to native cross-platform code, but lacks a GUI library. Python can have its code packaged into executables but it's kind of a kludge and not native code. And so on...
C/C++ would be your language but don't use any fancy libraries like MFC, MSVCRT, etc. or if you do link them statically to your executable.
"No external references" is a bit vague. Are you talking about a deployment solution for an application?
For example, you can use Tcl which supports the ability to create a single file executable that contains both the application code and a virtual filesystem that can contain any other files needed by the application. If your goal is to create a single file that can be deployed without having to install extra files, read up about "starkits" and "starpacks".
If you target a Windows Vista .NET 3.0 is preinstalled,
If you target a Windows 7 .NET 3.5 is preinstalled, if you use no other libraries than the ones included in those distributions then you app will run. Installing .NET isn't really that much work anyway, just ship with the redistributable.
Assembler. Your only dependency is the CPU
Here's a left field answer...
Tcl
combined with starkits, you can create a simple double-clickable .exe with no need for an installer.
the downside, of course, is that it'll be written in tcl.
As an added bonus, you'll be able to port your app trivially to mac or linux (or a range of other odd operating systems)
Do you consider the .NET Framework "external"? If you stick to .NET Framework and use C#, your code should run anywhere the .NET Framework of appropriate version is installed, and you'll only need to deploy your .exe and .exe.config.
It is not possible to run a .NET program without the .NET Framework. If you can't require the .NET Framework to already be installed, then you cannot use a .NET program. That's what I meant.
I've no clue what the downvotes are about, but let me try once more to clarify. The original post said:
the stalwarts like C are obvious but
if you are a .NET developer and need
to build something like this very
quick what language/tool would you
use?
The answer is that if you are a .NET developer, there is no tool or language you can use for this purpose, as every .NET program requires the .NET Framework be installed. If you need a program that is entirely independant, then don't use .NET. As others have replied, you can bundle .NET into your exe. You can also have .NET installed with your application, if you're willing to ship a .MSI file and not just your exe.
But, by definition, a .NET program cannot be independent of the .NET Framework.