伴随 Windows 发展已超 25 年的 Raymond Chen，刚刚在一篇《The Old New Thing》开发者博客中调侃了系统剪贴板（clipboard）存在的所谓“最大数据限制”Bug 。他以行数 30 万+的一份大型电子表格文件为例，当用户打开后选中了所有行、并将之复制到剪贴板后，就会在粘贴至另一应用程序时遇到问题。
假设这个应用程序使用了 GetClipboardData 函数，以检索富文本格式的数据。那你就会遗憾地发现 —— 函数竟然返回了空值（NULL）。
许多人或许会猜测，该问题或与剪贴板的数据上限有关。
然而 Raymond Chen 指出，事情并非如此 。
剪贴板未预设可提取数据的最大值，其内容仅受可用内存和地址空间的限制。
为避免 GetClipboardData 调用失败，主要有两种替代方案 —— 一种是将数据直接放到剪贴板，另一种就声明拥有特定类型的数据、而不直接将它放到剪贴板上。
对于很少被使用、或生成资源耗费过高的数据格式时，常见优化方案是利用剪贴板的延迟渲染（delay-rendered）。
然后在被询问数据的格式时，数据源的使用者会收到一条 WM_RENDERFORMAT 消息 —— 某人想调用该数据，你是否选择即时生成？
Raymon Chen 解释称：
Excel 本身无法以富文本格式运行，其放置在剪贴板上的此类数据，都是延迟渲染得来的。
然后当另一个程序要求提供富文本格式数据时，Excel 会给出这样的回应 —— 哦，好的，请稍等，我这就帮你去拿。
据悉，富文本并不是数据表的最佳格式，因为它主要是为了文本而设计的。即使可以搞定简单的表格，但更复杂的任务就跑不顺了。
当系统要求剪贴板的所有者呈现数据时，它会发送消息并等待最多 30 秒返回。
若未能在 30 秒内生成数据，则系统会放弃请求、并导致 GetClipboardData 返回 NULL 空值。
本例的问题，在于原表实在太大，导致 Excel 需要超过 30 秒才能生成富文本格式表。后续开发团队会设想通过特殊手段，来延长此类处理的等待时间。