建站优化

当前位置:

windows操作历史,windows的操作系统和发展史

浏览量:27次

windows操作历史,windows的操作系统和发展史

  windows操作历史,windows的操作系统和发展史

  欢迎阅读“Windows命令行”系列的第二篇文章。在本文中,我们将讨论Windows命令行背后的一些背景和历史。具体来说,我们将探究它在MS-DOS中卑微的出身以及它的现代支持工具,比如Linux系统中的PowerShell和Windows子系统。

  1、命令行的由来

  2.Windows命令行的发展历史(本文)

  在本系列的上一篇文章中,我们讨论了命令行的历史和基本原理,并了解了命令行的架构如何随着时间的推移而基本保持不变,即终端从机电电传发展到现代终端应用。

  我们的旅程现在沿着一条相当复杂的道路继续,从早期的PC,通过微软和几个操作系统的合作,到今天复兴的命令行:

  简陋的开始- MS-DOS

  回顾计算机行业的早期,大多数计算机都是通过在命令提示行中输入命令来操作的。基于Unix、CP/M、DR-DOS和其他操作系统的计算机争夺领导地位和市场份额。最后,MS-DOS作为IBM个人计算机和装配工的标准操作系统脱颖而出,特别是在商业领域。

  MS-DOS 6.0

  和当时大多数主流操作系统一样,微软的MS-DOS“命令行解释器”或“shell程序”提供了一套简单、奇怪但相对有效的命令和一套用于编写batch(。bat)文件。

  MS-DOS很快被各种规模的企业采用,数百万个批处理脚本被创建出来,其中一些至今仍在使用。批处理脚本用于自动配置用户的机器、设置/更改安全设置、更新软件、编译代码等等。

  由于命令行脚本在后台运行,您可能永远看不到命令行脚本运行。举个例子,当你登录一台工作电脑时,实际上每天有数百亿个命令行脚本和命令在Windows上运行。

  因为命令行是一个需要耐心和坚持学习如何使用这些最有效的命令和工具的命令,所以大多数非技术用户都苦于使用命令行来有效地驱动他们的计算机,而大多数不喜欢命令行的人则不得不学习记忆大量短得令人难以置信的命令,以使他们的计算机做任何有用的事情。

  因此,迫切需要一种更加用户友好和高效的用户体验。

  

  图形化界面变成主流

  受施乐Alto的启发,图形用户界面(GUI)已经成为主流。

  很多有竞争力的GUI正在迅速涌现,包括苹果的Lisa和Macintosh,Commodore Amiga (Workbench),Atari ST (DRI的GEM),Acorn Archimedes (Arthur/RISC OS),Sun Workstation,X11/X Windows,还有很多其他的,包括微软的Windows:

  Windows 1.0于1985年问世。它基本上是一个MS-DOS应用程序,提供一个简单的窗口GUI环境,允许用户同时运行多个应用程序:

  Windows 1.01在MS-DOS上运行

  Windows 2.x,3.x,95,98都是在MS-DOS的基础上运行的。虽然后来的Windows版本开始替代以前MS-DOS提供的功能,但都是基于Windows的替代(如文件系统操作),都依赖于其MS-DOS基础。

  注意:Windows ME(千禧年版)是一个有趣的嵌合体!它最终用一些新功能(尤其是游戏和媒体技术)取代了MS-DOS的基础和上一版本Windows的实模式支持。Windows 2000中增加了一些功能(比如新的ip协议栈),在家用电脑上运行可能会比较困难。这个故事最终可能会成为一个有趣的帖子。(感谢蜜蜂对此的看法:)

  然而,微软知道,到目前为止,他们只能扩展MS-DOS和Windows的架构和功能:微软知道,它需要一个新的操作系统来构建他们的未来。

  微软-Unix市场的领导者!是的,我是认真的!

  在开发MS-DOS的过程中,微软也在忙于将Xenix ——微软的Unix版本7-交付给各种处理器和机器架构,包括Z8000、8086/80286和68000。

  到1984年,微软的Xenix已经成为世界上最流行的Unix变种!

  然而,美国政府拆分了贝尔实验室—— Unix的故乡——,这导致了ATT的拆分,后者开始向计算机制造商和最终用户销售Unix system V。

  微软认为,没有自己的操作系统,他们实现未来目标的能力将受到损害。这导致了从Xenix转型的决定:1987年,微软将Xenix的所有权转让给了其合作伙伴——圣克鲁斯运营公司(SCO)。微软在Xenix上开发了几个项目,在不同的平台上移植和增强Xenix。

  微软+IBM==OS/2

  1985年,微软开始与IBM合作开发新的操作系统OS/2。OS/2最初被设计成“一个更有能力的DOS”。它的设计利用了一些现代的32位处理器和原始设备制造商(包括IBM)的其他技术。

  然而OS/2的故事总是扑朔迷离。1990年,微软和IBM结束了合作。这是由许多因素造成的,包括IBM和微软开发人员之间的显著文化差异、时间安排挑战以及Windows 3.1采用的爆炸式成功和增长。IBM继续开发和支持OS/2,直到2006年底。

  到1988年,微软确信它未来的成功需要一个更大、更大胆和更有雄心的方法。这种方法需要一个新的现代操作系统来支持公司的宏伟目标。

  微软的大赌注——Windows NT

  1988年,微软聘请了戴夫卡特勒,他是DEC广受欢迎的vax/vms操作系统的创始人。Cutler的——的目标是创建一个新的、现代的、独立于平台的操作系统,在未来的大部分时间里,微软将拥有、控制和构建这个操作系统。

  这个新的操作系统变成了Windows NT ——。发展到Windows 2000,Windows XP,Windows Vista,Windows 7,Windows 8,Windows 10,以及Windows Server,Windows Phone 7,Xbox,Hololens的所有版本!

  Windows从一开始就被设计成平台无关的,最初是支持Intel的i860,后来是MIPS R3000、Intel 80386、DEC Alpha和PowerPC。此后,Windows NT操作系统被移植到支持IA64“Itanium”、x64和ARM/ARM64处理器架构的硬件上。

  Windows通过其Windows控制台终端应用程序提供了命令行界面和命令提示符外壳(cmd.exe)。Cmd被设计为尽可能与MS-DOS兼容的批处理脚本,以帮助简化企业对新平台的采用。

  PowerShell 的力量

  尽管Cmd仍然存在于Windows中(并且很可能在未来的几十年内都是如此),但因为它的主要目的是尽可能保持向后兼容性,所以Cmd很少得到改进。如果这些“错误”存在于MS-DOS或更早版本的Windows中,甚至“修复错误”有时也会很困难!

  2000年初,Cmd shell已经失去了它的威力,微软及其客户迫切需要一个更强大、更灵活的命令行体验。这种需求推动了PowerShell的产生(这来自杰弗里斯诺弗的“单子宣言”)。

  PowerShell是一个面向对象的Shel l L,与*NIX世界中基于文件/流的Shell不同:PowerShell脚本编写人员可以直接访问和操作对象及其属性,而不需要处理文本流,他们不必编写和维护大量的脚本来解析和操作文本(例如,通过sed/grep/awk/lex/等。).

  基于。net框架和公共语言运行时(CLR),PowerShell的语言和语法结合了。net与许多不同的外壳具有最常见的和其他有用的功能,重点是确保脚本高度一致和非常强大。

  要了解更多关于PowerShell的信息,我推荐阅读《PowerShell In Action》(Manning Press),作者是Bruce Payette,他是PowerShell语法和语言的设计者。在前几章中,以启发性的方式讨论了语言设计的基本原则。

  PowerShell已被许多微软平台技术和合作伙伴采用,包括Windows、Exchange Server、SQL Server、Azure和许多其他技术,并以高度一致的方式提供用于管理和控制Windows机器和/或环境的所有方面的命令。

  PowerShell Core,PowerShell的开源未来版本,适用于Windows以及各种版本的Linux、BSD、macOS!

  在 NT、Interix 和 UNIX 服务上的 POSIX

  在设计NT时,Cutler和他的团队专门设计了NT内核和操作系统,以支持多个子系统3354的用户模式代码与底层内核之间的接口。

  当Windows NT 3.1在1993年首次发布时,它支持几个子系统:MS-DOS、Windows、os/2 v1.3和POSIX v1.2。这些子系统允许NT在同一台机器和基本操作系统上运行应用程序,而无需虚拟化或仿真。——即使在今天,这也是一个强大的功能!

  虽然Windows NT最初的POSIX实现是可以接受的,但它需要显著的改进才能真正具备能力,因此微软收购了Softway Systems及其“Interix”NT子系统。Interix最初是作为一个单独的插件发布的,后来与几个有用的实用程序和工具结合在一起,在Windows Server 2003 R2和Windows Vista中作为Unix服务(SFU)发布。然而,SFU在Windows 8之后停止了,主要是因为客户缺乏兴趣。

  然后一件有趣的事情发生了。

  

  Windows 10 - 新时代的 Windows 命令行!

  在Windows 10开发之初,微软就开通了用户反馈页面,向社区询问操作系统各方面需要哪些功能。社区强烈要求微软:

  1.重点改进Windows控制台。

  2.允许用户在Windows下运行Linux的工具

  基于这些反馈,微软组建了两个新团队:

  1.Windows控制台命令行团队,接手并彻底完善Windows控制台命令行底层。

  2.另一个团队负责在Windows 10下运行Windows A的真实的、未修改的Linux二进制文件—— Linux子系统(WSL)。

  其他人,他们都说,那是历史!

  Linux 的 Windows 子系统(WSL)

  基于GNU/Linux的“分发”(Linux内核和用户模式工具集合的组合)的使用率一直在稳步增长,尤其是在服务器和云计算领域。虽然Windows有一个兼容POSIX的运行时,但SFU缺乏运行许多Linux工具和二进制文件的能力,因为后者的系统调用和行为差异与传统的Unix/POSIX不兼容。

  由于Windows客户和用户的反馈,以及微软内部不断增长的需求,微软做了很多调查,最终决定让Windows运行不加修改的,真正的Linux二进制文件!

  2014年年中,微软成立了开发Linux的Windows子系统(WSL)的团队。WSL最初是在2016年的Build大会上公布的,不久之后在Windows 10的内部版本中进行了预览。

  此后,在大多数内部版本中,自2016年秋季发布周年更新以来,WSL的功能广度、兼容性和稳定性都有了显著提升:WSL最初发布时,是一个有趣的实验,运行了几种常见的Linux工具,但未能运行许多常见的开发者工具/平台。团队迭代很快,并得到了社区的大量帮助(感谢所有社区!),WSL很快获得了许多新特性,使其能够运行越来越复杂的Linux二进制文件和工作负载。

  今天(2018年年中),WSL能够愉快地运行大多数Linux二进制文件、工具、编译器、连接器、调试器等等。许多开发人员、IT专业人员、devops工程师和许多需要运行或构建Linux工具、应用程序和服务的人都享受到了显著提高的生产力,他们可以在同一台机器上运行他们喜爱的Linux工具和所有Windows工具,而无需双系统。

  WSL团队继续致力于提高WSL执行许多Linux场景的能力,以及它与Windows集成的性能和体验。

  Windows控制台重启和检修

  2014年底,Linux构建Windows子系统(WSL)的项目如火如荼。由于对命令行的兴趣激增,显然Windows控制台需要一些TLC,应该根据客户和用户的常规需求进行许多改进。

  特别是,该控制台缺乏许多现代NIX兼容系统的功能,例如解析和呈现在*NIX世界中广泛使用的ansi/vt序列,以呈现丰富多彩的文本和基于文本的UI。

  那么,如果用户不能正确查看和使用Linux工具,那么构建WSL的目的是什么?

  以下是Windows 7和Windows 10中的控制台渲染示例:注意Windows 7中的控制台(左)无法在Windows 10中正确渲染tmux、htop、Midnight Commander、cowsay等Linux工具生成的VT(右):

  比较Windows 7和Windows 10中的控制台

  

  因此在2014年成立了一个新的小型“Windows主机团队”,负责破解、理解和改进主机的代码库.这个时候游戏机已经28岁了,3354比开发它的开发者还要老!

  任何曾经不得不采用旧的、粗糙的和不太优化的代码库的开发人员都可以证明,更新和优化旧代码通常是“棘手的”。在不破坏现有行为的情况下做到这一点更加困难。在不破坏数百万客户的脚本、工具、登录脚本、构建系统、制造系统、分析和生产系统的情况下,更新所有windows版本中最频繁的可执行文件需要大量的“细心和耐心”。

  为了应对这些挑战,团队很快学会了严格符合客户期望的控制台:例如,如果团队从一个版本偏离了两个控制台甚至百分之一的性能,Windows build团队就会触发警报,导致“嗯…”快速而直接的反馈”,通常需要立即修复。

  因此,当我们在未来的文章中讨论控制台的改进和新功能时,请记住,每一个变化都有一些不可侵犯的原则,包括:

  1.不要引入/暴露新的安全漏洞。

  2.不要破坏现有的客户(内部或外部)、工具、脚本、命令等。

  3.不要逆转性能或增加内存消耗/IO(没有明确和充分沟通的原因)

  在过去的3年中,控制台团队已经:

  控制台的内部结构检查了很多。

  极大地简化和减少了控制台中的代码量。

  替换几个内部实现的集合、列表、堆栈等。使用STL容器

  以及模块化和隔离的逻辑和功能单元,从而在不“毁灭世界”的情况下改进(有时替换)功能。

  将几个以前独立且不兼容的控制台引擎合并为一个

  增加了许多可靠性、安全性和安全性改进。

  增加了解析和呈现ansi/vt序列的能力,使控制台能够准确呈现来自NIX和其他现代命令行工具和应用程序的富文本输出。

  让主机呈现24位颜色,而之前只有16种颜色!

  提高控制台的可访问性,以便叙述者和其他UIA应用程序可以浏览控制台窗口的内容。

  添加/改进了鼠标和触摸支持

  工作还在继续!我们目前正在完成一些令人兴奋的新特性的实现,我们将在本系列的最新文章中讨论这些特性。

  那么,我们现在在哪里?

  如果你读到这里,恭喜你,谢谢你!

  那么,为什么要上历史课呢?

  希望你看了上面的历史就明白了。要知道命令行仍然是微软战略、平台和生态系统的关键组成部分。

  即使微软向最终用户提供Windows GUI,微软及其技术客户/用户/合作伙伴也严重依赖Windows命令行来完成大量的技术任务。

  事实上,如果没有一个快速、高效、稳定、安全的控制台,微软根本无法打造Windows本身或任何其他软件产品。

  在MS-DOS、Unix、OS/2、Windows时代的整个过程中,命令行仍然是每个技术用户工具箱中最重要的工具!甚至很多很少在控制台输入命令的用户,也会每天使用控制台!当您在Visual Studio(VS)中构建代码时,您的构建是在一个隐藏的控制台窗口中生成的!如果您使用Exchange Server或SQL Server的管理工具,那么许多这些命令都是通过PowerShell在一个隐藏的控制台中执行的!

  在本文中,我们讨论了很多问题:我们回顾了微软操作系统的一些历史,因为它与命令行和Windows控制台有关。我们还了解了Windows控制台的起源。

  在下一篇文章中,我们将开始深入研究这项技术本身。敬请期待!

[声明]本网转载网络媒体稿件是为了传播更多的信息,此类稿件不代表本网观点,本网不承担此类稿件侵权行为的连带责任。故此,如果您发现本网站的内容侵犯了您的版权,请您的相关内容发至此邮箱【779898168@qq.com】,我们在确认后,会立即删除,保证您的版权。