VisualStudio with a basic Windows Forms application in C# should be one of the simplest ways.
The default look is not that bad for a business oriented application, and the drag-and-drop features are really simple to learn.
Java Swing with Netbeans graphical editor would be my second choice if you like Java better than C#.
EDIT: From personal experience, I found that styling the application beyond the default look, was simpler in Java Swing, using look-and-feel packages. For Windows Forms (maybe because my lack of experience) I had to do most elements as images in order to get the style I wanted.
WPF is superior to Windows Forms in many ways, particularly layout responsiveness. I would not recommend anyone entering the Windows Desktop scene to use this old paradigm of UI design springing from Win32 (or older). Moreover, since WPF uses XAML, learning it (as opposed to Windows Forms) better prepares one for other popular UI frameworks these days, including for Web and Mobile. Also, if only newer OS versions are of concern, consider using Universal Apps (UWP) instead of WPF. They are both very similar, but UWP is newer.
There is a much steeper learning curve for WPF, if all you are doing is a simple front end to a command line WinForms is a very easy way to get started.
Is this a scientifically supported assessment? I say this because I have heard it often, but in thinking about it, I cannot see this necessarily being true. WPF uses XAML, which is similar to HTML or other markup languages in structure. Sure, this is much different than the paradigm where you specify coordinates for all window elements (Win32, WinForms, et al.), but is it proven than a person having no background knowledge or experience in software would find markup-based layout more difficult than coordinate-based layout? Even if so, is the difference big enough to warrant telling all newcomers to use a coordinate-based layout, despite its inherent lack of responsiveness? Yes, XAML has many additional features, particularly in terms of effects, but these need not be used.
So they say, but that doesn't mean its support is about to end. If you look at how long MS supports technologies, you can be pretty sure it has plenty of usable life. Plus, UWP is practically the exact same thing from a design and coding perspective, so the knowledge is by no means lost.
I'm going to throw my vote in for the C#/UWP pairing. I am part of the prototype team where I work, and when I need to target Windows it's my weapon of choice. Sometimes I can't get access to something I need due to the sandboxing, so I'll drop back to WPF. I am familiar with forms, but I find that UWP/WPF's XAML is much easier once you get used to it. I would recommend against MVVM stuff if you're just prototyping or making small one-off apps, that is a time trap in those cases.
That being said, if you don't want to hit the more "Universal" part of the UWP and you just want to tie into shell commands/utilities, it's hard to beat Python with TKinter.
I'll also use Unity a lot (I was previously in games, and we do a lot of entertainment work). It's probably not what you like, but you'll be able to hit every non-embedded platform under the sun (including Windows and UWP, but also including Chrome, various TV's, &c). The UI system has improved a lot, and their (older) IMGUI implementation makes it super easy to wrap a UI around logic.
Finally, I'll add that (especially if I know that I'm building for a specific platform), it's hard to beat the native rendering APIs these days. They're all super easy (all being UWP/WPF, Android, iOS's UIKit, and macOS's AppKit), and will generally get out of your way. I've gone down the Xamarin route in the past, and it turned out to be overly difficult to build some simple apps (plus, I've had trouble deploying to Android in some instances).
UWP is definitely overkill if you go through the trouble of writing all the MVVM bindings as I mentioned. But, for really quick things, I can type XAML faster than I can try to align gui elements with a mouse. Then you get the same code-behind file to do your heavy lifting. The WYSIWYG editor is far worse though, I pretty much would only use it for a preview and only touch the layout via the XAML.
Disagree. As someone who has worked extensively with both WPF and WinForms, they're just different programming paradigms (XAML vs Forms Designer), but once you get up to speed on WPF, you can develop interfaces, even "quick and dirty" ones, just as fast if not faster than WinForms. What exactly about WPF is overkill?
Yes, in that it has been replaced by WPF and now UWP. That said, it is complete, stable, and mature. You know what you're getting with it. Going by what Microsoft recommends (e.g. whatever the latest they've put out is) isn't always a good idea. For example, early on the WPF days, there were loads of bugs in the framework. Even today, with WPF not being actively developed, it's filled with quirks and bugs that you just come to know about by working with it a lot. I'm sure UWP is in a similar state right now to early WPF, which is why I'll avoid it until it becomes more proven.
You could use Java with Avian, which is a small embeddable, statically linkable JVM. It uses LZMA and aggressive dead code elimination to make tiny binaries. If you use it with SWT you get native widgets too, and they have an example which does exactly that weighing in at only one megabyte:
Creating such a tight binary isn't entirely point and click, but if you want a tiny self contained executable and don't want to assume a pre-existing runtime like .NET then your options are really only VB6 (classic), Delphi or VC++ and all of them will involve a lot of arcane wizardry too.
Not "all" if you mean it literally. .NET came much later than Windows - maybe post-Win NT as well as post-Win 2K - others who know better can probably correct me or give a more precise date.
I remember meeting and talking with (or rather he did more of the talking) a senior Microsoft software engineer who was involved in the first .NET version, and he was telling me stuff about it. He may not have used the term .NET (can't remember), but I remember him saying that it used XML throughout (and also a lot of other stuff about its advantages). Very enthusiastic about it, he was. It was only some time later that I realized that what was now called .NET, was the same as what he had been referring to in his talk with me.
Also, Turbo Delphi Explorer (which was a stripped-down version of Delphi 6), came in two versions - the plain Win 32 version (non-.NET) and the .NET version. I remember, because I installed and used it some. Here's a blog post about a small utility I wrote with it (screenshot of the clock not there now, sorry):
Before .NET there was only Win 32, and before that, Win 16. (Worked some on both). Edit: Okay, there was and maybe still is WoW too (Windows on Windows), and even something called Win32s (or 16s) (IIRC, but I don't know or remember much about those).
I've had to install .NET many times. Maybe it's due to people using older windows versions when the software uses a newer .NET version that isn't pre-installed
Delphi does not really involve any "arcane wizardy" for basic applications - it really is drag/drop/code/compile/deploy a single .exe. Things only get a little more complicated once you "up the level of polish" to a commercial application that needs to deal with high-DPI and multiple image sizes, etc. But, that's a problem for any platform that uses raster images for toolbars, menus, etc.
I was a Delphi programmer for years: yes it makes self contained binaries. But at this point the VCL definitely counts as arcane wizardry unfortunately - it's hard to think of a more legacy technology except maybe COBOL. More's the pity.
Then you also know that the VCL is a wrapper around the Win32 API, which is still present in Windows 10 and used by every native Windows desktop application on the planet, including .Net applications. So, how exactly is it legacy technology ?
I think it gets harder to hire people with strong Win32 knowledge every year, and there were always far more apps written against Win32 directly than the VCL.
>Delphi does not really involve any "arcane wizardy" for basic applications
Agreed. Said as a guy who is not a GUI programming expert - just used VB's earlier versions in real life projects (but more as project manager than dev, on those VB projects), and VB and Delphi (both in multiple versions) and wxPython for some small personal GUI apps. Not had any problems with Delphi that can be called arcane. And Pascal is a pretty straightforward language, and Object Pascal just adds some (mainly OO and GUI and Windows API) stuff on top of that.
If you just want to make a simple Windows Forms application, I'd just use .NET (VB or C#). If you don't have Visual Studio, you can download the Express version for free.
or if you want cross platform apps - Use .NET too... Microsoft bought Xamarin and added iOS, Android, and Linux and Mac support to .Net and Visual Studio. It's all included free in VS 2015.
If you don't have Visual Studio, you can download the Express version for free.
Not any more, it seems. Now you get the Community editions, which work for free for about a month but then apparently require you to associate them with a Microsoft account and have strings attached.
4. DATA. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the product documentation. [...] Your use of the software operates as your consent to these practices.
Now, perhaps someone can find me the wording in any of the multiple directly and indirectly referenced privacy policies and other documentation that guarantees Microsoft won't upload and examine potentially sensitive data like my source code under those terms?
There is simply no way in which having to sign in to desktop software in order to do the same things you used to do without signing in is an improvement for the user. It is a security and privacy risk with absolutely no upside.
I'm not concerned with whether it was developed for that purpose.
I'm concerned with whether I'm potentially disclosing trade secrets, violating NDAs or other contractual provisions, or simply risking a leak of my big new idea if someone else's system has a security breach.
As I wrote before, requiring a log-in and open-ended telemetry for a traditional desktop app is a vulnerability with no benefit as far as the user is concerned.
The problem with .NET is that I don't really trust it. In the past I had experienced various bad behaviors when trying to install .NET applications with strange messages requiring me to install specific .NET framework versions. The more strange thing is that after I installed the .NET framework and the application it still didn't start but complained about windows sxs or something like that. I never understood what the problem was.
Also, how well would .NET apps developed with Visual Studio support older windows versions (i.e windows XP or vista) ?
I believe (and I hope that someone double checks me on this) that you can set which version of the .NET libraries you want to use during development in visual studio. If you use version 3.5, your application will be compatible with all versions of windows back to XP.
These days .NET 4.0 is probably a better target for maximising compatibility - Windows 8 and above don't come with .NET 3.5 installed by default, and a lot of Windows XP/Vista/7 machines will already have .NET 4.0 or newer installed thanks to Windows Update.
Can you limit support to Windows 10 only? If so, you should go with the Universal Windows Platform.
UWP has got the latest and greatest tools from Microsoft, and it's more coherent and pleasurable to use than any of the older options. You'll get a modern-feeling UI with much less effort.
If you need to target anything older though, getting the UCRT installed is the biggest pain! It can involve hot fixes and service packs for older OS's!! I spent money on a Microsoft support call to figure out why their installer couldn't get the UCRT installed on Win 2008 R2 and we never did figure it out. No thank you!
To add to this, if you are a web developer primarily you can also use JavaScript to create UWP apps that act like native. The documentation is very good and the toolset/libraries modern.
I would just like to echo my support for Electron. I think it's one of the most important development platforms out there.
Of course, the great thing about it is that you can use HTML5 to build native apps on Windows, Mac, and Linux. As unique selling propositions go, you can't get much better than that.
As a Web developer, I am going to be using it soon to build a few apps and I'm really looking forward to it.
I think it really depends on your skillset. If you're a node/JS person, you can easily make a desktop app with electron.
If you're purely targeting windows, and want this to be a 'traditional' desktop, then go with WPF. If you want this to be a 'store' app, you can use WPF or Javascript.
You can do all of this w/ VS Community edition, or if you're going the JS route, try VS Code!
We are using electron with nice results. It is great if you already have a stable of js devs and you need to do something with the file system and or network access. We basically have electron load in our basic tool and then have shims that can go to local dbs instead of making web calls so that users can patch in to their own data without having to open a bunch of ports on their internal networks.
We use Xojo (former RealBasic), it's quite good it compiles native apps on all major platforms. Language is quite easy to understand and pick up, the resources are big, articles, conferences, libraries, and video material: http://www.xojo.com/resources/ If you want to check out some apps made with Xojo, you need to go to this FB group https://www.facebook.com/groups/127238180792805/
General purpose apps -- actually, what I had in mind was rather simple, just one dialog window that would act as a GUI to a command line application (that already exists in the user's system). This would be mainly for people that can't use the command line.
However, to elaborate more, I'd like to add a couple of nice -to-haves (these are specific for me but I think that most of the following could generally be nice-to-haves for any application targeted to non-experienced users):
- The size of the resulting application shouldn't be proportionaly big. For that simple app I described I would expect a couple of MB (I think that's a problem with electron/nw.js apps)
- The user ideally shouldn't need to install anything else - everything should be contained in the application, so python based apps are probably not very good. Also, for the same reason I had some really bad experiences with applications that required a very specific version of .NET that would take half an hour to install on my system :(
- There shouldn't be any installation - ideally, just give the user a zip containing a .exe and maybe a couple of libraries (even better if these libs could be statically linked to the exe)
- The app should be able to access the full windows API - I want to be able to display file open dialog, write some configuration options to AppData etc
Before 15 years I know the answer to my needs was to just use VB (or C++ with MFC for those that knew it), before 10 years I guess Java with Swing (or AWT)... Probably even now these could also be used, however I was thinking if there are some other methods of developing desktop windows application I wasn't aware of.
Do you need to target versions earlier than Windows 10? If so, you'll have to rule out a Universal Windows Platform app (which might otherwise suit your needs, though you wouldn't be able to use it to write to AppData).
A Windows Presentation Foundation or Windows Forms app targeting .NET 4.0 will get you pretty good compatibility - Windows 8 and above come with it pre-installed* and it's an optional Windows Update for Windows XP/Vista/7. I don't think the XAML learning curve is as steep as some people claim, but it'll still be quicker to hack something together in WinForms over WPF if you haven't used the latter before.
Also check out the Desktop App Converter for Windows 10 - you can now package up a WPF/WinForms/Win32/etc. app into a UWP app for Windows 10 users and pick up some of the benefits that those apps have†.
Prob C++... At least that is the only thing that I believe will meet your requirements exactly.
I ended up (a few years back) going with WPF (Windows Presentation Foundation) in C# targeting .NET client profile. Of course you still need .NET, however, the client profile is a much smaller install than the full version and I have no problems going from .NET 4 to 4.5. No specific version is needed unless you want to use new features.
In regards to your needs here is a couple of reasons I like WPF:
-The entire GUI can be written in markup XAML (an XML based markup language) so its kind of web like. You can use the GUI if you like but doing it in XAML forces good design patterns and IMO is easier.
-"Click Once Deployment" allows you to publish the app build to a network share which can be run directly over the network (no local install). There are various options so if you choose to run locally you can. If you update your app, you simply publish again, and when the end users launches the app again it will be updated.
You can bundle dependencies so the first install would include the large (41MB) .NET client profile but after that it would just be the size of your app. This has worked well for me to allow users to install/update the apps over slow VPN connections.
For this situation I would recommend a "Windows Forms" app. You can include the framework/base class library bits you need in the distribution package if you think they won't already be available on the machine
There's also PyInstaller. I've tried it out a bit, to create standalone Windows EXEs from small Python apps - under 1K LOC, both command-line and GUI (the GUI ones were wxPython). Worked okay for me. ~10 MB EXE size. This is anecdotal though. Can't speak to how stable it is in general, or for bigger apps.
The only thing that fits the bill is C++ with the basic Win32 API that you're guaranteed ships with every version of Windows. But you'll still need to bundle the Microsoft VisualC++ runtime installer. To save yourself from writing raw Win32, I would suggest WxWidgets. You can link statically to the library and compile in only what you need, keeping size manageable.
Not sure about recommended, but I develop a few Windows desktop apps that run on special systems (think a PC that is connected to custom hardware). We use WPF, which is an improvement over WinForms, especially in terms of UI look and feel.
1) Solid, super-fast, single-pass compiler that produces native 32-bit/64-bit executables that can be deployed by copying them to the target machine (single, monolithic .exe with no external dependencies).
2) The language, Object Pascal, is statically-typed, easy to learn, supports procedural/OO/functional coding, and includes modern features like generics, RTTI, and class/record helpers. IOW, you aren't forced to code everything in a class, if you don't want to. The string support, especially the Unicode string support, is also very good.
3) The Visual Component Library (VCL) is still pretty good for creating Windows desktop applications (native, not universal "apps"), and you can skin your application for a different look and feel. Database access is also top-notch, and you have access to a pretty large set of 3rd party components that can be installed into the IDE as first-class residents of the IDE.
4) Development productivity is very high in the IDE, with a WYSIWYG form designer and two-way tools for coding the UI (what you do in the designer is reflected in the code-behind, and vice-versa).
Cons:
1) The price is high, but they're starting to fix that with more special offers and will, hopefully, continue to move the price down.
2) Partly the cause of 1), the product has been mismanaged over the years and its developer base has dwindled accordingly. This was also partly due to the fact that C# grabbed a lot of their market share (as well as the original developers of the product, including Anders Hejlsberg, the architect).
3) The RTL and component library (VCL) need pruning a bit. They've got a lot of legacy code in there due to an almost-maniacal focus on backwards-compatibility.
4) The IDE is a bit schizophrenic and needs to be updated, but it does include just about everything you would need in terms of real-time coding with error highlighting, code-completion, formatting, Git/SubVersion integration, etc.
5) Memory management is deterministic, which makes it very fast, but does require a Create/Free cycle for class instances. An ownership model helps to alleviate this for GUI applications (forms "own" the component class instances that are placed on them). Also, strings and dynamic arrays are reference-counted and managed for you, and you can wrap class instances in interfaces that will allow you to use class instances in a reference-counted manner, also.
In summary, if you simply need something to create desktop applications for Windows now, especially for vertical market software that will be deployed on a lot of machines, then Delphi is a good solution and can be a technical advantage for your company if you know how to use it well. If you're looking for something that you can use to further your job prospects, then it might not be the best solution for you, and you might be better going with .NET/C#. But, be forewarned that application deployment can still be problematic with .NET - the developer edition of SQL Server 2014 refused to install on my development machine this week because the SQL Server .NET-based installer could not cope with something in the .NET installation on my machine.
Might be wrong, but anyone else found that the site seems to be only available in the German version (/de/ in the URL) as of now? Tried a few different things, but not getting the English version. Seems to either redirect back to .de site or give a 404 error. Both changing the URL to sensible values (/en/ or nothing instead of /de/) and selecting English from the drop-down at top right, did not work.
Another possibility: could be it's a region-wise rollout? But would have expected .en first, unless the latest acquirer of the product line is German. (Seem to remember reading recently that it got sold again.)
Sorry, I did not notice that the site is in German. This is the "Shop" site. I think you can open the front page of embarcadero.com and manually navigate to it, or use the link TimJYoung provided.
> with a WYSIWYG form designer and two-way tools for coding the UI (what you do in the designer is reflected in the code-behind, and vice-versa)
IMO, that is one of Delphi's best features, and it had it had right from v1 or at least v2, IIRC. (Used both versions a bit.) The two-way tools, I mean - because over time, it helps you to rely less on the designer (if you wish), for things like writing code for properties and event handlers, and anyway you still have it as a fallback.
Of course it has many other great features too, as your comment describes very well (and it's good to mention the cons too).
Wow I remember Delphi from the past (I had never used it but always heard nice things about it), I didn't know that it was still supported!
What you write about the statically linked exe, the native look-n-feel and the WYSIWYG form editor are really killer features! I'm not so much into pascal though (15 years since I'd written anything in Pascal) and, unfortunately the price rating is a blocker for me (as I just want to create a GUI for a command line app to help non-expert users use it) :/
You might be interested in https://github.com/koush/electron-chrome - as the developer stated he was polyfilling all the chrome.* APIs and replicating the Chrome App environment in Electron and was open sourcing it in case anyone else wants to keep running Chrome apps.
The default look is not that bad for a business oriented application, and the drag-and-drop features are really simple to learn.
Java Swing with Netbeans graphical editor would be my second choice if you like Java better than C#.
EDIT: From personal experience, I found that styling the application beyond the default look, was simpler in Java Swing, using look-and-feel packages. For Windows Forms (maybe because my lack of experience) I had to do most elements as images in order to get the style I wanted.