Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

Post reply on HN
Print view View original

231–240 of 577 posts

Re: Writing GUI apps for Windows is painful

#231

Post by blep-arsh »

JodieBenitez wrote: post #53

I don't do a lot of desktop apps but for simple GUI apps I've been using Python and Pywebview, with packaging left to Pyinstaller. The main reason is that I get to reuse the python/javascript/css libs that I know, and it's easily portable. I'm sure a native app uses less memory and cpu but frankly what I get with this combination is not that resource hungry. In fact, anytime something goes south it's my fault for usi…

I was going to suggest embedding the native WebView ActiveX control (which I did in the past with great success) but it turns out the WebView has been updated and wants end users to download and install the Chromium-based runtime library nowadays.

Re: Writing GUI apps for Windows is painful

#232

Post by smackeyacky »

EasyMark wrote: post #227
Aurornis wrote: post #19

This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options. Specifically, the requirement for completely custom GUI styling without writing his own render functions means it’s really a task of selecting easy, customizable GUI libraries rather than generic GUI work. The requirements to be self-contained executables and under a…

If you’re on windows and want a “standard” guy, either use the .net GUI or Qt , if you want completely custom and willing to do the work use QML or ImGui (or variant like eGUI)

Which particular .NET Gui? There is a collection of them: MAUI, WPF, Blazor Hybrid, WinUI.

Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.

Re: Writing GUI apps for Windows is painful

#233

Post by skydhash »

fleabitdev wrote: post #217
mike_hearn wrote: post #166

Earlier quoted context omitted.

The issue is the React paradigm, which is a bit questionable to begin with. It's a sort of fake OOP in a trenchcoat pretending to be something else, whilst abusing the language in ways that requires compiler plugins. My experiences with Compose and SwiftUI have been ... not that great. I kinda wish people would just have kept investing in their OOP toolkits.

You're right that reactive UI is a poor fit for most languages (especially JavaScript!), but I think the problem is more general than that. Good UI architecture needs some convenient and efficient way to propagate state changes between different parts of the UI framework [0]. This requirement sits in an awkward place, halfway between imperative programming and functional programming. It just isn't in the day-to-day v…

We already have a solution for most UI presented in this paper [1]. Functional programming let you represent the solution in a much nicer way after you've hidden the oop/imperative machinery away. But it's a complete package where the declarative part is only the shell. The UI part of any application should be considered as an external module, (like the data access layer) and the code architecture should reflect this. In an extreme way, if you can't create a telnet interface to you GUI software, that means your interface is already too coupled to the rest of the code.

[1]: https://dl.acm.org/doi/10.1145/62402.62404

Re: Writing GUI apps for Windows is painful

#234

Post by markus_zhang »

userbinator wrote: post #100
markus_zhang wrote: post #52

I'm teaching myself the Win32 API for a future RE project, thinking that knowing it helps with the reverse engineering effort. I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet. It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for any…

I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet. You could just use the standard Edit control for that. If you really want to do it manually, which I have done, it's less than ~300 lines of code for the whole app (including working scrollbars). The binary is less than 4k. but I never realized that showing strings on Windows is suc…

Thanks, I don't know about that yet, so it's going to be while.

For the string it's mostly the wchar and char stuffs. I think I'm getting a hang of it.

Re: Writing GUI apps for Windows is painful

#235

Post by markus_zhang »

Jare wrote: post #124
bonzini wrote: post #74

Earlier quoted context omitted.

IIRC WinG was basically a way to set up a GDI device context that corresponded to a frame buffer, so you could take your DOS SuperVGA code and run it under Windows, only redoing sound and input. It's been almost 30 years though. :)

That's what it was, mostly. You could do pretty decent games using GDI as long as you just wanted to blit some sprites and were very much adhering to what GDI would give you. If I remember correctly, all the examples in the "GameSDK sampler CD-ROM" (the original name of DirectX 1.0) were in fact not done with GameSDK or even with WinG, but straight GDI.

I don't know much about the performance, but I guess non-action games should be fine?

Re: Writing GUI apps for Windows is painful

#237

Post by markus_zhang »

qingcharles wrote: post #133
markus_zhang wrote: post #52

I'm teaching myself the Win32 API for a future RE project, thinking that knowing it helps with the reverse engineering effort. I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet. It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for any…

I'm amazed Fury3 worked under WinG. I used WinG for some simple 2D games, but I don't think I would have tried texture-mapped 3D! We wrote this game on DirectX 1.0. It was a pig because the game was designed to be all 2D sprites, but early in the project it became clear there wasn't enough RAM, so I wrote a 3D engine that integrated with the 2D backgrounds. The video cards of the day didn't like that shit, and there…

Wow that looks pretty slick. Now I know why early Windows don't have competitive games and why things like WinG and DirectX are pretty big. I think Carmack did not jump on the DirectX wagon until much later.

Re: Writing GUI apps for Windows is painful

#238

Post by neonsunset »

smileybarry wrote: post #223
chipdart wrote: post #48

Earlier quoted context omitted.

> While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret. What I find the most mind-numbing thing about the blog post is the way WinUI3 was excluded. WinUI3 looks like an exac…

WinUI3 is a can of worms that’s becoming palatable only with .NET 8 (and soon 9). In a normal configuration, you have to bring 500MB of dependencies with you, or ask the user to install a redistributable. You also need the user to install .NET 8, or bring said 0.5GB with you. WinUI3 can be used in unpackaged apps (I.e.: not appx) but has a few random caveats that just don’t work; random APIs that have a footnote of “…

What kind of build settings lead to 500 MiB binaries? I struggle to imagine something that could make the toolchain to emit such a large binary save for select degenerate cases of runaway generic specialization when you AOT compile an SDK that combines LINQ with 2102718201 enum types, all of which get their own set of generic instantiations for every internal iterator within LINQ - that's a known issue that is fixed by enabling identical method folding in ILC, the worst offender used to be Kiota OpenAPI generator causing this, but thanks to tireless work by Filip Navara that was fixed there.

In general, there are quite a few knobs for configuring how exactly you would like to have your application published. This is also an area of active improvement with each new release as you noted. It is very worth it to look into further build configuration nonetheless. If you still face an issue with "this surely shouldn't take this much space", it might be a good idea to submit it to either https://github.com/dotnet/runtime or to the repo of the GUI framework depending on where you think the fault lies - without feedback it's difficult to know if there is an area that needs improvement or a known improvement opportunity that has demand.

Re: Writing GUI apps for Windows is painful

#239

Post by alkonaut »

smileybarry wrote: post #224
vunderba wrote: post #79

Earlier quoted context omitted.

Agreed. I had the exact same question. From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)." I don't understand w…

C++/CLI is managed code, it’s basically C++ compiled into .NET IL. If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.

But why even use C++ for the front end if it’s going to be .NET? Managed C++ is mostly useful as a shim, not as a platform language. It’s not really an alternative to C# on the .NET runtime but just some C++ extensions for interop with it.

If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be embedded into the managed exe). There could be a layer of C++/CLI between these to layers (C# front end and native backend) because it would make the interop a bit easier than having to do C-style interop.

Re: Writing GUI apps for Windows is painful

#240

Post by alkonaut »

delta_p_delta_x wrote: post #90
vunderba wrote: post #79

Earlier quoted context omitted.

Agreed. I had the exact same question. From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)." I don't understand w…

> I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it. I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being…

That insistence isn’t motivated in the post in any way, which makes it a really weird and arbitrary requirement.
Post reply on HN