TL;DR：我个人认为微软不会对全局原子表进行任何更改，因为这只是一个次要的安全问题。
原子表可让您将字符串与 16 位数字相关联。你给 Windows 你的字符串，它会给你一个数字。然后，您只需知道分配的数字即可再次检索该字符串。
每个正常进程都有自己的本地原子表，但它通常是空的，不是安全问题。
有多个“全局”原子表被同一个window station 中的所有进程共享。其中 1 个已记录在案，称为全局原子表。 MSDN 对tell us 也很友好，RegisterClipboardFormat 和RegisterClass 在他们当前的实现中也在内部使用他们自己的原子表。 SetProp 等其他函数也使用原子，但我们只对漏洞利用使用的原子表感兴趣，原子通过 GlobalAddAtom 函数添加到该表中。
这个原子表的主要目的是充当一个简单的存储位置，以便不同的进程可以在称为DDE 的协议中相互通信。当一个进程想要向不同进程中的窗口发送消息时，您不能发送超过 8 个字节（2 个参数，每个 4 个字节），并且这没有足够的空间来传输文件系统路径或 URL。
为了解决这个限制，应用程序通过调用GlobalAddAtom 将字符串/路径/URL 存储在公共全局原子表中。 GlobalAddAtom 返回一个应用程序可以发送给其他进程的数字。当其他进程收到 DDE 消息时，它只是将数字传递给GlobalGetAtomName 函数以检索字符串。
这怎么会是一个安全问题？事实证明，这个过度炒作（恕我直言）利用 uses 全局原子表来完全按照表的设计目的进行操作；将字符串从一个进程传输到另一个进程。
要将代码注入另一个进程，您通常会调用OpenProcess 来获取所需进程的句柄，VirtalAllocEx 在此进程中分配一些内存，WriteProcessMemory 用您的代码填充这个新分配的内存，最后CreateRemoteThread 开始执行这段代码。
漏洞利用基本上以复杂的方式（NtQueueApcThread）调用GlobalGetAtomName，以避免使用WriteProcessMemory。更令人印象深刻的是它如何构建 ROP 链并使用 NtQueueApcThread 执行它，但这与原子表无关，原子表只是一种不寻常/聪明的内存传输方式。
漏洞利用不允许恶意代码提升或以其他方式获取源进程尚未拥有的权限，因为NtQueueApcThread 不能用于任何随机进程，您仍然需要适当的权限才能访问所需的目标进程。 NtQueueApcThread 可能在漏洞利用出现时让一些反病毒公司措手不及，但作为一个必须由某人首先执行的独立代码，它本身不能造成太大的损害，它必须结合起来加上其他代码就吓人了。
Microsoft 可以删除原子表吗？不，不是真的，其他表太重要了。
他们可以删除全局原子表吗？不，不是，它是一个记录在案的 API，并且已经有 20 多年的历史了，Microsoft 不喜欢破坏兼容性。
但是，他们可以稍微中和全局原子表。他们可以通过根据调用进程的integrity level 将其划分为多个隔间来降低全局性。这不会改变有问题的漏洞利用，因为它首先无法访问具有更高完整性级别的进程。
如果我们假设 Microsoft 更改了全局原子表，使其充当每个进程的表，会发生什么情况？
Microsoft 在 Windows XP 中开始远离 DDE，但在 Vista/7 中更加认真地对待它。在这台 Windows 8.1 机器上，Internet Explorer 仍将 DDE 用于“在同一窗口中打开”命令，但这不是 .html 文件的默认动词。在注册表中搜索 ddeexec 以查找所有使用 DDE 处理其文件关联的应用程序。从好的方面来说，文件关联 DDE 仅在应用程序实例已打开时使用。最坏的情况是;在双击新文件之前关闭应用程序。
DDE 也可以用来做其他事情，但很难说哪些应用程序和/或功能会损坏以及它们会损坏到什么程度。
全局原子表可用于 DDE 以外的其他事物，但很难说这样做有多普遍。
如果全局原子表被限制为仅将其字符串共享给具有相同文件名的进程，那么很多这些问题都会消失，因为它通常只用于与同一应用程序的其他实例进行通信。