Framework for Windows? App development

[AdrianS]

I'm not sure exactly where this belongs...

We make workshop machines (dynamometers), which are controlled by a PC / Laptop.
The machines themselves have a lifetime of 20+ years (and yes there are 30 year old dynos in daily use).

The GUI has to talk to hardware (currently via USB) with relatively low latency (~100 ms).

We currently use Windows, and will probably stick with Windows because
a) We don't have to support the OS.
b) Accessories like printers are a commodity item that we don't have to support.
c) We / our customers can get PC's preloaded and warrantied anywhere in the world.

All our recent code is C#, but that's not a hard requirement.

A browser-based app is a possibility, but needs access to the hardware we're controlling.

Given those constraints, what would people suggest for a UI framework for the next generation?

 

[Ardax]

First, consider whether or not the thing that actually needs to communicate with the hardware with such low latency is the UI or a service that's acting as an intermediary between the UI and the hardware. That rather blows open the frontend options too.

 

[ShuggyCoUk]

What Ardax said, but even stronger.

Absolutely write the hardware communication layer in a really simple (no guis no nothing) library on a toolchain with lots of support. make it have C ABI bindings available to talk to anything else that can consume them (which is basically everything now).

Do whatever GUI you want on top of that.

Given the latency restrictions I would not write the comms library using a managed language, too easy to have spooky action at a distance from GC related pauses if you need low latency (I honed my ability to avoid this for literally years and it's still hard).

C++, C, Rust, Zig all options for the library. in rough order of likely stability for you and ease of getting programmers knowing them. Look at what libraries exist for them for talking USB on windows (hopefully the libraries can abstract this for linux as well, that should be viewed as a potential big win then you don't have to care about the OS at all I would suspect) I suggest looking at libusb which has wrappers in rust

There's a guide for using it on windows:

Please refer to the following Wiki page:
https://github.com/libusb/libusb/wiki/Windows#How_to_use_libusb_on_Windows

Basically you will need to install a supported driver.

• If your device is a generic HID device, no extra driver is needed since it is supported. But HIDAPI is recommended for HID device rather than libusb on Windows.
• If your device uses WinUSB driver, no extra driver is needed since it is supported natively.
• If your device uses libusbK driver, you should be set as well (libusbK.dll should have been installed).
• If your device uses libusb-win32 (libusb0.sys) device driver, please try it to see if it works well. If not, try to switch to libusbK driver.
• If your device uses libusb-win32 filter driver, please switch to device driver mode. If you really need to use a filter driver, please uninstall the libusb-win32 filter driver and try usbdk instead.
• If your device uses other driver, and you do want to keep using the existing driver, then try usbdk.
• If your device uses other driver and you are okay with switching drivers, then switch to WinUSB (preferred) or libusbK driver.

Personally for greenfield I'd strongly suggest Rust. This gets you a really good build/dependency system (cargo) off the bat and avoids a lot of mistakes, at the cost of learning rust/taking a dependency on it. I suspect it's worth it but YMMV.

 

[hanser]

I guess I don't view 100ms as low latency? Our backend API SLAs are half that, and there's a lot of going over the wire to search and other data storage capabilities, and we rarely exceed 15ms.

So I guess I have questions.

• What happens if you blow your latency budget? What are the consequences?
• Can you queue up a series of actions? Like... are you just taking readings, or are you sending signals to the device being measured?
• How much data is coming over USB? Bytes? Kilobytes? Megabytes?

I'm just generally leery of unnecessary complexity, and splitting something into frontend vs backend introduces IPC complexity when it might not be warranted.

There may also be advantages to using a managed language + runtime beyond latency. Like... that C# app is going to work with the CLR ten years from now, most likely. Is the compiled Rust binary?

 

[ShuggyCoUk]

The compiled rust binary will work lots longer I would think. Very low churn on those things.
You're right about the additional complexity though, if you can get a prototype working with a c# wrapper on libusb do that first. I still wouldn't directly try to use USB from managed code though

 

[koala]

Which lifetime do you expect out of the application? Because if it's inline with the 20 years hardware lifetime...

20 years ago was 2004; RHEL 4 is 2005. Windows Server 2003 R2 was 2005 too. Just trying to build something that runs those would be a pain, unless you're superdilligent at keeping images and ensuring your virtualization platform supports those well.

Frameworks are difficult too, in 2004 we had GTK 2.6 (two major versions behind current GTK4) and QT3.3 (QT6 nowadays). Windows would likely be better- you can still run software much older than 2004, but good luck finding people willing to work on stuff 20 years old.

I actually think fully compiled binaries will stand better the test of time than runtimes. 2004 had J2SE 5.0, NET 1.0, Python 2.4. I know that developing for Python 2.4 these days would be massively painful, but certainly Python is clearly worse than Java and .NET for backwards compatibility, but I'd be curious to see if you can pick a J2SE 5.0 JAR and run it correctly today (likely anything Swing is going to be a problem. Perhaps AWT will work well?)

 

[AdrianS]

I don't regard the 100 ms latency as hard real-time. The real-time control loop is done in the external hardware.

The latency limit is for the operator feedback - time see a fuelling error, overspeed, etc. and react to it.
If I've done my job right, the external hardware will fail-safe if the operator does nothing, but their $50,000 competition engine may not survive.

We are using C# services communicating via named pipes or sockets as the bridge to the hardware, and I'm happy to keep using that architecture- it's fast enough, C# will be around for a while, and we can replace that layer later if need be.

It's the UI that needs replacing - it currently uses LabWindows CVI, which appears to now be dead: last major version was 2020.

MS appears to have no consistent vision for desktop UI since WPF, and no-one knows where they are going - WPF / WinUI / revamped WinForms / MUI - it's a mess.

The problem is that we are not a software company, but a manufacturer of engineering equipment, and the development budget reflects that.
We sell a few hundred of these machines a year, and even if the software was fantastically better than it is now, we'd still be selling in the hundreds, not thousands.

My current leaning is towards something browser based, but my experience in that area is 20 years out of date. Being browser based also gives us a future path away from Windows.

I'm interested in Rust for the firmware side, but it doesn't really solve the UI issue, which is more about the framework than the language.

 

[AdrianS]

As regards software lifetime, I'd expect at least 10 years from the framework before having to switch again - we've been on the current platform (LabWindows CVI) for something like 20 years.

The software started as a DOS app I re-wrote in the early 1990's; I've left and rejoined the company three times in the intervening 30 years .

 

[koala]

My current leaning is towards something browser based, but my experience in that area is 20 years out of date. Being browser based also gives us a future path away from Windows.

VV

Absolutely write the hardware communication layer in a really simple (no guis no nothing) library on a toolchain with lots of support. make it have C ABI bindings available to talk to anything else that can consume them (which is basically everything now).

Do whatever GUI you want on top of that.

That's the thing- if you expose the stuff in a simple API (I'm not sure what will work best here- C bindings surely are universal, but if you can expose an HTTP API or something, that is also something that is usable from most languages easily, and extremely long-lived).

If you can build today an UI based on an API (whether based in a library, or some network protocol), then tomorrow you should be able to switch out the UI. If it's a network protocol, that might allow you to run the UI on a separate host- which might be something desirable or undesirable depending on your situation.

...

Lots of people build Electron apps nowadays. They are very much hated by users, but it's understandable why people pick it; it is a fairly sophisticated platform which is perfectly portable across Linux, macOS, and Linux. You can also turn an Electron app into a web app that you access through a browser.

 

[Ardax]

From a UI standpoint, since you already have C# expertise in house, WPF or WinUI should stick around for quite a while. As schizophrenic as MS is with UI toolkits, it does tend to let them be zombies for quite a while before actually ending support for them.

Avalonia is another very popular option for .NET developers, but it's a 3rd party library.

Hell, WinForms is still supported on .NET 8 and will almost certainly be around in another decade.

 

[cerberusTI]

I don't regard the 100 ms latency as hard real-time. The real-time control loop is done in the external hardware.

The latency limit is for the operator feedback - time see a fuelling error, overspeed, etc. and react to it.
If I've done my job right, the external hardware will fail-safe if the operator does nothing, but their $50,000 competition engine may not survive.

We are using C# services communicating via named pipes or sockets as the bridge to the hardware, and I'm happy to keep using that architecture- it's fast enough, C# will be around for a while, and we can replace that layer later if need be.

It's the UI that needs replacing - it currently uses LabWindows CVI, which appears to now be dead: last major version was 2020.

MS appears to have no consistent vision for desktop UI since WPF, and no-one knows where they are going - WPF / WinUI / revamped WinForms / MUI - it's a mess.

The problem is that we are not a software company, but a manufacturer of engineering equipment, and the development budget reflects that.
We sell a few hundred of these machines a year, and even if the software was fantastically better than it is now, we'd still be selling in the hundreds, not thousands.

My current leaning is towards something browser based, but my experience in that area is 20 years out of date. Being browser based also gives us a future path away from Windows.

I'm interested in Rust for the firmware side, but it doesn't really solve the UI issue, which is more about the framework than the language.

If you want a long term platform, I like C for anything where you care how it is done, and a JS application running in a browser for the UI. JSON is dead easy to implement in C, so just pass JSON messages.

JS and the HTML DOM are well standardized with a few excellent implementations, so that is a very easy and portable client. Its position means you can expect very long term support and good compatibility with existing code in the future.

ISO standard C can be written such that changing operating systems is not an overwhelming task, is a very stable language in terms of not changing often or without very good reason, and as the language operating system kernels are mostly written in it tends to have excellent support which is expected to continue for the very long term. MS is probably committed enough to C# that you could put together a service which reads USB data and works as a web service and expect it to survive long term if being tied to Windows is fine.

Most UI frameworks and even higher level OS UI libraries tend to have a lot of churn, as do languages which are not standardized. If you want decades of use, you want strong standards on everything you use. I require a standard by one of the big organizations (preferably ISO), and at least two separate and task suitable implementations by different vendors for long term code. That is easier to get away with at a software company.

If you are rewriting your UI, I would consider making the browser your UI client though. It is usually very convenient in a number of ways, and is effectively a UI framework with a strong standard behind it.

 

[AdrianS]

As I said earlier, I am leaning towards a browser-based solution. That still leaves the framework question hanging, as we're not going to code raw HTML, so would need to leverage some sort of UI builder.

I still have a fair bit of research to do, and then get management buy-in.

It's a hard task to sell "We need to spend [x] programmer-years to replicate what we already have in a new framework".

 

[koala]

It really depends on the UI you want to build. Actually, raw HTML is pretty decent. If you don't need realtime/very interactive/complex widgets, plain HTML can work SUPER well.

Even the people using fancy JS frameworks, I think rarely anyone is using any UI builder.

Maybe there's something worrying you about that?

(Raw HTML can do "ugly forms", but quite usable and fast. Adding something like even "obsolete" Bootstrap can allow you to make something decent looking, and reasonably responsive without much effort.)

 

[koala]

Anecdote: in ~2010 I developed an internal business app using Spring, with a plain HTML with nearly 0 JS. It was complex forms, but really didn't require much interactivity/real-time.

For kicks, I decided to do absolutely 0 CSS.

Every user was quite pleased using it. Our graphic designer rolled his eyes every time he was it, but he used it sometimes and also was happy with it.

I'm pretty sure the UI would continue to work exactly as well nowadays, 14 years after it was written.

 

[AdrianS]

I've written raw HTML in the past.
The most complex was an app that read AS400 terminal output, converted it to XML, and transformed that into HTML via XSLT, so it could be easily re-skinned.

The UI we're considering replacing does (almost) real-time data display, with bars, dials and graphs etc. There are about 10 main screens, plus dialogs.
It also does a lot of data transformation / calculations.
It's an app that has been in producion for 20+ years, and there is a lot of functionality to replicate.
And a whole lot of ugliness under the skin.

I've checked out various UI widget libraries that will support the appearance of individual controls - TeeChart is one I like the look of.
The individual elements are fairly framework agnostic (supports WPF, Winforms, UWP, HTML5, XAMARIN, ASP etc)
They've been around a long time (I used their Delphi components in the late 90's), and will provide source code, so I am confident in their longevity.
All our utility programs are C# / Winforms, and it's interesting that MS appears to be updating Winforms again.

So it boils down to Winforms / WPF, and hope MS keeps supporting them, or a HTML based solution.

Industrial computing is a strange niche:
Our users make money by running the machine, so while they like new features, they don't like major changes: "I just want to turn it on and do what I did yesterday".

They almost always run 2 large monitors, so mobile is out.

The machine draws up to 50 amps 3 phase, so power consumption is irrelevant to them.

The hardware lives forever - there are still quite a few of the old DOS based systems out there, running code I wrote in 1992!

I've seen so many frameworks come and go in that time, especially for HTML development, so picking something that will be around for a while is the challenge.
And finding one that we can get younger developers on board for.

I won't be around for ever, our dev team are all 40+ years old (youngsters!), and I want to leave a stable platform for the next iteration.
I've worked for this company on and off for about 1/3 of my career, so there's a lot of me invested in this.

Thanks people for feedback - this thread is partly me thinking aloud.

As I've been in this niche for a 10 years this time around, I am well aware that there are huge gaps in my experience.

My brother and I play bragging games - he says if you're not handling millions of records it's just tinkering; I say it's kid stuff if you're not controlling at least a megawatt.