OS/2的Presentation Manager，只是因为它是第一个为早期的Windows程式写作者（比如我自己）介绍多执行绪的环境。有趣的是，PM实作多执行绪的局限为程式写作者提供了应该如何架构多执行绪程式的必要线索。即使这些限制在32位元的Windows中已经大幅减少，但是从更有限的环境中学到的经验仍然是非常有效的。因此，让我们继续讨论下去。
在一个多执行绪环境中，程式可以将它们自己分隔为同时执行的片段（叫做执行绪）。对执行绪的支援是解决PM中存在的序列化讯息伫列的最好方法，并且在Windows中执行绪有更实际的意义。
就程式码来说，一个执行绪简单地被表示为可能呼叫程式中其他函式的函式。程式从其主执行绪开始执行，这个主执行绪是在传统的C程式中叫做main的函式，而在Windows中是WinMain。一旦执行起来，程式可以通过在系统呼叫CreateThread中指定初始执行绪函式的名称来建立新的执行绪的执行。作业系统在执行绪之间优先权式地切换控制项，和它在程序之间切换控制权的方法非常类似。
在OS/2的Presentation Manager中，每个执行绪可以建立一个讯息伫列，也可以不建立。如果希望从执行绪建立视窗，那么一个PM执行绪必须建立讯息伫列。否则，如果只是进行许多的资料处理或者图形输出，那么执行绪不需要建立讯息伫列。因为无讯息伫列的程序不处理讯息，所以它们将不会当住系统。唯一的限制是一个无讯息伫列执行绪无法向一个讯息伫列执行绪中的视窗发送讯息，或者呼叫任何发送讯息的函式（不过，它们可以将讯息递送给讯息伫列执行绪）。
这样，PM程式写作者学会了如何将它们的程式分隔为一个讯息伫列执行绪（在其中建立所有的视窗并处理传送给视窗的讯息）和一个或者多个无讯息伫列执行绪，在其中执行冗长的背景工作。PM程式写作者还了解到「1/10秒规则」，大体上，程式写作者被告知，一个讯息伫列执行绪处理任何讯息都不应该超过1/10秒，任何花费更长时间的事情都应该在另一个执行绪中完成。如果所有的程式写作者都遵循这一规则，那么将没有PM程式会将系统当住超过1/10秒。
