Hacker News Reader

Comment by markasoftware | Hacker News Reader

More accurately:

+ "portable" (single exe with no automatic unzipping of dlls or anything)

+ commercial and unwilling to redistribute compiled object files (which together with the "portable" requirement, means no LGPL)

+ dark mode

Windows GUI apps is painful. Drop any one of these requirements and there are good established options.

Specifically I think most "portable" applications use win32 because, usually, portable => small, simple application where functionality is more important than dark mode or other styling ability.

View on HN

> Windows GUI apps is painful. Drop any one of these requirements and there are good established options.

The "portable" one is not a hard requirement. It's a whimsical self-imposed constraint, which makes as much sense as complaining that you can't stand on your right foot on Tuesdays. All installer toolkits released in over two decades support deploying arbitrary components. Is this not a solved problem?

WinUI3 supports dark mode/theming out of the box along with fully customizable styling. It's as free as it gets. It's also Microsoft's official GUI framework for Windows. But the blogger rejects it because... Because what?

Well I remember one project where having the app small and portable or at least self-contained was a hard requirement. It involved an embedded device (ridiculously complex and over-engineered embedded device) that used customized USB flash sticks for user authentication, data transfer and firmware updates and configuration. The partitioning scheme of the update/configuration scheme meant that I had only about 16MB of free space on the windows-visible partition for a Windows GUI configuration application for the thing.

Originally I started writing it in MFC, but MFC is not exactly good match for something so trivial and all the abstractions meant for document-based applications were mostly in the way and I ended up doing it in Lazarus.

And those COM errors that just kill the process, bypassing C++, and .NET exception mechanisms? lovely!

No designer, manualy editing IDL files for XAML C++ bindings, without any kind of syntax highlighting or code completion, manually merging generated C++ code, even more lovely.

Using a Webview wrapping Bing Maps, instead of the native UWP map control, even better.

"Portable" i could see a few use cases. No MSIL and only native code, however...

Anyone can compile a static binary with FLTK and have the binary size start under 100KB.

You can do that with straight win32 as well. Steve Gibson has a bunch of utilities and most of them are pretty tiny. His DNS Benchmark is one of the larger utilities at 169k.

I like win32 and you can get a lot smaller with win32, but there are a lot of things missing. FLTK has a lot of components, component layouts, fonts, file system stuff, networking, audio, an openGL context, image loading and it's cross platform.

I'm confused. What is "missing" from Win32? To be clear, I count all base DLLs included with Windows a "Win32". One thing I can think of from your list: component layouts. Resizable windows with component layout is awful in Win32.

I've used FLTK for an application. It relies heavily on opaque pointers and convention. The compiler will not help you out if you mess up.

https://github.com/gammasoft71/Examples_FLTK/blob/c6f630eaa3...

You can use dynamic_cast instead of reinterpret_cast. If the pointer isn't correct it would return null. A better solution is to subclass the widget, store a function pointer for the callback which takes the same class instead of an Fl_Widget, and call that in the callback: https://github.com/MoAlyousef/FLMH This uses a std::function for the captures but you can use a function pointer as well.

Or with Lazarus, I've tested it a year or so back. Under 50KB, IIRC, for a CLI Hello world app, though, not a GUI one. Similar size with a D app.

nuklear solves all of these for me, plus it's plain C

Reply on news.ycombinator.com