121–130 of 577 posts
Earlier quoted context omitted.
Totally agree with this. I’ll get shot for this one but I write most of my GUIs in Excel these days.
Do you mean Visual Basic for Applications? How are you creating a GUI in Excel?
Apple and Microsoft underinvest in their widget toolkits. It’s especially damning for Apple since they spend the money to write numerous custom widgets (e.g., the widgets in their professional apps like Final Cut Pro and Logic Pro) but don’t upstream. Nobody is inspired by yet another implementation of button or tab widgets.
The most solid of their toolkits is far and away UIKit on iOS. It's got almost all of the best parts of AppKit with over a decade of thoughtful tweaks, polish, and QoL improvements. AppKit has become a bit more neglected since iOS stole the title of favorite child from macOS but is still quite solid. Both have an extensive set of highly capable stock widgets and with both, you can write just about anything imaginable pretty easily without importing a single third-party library. Neither locks you into a WYSIWYG editor or hand-editing XML and are pure-code-friendly, particularly since the addition of autolayout anchors.
SwiftUI is finally getting to the point where it's not so green and is becoming a more practical choice. Though it wasn't a headliner, this recent WWDC brought a number of long called-for improvements.
By contrast, WinUI lacks such fundamental basics as a tableview/datagrid, meaning you're going to be rolling your own or importing third-party widgets much more frequently. While you're not as locked into XML layouts and resources as one would be with Android Framework with it, it's not as friendly to pure code. It's also decidedly mobile-esque relative to AppKit (likely owing to its UWP heritage) which might be a problem if the goal is to build a true desktop-class app.
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…
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. :)
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.
If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your C++ DLL with static C runtime, your C++ DLL won’t have any dependencies apart from OS components like kernel32.dll.
If you insist on having a single EXE you’ll need to bundle it and extract, but the additional code for the P/Invoke to work is like 4 lines of that code, call LoadLibraryW from kernel32.dll early on startup, before using any stuff with [DllImport] from that DLL.
I do not recommend C++ CLI. Write normal C++ which compiles into native code without any weird metadata. You can use C APIs, or COM interop with ATL, or check this library of mine https://github.com/Const-me/ComLightInterop/
If you start with this approach (as opposed to refactoring a C++ app you already have) you’ll find out that you need substantially less C++ than you expected. Essentially, C++ is only required for 2 things: CPU-bound number crunching, and code which consumes large C or C++ libraries (Windows SDK is huge and pieces like D3D or MediaFoundation require C++). It’s much easier to do everything else in C#, as the language and especially the standard library are just better.
Hmm, this got me thinking about stuffing native code into CLR image. If you would just include additional executable code sections into PE, would loader map them normally? Or presence of IMAGE_DIRECTORY_ENTRY_COMHEADER would stop it from mapping native code? If so, maybe you could remove that header and manually do pre-XP style initialization, by calling _CorExeMain from imported mscoree.dll. Though you would need to somehow trick it into locating COMHEADER that we removed.
Or maybe I'm overthinking this and MS already supports that? https://learn.microsoft.com/en-us/cpp/dotnet/mixed-native-an...
>As a fellow European, I do not have air conditioning. Is anything stopping the author from buying a heat pump?
Interestingly, some people would describe that temperature as only "warm". I recently watched a video of a machinist working in his shop (southern US) saying that it was 94 and "a little warm".
Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK. It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center. A simple Hello World, click OK to exit the program application should be able to be cr…
Win32 Hello World messagebox is a few hundred bytes.
Earlier quoted context omitted.
Never coded a GUI app but speaking of regressions: As a heavy windows KB user, losing the ability to alt+letter all the things to /quickly/ navigate windows apps is incredibly frustrating. I've read that Mac OS envy infiltrated the WinUI time and while some may prefer the aesthetics, on Windows 11 apps like mspaint I can no longer navigate anywhere near as quickly. From milliseconds to multiple seconds. I'm incensed…
It's funny that you mentioned apple because their system shortcuts are integrated as hell and they even let you map them in the OS -> App level, way better than anything MS has ever shipped.
It's one of the reasons why longtime Mac users are disinclined towards non-native apps. Most don't bother to reproduce these behaviors, and so when you as a user go to reach for these features that you have muscle memory for and they're not there, it's like hitting a brick wall in the middle of your workflow and makes the app in question feel basic and unrefined.