windows95|任务栏发明之前,窗口是如何最小化的?

windows95|任务栏发明之前,窗口是如何最小化的?

在Windows 95操作系统引入资源管理器之前 , Windows的桌面是一个非常与众不同的存在 。
当时的桌面上的图标并不代表文件 , 而是当你最小化一个程序时 , 它会最小化成为桌面上的一个图标 。 如果你希望打开一个已经最小化的程序时 , 你必须在桌面上寻找它对应的图标 , 有可能你还需要最小化其他程序 , 从而让这个图标可见 , 然后双击对应的图标 , 从而恢复窗口的显示 。 (当然 , 你可以使用ALT + TAB这个组合键进行程序窗口切换 。
资源管理器的出现 , 修改了桌面模型 , 从而将桌面上的图标表示为一个文件或者文件夹 , 而不是之前的程序图标 。 而程序的显示管理则交给了新设计的任务栏 。
但是 , 不知道你是否想过 , 当一个程序的窗口最小化后 , 这个窗口去哪里了呢?
在旧的桌面模型下 , 当一个窗口被最小化时 , 它会被显示成一个图标 , 这个图标有一个特定的屏幕坐标 , 而程序通过绘制这个图标来响应窗口绘制消息 。 (当然 , 大多数应用程序会调用默认的DefWindowProc来绘制窗口图标) 换句话说 , 窗口一直都在那里 , 只是它的显示形态改变了而已 。
但是引入了任务栏组件之后 , 当一个程序的窗口被最小化时 , 它确实是消失了 。 它只会显示在任务栏上 。 对于如何处理最小化后的窗口 , 我们设计了若干实现 , 因为看起来不管我们怎么设计 , 都有一些用户不太能接受 。
第一种做法很简单:当一个窗口被最小化之后 , Windows 95的窗口管理器会将这个窗口设置为隐藏状态 。 这种做法在运行了很多应用程序的场景下 , 运作的并不是很好 。 因为有些应用程序需要严格区分窗口的最小化状态(依然可见)和隐藏状态(不再可见) 。
第二种做法是 , Windows 95的窗口管理器使用了旧版本的设计模型 , 将窗口最小化 , 但是会把最小化的窗口的坐标设置到(-32000 -32000) , 这也没能按我们预期的那样工作 , 因为有些应用程序在发现窗口坐标为负值的时候 , 会极大出乎他们的意料 。
所以 , Windows95的窗口管理器会尝试在坐标(32000 32000)位置对窗口进行最小化 , 这也没能正常工作 , 因为有些程序会对窗口坐标为正值但是数值非常大的场景感到意外 。
最终 , 设计方案将坐标改为了(3000 3000) , 这个设定看起来满足了所有人的预期 。 坐标不是负值 , 也不是很大 , 但是却能足够大而不至于显示在屏幕上(至少不会在1995年那个时候的屏幕分辨率下) 。
如果你运行一台拥有三台显示器的Windows 98机器 , 则你可以这样试试:
将每个屏幕的分辨率设置为1024*768 , 然后将它们并排摆放好 。 在第三台显示器的右下角 , 你会看到所有已经处于最小化状态的窗口 。
从Windows NT开始 , 设计方案还是将窗口最小化坐标修改为了-32000 , 并且因为某种原因不在考虑兼容性修复 。 我猜想 , 开发团队觉得当Window NT开始变得流行的时候 , 所有未兼容的程序都会修复这个问题 。 换句话说 , 还是让Windows 95来做这份脏活吧 。
总结
敢问老大哥一句:任务栏是否借鉴了Macintosh的Dock?
最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一 , 里面有很多关于Windows的小知识 , 对于广大Windows平台开发者来说 , 确实十分有帮助 。
本文来自:《Where did windows minimize to before the taskbar was invented?》
【windows95|任务栏发明之前,窗口是如何最小化的?】