6 ms·
There's something elegant about https://github.com/LeZuse/minimal-win32-app/blob/master/main.cpp https://github.com/LeZuse/minimal-win32-app/blob/master/main...
by davb 10y ago
There's something elegant about https://github.com/LeZuse/minimal-win32-app/blob/master/main.cpp https://github.com/LeZuse/minimal-win32-app/blob/master/main...
I remember just how painful working with the Win32 API could be (a lifetime ago), but I felt like I really understood how it worked. These days, it's layer upon layer of abstractions. Or bindings from my language of choice to an abstraction layer/framework running on the native OS.
I couldn't begin to explain how many of the popular UI frameworks work, all the way down to the native OS layer.
There was something substantial, concrete in programming at this layer rather than some higher level, fragile abstraction.
- achr2 10y agoI think that sentiment is mostly revisionist nostalgia. Yes it was easier to 'know' what was going on between your code and the OS, but to say that modern UI frameworks are more fragile than the hand-coded win32 code of yore is certainly fallacious.
- davb 10y agoI'd argue that it's not "fallacious", it's simply a matter of opinion and taste.
- maxxxxx 10y agoActually I would agree that win32 is more stable once you get the hang of it. I have worked with WPF, Winforms, MFC and win32. win32 was by far the most complete, predictable and flexible environment. It takes a lot of learning and you can't just let anybody work on the codebase. But once you know what you are doing and maybe have some simple wrappers for routine stuff it's pretty good.
- pjmlp 10y agoComing from MS-DOS and Amiga as background, I was amazed how Win16 was a productivity changer (for the better). It is funny to see people bashing it nowadays, given how I came to enjoy it. When I started GUI coding on UNIX, Xlib, Xt and Motif on the other hand were anything but productive.
- wiz21c 10y ago100% agree. With modern tools, I : Think the UI the way I code it (declarative) Don't have to think about screen resolution, colour depth,... Don't have to bother with non unicode stuff Have access to well behaved widgets Can have portability if I need that Even if I can't control 100% of the rendering process, my productivity has increased...
- wolfgke 10y ago> Think the UI the way I code it (declarative) Windows Ressource files exist at least since Windows 3.x > Don't have to bother with non unicode stuff Just use the WinAPI functions that are prefixed with W (Unicode) instead of A (ANSI), e.g. CreateWindowExW instead of CreateWindowExA. > Have access to well behaved widgets Call CreateWindowEx (https://msdn.microsoft.com/en-us/library/windows/desktop/ms632680.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...) (yes, the name is confusing, accepted) with lpClassName value, say, of BUTTON, COMBOBOX, EDIT, LISTBOX, MDICLIENT, SCROLLBAR (for a more complete list look at the MSDN site that I linked). This creates such a widget.
- pjmlp 10y agoUsing the message crackers and type safe handles introduced in Windows 3.1 SDK made it somewhat better. In any case, OWL, VCL and later on MFC were my tools during those days, when given an option.