6 ms·

> 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 w

by 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 ago
Kind 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...
- asveikau 2y ago
  I learned a bunch of these things largely on my own, but it probably helped that I was at MSFT for a few years.
- actionfromafar 2y ago
  Completely amazed that you could write this comprehensive reply just like that.
  - mananaysiempre 2y ago
    I guess I’m just a bit obsessed with Golden Age Microsoft, having grown up during that time without understanding much of what was going on. My original point, though, was that they had some very nice, perhaps thesis-chapter-worthy points that ended up buried in the specifics of (and on more than one occasion, in the same grave as) their products. Windows’s, well, windows as a object/concurrency system are one (even if the Win32 transition to multithreading is IMO conceptually botched). The actor model admittedly already existed at that point, but Mark Miller et al.’s work on E (the only other source I know for having separate synchronous and asynchronous sends) hadn’t even started at that point. (There are innumerable papers on various versions of actors, though, so I might have missed it.) COM aggregation is another. It would probably have been much more successful had they used fat pointers, and there are a couple of old papers pointing this approach is a viable way to do implementation (as opposed to interface) inheritance. But I know of no precedent in the literature for the inside-out way WinRT builds its allegedly more conventional inheritance mechanism on it. (I guess I would’ve referenced BETA if I were writing a paper on it?) DCOM’s “causality IDs” for reentrancy control are yet another. You can basically have calls to your object guarded by a recursive mutex whose ownership is passed along with any remote calls that that object itself makes. I’m not sure they are a good idea (recursive mutexes are perilous in the simplest of situations, and this is most definitely not one of those), but I’m almost certain it’s an original one. That’s it, for now, but I’m almost certain I could find more, if only I knew where to look.
    - amluto 2y ago
      Recursive mutexes are a terrible idea, except maybe in context. In a world where you can SendMessage a message to yourself or to another window in the same thread, process the message synchronously, and then return back to where you were, you have essentially uncontrolled reentrancy. If you want to throw mutexes into the mix, they pretty much need to be recursive. Then you get to acquire the mutex in a message handler to protect against other threads, and everything sort of works. In my own code, I try fairly hard to avoid this sort of reentrancy.

by 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 ago

Kind 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...

asveikau 2y ago
I learned a bunch of these things largely on my own, but it probably helped that I was at MSFT for a few years.
actionfromafar 2y ago
Completely amazed that you could write this comprehensive reply just like that.
- mananaysiempre 2y ago
  I guess I’m just a bit obsessed with Golden Age Microsoft, having grown up during that time without understanding much of what was going on. My original point, though, was that they had some very nice, perhaps thesis-chapter-worthy points that ended up buried in the specifics of (and on more than one occasion, in the same grave as) their products. Windows’s, well, windows as a object/concurrency system are one (even if the Win32 transition to multithreading is IMO conceptually botched). The actor model admittedly already existed at that point, but Mark Miller et al.’s work on E (the only other source I know for having separate synchronous and asynchronous sends) hadn’t even started at that point. (There are innumerable papers on various versions of actors, though, so I might have missed it.) COM aggregation is another. It would probably have been much more successful had they used fat pointers, and there are a couple of old papers pointing this approach is a viable way to do implementation (as opposed to interface) inheritance. But I know of no precedent in the literature for the inside-out way WinRT builds its allegedly more conventional inheritance mechanism on it. (I guess I would’ve referenced BETA if I were writing a paper on it?) DCOM’s “causality IDs” for reentrancy control are yet another. You can basically have calls to your object guarded by a recursive mutex whose ownership is passed along with any remote calls that that object itself makes. I’m not sure they are a good idea (recursive mutexes are perilous in the simplest of situations, and this is most definitely not one of those), but I’m almost certain it’s an original one. That’s it, for now, but I’m almost certain I could find more, if only I knew where to look.
  - amluto 2y ago
    Recursive mutexes are a terrible idea, except maybe in context. In a world where you can SendMessage a message to yourself or to another window in the same thread, process the message synchronously, and then return back to where you were, you have essentially uncontrolled reentrancy. If you want to throw mutexes into the mix, they pretty much need to be recursive. Then you get to acquire the mutex in a message handler to protect against other threads, and everything sort of works. In my own code, I try fairly hard to avoid this sort of reentrancy.