The clipboard holds UTF-8 text, and data by MIME type beside it. Every operation is a request of a window, answered by a completion, because the platforms answer late or ask the user first: the browser may ask, iOS asks before reading another application's text, and on Wayland and Android only a focused window may use the clipboard.
mwinWindow_RequestClipboardWrite puts text there. Text that is not UTF-8 is refused with mwin_errorInvalid, and text past clipboardBytes (1 MiB by default) with mwin_errorCapacity.mwinWindow_RequestClipboardRead reads it. When the read completes done, mwinRequest_GetClipboardText copies the text into the program's buffer; it takes the read's request from the completion record, so it never answers one read with another's text.mwin_outcomeTooLarge rather than arriving cut short.mwinWindow_RequestClipboardWriteData offers up to four items, each a MIME type and its bytes, one of which may be text/plain as the clipboard's text. mwinWindow_RequestClipboardReadData asks for one type and mwinRequest_GetClipboardData copies it out; a clipboard without the type completes the read failed. Bytes pass through unchanged: an image goes as PNG the program encodes, and a program reads the bytes another program put there. A text write replaces the data, and a data write the text. Android takes text only.
On X11 and Wayland, mwinWindow_RequestPrimaryWrite, mwinWindow_RequestPrimaryRead and mwinRequest_GetPrimaryText use the primary selection, the text last selected and pasted with the middle button, apart from the clipboard. Elsewhere they answer unsupported.
Two reads on one window in one frame paste once: the first is superseded. A getter answers mwin_errorStale for a read whose payload a later read of the same kind replaced.
While something is dragged over a window, the program hears mwin_eventDragEntered, mwin_eventDragMoved and mwin_eventDragLeft, with the place and what the drag holds (files, text). A drop brings mwin_eventDropped instead of the leaving. Windows take every drag of files or text; a program that does not want one ignores it. On X11 and Wayland, a drop is read from the dragging program after it is made, for at most five seconds, and a drag that comes meanwhile is refused and not reported. On Android, a drag that enters the window while the last drop's documents are copied ends that copy instead: the last drop arrives first, with the documents already whole, marked truncated, and then the new drag's records. A drag over a window the program destroys ends with the window: none of its records reach another window, and a drop still being gathered is refused, its copies on Android stopped.
The drop's payload waits under the drop's id from its record: mwinDrop_GetFiles copies out its paths, each UTF-8 and ended by a NUL, and mwinDrop_GetText its text, until the next drop makes that id stale. A path that is not UTF-8 names no file the program could open and is left out. Past droppedFiles (256) files or dropBytes (1 MiB) of paths or text, what does not fit is left out whole and the record's truncated says so. It says so too when the dragging program handed its files or text over in a form that could not be read.
A drop gives files and at most one text, and what it can leave out depends on how the platform hands a drag over. On Windows, X11 and Wayland, a drag is one thing offered in several formats: the library reads its files and its text, and a format it does not read leaves nothing out. A web page's drag holds its files and at most one text, also in several formats, of which the library reads the plain text. On macOS, iOS and Android, a drag is a list of items: each item that is a file gives a file, the first of the others that is text gives the drop's text, and any other item, a text after the first or one that is neither, is left out and the drop marked truncated.
A path names a file; nothing is granted with it. On the web a page sees file names, never paths. On iOS and Android, whose documents have no paths a program can keep, each dropped document is copied into the application's temporary or cache folder first, and the drop arrives once every copy is whole. A document that cannot be read or copied is left out, and the drop marked truncated. On iOS, so is a text that does not load: the user dropped something the program did not get. On Android, so is a document whose application sends nothing for five seconds. X11's and Wayland's five seconds bound the whole read of a drop's list of files from the drop. Android's start again with each piece a document's application sends, since a whole document can take longer to copy than that while it still comes. An application that keeps sending slowly holds the drop until another drag enters the window, which ends the copy as above, or the program destroys the window. A drag elsewhere on the device does not end it.