4 ms·
I think C++ is especially good for a GUI. The two counter-examples I can think of with plain C: * GTK+, though honestly speaking I think quality has dipped ov
by asveikau 2y ago
I think C++ is especially good for a GUI.
The two counter-examples I can think of with plain C:
* GTK+, though honestly speaking I think quality has dipped over the decades where C++ equivalents have flourished.
* Old school Win32 style. Counter to the bad reputation, I find it easy to be productive with in plain C once you adjust your mental model to its expectations. Though it's probably better from C++ than C, for a few convenience features to reduce boiler plate.
- mananaysiempre 2y agoOld Win32 style received less attention than it deserves, I think. It's an object system in its own right—a Smalltalkish one, at that, with an (admittedly muddled) E-style separation of synchronous and asynchronous calls!—but one rarely sees it mentioned in the same sentence as Objective-C, C++, and GObject/Vala. Part of the blame for that undoubtedly rests on Microsoft’s incompetence at documenting concepts, but whatever the causes I’d definitely like to see that corner of the object-system design space explored more, with or without GUIs.
- asveikau 2y agoWhen win32 was dominant they didn't need to document it, people had the motivation to figure it out. Successive waves of Microsoft people then tried to make it easier to use or replace it entirely, which, they never did so with the same quality as the original. Unfortunately some of those misadventures became synonymous with building a windows UI.
- tomcam 2y ago> Part of the blame for that undoubtedly rests on Microsoft’s incompetence at documenting concepts I mean Charles Petzold did that so successfully redoing it would be superfluous
- mananaysiempre 2y agoKind of. He stops somewhat short of admitting that Win16/32 windows are objects and their graphical representation is mostly incidental. That’s not a bad thing—the book is introductory on many topics, in a good way, and just dropping such an idea somewhere in the beginning portions would be more confusing than helpful for the intended audience. That audience would almost certainly not be helped by the observation that they are dealing with a sort of Smalltalkish/Actorish system with badly bolted-on multithreading—most of it wouldn’t have knowm what that meant, at the time. Still, this is kind of a common theme. Perhaps “you had to have been there” worked as an approach to documentation for the first ten to fifteen years, but afterwards any newcomer is just guaranteed to get lost. If you want to learn Win32, you need to read Petzold. If you’re interested specifically in how the dialog manager works, you need to invent a time machine and read a series of blog posts Raymond Chen wrote in 2005[1]. If you want the particulars on message queueing, you need to invent a time machine and read the chapter about then in Raymond Chen’s blogobook[2]. If you want to learn about STRICT and the very useful message cracker macros in WINDOWSX.H, first, you were probably reading Raymond Chen, because the official documentation is basically mum about it, but second, you need to track down that one KB article about porting to Win32 that accompanied one particular Windows 3.1-era Microsoft compiler[3]. If you want to learn DCOM95-vintage COM, you need to read Box and Brockschmidt and that COM Programmer’s Cookbook[4] thing that was somebody’s own private initiative inside Microsoft and is buried somewhere in the technotes and then the COM Specification[5] will be accessible to you, and only after that will the MSDN specification make some sort of sense. If you want to learn the how or why of COM marshalling in particular, you will perhaps be helped by some of the above, but really you need to invent a time machine and read a series of blog posts Raymond Chen wrote in 2022[6]. Only then will the MSDN reference be even slightly helpful (and even then not that much over the IntelliSense hints). If you want to learn ActiveX ... I have no idea what you need to read! And that itself is indicative of a problem (took me five years to stumble upon Brockschmidt). If you want to learn MSMQ/MTS/COM+/whatever, you need to read that one book[7] that’s still going to leave you with more questions than answers, and then maybe track down some MSJ articles from after COM+ was only a vague marketing term for something internal, but before .NET completely overtook all Microsoft communications channels. If you want to learn about using COM contexts, first, my condolences, second, AFAIK your only source for this Win2K-era, and I quote, “backdoor into the very low-level COM infrastructure” is Raymond Chen’s post from two decades later[8]. There’s no motivating spec for any of this, even one as scarce on details as the later parts of the COM one. If you want to learn about WinRT internals, well, there are some blog posts random people on the Internet have written[9], and maybe you can spelunk some in the Win8-era legacy MSDN docs that are somewhat more explicit about what’s happening. If you want to learn about WinRT’s headline feature of “metadata-driven marshalling”, fuck you, it’s not explained anywhere, nor is an up-to-date MIDL grammar that would include the ways to adjust it a “priority” for that team—or maybe it’s just that I don’t have a time machine, but Raymond Chen is mortal too, and it’s been over a decade. And it’s all like that. (Eric Lippert copied some of the articles on Active Scripting / WSH from his now-deleted MSDN blogs, but not all of them. Michael Kaplan’s blog, one of the best resources on Windows i18n, was speed-deleted from MSDN after he published a Vista leak, and the man himself died shortly afterwards, so for anything after that you’re out of luck. Etc., etc. Need I say there’s no type system spec for TypeScript?) Again, if you were there at the time and you subscribed to MSDN, until 2005 or so I think you would’ve gotten basically all of the things I listed on the CDs, and more besides (Dr. GUI and Dr. International anyone?). But if you only joined in 1995 or 1998 or 2000, God help you. (WinRT happened after 2005, though, so the sum total of in-depth, under-the-hood narrative stuff about it is fuck all.) The references from that era are excellent, but as far as, again, narrative docs are concerned— C’mon, guys, you had Ted Chiang at your disposal and that’s what you managed?.. (Then again, it probably had very little to do with the technical writers themselves and a lot to with the preposterously hectic development and a management culture that just did not prioritize this sort of thing. But still.) [1] http://web.archive.org/web/20231204102018/https://bytepointer.com/resources/old_new_thing/20050329_078_the_dialog_manager_part_1_warm_ups.htm http://web.archive.org/web/20231204102018/https://bytepointe... (wait, has bytepointer.com died? that would make me very sad...) [2] https://openlibrary.org/works/OL9256722W/The_old_new_thing https://openlibrary.org/works/OL9256722W/The_old_new_thing [3] Nope, can’t find it right now! Good thing Microsoft deleted most of the old KB articles from their website... —an hour passes— Found it! Q83456: https://raw.githubusercontent.com/jeffpar/kbarchive/master/txt/083/Q83456.TXT https://raw.githubusercontent.com/jeffpar/kbarchive/master/t... (thank goodness these were numbered). [4] https://learn.microsoft.com/en-us/previous-versions/ms809982(v=msdn.10) https://learn.microsoft.com/en-us/previous-versions/ms809982... [5] What, were you expecting a microsoft.com link? Hahaha, nope! Just imagine you’re listening to Rick Astley, I guess. Anyway, there are two versions in circulation (originally as DOC). The “Component Object Model specification”, version 0.9, is dated 1995 and is easier to find, e.g.: https://groups.csail.mit.edu/medg/ftp/emjordan/COM/THE%20COM.DOC https://groups.csail.mit.edu/medg/ftp/emjordan/COM/THE%20COM.... The “COM core technology specification”, version 1.0, is dated 1998 and is, as far as I know, only available from this one Russian-language homepage, last updated 2004 (and you can certainly tell): https://thegercog.narod.ru/index.htm?u=https://thegercog.narod.ru/Pages/Docs.htm https://thegercog.narod.ru/index.htm?u=https://thegercog.nar..., direct link: https://thegercog.narod.ru/Files/Docs/ds/com/com_spec.rar https://thegercog.narod.ru/Files/Docs/ds/com/com_spec.rar. A lot of the same material is in the DCOM Internet-Draft and the ActiveX Spec drafts on the Open Group website. [6] https://devblogs.microsoft.com/oldnewthing/20220615-00/?p=106753 https://devblogs.microsoft.com/oldnewthing/20220615-00/?p=10... [7] https://thrysoee.dk/InsideCOM+/ https://thrysoee.dk/InsideCOM+/ [8] https://devblogs.microsoft.com/oldnewthing/20191128-00/?p=103157 https://devblogs.microsoft.com/oldnewthing/20191128-00/?p=10... [9] https://www.interact-sw.co.uk/iangblog/2011/09/25/native-winrt-inheritance https://www.interact-sw.co.uk/iangblog/2011/09/25/native-win...
- WesolyKubeczek 2y agoOOP is especially good for making UI toolkit. If you look at GTK+ and Win32 closely, you’ll notice that they all sport some kind of a homegrown class system, complete with inheritance and polymorphism. It’s popular to dunk on OOP and its concepts nowadays, but I think that languages that straight away shun them because “OOP sucks” are an example of their authors overreacting to OOP’s dominance back in 1990s-early 2000s and tendencies to shove OOP into every nook and cranny, with a notion that if you don’t do it, or do not enough of it, your solution is inferior. Holy hell. Linux kernel is object-oriented. Because it’s damn convenient for a lot of things.