How do Ctrl+C and Ctrl+V work?

One thing in common across all systems is that keyboard shortcuts such as CtrlC are not system-level – they are handled by each program individually, just like the "Copy" or "Paste" menu items are specific to each program. So it's not the OS itself that "copies" something, but rather it's the app (Word) that uses some OS-specific function to put data in the global clipboard.

Windows

In Windows the clipboard API and storage buffer are provided by the OS at kernel level. (The clipboard belongs to the "window station" kernel object.)

• When you "copy" something, the program will store the "copied" data using the Win32 API function SetClipboardData(), which also corresponds to NtUserSetClipboardData() in the Native API.

  Normally the copied data is immediately stored in the OS-managed clipboard buffer and no longer depends on the source program. The program can provide several different formats – e.g. text copied from Word can simultaneously come in HTML, RTF, and plain-text formats in addition to Word's own format.

  However, the program may store 'null' data and defer conversion until a paste is requested using WM_RENDERFORMAT, e.g. if the copied data is large. In this case the data is lost when the program is closed. You might've seen Word or Photoshop ask about this when exiting the program.

  (Note that when you "cut" or "copy" a whole file through Explorer, this doesn't put the entire file's contents in the clipboard, but only a file reference that Explorer itself will understand when it's pasted.)

• When you ask the program to "paste", the program chooses the desired format and retrieves it using GetClipboardData(). Some programs, e.g. WordPad or Paint, have a "Paste as" feature that lets you choose the preferred format (e.g. if you copied from a web browser but want to paste without formatting).

See also the blog post "NT Debugging: How the clipboard works".

Linux, BSD, Solaris, OpenVMS

In Linux and other similar systems, the clipboard is provided by the graphical environment you're using (that is, an X11 server or a Wayland compositor) – there is no shared clipboard for programs running outside such an environment.

X11

X11 handles the clipboard a little bit differently – the X server doesn't provide storage at all, it only facilitates communications between the copy-source program (which announces that it has something "copied") and the paste-target program.

Both the initial "copy" announcement and the later "paste" transfer are done via X11 messages according to the ICCCM protocol. (Each X display therefore has a separate clipboard

• Upon pressing CtrlC, the source program will keep track of "copied" data in its own memory and will claim ownership of the X11 "selection" called 'CLIPBOARD', which is done using XSetSelectionOwner().

  This ownership is tracked centrally by the X server (e.g. Xorg). Whenever you "copy" something new, the previous app that owned the 'CLIPBOARD' selection is informed about losing its ownership so that it can discard the now-unneeded data.

  Because clipboard transfer is always deferred, the copied data is usually lost as soon as you close the "source" program (unless you're running a "clipboard manager" which proactively stores everything that is copied). So if you copy something from Firefox and then close Firefox, you cannot paste it anymore.

• When pasting, the program will look up the current owner of the 'CLIPBOARD' selection using XGetSelectionOwner(). Similar to Windows, it is possible for X11 clipboard to hold data in several alternative types so the destination program will ask the source for the preferred type using XConvertSelection().

  (Usually a special type named 'TARGETS' is available, which has the source program return an ASCII list of data types that are currently available.)

See this link for a practical example.

Note: When you "copy" text by selecting it and paste it using middle-click, the mechanism is the same but the 'PRIMARY' selection is used instead. This is where the term 'X11 selection' comes from.

Wayland

I don't actually understand how it works in Wayland, all I have is the protocol docs:

• https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-data-sharing

• https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_data_device

• See https://github.com/bugaevc/wl-clipboard for a command-line tool.

Non-graphical programs

Traditional text editors (Vim, emacs, nano) often have their own internal clipboards (aka registers/killrings).

Terminal-based apps may access X11 or Wayland clipboards if running inside a graphical terminal emulator, e.g. Vim's "+ register will paste from the X11 clipboard (whereas other Vim registers are internal to the program).

macOS (Mac OS X)

In macOS, something called a "pasteboard server" appears to be used (which I think means that programs communicate with it through Mach APIs). Other than that, it behaves like the Windows clipboard and stores the currently copied data itself.

• https://developer.apple.com/documentation/appkit/nspasteboard

• There is a sample application: https://developer.apple.com/library/archive/samplecode/ClipboardViewer/Introduction/Intro.html

I'm more intrigued with images, how can they be copied so easily

There is nothing special about images – they're still just chunks of binary data that can be represented as bytes, so if they can be saved in a file (e.g. in PNG or JPEG format), they can also be stored in the clipboard using the same format.

Windows apps typically store copied images in BMP/DIB formats (the same as in a .bmp file), while on Linux it is common for apps to offer PNG (i.e. "image/png" target).