在Windows 7进入开发的最后RC阶段时,微软的Windows and Windows Live Engineering Group副经理Steven Sinofsky透露了一个数据.
那就是可爱的测试者们向微软提供了2000多个Bug线索,帮助Windows 7顺利完善,最频繁的时候微软甚至每15秒就会接到一个错误报告,一共收到超过50万份问题报告,每个开发人员要处理500余份.
微软在此对MSDN/TechNet和Connect的用户表示感谢.此外,微软还对包括硬件支持和UAC改进在内引起争议的改进作了特别的说明,这些议题曾经让开发人员和测试人员闹不愉快,后来都得到了完美的解决.
微软最近已经变得不像以往那么固执,更容易接受的反馈意见,当UAC功能被发现重大漏洞时微软最初拒绝改变它,然而几天时间,用户就让微软的态度180度大转弯.
因此，Windows 7的发布能再次拉动个人电脑销售吗？即使是预发行时期，Windows 7的稳定和性能无论在博客还是在网站上，已经产生了显著的、真实和正面的回响。一些零星的证据显示很多人愿意Windows 7发布时购买一台新机器。
分析师在接受InternetNews.com采访时对Windows 7有助于个人电脑销售表示谨慎的乐观。不确定的经济形势犹如笼罩在人们头上的一团阴云，让人不由自主地压抑着自己的情绪。
影响情绪的还有微软还没给出Windows 7的发布日期。InternetNews.com了解到的情况是微软内部的日期是在2009年6月。根据对beta版本的表现和赞扬来看，6月份发布的可能性非常大。
在Beta版本中确认支持DivX文件以后,Windows 7开发人员又对Windows Media Player作出了明显的改进---开始原生支持.mov文件.
这一格式对于喜欢数码产品的朋友们来说一定不陌生,它是许多数码相机抓去视频的默认格式,也是许多产品介绍中的视频所用格式,这也意味着观看这种视频不再需要下载Apple QuickTime,直接在网页中打开就可以了.
Aero Peeks 支持Alt+Tab
陈瑞聪认为，在当前经济形势下，广受好评的Windows 7可能会有助于刺激PC销量，而如果能在年底购物季之前及时就绪自然会更好。
他还预测今年的全球笔记本出货量为1.25亿部，只比去年多500万部。
微软CEO史蒂夫・鲍尔默昨天宣称Office 14不会在2009年发布，但继续拒绝透露Windows 7的发布时间，只是说这是一件"极为出色的产品"。
不得不否认,SoftMod是目前为止最好用的Windows Vista破解法,而请这些盗版用户一定要注意,本周开始,微软将向Windows Vista Ultimate用户投送"毒药".
通过Windows Update安装这个更新后,SoftMod的破解法就将失效,同时您的系统将会被继续锁定.
SoftMod是一种利用Vista OEM识别机制进行的破解方法,它伪造标识,让系统认为这台机器是品牌机的OEM,从而让激活倒计时钟停止.
但毕竟是"Soft"的Mod,微软处理起来也比较简单,Windows Genuine小组表示,目前只会对Windows Vista Ultimate版本,并针对以英语为主要语种的系统发布.
如果您正在运行Windows 7操作系统,您会发现旧版本的微软硬件驱动程序IntelliPoint和IntelliType,Lifecam无法使用,这样您就不能用到微软硬件的扩展功能了,今天,微软硬件部门发布了面向Windows 7 Beta的有效驱动程序,它可以帮您解决键盘鼠标在Windows 7下无法正确定义功能的问题.
微软最近已经停止Windows 7 Beta的下载，微软WGA(Windows Genuine Advantage)事业部产品经理Alex Kochis在MSDN博客上发表文章解释，如果没有激活Windows 7 Beta，超过30天的激活期限之后会出现什么样的状况。首先微软不建议用户使用破解工具进行激活，不建议用户下载来源不明的Windows 7 Beta。
Windows XP，Vista，和Windows 7 Beta都包含30天的激活期限。在系统安装过程中有个选项可以允许用户填写激活信息，在使用Windows 3天之后自动激活。如果没有选择自动激活，在3天后将开始在系统托盘出现"Activate Windows Now"的激活提示，以及离激活期限还剩余的时间。点击"Activate Windows Online Now" 选项将出现标准的激活过程：
如果你选择"Ask me later"，将在安装之后的第27天前，每天都收到系统托盘激活提示，要求你"Activate Now"。如果27天之后没有采取措施，你将每4个小时收到系统托盘激活提示。第30天，激活提示将每小时出现一次。
超过了30天的期限之后，每次登录Windows界面上都会出现"Activate Windows now"的提示，如果选择"Activate now"将出现标准的激活过程。如果选择"Ask me later"，将出现关于非正版增值软件的风险，正版增值软件的利益以及一些帮助信息的描述通知：
如果你还是没有激活该软件，你将持续不断的收到通知，包括：每60分钟的系统托盘提示"Activate Windows Now"；桌面上出现"该Windows不是正版增值软件"的通知；打开控制面板时也会提示不是正版增值软件的信息；同时桌面背景设置为黑色（俗称"黑屏"）。你可以将黑色背景改成你想要的，但是每60分钟都会重置为黑色背景。这些过程将持续到你激活Windows 7 Beta为止。此外如果还没有激活将无法通过Windows Update进行更新：
cnBeta编译自MSDN博客
上周有报道说Windows 7 RC将于4月10日正式推出,并且报道说在Windows 7 RC之前不会再有其它的Windows 7 beta版本,而Windows 7 Build 7046将是Windows 7 RC之前的最后一个版本.不过这一消息目前被微软的一名员工所否认,该微软员工Twitter上透漏Windows 7 build 7047才是最新的版本.
此员工为微软的市场部雇员,他的Twitter在此
微软在今天早些时候发布了一系列的更新程序,包括微软全系列产品.其中面向Windows 7beta 的IE8更新程序.建议大家通过Windows Update或者是自行到微软下载网站下载,此程序将提高Internet Explorer的可靠性.
约有10%的Windows 7用户在使用IE8的时候遇到各种可靠性问题,其中包括崩溃,挂起,或者是内存溢出等等问题,但是只有1.5%的用户会经常遇到可靠性问题.新版本的IE崩溃恢复功能,有94%的机会帮助用户恢复崩溃的网页.
KB967062：解决Windows 7 Beta和Windows Server 2008 R2 Beta下的一些应用程序不兼容问题。
7 x86：
http://www.myfiles.com.cn/soft/26/26262.htm
7 x64：
http://www.myfiles.com.cn/soft/26/26190.htm
KB962921：解决Windows 7 Beta中IE8 Beta的一些问题。
KB967715：解决无法正常启用自动启动(AutoRun)功能的问题。
KB967131：解决如果使用IIS 7.0的Hostable Web Core功能、且承载HWC的进程是Windows工作对象的一部分则FastCGI模块无法工作的问题。
2003/2008 x86：
http://download.microsoft.com/download/C/B/4/CB4F2584-D9EE-4FAF-8D83-C487EC63BBA1/WYukon2005Setup-KB955706-x86-ENU.exe
2003/2008 x64：
http://download.microsoft.com/download/F/1/C/F1CF6AE9-D2D6-4225-A72D-BC78A340E2BC/WYukon2005Setup-KB955706-x64-ENU.exe
KB956263：包含用于Windows Server 2003的UDP端口保留实用程序。
KB959772：可让Windows Media Player自动更正受DRM保护的内容要求对许可进行更新时可能发生的错误。
Windows Experience Index (WinEI)是一个微软Windows系统中用来测定硬件性能并提出试用建议的工具,它可以给硬件评分并显示Windows的运行状况.
而在Vista中,最高评分只有6,目前最新的硬件绝大多已经破表,因此Windows 7的WinEI将采用新的评分模型,并将最高分数提到7.9,以下是详细情况:
微软CEO史蒂夫・鲍尔默周二在分析师会议上表示,微软将针对上网本发布功能强大的Windows 7版本,希望通过上网本的热销提升公司营收。
作为每年节支15亿美元计划的一部分,微软已经于1月22日宣布了裁员5000人的计划。鲍尔默在会上表示:"我认为再节支20亿美元的计划没有意义。" 在谈到经济前景不明朗时,鲍尔默表示,将在上网本市场攫取更多的市场份额;还表示尽管微软不愿意收购雅虎,但希望与雅虎联手共同抗衡 Google。
他说,希望与雅虎CEO卡罗尔・巴茨探讨结成搜索合作伙伴的关系,并预计Google会通过发布上网本版的Android操作系统挑战微软的Windows操作系统。
微软将针对上网本推出功能受限的Windows 7。由于去年经济危机一些,上网本销量激增。鲍尔默表示:"经济将影响PC销售,我们无法控制。"鉴于此,微软推面向上网本的操作系统也就不难理解了。分析师预计,每发售一款预装Windows 7的上网本,微软就可以得到约35美元。
微软刚刚发布了Windows 7 beta软件的第一个兼容性更新,该更新基于Windows 7 Prerelease License Terms许可发布,知识库号码KB967062.
本次更新修正了一系列软件在Windows 7上运行不兼容的问题,在安装该更新后您可能需要重新启动计算机.
微软负责互动娱乐的副总Chris Lewis近日表示,Windows 7的稳定性以及速度快的优势,使其更加适合游戏玩家.
"毫无疑问,Windows 7非常适合游戏,比如更稳定,相对来说更快,"Lewis这样表示:"我相信这对PC玩家来说是个好消息,不仅如此,今年晚些时候我们还会出台更多好消息."
此外,Lewis还宣称会不断为Games For Windows计划注入活力.他表示:"并不是所有的主机游戏都可以搬上PC平台,但时机成熟时我们会推广至所有平台,否则我们只好按兵不动."
一家俄罗斯网站今天透露，Internet Explorer 8已经在2月21日完成开发，正式RTM.
最终版本的版本号是8.0.6001.18691，在正式发布到Web以前将分发给TechNet/MSDN和Connect的用户，他们还给出了截图。新版IE8带来了更快的浏览速度和更少的用户操作，并且安全性和私密性更高。
许多参与Beta测试的测试者常常提出疑问：在Windows 7 Beta和RC版之间有没有向测试者发布过渡版本？答案很简单，没有。但是背后的原因比这个简单的答案复杂得多。许多人可能还记得在Vista测试期间存在着多个过渡版本，这些版本常常在每个月来一次，部分版本可能跨越更长的时间。
而Windows 7的测试用户没有收到任何官方过渡版本，1月份他们得到Beta版，在4月份他们将收到RC版，届时他们可以评估该版本是否解决了beta版里的bug。
笔者曾经向Steven Sinofsky询问是否向技术测试者发布过渡版本，他给笔者相应的回复。他们向技术测试者发布的不是第一个的winmain build，而是经过严格验证测试的，然后再重新封装发布给测试者，以下我们来举个例子展示验证测试的过程：
5231.0.winmain.050912-2020――就像你所看到的是第一个的winmain build，版本号中明确标明序号0和winmain，该版本将进行验证测试，重新封装再向测试者发布。
5231.2.winmain_idx03.051004-2120――这个重新封装的版本，该版本在9月12日和10月4日之间通过多次验证测试之后，进行重新封装。他的版本标签也有所改变，在winmain后添加_idx03，该版本在经过完整的验证测试之后向测试者发布。
上面两个例子中，微软花费了3周（标签中的0-2）对build 5231进行验证测试和封装，再向beta测试者发布。现在微软不是每个月都对Windows 7进行上述过程，所以时间节省下来了。下面继续举例说明的验证过程：
5308.17.winmain_idx01.060217-2200――很显然这个版本是重新封装的版本，看到前面的标签17，这说明微软在向Vista测试者发布Beta版本前确实做了很多准备，花了很长的时间。
Steven不想Windows 7团队把精力集中在这些预编译版本，使得他们可以集中精力在下一个milestone版本。微软频繁的给OEM，TAP项目成员，IHV发送winmain版本，为何不给技术测试者每月发放？他解释道，这些版本没有经过严格的测试，可能导致一些问题出现，如果这样会影响该产品的形象。
cnBeta编译自geeksmack
微软正在加紧新版操作系统Windows 7的推出,而火狐浏览器也正在为占有四分之一全球浏览器市场而努力,在欧盟法庭上一场浏览器战争也已经悄然打响.未来人们访问互联网将采取何种方式,现在 无疑到了决定浏览器市场格局的关键时刻.欧盟委员会已经针对微软发出反垄断诉讼,称微软"捆绑IE浏览器到Windows中的做法伤害了Web浏览器之间 的竞争,破坏了产品创新,从而最终减少了消费者的选择."
这个观点受到了火狐浏览器背后的Mozilla基金会的支持,同样持此观点的还有最先将微软告上法庭的Opera.
Mozilla的首席执行官米歇尔•贝克尔(Mitchell Baker)在博客中表示,"在我看来,欧盟的这个声明毫无疑问是正确的,这丝毫不用怀疑.在微软开始开发IE之前,我就一直从事开发和推广Web浏览器的工作,微软的所作所为已经明显的损害了竞争、创新和Web开发的步伐,而且它目前仍然在继续这种做法."
浏览器市场争议不断
即便没有这场官司,IE浏览器自从问世以来,围绕它的争论就一直从未中断过.
在19世纪90年代,IE浏览器与Netscape的战争成为人们关注的焦点,也正是这场战争让许多人对微软及其与对手竞争的手段产生了坏印象;这次的反垄断案只是此事件的一个最新延续.
贝克尔表示,微软还通过美国司法局和法庭裁定违法的方式来推广IE,导致IE浏览器最终占据了90%以上的市场份额.而一旦实现垄断浏览器市场的目的后,微软就停止了浏览器的开发;甚至裁减了浏览器开发团队.
随着最近火狐浏览器市场份额的稳步提升,以及其它像Opera、苹果的Safari和谷歌的Chrome等浏览器市场份额的日渐增长,单纯从数据上来看,微软似乎正在逐渐失去对浏览器市场的掌控.
然而,从Windows 7 beta中,微软已经看到了扭转这种趋势的希望,Windows 7这个新操作系统的发布,或许让IE浏览器的市场份额再度攀升.
原因何在?毫无疑问,Windows 7必定选择IE8作为其默认浏览器,大量用户将面临一个选择:是使用IE8这个微软大大改进的浏览器,还是再费劲的下载安装使用其它浏览器,多数用户的选择可能是前者.
分析机构Forrester的首席分析师Paul Jackson表示,"在IE8中,你将看到更多更强大的功能,这是一个与操作系统集成更紧密的浏览器.或许欧盟还在持观望态度,不过我认为当Windows 7推出后,人们将看到一个全新的浏览器市场格局."
IE8能否受益Windows 7决定历史重演与否
业内存在一个观点,用户会发现系统自带的IE 8浏览器已经足够好用,无需再去下载像火狐或Opera之类的浏览器,因此Windows 7会再次巩固IE的市场统治地位.但是Gartner分析师David Mitchell并不认同此观点.
IE 8是一个更完善的浏览器,将意味着有更多的人会觉得没有必要去使用一个其它的浏览器,这个观点只能说部分正确.Mitchell认为只会暂时阻碍火狐浏览器的增长,单单靠Windows 7本身,无法对浏览器市场带来如此重大的影响.
已经习惯使用某个浏览器的用户,会直接去下载他们过去喜欢的浏览器.
而且,微软是否还被允许在Windows 7中设置IE为默认浏览器,这还是一个有待确认的问题.
贝克尔认为,"微软一直在坚持伤害浏览器市场的行为,大量的用户在使用老版本的IE,他们通常不知道浏览器为何物,也不知道自己可以选择使用高质量浏览器.这让浏览器市场很难迎来创新,难以提高互联网上大多数用户的使用体验."
然而,资深微软观察家Mary Branscombe却有另一种看法.
她表示,在上一次反垄断战争中,Netscape声称它无法从IE手中争夺浏览器市场份额,因为微软通过免费在操作系统中提供一个浏览器,抑制了Netscape争夺客户的可能.
但是根据这场官司所披露出的数据来看,事实证明Netscape曾经推出了比当时互联网用户数量还多的Navigator浏览器软件,其失势的主要问题在于通过ISP来推广Navigator的商业模式,以及未能说服微软在Windows中包含Navigator.
现在看来,尽管欧盟表达了自己的看法,关于捆绑浏览器到操作系统的争论却仍将继续.的确,Windows 7的推出将为浏览器市场注入了各种可能事件的发生,最终它将对这个行业带来多大影响还要拭目以待.
文/IT168
One of the features that you’ve been pretty clear about (I’ve received over 100 emails on this topic!) is the desire to improve the disk defrag utility in Windows 7. We did. And from blogs we saw a few of you noticed, which is great. This is not as straight forward as it may appear. We know there’s a lot of history in defrag and how “back in the day” it was a very significant performance issue and also a big mystery to most people. So many folks came to know that if your machine is slow you had to go through the top-secret defrag process. In Windows Vista we decided to just put the process on autopilot with the intent that you’d never have to worry about it. In practice this turns out to be true, at least to the limits of automatically running a process (that is if you turn your machine off every night then it will never run). We received a lot of feedback from knowledgeable folks wanting more information on defrag status, especially during execution, as well as more flexibility in terms of the overall management of the process. This post will detail the changes we made based on that feedback. In reading the mail and comments we received, we also thought it would be valuable to go into a little bit more detail about the process, the perceptions and reality of performance gains, as well as the specific improvements. This post is by Rajeev Nagar and Matt Garson, both are Program Managers on our File System feature team. --Steven
In this blog, we focus on disk defragmentation in Windows 7. Before we discuss the changes introduced in Windows 7, let’s chat a bit about what fragmentation is, and its applicability.
Within the storage and memory hierarchy comprising the hardware pipeline between the hard disk and CPU, hard disks are relatively slower and have relatively higher latency. Read/write times from and to a hard disk are measured in milliseconds (typically, 2-5 ms) – which sounds quite fast until compared to a 2GHz CPU that can compute data in less than 10 nanoseconds (on average), once the data is in the L1 memory cache of the processor.
This performance gap has only been increasing over the past 2 decades – the figures below are noteworthy.
In short, the figures illustrate that while disk capacities are increasing, their ability to transfer data or write new data is not increasing at an equivalent rate – so disks contain more data that takes longer to read or write. Consequently, fast CPUs are relatively idle, waiting for data to do work on.
Significant research in Computer Science has focused on improving overall system I/O performance, which has lead to two principles that the operating system tries to follow:
Both rules have reasonably simply understood rationale:
File systems such as NTFS work quite hard to try and satisfy the above rules. As an example, consider the case when I listen to the song “Hotel California” by the Eagles (one of my all time favorite bands). When I first save the 5MB file to my NTFS volume, the file system will try and find enough contiguous free space to be able to place the 5MB of data “together” on the disk. Since logically related data (e.g. contents of the same file or directory) is more likely to be read or written around the same time. For example, I would typically play the entire song “Hotel California” and not just a portion of it. During the 3 minutes that the song is playing, the computer would be fetching portions of this “related content” (i.e. sub-portions of the file) from the disk until the entire file is consumed. By making sure the data is placed together, the system can issue read requests in larger chunks (often pre-reading data in anticipation that it will soon be used) which, in turn, will minimize mechanical movement of hard disk drive components and also ensure fewer issued I/Os.
Given that the file system tries to place data contiguously, when does fragmentation occur? Modifications to stored data (e.g. adding, changing, or deleting content) cause changes in the on-disk data layout and can result in fragmentation. For example, file deletion naturally causes space de-allocation and resultant “holes” in the allocated space map – a condition we will refer to as “fragmentation of available free space”. Over time, contiguous free space becomes harder to find leading to fragmentation of newly stored content. Obviously, deletion is not the only cause of fragmentation – as mentioned above, other file operations such as modifying content in place or appending data to an existing file can eventually lead to the same condition.
So how does defragmentation help? In essence, defragmentation helps by moving data around so that it is once again placed more optimally on the hard disk, providing the following benefits:
The following diagram will help illustrate what we’re discussing. The first illustration represents an ideal state of a disk – there are 3 files, A, B, and C, and all are stored in contiguous locations; there is no fragmentation. The second illustration represents a fragmented disk – a portion of data associated with File A is now located in a non-contiguous location (due to growth of the file). The third illustration shows how data on the disk would look like once the disk was defragmented.
Nearly all modern file systems support defragmentation – the differences generally are in the defragmentation mechanism, whether, as in Windows, it’s a separate, schedulable task or, whether the mechanism is more implicitly managed and internal to the file system. The design decisions simply reflect the particular design goals of the system and the necessary tradeoffs. Furthermore, it’s unlikely that a general-purpose file system could be designed such that fragmentation never occurred.
Over the years, defragmentation has been given a lot of emphasis because, historically, fragmentation was a problem that could have more significant impact. In the early days of personal computing, when disk capacities were measured in megabytes, disks got full faster and fragmentation occurred more often. Further, memory caches were significantly limited and system responsiveness was increasingly predicated on disk I/O performance. This got to a point that some users ran their defrag tool weekly or even more often! Today, very large disk drives are available cheaply and % disk utilization for the average consumer is likely to be lower causing relatively less fragmentation. Further, computers can utilize more RAM cheaply (often, enough to be able to cache the data set actively in use). That together, with improvements in file system allocation strategies as well as caching and pre-fetching algorithms, further helps improve overall responsiveness. Therefore, while the performance gap between the CPU and disks continues to grow and fragmentation does occur, combined hardware and software advances in other areas allow Windows to mitigate fragmentation impact and deliver better responsiveness.
So, how would we evaluate fragmentation given today’s software and hardware? A first question might be: how often does fragmentation actually occur and to what extent? After all, 500GB of data with 1% fragmentation is significantly different than 500GB with 50% fragmentation. Secondly, what is the actual performance penalty of fragmentation, given today’s hardware and software? Quite a few of you likely remember various products introduced over the past two decades offering various performance enhancements (e.g. RAM defragmentation, disk compression, etc.), many of which have since become obsolete due to hardware and software advances.
The incidence and extent of fragmentation in average home computers varies quite a bit depending on available disk capacity, disk consumption, and usage patterns. In other words, there is no general answer. The actual performance impact of fragmentation is the more interesting question but even more complex to accurately quantify. A meaningful evaluation of the performance penalty of fragmentation would require the following:
Let’s walk through an example that helps illustrate the complexity in directly correlating extent of fragmentation with user-visible performance.
In Windows XP, any file that is split into more than one piece is considered fragmented. Not so in Windows Vista if the fragments are large enough – the defragmentation algorithm was changed (from Windows XP) to ignore pieces of a file that are larger than 64MB. As a result, defrag in XP and defrag in Vista will report different amounts of fragmentation on a volume. So, which one is correct? Well, before the question can be answered we must understand why defrag in Vista was changed. In Vista, we analyzed the impact of defragmentation and determined that the most significant performance gains from defrag are when pieces of files are combined into sufficiently large chunks such that the impact of disk-seek latency is not significant relative to the latency associated with sequentially reading the file. This means that there is a point after which combining fragmented pieces of files has no discernible benefit. In fact, there are actually negative consequences of doing so. For example, for defrag to combine fragments that are 64MB or larger requires significant amounts of disk I/O, which is against the principle of minimizing I/O that we discussed earlier (since it decreases total available disk bandwidth for user initiated I/O), and puts more pressure on the system to find large, contiguous blocks of free space. Here is a scenario where a certainly amount of fragmentation of data is just fine – doing nothing to decrease this fragmentation turns out to be the right answer!
Note that a concept that is relatively simple to understand, such as the amount of fragmentation and its impact, is in reality much more complex, and its real impact requires comprehensive evaluation of the entire system to accurately address. The different design decisions across Windows XP and Vista reflect this evaluation of the typical hardware & software environment used by customers. Ultimately, when thinking about defragmentation, it is important to realize that there are many additional factors contributing towards system responsiveness that must be considered beyond a simple count of existing fragments.
The defragmentation engine and experience in Windows 7 has been revamped based on continuous and holistic analysis of impact on system responsiveness:
In Windows Vista, we had removed all of the UI that would provide detailed defragmentation status. We received feedback that you didn’t like this decision, so we listened, evaluated the various tradeoffs, and have built a new GUI for defrag! As a result, in Windows 7, you can monitor status more easily and intuitively. Further, defragmentation can be safely terminated any time during the process and on all volumes very simply (if required). The two screenshots below illustrate the ease-of-monitoring:
In Windows XP, defragmentation had to be a user-initiated (manual) activity i.e. it could not be scheduled. Windows Vista added the capability to schedule defragmentation – however, only one volume could be defragmented at any given time. Windows 7 removes this restriction – multiple volumes can now be defragmented in parallel with no more waiting for one volume to be defragmented before initiating the same operation on some other volume! The screen shot below shows how defragmentation can be concurrently scheduled on multiple volumes:
Among the other changes under the hood in Windows 7 are the following:
Best practices for using defragmentation in Windows 7 are simple – you do not need to do anything! Defragmentation is scheduled to automatically run periodically and in the background with minimal impact to foreground activity. This ensures that data on your hard disk drives is efficiently placed so the system can provide optimal responsiveness and I can continue to enjoy glitch free listening to the Eagles :-).
Rajeev and Matt
About every decade we make the big decision to update what we refer to as the applets (note we’ll use applet, application, program, and tool all interchangeably as we write about these) in Windows—historically Calc (Calculator), Paint (or MS Paint, Paint Brush) and WordPad (or Write), and also the new Sticky Notes applet in Windows 7. As an old-timer, whenever I think of these tools I think of all the history behind them and how they came about. I’m sure many folks have seen the now “classic” video of our (now) CEO showing off Windows to our sales force (the last word of this video is the clue that this video was done for inside Microsoft). Windows 7 seems like a great time to update these tools. The motivation for updating the applets this release is not the 10-year mark or just time to add some applet-specific features, but the new opportunities for developers to integrate their applications with the Windows 7 desktop experience. While many use the applets as primary tools, our view of these is much more about demonstrating the overall platform experience and to provide guidance to developers about how to integrate and build on Windows 7, while at the same time providing “out of box” value for everyone. There’s no real “tension” over adding more and more features to these tools as our primary focus is on showing off what’s new in Windows—after all there are many full-featured tools available that provide similar functionality for free. So let’s not fill the comments with request for more bitmap editing features or advanced scientific calculator features :-).
The APIs discussed in this post are all described on MSDN in the updated developer area for Windows 7 where you can find the Windows 7 developer guide. Each of the areas discussed is also supported by the PDC and WinHEC sessions on those sites.
This post was written by several folks on our applications and gadgets team with Riyaz Pishori, the group program manager, leading the effort. --Steven
This blog post discusses some of the platform innovations in Windows 7 and how Windows 7 applications have adopted and showcased these innovations. This post details some of the platform features that developers and partners can expect in Windows 7 and how Windows 7 programs have showcased these innovations. This post also discusses how applications have been given a facelift both in terms of their functionality as well as their user experience by focusing on key Windows design principles and platform innovations. Finally, this post can serve as a pointer or guide to application developers and ISVs to get themselves familiar with some of the key new Windows platform innovations, see them in action and then figure out how they can build on these APIs for their own software.
The post is organized by each subsystem, and how Windows applets are using that particular subsystem.
The Windows Ribbon User Interface is the next generation rich, new user interface for Windows development. The Windows Ribbon brings the now familiar Office 2007 Ribbon user interface to Windows 7, making it available to application developers and ISVs.
There are several advantages of adopting the Windows Ribbon user interface, many of which have been talked about in the Office 2007 blogs. The Ribbon provides a rich, graphical user interface for all commands in a single place, without the need to expose various functions and commands under different menus or toolbars. The Ribbon UI is direct and self-explanatory, and has a labelled grouping of logically related commands. While using an application that is built on the Ribbon UI platform, the user only needs to focus on his workflow and the context of his task, rather than worry about where a particular function is located or accessible. The Ribbon UI also takes care of layout and provides consistency as compared to toolbars which the user can customize in terms of their sizes, location and contents. It also has built-in and improved keyboard accessibility, and making the application DPI and theme aware becomes easier by using the Ribbon. Finally, development and changes to the user interface is very quick and rapid due to the XML-markup based programming model for the Ribbon User Interface.
Paint and Wordpad are two of the first consumers of the Windows Ribbon UI Platform. In Windows 7, both these applications are enhanced with a set of new features, and the user interface of these applications also required to be brought up to the Windows 7 experience and standards. The Windows Ribbon UI is a great fit for these applications to revamp their user experience and make it consistent, and make these applications rich, fun and easy to use. The tasks and commands in these applications were amenable to be applied to the Ribbon UI framework, and it also served as an opportunity for popular native Windows applications to showcase the Windows Ribbon UI platform to consumers, as well as developers and ISVs. Many has asked about the Windows Explorer and IE also using the ribbon, which we did not plan on for Windows 7. Our Windows 7 focus was on the platform and demonstrating the platform for document-centric applications such as Paint and Wordpad.
Both these applications showcase several elements of the Windows UI Ribbon. The Application Menu of both Paint and Wordpad exposes Application related commands that are typically available thru the ‘File’ menu of an application. Both the applications have a core tab set that consists of ‘Home’, which exposes most of the commands in the application, and ‘View’ which exposes the image or document viewing options in the application. The commands in both these tabs are laid out logically in groups of related functionality.
A quick access toolbar (QAT) is provided by both Paint and Wordpad, which comes with certain defaults like Save, Undo and Redo that are meaningful to the application. The user can customize the QAT by using the QAT drop-down, or right-click on any command or group in the ribbon and add it to the QAT.
Several ribbon commands are used in both these applications, like command buttons, split buttons, galleries, drop-downs, check boxes and toggle buttons.
Further, both applications provide a ‘Print preview’ mode which shows a print preview of the image or the document in context. In a mode, all the core tabs are removed and only the mode is displayed for the user to interact with. On exiting a mode, the user is returned to the core tab set.
Paint also exposes a contextual tab for the Text tool, which is displayed only when a text control is drawn on canvas. A contextual tab shown next to the core tab set when the text tool is in focus, and removed when the text is applied to the image on the canvas. The contextual tab set contains the tools that are specific and relevant only to the text tool.
Both the applications provide live previews through ribbon galleries, for example the font size and font name for Wordpad and Paint while formatting text, bullets and lists in Wordpad, and color selection, outline size selection and outline and fill styles for shapes in Paint. A live preview allows the user to see the changes instantaneously on mouse hover, and then apply those changes on a selection. These previews are one of the key elements of the ribbon UI and demonstrate why the metaphor is much more than a “big toolbar” but a new interaction style.
By adopting the Ribbon User Interface, both the applications inherit built-in keyboard accessibility support using ribbon Keytips, have tooltips on all commands, and have ready support for DPI and Windows themes.
Paint and Wordpad can serve as examples of how the Ribbon UI can be easily used in MFC applications. The Windows Ribbon presents new opportunities and options for developers and ISVs to develop applications with the Ribbon User Interface. The Windows Scenic Ribbon programming model and architecture emphasizes the separation of the markup file and the C++ code files to help developers decouple the presentation and customization of the UI from the underlying application code. The platform also promotes developer-designer workflow, where the developer can focus on the application logic, while the designer can work on the UI presentation and layout. The ribbon UI is a significant investment for us and you should expect to see us continue to use it more throughout Microsoft, including an implementation in the .NET Framework as was demonstrated by Scott Guthrie at the PDC, which will be built on Windows 7 natively in the future.
Windows 7 provides support for multi-touch input data, as well as supporting multi-touch in Win32 via Windows messages. The investments in the multi-touch platform include the developer platform that exposes touch APIs to applications, enhancing the core user interface in Windows 7 to optimize for touch experiences, and providing multi-touch gestures for applications to consume. Developers on Windows 7 can build on these APIs decide on the appropriate level of touch support they would like to provide in their software.
Wordpad enhances the document reading experience by using the multi-touch platform and using the zoom and pan gestures. Zooming, panning and inertia lets the user get to a particular piece of content very quickly in an intuitive fashion. By using the zoom gesture, the user can zoom in or zoom out of the document which is akin to using the zoom slider at the right of the Wordpad status bar. On multi-touch capable hardware, the user can zoom in and out of the document by placing his fingers anywhere within the document window and executing the zoom gesture. Wordpad also supports the pan gesture to pan thru the pages of a document that is open in Wordpad. By executing the pan gesture, the user can scroll-down or scroll-up a document similar to using the scroll bar of the Wordpad application.
In Paint multi-touch data is used to allow users to paint with multiple fingers. It is an example of an application that allows multi-touch input without the usage of gestures. For Paint’s functionality, providing multiple finger painting ability was more compelling and enriching than allowing for zoom, pan, rotate or other gestures that act on the picture in a read-only mode and not in an edit-mode. New brushes in Paint are multi-touch enabled, and they handle touch inputs via multiple fingers and allow the user to simultaneously draw strokes on canvas on finger drag. These brushes are also pressure-sensitive, thereby providing a realistic experience with touch by varying the stroke width based on the pressure on the screen. While adopting the multi-touch platform to enhance the end-user experience in Paint, conscious design decisions were made to preserve the single touch experience for functionalities where a multi-touch scenario does not apply such as the color picker, magnifier and text tool.
By building with the multi-touch APIs, Paint and Wordpad have created more natural and intuitive interfaces on touch-enabled hardware and show “out of the box” how different capabilities can be exposed by developers in their software.
Sticky Notes (or just Notes) is an extension of a TabletPC applet available in Windows 7. One of the things which was key to the Notes experience on the desktop was to have the ability to quickly take all the notes away and get them back, but still making sure it is really easy to create a new note. We achieved this by having a single top level window for the sticky notes application. You can minimize all your notes and view a stack of notes in the preview on the command bar with a single click. The stacked preview has been achieved using the new thumbnail preview APIs that enable apps to override the default taskbar previews that are essentially a redirected snapshot of the top level application window, and provide their own. This enables applications to decouple their previews from the top level application window and provide a more productive preview based on the scenario. For example, this was very valuable in Sticky Note scenarios where a quick peek at a note that was last touched provides for quite a productive workflow. Taskbar also caches the preview thumbnail images so once the preview is given to the Taskbar, the application does not need to keep it around – the application does however need to send an updated preview whenever it changes.
Another nifty customization end-point on the task bar is the destination menu (aka jumplist). This menu comes up when a user right clicks on the application in the taskbar or hovers over the application icon in the Start Menu. The Sticky Notes application does not have a single main application window – this makes the application feel really light weight and fits in well into the Windows 7 philosophy of creating simple and powerful user experiences. The challenge then was exposing functionality such as the ability to create a new note from a central location or potentially other custom “tasks”. The destination menu helped exposing these scenarios in a simple yet discoverable way.
The new taskbar functionality and extensibility built in that has the potential to make it a lot easier for people to work with applications/scenarios in a more productive and efficient manner when developers integrate their software with the Windows desktop.
Building on the long history of Search in Windows and the significant enhancements in Windows 7, there are APIs available to developers to deeply integrate their content types with the desktop search user experience affordances in Windows 7. Sticky Notes shows one example of how these APIs can be used.
The Sticky Notes application now allows users to get back to their notes by simply searching for content through Windows Inline search within the start menu. This is in line with allowing users to reach the relevant note as quickly as possible even when the application is closed. Even though search could be done for both Text and Ink content, it is restricted to text because of lower success rates with varied handwriting styles in ink. The application registers a protocol handler that generates a URL for each Note. The Sticky Notes Filter handler gets asked for the content associated with each note that is then indexed by the Search infrastructure. These indexes are then used to perform a quick lookups when the user searches the Search interfaces provided by the Windows Shell. When a user clicks on a result, Search invokes the associated application with the URL corresponding to the one that the protocol handler had generated that the Filter handler associated with the content it sent to the Search indexer.
The search platform also has the ability to enable the filter handler to specify the language of each chunk of content passed on to it that overrides the default Search heuristics used to compute the language - this increases Search accuracy manifold and thereby enhances internationalization support of the entire ecosystem.
The reason Sticky Notes implemented a protocol handler in addition to a Filter handler was because it implements its own integrated storage schema on top of the Windows File system - all the notes are represented by a single .snt file. The protocol handler generates URL's to individual entities (in this case - notes); the filter handler picks out content for each of these URL's and gives it to Search for indexing.
This demonstrates the ease in which applications can plug into the search platform in Windows 7, and add search handlers which can enhance the overall user experience from the App as well as the platform.
Real-Time Stylus (RTS) is infrastructure that provides access to the stylus events coming from pen or touches digitizers. It provides information about strokes and points and provides access to ink-related events. Using RTS, applications can get access to stylus information and develop compelling end-user scenarios and experiences.
Sticky Notes now allows the users to Ink and Type on notes depending on the availability of inking hardware. Users can use keyboard input to type on notes and use the stylus to ink on notes. Though the experience has been designed keeping in mind that users will either use either ink or text on a particular note, it does allow users to ink and type on the same note. However these surfaces are maintained agnostic to each other. Sticky Notes also auto-grows the note while inking on the note, providing a real-time experience of the note adjusting its size to fit the inked content.
Real Time Stylus (RTS) is used for inking features provided in Sticky Notes. Inking gestures are also available to applications, and the scratch out gesture has been implemented in Sticky Notes to delete content.
In addition, Paint uses RTS to get a stream of positional input from mouse, stylus or touch which are used for drawing strokes on canvas. Paint also captures additional input variables like pressure and touch surface area when such input is available from the digitizer, and maps these inputs into the stroke algorithms that are used to generate Paint strokes on canvas. Using this algorithm, the user is able to modulate stroke width and other parameter based on the pressure or touch area on canvas.
Using RTS allows the development of applications and software that can build on the inking platform and provide ways to interact with the application that go beyond mouse or keyboard. Using stylus, inking and gestures, developers can create interactive experiences for end-users.
The Windows Error Reporting (WER) infrastructure is a set of feedback technologies that is built into Windows 7 and other earlier versions of Windows client and server. WER allows applications to register for application failures and capture this data for end-users who agree to report it. This data can be accessed and analyzed and can be used to monitor error trends and download debug information to help developers and ISVs determine the root cause for application failures.
WER can add value to software development at various stages: during development, during beta testing by getting early feedback from end-users, after the release of the product by analysing and prioritizing the top fixes, and at end of life of the product.
Related to failure recovery, Applications can also register with WER for restart on application of a Windows patch that terminates the application and on application of an update that reboots the computer, as well as failure caused due to an application crash or hang or not responding state. Applications can optionally register for recovery of lost data, can develop their own mechanism for recovery.
Several Windows applications adopt the WER infrastructure to collect and analyze data. Calculator, Paint and Wordpad register for restart and additionally recover the current data in the sessions of the application that were running. Sticky Notes also registers for restart and recovery, and returns the user to the set of notes open on the desktop. Using WER, end-users would allow Windows to capture and collect problem data and then would be returned to the applications in the same state that they were in earlier.
As you can see, our primary effort for the applets in Windows 7 is to showcase some of the new platform APIs and innovations available to developers. As you get to try out these applications you will see that while showcasing the Windows 7 platform innovations, we have also added some commonly requested features and functionality. Some of them are: Check and correct, calculation modes and templates in Calculator, New brushes, shapes and multi-touch support in Paint, Open standards support in Wordpad and Ink and text, taskbar and search integration in Sticky notes. Maybe we won’t wait 10 years to update these again :-)
--Riyaz Pishori and team
Many posts start with a thank you and I want to start this post with an extra special thank you on behalf of the entire Windows team for all the installs and usage we are seeing of the Windows 7 Beta. We’ve had millions of installations of Windows 7 from which we are receiving telemetry, which is simply incredible. And from those who click on the “Send Feedback” button we are receiving detailed bug reports and of course many suggestions. There is simply no way we could move from Beta through Final Release of Windows 7 without this type of breadth coverage and engagement from you in the development cycle. There’s been such an incredible response, with many folks even blogging about how they have moved to using Windows 7 Beta on all their machines and have been super happy. The question we get most often is “if the Beta expires in August what will I do—I don’t want to return to my old [sic] operating system.” For a Beta release, that is quite a complement and we’re very appreciative of such a kind response.
This post is about the path from where we are today, Beta, to our RTM (Release To Manufacturing), building on the discussion of this topic that started at the PDC. This post is in no way an announcement of a ship date, change in plans, or change in our previously described process, but rather it provides additional detail and a forward looking view of the path to RTM and General Availability. The motivation for this, in addition to the high level of interest in Windows 7, is that we’re now seeing how releasing Windows is not something that Microsoft does “solo”, but rather is something that we do as one part of the overall PC ecosystem. Obviously we have a big responsibility to do our part, one we take very seriously of course. The last stages of a Windows release are a partnership across the entire ecosystem working to make sure that the incredible variety of choices you have for PCs, software, and peripherals work together to bring you a complete and satisfying Windows 7 experience.
The next milestone for the development of Windows 7 is the Release Candidate or “RC”. Historically the Release Candidate has signaled “we’re pretty close and we want people to start testing the release, especially because all the features are done.” As we have said before, with Windows 7 we chose a slightly different approach which we were clear up front about and are all now experiencing together and out in the open. The Pre-Beta from the PDC was a release where we said it was substantially API complete and even for the areas that were not in the release we detailed the APIs and experience in the sessions at the PDC. At that time we announced that the Beta test in early 2009 would be both API and feature complete, widely available, and would be the only Beta test. We continued this dialog with our hardware partners at WinHEC. We also said that many ecosystem partners including PC makers, software vendors, hardware makers will, as has been the case, continue to receive interim builds on a regular basis. This is where we stand today. We’ve released the feature complete Beta and have made it available broadly around the world (though we know folks have requested even more languages). As a development team we’re doing just what many of you do, which is choosing to run the Beta full time on many PCs at home and work (personally I have at least 9 different machines running it full time) and we’re running it on many thousands of individual’s machines inside Microsoft, and thousands of machines in our labs as well.
All the folks running the Beta are actively contributing to fixing it. We’re getting performance telemetry, application compatibility data, usage information, and details on device requirements among other areas. This data is very structured and very actionable. We have very high-bandwidth relationships with partners and good tools to help each other to deliver a great experience. One thing you might be seeing is that hardware and software vendors might be trying out updated drivers / software enhanced for Windows 7. For example, many of the anti-virus vendors already have released compatibility packs or updates that are automatically applied to your running installation. You might notice, for example, that many GPU chipsets are being recognized and Windows 7 downloads the updated WDDM 1.1 drivers. While the Windows Vista drivers work as expected, the new 1.1 drivers provide enhanced performance and a reduced memory footprint, which can make a big difference on 1GB shared memory machines. You might insert a device and receive a recently updated version of a driver as I did for a Logitech QuickCam. Another example some of you might have seen is that the Beta requires a an updated version of Skype software currently in testing. When you go to install the old version you get an error message and then the problem and solutions user interface kicks in and you are redirected to the Beta site. This type of error handling is deployed in real time as we learn more and as the ecosystem builds out support. It is only because of our partnerships across the ecosystem that such efforts are possible, even during the Beta.
Of course, it is worth reiterating that our design point is that devices and software that work on Windows Vista and are still supported by the manufacturer will work on Windows 7 with the same software. There are classes of software and devices that are Windows-version specific for a variety of reasons, as we have talked about, and we continue to work together to deliver great solutions for Windows 7. The ability to provide people the vast array of choices and the openness of the Windows platform make all of this a massive undertaking. We continue to work to improve this while also making sure we provide the opportunities for choice and differentiation that are critical to the health and variety of the overall ecosystem. This data and the work we’re doing together with partners is the critical work going on now to reach the Release Candidate phase.
We’re also looking carefully at all the quality metrics we gather during the Beta. We investigate crashes, hangs, app compat issues, and also real-world performance of key scenarios. A very significant portion of our effort from Beta to RC is focused on exclusively on quality and performance. We want to fix bugs experienced by customers in real usage as well as our broad base of test suites and automation. A key part of this work is to fix the bugs that people really encounter and we do so by focusing our efforts on the data we receive to drive the ordering and priority of which bugs to fix. As Internet Explorer has moved to Release Candidate, we’ve seen this at work and also read about it on IE Blog.
Of course the other work we’re doing is refining the final product based on all the real-world usage and feedback. We’ve received a lot of verbatim feedback regarding the user experience—whether that is default settings, keyboard shortcuts, or desired options to name a few things. Needless to say just working through, structuring, and “tallying” this feedback is a massive undertaking and we have folks dedicated to doing just that. At the peak we were receiving one “Send Feedback” note every 15 seconds! As we’ve talked about in this blog, we receive a lot of feedback where we must weigh the opinions we receive because we hear from all sides of an issue—that’s to be expected and really the core design challenge. We also receive feedback where we thought something was straight forward or would work fine, but in practice needed some tuning and refinement. Over the next weeks we’ll be blogging about some of these specific changes to the product. These changes are part of the process and part of the time we have scheduled between Beta and RC.
So right now, every day we are researching issues, resolving them, and making sure those resolutions did not cause regressions (in performance, behavior, compatibility, or reliability). The path to Release Candidate is all about getting the product to a known and shippable state both from an internal and external (Beta usage and partner ecosystem readiness) standpoint.
We will then provide the Release Candidate as a refresh for the Beta. We expect, based on our experience with the Beta, a broad set of folks to be pretty interested in trying it out.
With the RC, this process of feedback based on telemetry then repeats itself. However at this milestone we will be very selective about what changes we make between the Release Candidate and the final product, and very clear in communicating them. We will act on the most critical issues. The point of the Release Candidate is to make sure everyone is ready for the release and that there is time between the Release Candidate and our release to PC makers and manufacturing to validate all the work that has gone on since the pre-Beta. Again, we expect very few changes to the code. We often “joke” that this is the point of lowest productivity for the development team because we all come to work focused on the product but we write almost no code. That’s the way it has to be—the ship is on the launch pad and all the tools are put away in the toolbox to be used only in case of the most critical issues.
As stated up front, this is a partnership and the main thing going on during this phase of the project is really about ecosystem readiness. PC makers, software vendors, hardware makers all have their own lead times. The time to prepare new products, new configurations, software updates, and all the collateral that goes with that means that Windows 7 cannot hit the streets (so to speak) until everyone has time to be ready together. Think of all those web sites, download pages, how-to articles, training materials, and peripheral packages that need to be created—this takes time and knowing that the Release Candidate is the final code that we’re all testing out in the open is reassuring for the ecosystem. Our goal is that by being deliberate, predictable, and reliable, the full PC experience is available to customers.
We also continue to build out our compatibility lists, starting with logo products, so that our http://www.microsoft.com/windows/compatibility site is a good resource for people starting with availability. All of these come together with the PC makers creating complete “images” of Windows 7 PCs, including the full software, hardware, and driver loads. This is sort of a rehearsal for the next steps.
At that point the product is ready for release and that’s just what we will do. We might even follow that up with a bit of a celebration!
There’s one extra step which is what we call General Availability or GA. This step is really the time it takes literally to “fill the channel” with Windows PCs that are pre-loaded with Windows 7 and stock the stores (online or in-person) with software. We know many folks would like us to make the RTM software available right away for download, but this release will follow our more established pattern. GA also allows us time to complete the localization and ready Windows for a truly worldwide delivery in a relatively small window of time, a smaller window for Windows 7 than any previous release. It is worth noting that the Release Candidate will continue to function long enough so no one should worry and everyone should feel free to keep running the Release Candidate.
So to summarize briefly:
The obvious question is that we know the Pre-Beta was October 28, 2008, and the Beta was January 7th, so when is the Release Candidate and RTM? The answer is forthcoming. We are currently evaluating the feedback and telemetry and working to develop a robust schedule that gets us the right level of quality in a predictable manner. Believe me, we know many people want to know more specifics. We’re on a good path and we’re making progress. We are taking a quality-based approach to completing the product and won’t be driven by imposed deadlines. We have internal metrics and milestones and our partners continue to get builds routinely so even when we reach RC, we are doing so together as partners. And it relies, rather significantly, on all of you testing the Beta and our partners who are helping us get to the finish line together.
Shipping Windows, as we hoped this shows, is really an industry-wide partnership. As we talked about in our first post, we’re promising to deliver the best release of Windows we possibly can and that’s our goal. Together, and with a little bit more patience, we’ll achieve that goal.
We continue to be humbled by the response to Windows 7 and are heads down on delivering a product that continues to meet your needs and the needs of our whole industry.
--Steven on behalf of the Windows 7 team
UAC的目的
Jon
访问:
下载:Update for Windows 7 Client Beta