为什么Windows 9x软件可以在Windows 7 64位上运行?


-1

多年以来(在推出Windows XP之后很久),我运行了一系列旧的Windows 9x台式机。基本上,这些机器的硬件规格太低,无法升级到XP(并且花了很多钱),所以我继续使用它们的原始软件:Windows 98SE和Windows ME的各种安装(全部运行)作为32位版本)。

在这种情况下,我从未使用过XP。Win9x机器非常可靠,在XP和Vista出现之后,它们仍然可以使用很长时间。但我最终不得不在一段时间内迁移到Windows 7 64位。

我不打算做一些非常愚蠢的事情,比如问为什么这样的程序不会在Win7 64bit上运行!:-)

毫无例外,我在32位Windows 98SE上运行的所有软件都在Win7的NT 64bit架构上开箱即用(可以这么说)。今天,我仍然使用各种软件,特别是我经常使用的文字处理程序和HTML编辑器。

是否有技术原因导致我从未遇到过在64位NT上运行Windows 9x程序时遇到的困难?我被告知Win7上的“兼容性”设置,但从未必须以“兼容模式”运行程序。

我知道Windows 7将32位和64位软件保存在不同的位置,并以不同的方式处理它们:但我原本预计这与为Windows 7编写的32位和64位程序有关。

我很惊讶Windows 98 32位程序似乎与Windows XP / Vista / 7 32位程序完全兼容,并且想知道为什么会这样。它们之间真的没有区别吗?

此外,许多旧的Windows 9x程序都是可移植的。我一直习惯将它们放在USB记忆棒上,或者放在Windows 7桌面上,然后运行它们。我没有遇到任何问题。即使它们没有从Program Files文件夹运行。同样,我想从技术角度理解为什么操作系统不反对这一点?

我做了什么不安全的事吗?Windows 7 O / S似乎非常稳定:但我想知道我是否要求它做我不应该做的事情。

Answers:


3

您必须是第一个抱怨的用户,因为他/她没有任何问题。;)

虽然主流媒体已经花了很长时间才能在应用程序兼容性领域给Windows带来不应有的声誉,但事实是微软已经在后向兼容性方面投入了大量资金,而且为Windows 98编写的绝大多数应用程序仍可在Windows 7上使用。 ,Windows 7是微软有史以来最稳定的操作系统。没有错,Windows 7和Windows 98之间的差异很大,但是:

  • Windows 98利用了丰富的Windows API,微软并没有因为重新编写而无法重复编写!例如,在屏幕上绘制矩形创建窗口显示菜单栏的界面仍然相同。
  • Windows 7已实施旨在解决传统软件兼容性问题的措施。其中之一是UAC虚拟化。Windows 98应用程序将其应用程序数据写入其安装文件夹。Windows 7不允许这样做了; 但是,对于旧版应用程序,UAC Virtualization会将应用程序安装文件夹外部的数据写入操作重定向到%LOCALAPPDATA%\VirtualStore

不再适用于Windows 7的Windows 98时代的应用程序包括16位应用程序(不能在64位Windows上运行但有时在32位Windows上运行)以及依赖于黑客或神秘传统操作系统服务的应用程序。


1
tldr:他们保持API和ABI的兼容性;)
Journeyman Geek

...并实施了兼容性措施,如UAC Virtualization

@FleetCommand:我打开%LOCALAPPDATA%\ VirtualStore,奇怪的是,该文件夹是空的。其父目录中有大量条目,%LOCALAPPDATA%,但在\ VirtualStore中为zilch。顺便说一句,当我提到使用32位Win9x软件时,我完全准确,我很久以前就放弃了任何剩余的传统16位程序。
Ed999

1
缺少16位支持与英特尔决定模式工作时间以及如何禁用16位应用程序在启用长模式时运行所需的指令有关。我意识到这是一个随意的
事实--Ramhound

1
@ Ed999:再次,这只能是好的!你有文明的应用程序。当然,您确实提到“许多旧的Windows 9x程序都是可移植的”和“它们不是从Program Files文件夹运行”。因此,文件系统没有UAC虚拟化。(我们也为注册表提供了UAC虚拟化。)

1

你在这里问了很多问题,有些问题比较复杂,但基本答案是“微软在维护向后兼容方面付出了很多努力”。老实说,一个更好的问题可能是“为什么它不会起作用?”,因为Win9x和NT(包括Win7)都使用Win32 API和x86指令集(AMD对Intel x86指令集的64位扩展是向后兼容的;在64位模式下运行的“x64”处理器也可以运行32位程序。

事情不起作用的最可能原因仅仅是因为访问控制。Win9x根本不支持任何类型的访问控制; 任何程序都可以做任何想做的事情。恶意使用,这使得编写恶意软件非常容易。非恶意但懒惰地使用,这意味着许多开发人员编写了他们的程序,以便程序将数据写入他们的安装文件夹。出于多种不同的原因,这是一个坏主意,其中最重要的是安全性; 在“真实”操作系统上,安装文件的默认位置不允许非管理员写入文件,除非安装/更新软件,否则您应该以非管理员身份运行。

当然,这整个“写入你正在运行的目录”的事情很简单(我确实说开发人员很懒惰......)是的,它也使软件“可移植”在你可以把它放的意义上在flashdrive上(通常也完全没有访问控制,因为他们使用FAT文件系统的变体而FAT不支持文件权限)。运行软件这种方式比它安装到访问受限区域,并从那里运行它(作为一个非管理员用户)安全性较低,但只要你不与他人共用电脑,它可能只要确定。

至于操作系统为什么不反对...为什么你会期望它呢?Program Files它不是一个特殊的文件夹,它只是按照惯例安装程序的地方。(这实际上是一个非常愚蠢的约定,因为如果你将它安装到路径中有空格的位置,某些软件就会中断,但是MS可能希望确保开发人员不那么懒惰...)唯一的特殊之处Program Files是在64位系统上,当32位进程要求“Program Files”文件夹时,它们实际上被定向到该Program Files (x86)文件夹。除此之外......操作系统允许您从用户可以访问的任何地方运行程序。有些程序有意安装在您的用户配置文件中,或者安装在驱动器根目录下的自己的文件夹中(C:\Python27是在开发人员计算机上看到的常见文件夹)。那些程序运行得很好。


我不同意你对“开发人员懒惰”的冲击 - 在那些时候安全概念是未知的或不需要的,并且通常不允许开发人员花费很多时间来处理被认为无关紧要的事情。你所做的就像是在17世纪指责人们不要让街道足够宽敞的汽车。否则很好的答案。
Aganju

1
@Aganju:只有当你对计算世界一无所知时才会“未知”,在这种情况下你可能不是开发者。多用户操作系统中的安全基本原则可以追溯到1969年发布的Multics.Unix是一种更简单(但仍然安全)的语言分支,于1973年首次发布,并在70年代后期广泛使用。微软自1980年开始销售Unix(Xenix).Windows NT系列产品在很大程度上归功于Unix(包括安全产品),它于1993年首次发布(Linux,BSD和许多其他* nix操作系统都存在)。到1998年,没有任何借口无知。
CBHacking

自70年代以来,我一直在发展,但支付账单的人不想听到花一分钱安全。自2005
--Aganju

1
@Aganju:至于“不需要”,那是完全错误的。这是现在的要求,而且非常需要。Win98(甚至95,有一些发布后升级)表面上是一个多用户系统,因为它没有任何机制来强制实施用户间安全性。没有针对恶意软件的保护(并且有大量恶意软件)。然而,企业(和一些家庭)正在使用NT,它具有这些功能。至于“很多小时”,嗯,没有。写起来并不难,%APPDATA%\ProgramName\Filename而不仅仅是为了Filename!纯粹的懒惰。
CBHacking
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.