CTSS是在1963年和64年间开发的。当时我在麻省理工学院的计算机中心工作。在为CTSS编写了几十个命令之后，我到达了一个阶段，我觉得命令应该像子例程库一样，可以用作编写更多命令的构件。因此，我写了“ RUNCOM”，这是一种用参数替换驱动命令脚本执行的外壳。该工具立即成为最受欢迎的工具，因为它有可能在晚上回家，而留下长时间运行的runcom。它非常适合无聊和重复的任务，例如重命名，移动，更新，编译等。整个文件目录用于系统和应用程序的维护和监视。
同样，我也认为命令应该可用作库子例程，反之亦然。这源于我在MAD（密歇根算法解码器）（一种简化的类似于Algol的语言）中编写CTSS命令的实践（当时是唯一的）。它比IBM 7094汇编代码更快，并且代码更易于维护。由于我需要MAD友好的子例程调用来访问CTSS原语，因此我在汇编代码中编写了一系列接口子例程，这些子例程经常模仿CTSS基本命令功能。或者我想从处理常规杂事的子例程中发出命令。我觉得这很麻烦。但是，在CTSS的背景下，我没有走得更远。
然后在64年出现了Multics设计时间，我参与其中的时间并不多，因为我已经明确表示我想在65年中返回法国。但是，仍然以某种方式像编程语言一样使用命令的想法仍然存在。我的想法英国科学家克里斯托弗·斯特拉奇（Christopher Strachey）当时访问了麻省理工学院，他的宏生成器设计对我来说似乎是掌握命令语言的坚实基础，尤其是引用和传递参数的技术。在没有被邀请参加该主题的情况下，我写了一篇论文，解释了如何使用该目标设计Multics命令语言。我创造了“壳”这个词来命名。它必须在64的末尾或65的开始。
一小群的Multics向导发现这是一个时尚的主意，但他们希望在语言语法方面做些更精致的设计。由于剩下的时间很短，而且我不是语言设计专家，所以让他们辩论这个问题，而是制作了Shell的程序流程图。在我离开编写第一个Multics shell之后，就使用了它。格兰达·施罗德（Glenda Schroeder，麻省理工学院）和一名GE员工共同完成了这项工作。
分时是一个错误的说法。尽管它确实允许共享中央计算机，但它的成功源于共享其他资源的能力：数据，程序，概念。它破解了编写和调试程序的关键路径瓶颈。从理论上讲，这也可以通过直接访问方法来实现。实际上，它做不到。
直接访问在静态框架中限制用户。进化是不频繁的，并且由中央和遥远的主体控制。创造力不在用户手中。
随着时间的流逝，时间共享是一种生命有机体，在其中，具有各种专业知识的任何用户都可以创建新对象，对其进行测试，并将其提供给其他人使用，而无需管理控制和麻烦。有了互联网的经验，这不再需要证实。