That was excellent, thanks for writing and submitting it.
If you’re looking for post ideas, it’d be great to hear more about the tradeoffs of this model, why Windows moved away from it (or simply expanded on it?), and what other models are used by windowing toolkits. It’s been a curiousity of mine since seeing Casey Muratori’s videos on immediate mode graphics rendering for games - this early model you describe feels a lot like what I imagined ending up with.
Well, Win32 works that way under-the-hood, but people rarely program at that level anymore; they instead do more of an MVVP pattern based on callbacks that uses that machinery under-the-hood, but doesn’t expose it.
That said, I actually have no idea if WinUI has WndProcs under the hood. Do you know? I assume it does, but since you can’t access WndProc from there, and since there are plenty of other ways in the kernel to do message passing, I don’t know any reason why it would have to.
Yep. WndProc and messages are all still down there. I drop down to code at that level all the time, even in “high level” languages like C#. A good example would be when you want to change the behavior of a built-in control like a text box: say you want to filter keystrokes or have a custom background or something just a little non-standard.
Even weirder, a lot of hardware drivers, like TWAIN scanners, are built on top of the windows message passing and won’t work right if there is no window (at least a hidden window).
You will not need to care if you’re writing web apps.
Just to clarify: I know drivers and so on use WndProc under the hood, and that creating a hidden window is the normal way to do message passing on the traditional Windows API. My question was specifically about Modern UI, which, at least as of Windows 8.1 (the last time I looked at any of this), didn’t allow you to get down to the WndProc layer. (In fact, I think you only had access to very, very reduced versions of kernel32.dll, user32.dll, and gdi32.dll.) Further, since the NT kernel allows for totally different subsystems, it seemed plausible to me that Modern UI didn’t architecturally sit on top of Win32 in the first place. So I was wondering if, purely in the Modern UI area, WndProc was still a thing, or they were using a different system for internal message passing.
It is true that the WinRT support (for ARM) doesn’t use any of the old Win32 API. Those would be Metro-only apps that don’t run on regular x86/x64 Windows.
But the regular version of Windows8.1/10 definitely uses Win32/Winapi extensively.
I know drivers and so on use WndProc under the hood
The drivers don’t use WndProc. Usually WndProc is a callback that every windows application implements. Twain is a little different – but it runs in the application/user layer instead of the driver layer.
it seemed plausible to me that Modern UI didn’t architecturally sit on top of Win32 in the first place
It’s plausible. It’s just not exactly true. The window/message stuff is everywhere and easily accessible from almost every development platform: Winforms/C#, WPF, C++/MFC, etc.
I keep telling the junior devs that we haven’t invented anything new idea-wise in computing in over a decade (e.g. the argument over NoSQL style vs RDBM style from the 60s). I like that this article is approaching that a different, more accessible way. I could use to take some of that positivity in my own discussions on the topic.
I just hope we don’t have to reinvent MFC for browsers.
Databases are my favorite example of things not actually changing, also - although we have Spanner. But I do think a great many programming languages created in that timespan have new ideas, and it would be impossible to argue that we don’t know more about distributed systems than we did in 2005. I’d also suggest that, to the extent that cryptocurrency counts as computing, it’s certainly a new idea.
Curry-Howard is 1980. Things that are implemented in the language can be more recent. E.g. the “freer monad” stuff is novel as far as I can tell, and I expect that to one day become pervasive.
I assume so, but I don’t know. BeOS and OS/2 definitely did, so I find it very unlikely that X, which is a relatively old windowing system, worked differently, but you’d need to page @tedu or something to get a definitive answer.
Not sure. My dealings with X usually involve the not drawing side of things, but it’s pretty similar. You can sign up for “expose” events, which tell you which part of the window was damaged and needs to be redrawn. And then it’s a matter of whether you built your window out of a dozen subwindows or if it’s just a bitmap inside. As with Windows, nearly everyone builds on much high layer libraries like Qt or GTK/cairo these days.
That was excellent, thanks for writing and submitting it.
If you’re looking for post ideas, it’d be great to hear more about the tradeoffs of this model, why Windows moved away from it (or simply expanded on it?), and what other models are used by windowing toolkits. It’s been a curiousity of mine since seeing Casey Muratori’s videos on immediate mode graphics rendering for games - this early model you describe feels a lot like what I imagined ending up with.
Windows didn’t move away from this. There are other ways to program windows applications, but this is still how Windows works.
Well, Win32 works that way under-the-hood, but people rarely program at that level anymore; they instead do more of an MVVP pattern based on callbacks that uses that machinery under-the-hood, but doesn’t expose it.
That said, I actually have no idea if WinUI has
WndProcs under the hood. Do you know? I assume it does, but since you can’t accessWndProcfrom there, and since there are plenty of other ways in the kernel to do message passing, I don’t know any reason why it would have to.Yep. WndProc and messages are all still down there. I drop down to code at that level all the time, even in “high level” languages like C#. A good example would be when you want to change the behavior of a built-in control like a text box: say you want to filter keystrokes or have a custom background or something just a little non-standard.
Even weirder, a lot of hardware drivers, like TWAIN scanners, are built on top of the windows message passing and won’t work right if there is no window (at least a hidden window).
You will not need to care if you’re writing web apps.
Just to clarify: I know drivers and so on use
WndProcunder the hood, and that creating a hidden window is the normal way to do message passing on the traditional Windows API. My question was specifically about Modern UI, which, at least as of Windows 8.1 (the last time I looked at any of this), didn’t allow you to get down to theWndProclayer. (In fact, I think you only had access to very, very reduced versions ofkernel32.dll,user32.dll, andgdi32.dll.) Further, since the NT kernel allows for totally different subsystems, it seemed plausible to me that Modern UI didn’t architecturally sit on top of Win32 in the first place. So I was wondering if, purely in the Modern UI area,WndProcwas still a thing, or they were using a different system for internal message passing.It is true that the WinRT support (for ARM) doesn’t use any of the old Win32 API. Those would be Metro-only apps that don’t run on regular x86/x64 Windows.
But the regular version of Windows8.1/10 definitely uses Win32/Winapi extensively.
The drivers don’t use WndProc. Usually WndProc is a callback that every windows application implements. Twain is a little different – but it runs in the application/user layer instead of the driver layer.
It’s plausible. It’s just not exactly true. The window/message stuff is everywhere and easily accessible from almost every development platform: Winforms/C#, WPF, C++/MFC, etc.
If you’re using Windows then you can get a hold of an application called Spy++ (https://msdn.microsoft.com/en-us/library/dd460756.aspx). Watch the messages go to an fro to your heart’s content.
I suppose I should link to some references for all this.
I keep telling the junior devs that we haven’t invented anything new idea-wise in computing in over a decade (e.g. the argument over NoSQL style vs RDBM style from the 60s). I like that this article is approaching that a different, more accessible way. I could use to take some of that positivity in my own discussions on the topic.
I just hope we don’t have to reinvent MFC for browsers.
Databases are my favorite example of things not actually changing, also - although we have Spanner. But I do think a great many programming languages created in that timespan have new ideas, and it would be impossible to argue that we don’t know more about distributed systems than we did in 2005. I’d also suggest that, to the extent that cryptocurrency counts as computing, it’s certainly a new idea.
Everything in CS happened in 1969, +/- 1 year.
At least, that’s how it often feels.
I expect there is a lot of new ideas coming out of programming language research and specifically showing up in Haskell.
The ideas in Haskell aren’t particularly new. FP has been around a long time.
More to the point, Haskell was first standardized in 1998.
Curry-Howard is 1980. Things that are implemented in the language can be more recent. E.g. the “freer monad” stuff is novel as far as I can tell, and I expect that to one day become pervasive.
Excellent post. Just out of curiosity, did the X Window System have a similar model?
I assume so, but I don’t know. BeOS and OS/2 definitely did, so I find it very unlikely that X, which is a relatively old windowing system, worked differently, but you’d need to page @tedu or something to get a definitive answer.
Not sure. My dealings with X usually involve the not drawing side of things, but it’s pretty similar. You can sign up for “expose” events, which tell you which part of the window was damaged and needs to be redrawn. And then it’s a matter of whether you built your window out of a dozen subwindows or if it’s just a bitmap inside. As with Windows, nearly everyone builds on much high layer libraries like Qt or GTK/cairo these days.
Yes. So similar, in fact, that I was caught by surprise when the author’s gotcha was Win32 instead of the (“obvious”) X11.
Very few people have written anything directly X11 in their time. Usually it’s a lib built on top of X11 a few layers up.