How the Clipboard Works, Part 1 | Hacker News Reader

How the Clipboard Works, Part 1

blogs.msdn.microsoft.com

70 pointsnoselasd13 comments

> hData is null! Why is that? It turns out that the clipboard allows an application to pass in null to SetClipboardData for a given format.

"Turns out"? This is clearly spelled out in the MSDN API documentation, which is all you need to understand all this. (No NotePad stack traces required, let alone ones in a proportional font).

SetClipboard: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

hMem [in, optional]

Type: HANDLE

A handle to the data in the specified format. This parameter can be NULL, indicating that the window provides data in the specified clipboard format (renders the format) upon request.

Very interesting article. Can anyone comment on how this differs from clipboard access in *nix land? One of the things I miss about Windows is that copy+paste between applications is a lot more seamless.

https://www.jwz.org/doc/x-cut-and-paste.html

Oh wow, nice referral based redirect. Why though? jwz.org has some great articles, why the HN hate?

Pretty sure it's set up by JWZ to redirect on links from HN, not by HN to jwz.org links.

He's written pretty extensively (and in my opinion, not wholly incorrectly) about why the types who frequent this community is not one whose members he cares to appease.

> Since the clipboard is part of Win32k.sys, you’ll need to use a kernel debugger.

I'll never understand why they ruined the perfectly good design of Windows NT 3.x by moving everything + kitchen sink into the kernel.

A bug in the clipboard functions shouldn't be a kernel exploit vector.

My understanding, home desktop performance.

Even today you read articles like "SQlite 35% faster than the filesystem"[1], which boil down to one idea: kernel-space<->user-space interaction is slow.

This fact forms the basis for almost evey FUSE optimization.

[1] https://www.sqlite.org/fasterthanfs.html

Windows NT 3.5 ran the Win32 subsystem inside csrss.exe [1]. But csrss.exe was and continues to be a "God process" that is game-over if compromised. The difference between NT AUTHORITY\SYSTEM (what CSRSS runs as) and the kernel isn't particularly meaningful to an attacker: both are essentially unrestricted access.

[1]: http://j00ru.vexillium.org/?p=492

At the time they said it was for performance reasons. It was a problem though, I remember crashing a server on one site just by viewing a print queue.

Here's a real world example: https://github.com/sindresorhus/win-clipboard/blob/218dcffb9...

Should be marked with a [2012] tag.

Super interesting article though.

I will never understand people who publish technical articles with code examples in variable width font.

Reply on news.ycombinator.com