6 ms·
I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I
by cv5005 7mo ago
I'm an embedded programmer who occassionally needs to write various windows programs to interface with embedded devices (usually via serial port or usb), and I find it a breeze to write native gui programs in pure win32 and c++.
Recently had to add a new feature to and old program that was last updated in the XP era and two things to note:
1. The program did not need to be updated to run on Vista, 7, 10 and 11, shit just kept working throughout the years.
2. I loaded the project into Visual Studio 2022, it converted from VC6 and compiled without problems, added the feature, shipped a new .exe to the customer, and it just worked.
What other platform has that backwards and forwards compatibility success story?
- LAC-Tech 7mo agoWinforms? lol at them still bekng the best option. so much wasted effort trying to replace them
- pjc50 7mo agoWinforms is great until you try to make windows dynamically sized, or deal with DPI nicely. In every other regard it's still fine, and for accessibility actually _better_ than many subsequent frameworks. And produces nice small fast executables.
- HauntingPin 7mo agoI assume that if Microsoft hadn't abandoned WinForms for the next thing, it would support dynamic sizing and DPI properly. It's mindboggling how much time and effort they've wasted coming up with new GUI frameworks instead of just improving on what they have.
- deleted 7mo ago[deleted]
- bob1029 7mo agoI don't think it's abandoned and it looks like there is a lot of activity around the high DPI concern. https://github.com/dotnet/winforms/issues?q=is%3Aissue%20state%3Aopen%20label%3Aarea-HDPI-SA https://github.com/dotnet/winforms/issues?q=is%3Aissue%20sta...
- pjmlp 7mo agoIt does, but many still think it is like using VB 6 and don't learn the additional APIs that provide that support, e.g. FlowLayoutPanel and TableLayoutPanel. And for HiDPI, https://learn.microsoft.com/en-us/dotnet/desktop/winforms/high-dpi-support-in-windows-forms https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
- Quarrelsome 7mo agoI remember a marvelous quote from a guy that was at some MS conference and got handed a leaflet that said: > WinForm or WPF, how to choose and they were like: "the question I have isn't how to choose, but _why_ I have to choose".
- runjake 7mo agoIt's been a while since I've touched it, but IIRC they made WinForms play with Hi-DPI nicely.
- pjmlp 7mo agoWindows dynamically sized is quite easy, people have had enough time to learn how to use layout managers in Windows Forms. Naturally it is a bit more than just drag and drop controls from the toolbox. HiDPI is supported in modern .NET, with additionally APIs, that aren't enabled by default only due to backwards compatibility.
- ack_complete 7mo agoOr, unless they've changed it, hardware accelerated rendering. Winforms was based on System.Drawing, which used GDI+, which was largely software rendering. This was confusing because GDI+ was not really related to GDI, which had and still does retain some hardware acceleration support. Even basic color fills start becoming an issue with a big window/monitor. Winforms is also .NET based, so it's inaccessible if you don't want to write your UI in and take a dependency on .NET.
- SirMaster 6mo agoDevExpress has many advanced Winforms controls that are all GPU accelerated and super fast. So Winforms can certainly do GPU acceleration.
- Quarrelsome 7mo agotransparency as well. WinForm really struggles with the idea of stacking elements on top of one another where there is an arbitrary amount of transparency or tricky shapes. Its just not worth the hassle compared to WPF.
- jordand 7mo agoThe one big challenge I've had with big legacy Win32/C++ codebases is migrating it fully from 32bit to 64bit. Loads of know-how and docs for complex GUI controls and structs are lost to time, or really fragmented. Other than that, yeah it really does all just work once you're past that.
- cv5005 7mo agoWell it's still a 32 bit program so I guess that helps. Would probably require some porting to make it 64 bit native, but as long as you use the WPARAM, INT_PTR typed and what not correctly it 'should just work'.
- jordand 7mo agoYeah that's the bulk of the work for migrating small Win32 apps. Things escalate when someone has built their own dynamic GUI framework over Win32, used a range of GUI controls, and then built event-driven apps on top of that, it's a lot lol
- mschuster91 7mo agoDoesn't WINE have pretty decent documentation by now from all the reverse engineering?
- sourcegrift 7mo agoWine cannot even install office 2014. It's not really as food as some claim sadly.
- anthk 7mo agoLutris can up to 2016.
- jordand 7mo agoWin32 programming has been reduced to a small niche now. Even 20+ year old Win32 books don't cover things in-depth (or practical use cases) let alone the 32bit->64bit migration
- lucianbr 7mo agoHow does it look? I mean, what do the widgets look like?
- cv5005 7mo agoThis was an MFC project, so your old standard win32 common controls that looks the same since 98 or so.
- samiv 7mo agoTo me this kind of "no need to change anything" implies stability but there's a younger cohort of developers who are used to everything changing every week and who think that something that is older than week is "unmaintained" and thus buggy and broken.
- mcswell 7mo agoRepeat after me: New! Fresh! Clean!
- raw_anon_1111 7mo agoOne of the earliest security issues that I remember hitting Windows was that if you had a server running IIS, anyone could easily put a properly encoded string in the browser and run any command by causing IIS to shell out to cmd. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2000/ms00-078 https://learn.microsoft.com/en-us/security-updates/securityb... I mentioned in another reply the 12 different ways that you had to define a string depending on which API you had to call. Can you imagine all of the vulnerabilities in Windows caused by the layers and layers of sediment built up over 30 years? It would be as if the modern ARM Macs had emulators for 68K, PPC, 32-bit x86 apps and 64K x86 apps (which they do) and had 64 bit Carbon libraries (just to keep Adobe happy)
- userbinator 7mo agoBetter to have known unknowns, than unknown unknowns.
- eviks 6mo agoExcept the former doesn't eliminate the latter
- sethhochberg 7mo agoI think its at least as much of a working environment preference. Once I became experienced enough to have opinions about things like my editor and terminal emulator... suddenly the Visual Studio environment wasn't nearly as appealing. The Unix philosophy of things being just text than you can just edit in the editor you're already using made much more sense to me than digging through nested submenus to change configuration. I certainly respect the unmatched Win32 backwards/forwards compatibility story. But as a developer in my younger years, particularly pre-WSL, I could get more modern tools that were less coupled to my OS or language choice, more money, and company culture that was more relevant to my in my 20s jumping into Ruby/Rails development than the Windows development ecosystem despite the things it does really well. Or to say differently: it wasn't the stability of the API that made Windows development seem boring. It was the kind of companies that did it, the rest of the surrounding ecosystem of tools they did it with, and the way they paid for doing it. (But even when I was actually writing code full time some corners of the JS ecosystem seemed to lean too hard into the wild west mentality. Still do, I suspect, just now its Typescript in support of AI).
- user____name 7mo agoI feel like I'm the only person in the world who would rather write ugly win32 jank for the rest of my days than ever having to touch an "elegant" or "well structured" Cocoa codebase. In win32 if you want a button you call a function and pass a hande, in the Apple world you first subclass 7 interfaces in some unreadable Smalltalk-wannabe syntax and pray you don't need to access the documentation. And of course they constantly change things because breaking backwards compatibility is Apple's kink.
- cosmic_cheese 7mo agoThat feels like quite the exaggeration. If all you want is a button, all you need to do is initialize an NSButton and then tweak a few properties to customize it as desired. If you want something more custom, subclass NSControl and you’re off to the races. And if Obj-C isn’t your cup of tea, one can use Swift instead, even in a codebase that had been only Obj-C prior.
- 762236 7mo agoThis is such a wonderfully beneficial comment to the HN community. It should get an award.
- dgxyz 7mo agoAfter bouncing around GUI toolkits (from win32 to SwiftUI) and web for 30 years I have simply run out of fucks. They all suck. Each in their own unique way. Apple aren't worth singling out - they are just their own special isolated variant of it.
- lylejantzi3rd 7mo agoBut, why? It's been 30 years. You'd think somebody would have figured out how to make a decent GUI toolkit or framework.
- dgxyz 7mo agoWe just built layers of shit over the ones we have.
- raw_anon_1111 7mo agoAnd the 12 different ways to define a string depending on which API you call
- tsss 7mo agoHonestly, your GUIs are too simple to be part of this conversation. Try writing something like Spotify in WinAPI and that's not even a complicated GUI either.
- troupo 7mo agoMost apps at the time managed that quite successfully. IIRC Adobe Photoshop was an MFC app. There was no other API but Win32 API.
- QuadmasterXLII 7mo agoSpotify would be remarkably improved if it became a simple enough gui to be excluded from this conversation.
- pjc50 7mo agoWinAmp was the win32 music player of choice, once upon a time.
- leptons 6mo agoOnce upon a time? I still use WinAmp every single day. It works great, does what I need, and I've never had a problem with it.
- magicalhippo 7mo ago> Try writing something like Spotify in WinAPI and that's not even a complicated GUI either. Fruityloops, now FL Studio, was written in Delphi and to my knowledge still is[1]. When ot launched there were no options but Win32 for Delphi. That's just one example. Win32 makes it reasonably easy to skin things, and back in the 2000s a lit of programs did. [1]: https://blogs.embarcadero.com/fl-studio-is-a-massively-popular-digital-audio-workstation-software-built-in-delphi/ https://blogs.embarcadero.com/fl-studio-is-a-massively-popul...
- badsectoracula 7mo ago> Win32 makes it reasonably easy to skin things Actually it doesn't. Win32 skinning is either making a control completely from scratch or hacking into undocumented aspects of the native controls - i.e. what WindowBlinds does. AFAIK modern Delphi has some component that basically follows the WindowBlinds approach.
- dgxyz 7mo agoYeah that doesn't always work that well. Think you were lucky. Add high DPI to the mix and things get rough very quickly. Also the common control have weird input issues (try ctrl+backspace in an Edit control). All those little things need to be fixed carefully for something to be ok in 2026.
- moomin 7mo agoBut that’s the point the article’s making. At the C level you’ve got a fully functional system. Above that level (even at the C++ level), feature support is a mess.
- finghin 7mo ago‘Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule’ —F. Nietzsche (tongue in cheek)
- tibbydudeza 7mo agoSame here - our IOT device is a i5 running Windows IOT. Recently I switched from C++/Win32 to Golang and walk.
- sys_64738 7mo agoI've not done MFC Win32 programming since 1999 but if I recall those programs don't execute the main() function. They instantiate the Win32 class for your app or something like that. I can't remember any details anymore.
- int_19h 7mo agoYou still have a main function in Win32, it's just called WinMain and has a slightly different signature. MFC has CWinApp, which you'd normally subclass, and a stock WinMain implementation that instantiates that, but it's not strictly necessary to subclass it, just convenient.
- gzread 6mo agoThey don't use main because they use WinMain, which is the entry point for Windows apps that don't run in a console window. WinMain should create an instance of the app class and call Run. "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 https://news.ycombinator.com/item?id=47473604 which feels pretty unfair
- sys_64738 6mo ago> "You're posting too fast." I never got that before. How fast is too fast? I tried to post this comment hours ago, but I couldn't. I guess I've been restricted because of this comment https://news.ycombinator.com/item?id=47473604 https://news.ycombinator.com/item?id=47473604 which feels pretty unfair I get that if I post more than six replies in an hour.
- gzread 6mo agoI've always been able to post several replies in an hour before.
- psyclobe 7mo agoBut isn't that illegal now? You have to write everything in rust according to their cto.
- kelvinjps10 7mo agoand it would work on linux with wine lol.