Inside the Windows Messaging System (1993)

http://www.drdobbs.com/windows/inside-the-windows-messaging-system/184408943

by userbinator • 7 years ago

100 31 7 years ago

petjuh• 7 years ago

Ha, reminds me of the days I used WINAPI programming. The message pump would be done with a simple while loop that has GetMessage(), TranslateMessage() and DispatchMessage().

frutiger• 7 years ago

It’s more or less the same today.

maxxxxx• 7 years ago

That knowledge is still valuable for example in figuring out why a WPF app doesn’t update its Ui. We have more abstractions today but under the hood it’s still the same.

polskibus• 7 years ago

Reminds me of react.

thrower123• 7 years ago

I've yet to see anything touted as groundbreaking on web front-ends that wasn't thoroughly explored by unix forty years ago or Windows twenty-five years ago.

sn_master• 7 years ago

Isn't it the same for hardware too ? Most of the "innovations" in PCs were explored decades before in mainframes/supercomputers.

gruez• 7 years ago

react has a message passing system? maybe if you're talking about react + flux. also, in windows, there's no render() that declaratively renders your widgets.

Narishma• 7 years ago

Is the page broken? Random paragraphs look like links but you can't click them.

ComputerGuru• 7 years ago

Yes, it is. A lot of old Dr Dobbs articles are like that; we're rather lucky they still exist and haven't vanished into the ether.

DonHopkins2• 7 years ago

Yep. Looks like somebody put in <a> tags with names around all the paragraphs to target them with links, then somebody else put in css to manually underline all a tags, not just ones with href's.

In Chrome just Right Click => Inspect one of the paragraphs, then in the element tree select one of the a tags and un-check the "#content .story a" css rule. Then your eyes will stop burning!

zvrba• 7 years ago

Nice historical perspective:

Say your database program gets a WM_COMMAND message, which it interprets to mean, "Go sort this database of 300,000 records," and dutifully conducts this 45-minute operation;

ww5203• 7 years ago

It was done on floppy disk.

derefr2• 7 years ago

Fun thought, that I never see anyone bring up. A Windows “window” is (and has been, since Windows 3.1) pretty much the same thing as an Erlang actor-process: a light pseudo-execution-thread that carries its own state and can send/receive arbitrary messages from peer windows, and—while normally only “doing” something when it receives a messsage— is conventionally driven to tick at regular intervals by timer messages it asks the system to schedule to send back to it.

It just-so-happens that unlike an actor-process, a Windows window usually has a GUI element attached to it. But not always! “Hidden windows”—i.e. plain actor-processes without the extra GUI bits—were the design pattern for doing background stuff for a long time before Windows introduced background services.

I bet some Windows developer here has a story of “that time I built an actor-modelled system just using Windows primitives.”

jimmaswell• 7 years ago

“Hidden windows”—i.e. plain actor-processes without the extra GUI bits—were the design pattern for doing background stuff back then.

Isn't it still the same? cmd can't be hidden and this is the advice I found looking to do something around 5 years ago. Unless you want services but those have certain limitations. No idea why they found it appropriate to prevent services from interacting with the desktop post-XP.

derefr2• 7 years ago

No idea why they found it appropriate to prevent services from interacting with the desktop post-XP.

It’s an architecture thing. Background services are supposed to be light things that just do the stuff the user can’t do at their own privilege level; they aren’t supposed to do stuff at the user’s privilege level, like showing windows, because mixing in that secondary concern increases their attack surface. Instead, if you have some background system that has some user-level concerns (like a GUI) and some system-level concerns, you’re supposed to build it as two programs: a tray utility or configuration program, which acts as an IPC client; and a background service, which acts as an IPC server.

You’re correct in that, even today, if you want a background service to be able to just arbitrarily pop up a message to you, you’re going to be writing a tray utility as a Win32 process that starts with a rootmost hidden window, to catch the IPC message the background service sends.

ww5203• 7 years ago

It's a huge security risk. Background service typically runs at higher level of privilege. Letting it expose a UI element opens up a huge attack surface. Other much less privileged processes can send messages to its window. An old trick was to send SetWinEventHook message to a service's window to hook an event callback in a dll. The dll is run in the service window's process and thus with its privilege. Privilege elevation achieved!

tonyedgecombe2• 7 years ago

No idea why they found it appropriate to prevent services from interacting with the desktop post-XP.

That's been a real pain for me, there are some API's I'd love to use but they aren't supported from a Windows service.

DonHopkins2• 7 years ago

"I made up the term object-oriented, and I can tell you I did have Windows in mind." -Alan Kay ;)

bitwize2• 7 years ago

Alan Kay did actually say that he wished he'd built Smalltalk's GUI around a single class: "a smart rectangle that can contain other smart rectangles". In other words, Windows windows.

Todd• 7 years ago

You're describing DDE. In use since Windows 2.0 and still functioning today in Windows 10, 32 years later.

https://en.wikipedia.org/wiki/Dynamic_Data_Exchange

https://docs.microsoft.com/en-us/windows/desktop/dataxchg/dy...

It's implemented with the WM_DDE_... series of messages. There's a library, DDEML, which wraps some of the complexities.

tonyedgecombe2• 7 years ago

I seem to remember Invoke and BeginInvoke in Windows Forms work by using SendMessage or PostMessage to send a reference to the delegate to the message queue. I vaguely remember apartment threading in COM does this as well.

linux2647• 7 years ago

A quirk in the messaging system rears its head when you try to write a Windows-hosted debugger (also called a "GUI debugger"). A GUI debugger is a debugger for Windows programs that itself uses the Windows display mechanisms. What's the problem with that? Well, imagine the following scenario: A GUI debugger places a breakpoint inside of a Window procedure. Eventually, the debuggee program hits the breakpoint, and stops--and cannot call GetMessage() to yield control to other tasks! That means no other tasks--including the GUI debugger--can get their messages. The debugger can't even respond the mouse clicks that tell the debuggee to run again.

That’s unfortunate

asveikau2• 7 years ago

Keep in mind this is describing windows 3.x. Win95 and NT had preemptive multitasking and did not rely on calling GetMessage to yield.

fsfod• 7 years ago

The effect still exists in some way in later version windows like the Windows Volume Mixer will freeze up or won't open if you have an application stopped at a breakpoint. I think it gets stuck waiting for a reply from something like WM_GETICON that it would have to send to top-level windows.

SapporoChris• 7 years ago

I enjoyed this article very much. I still use SendMessage and heavily rely on pinvoke.net mainly for automating other programs. I have to take this opportunity to ask the crowd are there better resources or better tools for automation? Being retired, I mainly automate for my own amusement, websites and games on Bluestacks are my primary targets.

welcome_dragon• 7 years ago

I really miss Dr Dobbs (when it was a thicker physical magazine). As a budding programmer, I learned so much from it

Inside the Windows Messaging System (1993)

Related Stories