The key features are the Windows Store, Windows Style apps, and the touch-enabled UI. I was just listing some other technical features that are present in the OS that are useful, relevant to developers, and used for/by traditional desktop apps.
Actual technical content in a/. article... Hmmm. not sure if that's really an option, but here goes a partial list of stuff you get in 8.1 and not with 7:
DirectX 11.2 hardware support including tiled resources, Feature Level 11.1 hardware support, etc.
Much improved Direct3D capture support when using VS 2013 Graphics Diagnostics
Native USB 3.0 support
200% High-DPI scaling support
Bitlocker has been improved, particularly when initializing a new drive
The Xbox 360 and PS3 pushed game developers to embrace multi-threaded gaming when they were primarily single-threaded before that. This has definitely spilled over to more multi-core PCs, although there's been a number of 'early' generation games that tired to require quad-core before the PC gamers were really running them in large numbers. These console ports were often tuned for 3-6 threads, which didn't always map well to just a dual-core PC.
The Xbox 360 and PS3 are also 32-bit platforms, so they didn't push developers to move to 64-bit native. Xbox One and PS4 are 64-bit native platforms, so that's hopefully going to accelerate the move to 64-bit. Game developers are already using x64 native builds of their games internally, but publishers don't want to pay to test, release, and support both a 32-bit and a 64-bit version of their game--or they released it but stopped updating the 64-bit version. The biggest driver for this is that 32-bit applications can only manage 2GB of virtual address space, and AAA PC games were already hitting this limit.
So the focus on consoles in the industry, plus the lingering zombie life of Windows XP, had basically kept everyone stuck at Direct3D 9/Shader Model 3 and 32-bit for years. With next-generation consoles moving to Direct3D 11/Shader Model 5 and 64-bit, we should see more PC titles that take advantage of the latest generation PC hardware.
BTW, for some technical background on 64-bit and gaming, see http://www.gamasutra.com/view/feature/3602/sponsored_feature_ram_vram_and_.php
I had my first computer at 13, and learned to program in BASIC, high-level languages (C/C-like languages), and 6502 assembly well before high-school... Spent years BBSing, playing games, typing in programs from magazines & books, creating varoius graphics-related programs, and generally 'hacking' in the old-school sense. I don't think, however, I'd consider having any real training in 'computer science' until my second year of high-school CS class with an introduction to data-structures. Before that it was all 'hacking' or perhaps 'computer literacy'. Probably the most useful thing in that time was learning to touch-type and that was on an actual type-writer...
Being comfortable with technology, and able to learn new systems quickly is important and comes from hours immersed in the 'culture' of computers, but many "prep for college" skills are not computer-related: writing, linear algebra, probability, geometry, organizational skills, communications, etc.
Netbooks with 32-bit only CPUs, legacy printers with 32-bit only drivers, and the corporate upgrade cycle all contribute to the decision to keep 32-bit versions of Windows 7 around. By requiring x64 support in the Windows 7 logo program, the hope is that 32-bit only devices will phase out over time a bit faster so that Microsoft can switch to x64 only at some point in the near future. Hardware vendors would in general want to not do double the work for every driver, but at least for software developers the x86/x64 transition is really not that hard.
The Windows 7 SKU design is improved over Windows Vista. The feature set is strictly a super-set as you move up the chain; you get almost everything you'd need as a developer with Windows 7 Professional (in Windows Vista, you had to have Ultimate to support domain join and consumer media scenarios at the same time); and Windows 7 Ultimate is idetical in terms of features to Winodws 7 Enterprise except for how they are licensed instead of being weirdly different. And the retail boxes for Windows 7 include both x86 and x64 media instead of being limited to the Windows Vista Ultimate retail box or ordering 'alternate media'.
retiring the stupid BillG as The Borg icon! ST:TNG has been in reruns since 1994, there isn't a Star Trek show in production, he hasn't been involved in the daily running of MSFT for years, and as of today he isn't even an employee.
I'm not suggesting that anyone in the/. community consider updating their perceptions of the company for the last 10 years; to acknowledge that anyone who has gone to work for the company since 2000 has had any influence on the company's approach to business, markets, customers, or technology; or to suggest that the investment in software engineering practices, security tools and training, developer outreach, or a monstrous R&D spend could have any value what-so-ever to the PC industry, the software industry, or have improved any MSFT product. It does seem, however, like today would be a good day to update the thumbnail to something that at least reflects the cultural constructs of the 21st century.
While it may make the \. community feel a shared warm fuzzy of schadenfreude, the comparison of Windows Vista to Windows ME is completely lacking in any technical basis or comparison. Windows ME was a end-of-life release, the final gasp the death throes of MS-DOS-based versions of Windows. It was created for basically the same reasons that Windows 95 OSR2 was made: to address some important hardware support requests from PC hardware OEMs ahead of the release of the next major Windows release. The many shortcomings of Windows ME were well-known at the time the project was underway, and were to be addressed in the consumer release of Windows 2000 (aka Windows XP). The two main lessons of the project are: (a) giving OEMs too much opportunity to customize the desktop results in a poor consumer experience and (b) OEMs, like most of Corporate America, will fight against major change with their last breath even if it improves their product.
What Windows Vista and Windows ME do have in common is an immense amount of press and developer negative perception, but the basis of the negative perception is entirely different. Windows ME's bad experience came in large part because it was usually deployed via OEMS in a "customized" form that was basically crippled. Most developers and tech savvy people never used it because Windows 2000 was far superior being an NT-based product and not MS-DOS.
Windows Vista is burdened by the FUD around "Project Longhorn" which was really shot in the head back in 2004 in the "Longhorn restart". There were the much discussed project management problems in the Windows division, the immense impact of the security push effort, the efforts for x64 support, and failures managing extremely deep dependency chains between various component groups most famously seen in WinFS and Avalon. The "5+ years for this?" FUD completely ignores that Windows Vista took just over 2 years from start to finish. During "Project Longhorn", the security push resulted in Windows component teams doing almost nothing but fixing a backlog of security bugs for 2 years. Windows XP SP2 and Windows Server 2003 SP1 / Windows XP Pro x64 Edition were major development efforts from teh same component teams.
From a purely technical point of view, Windows Vista is perfectly fine as it is with the usual caveats of bugs endemic to all large software projects. It is, however, an extremely disruptive release: a complete rewrite of the graphics stack integrating the GPU into the OS scheduling; a new desktop shell; a new audio stack; major changes in the security model for applications, services, and drivers; and the first mainstream release of x64 for consumer systems. That's an immense amount of change for the PC industry to absorb. Many companies are happy to keep their head in the sand about these changes, and all the anti-Vista FUD continues to give them cover in this behavior. "Windows 7" (which is a codename more than anything else) will likely be much more the 95 => 98 or 2000 => XP releases, which were far less disruptive and coincide with stronger 3rd party support and expertise to back up the consumer experience. As for the theory that Windows Vista is being "thrown out in favor of XP", I invite you to look at the debugging symbols packages for Windows Vista SP1. They are identical to Windows Server 2008 RTM for a reason. The investment in the Windows Codebase made for Windows Vista set up the next decade of development, and unifies the codebases in a rationale, scalable way.
As for the "DRM in Vista is the devil" folks, all I can say is head down to Barnes & Noble and while buying yet another copy of Catcher in the Rye, browse through the latest edition of Windows Internals. The "DRM facilities" in the kernel are basically non-existent and the Protected Media Path is just leveraging some already existing security facilities like Authenticode signing and a non-debugging process type. That's it. The "Heart of DRM" is still in Hollywood, so if you don't like it: complain to the content producers who force DRM support in their licensing terms, and stop buying their protected content.
It took Microsoft engineers 5 years to develop Vista?
This little bit of FUD has been floating around for some time, and basically the argument goes "I don't see 5 years of work here, ergo Vista sucks". It's true that Microsoft evangelists oversold "Longhorn" for a very long time, so the roots of the FUD do in fact go back to Redmond. However, this particular argument falls flat in the face of the facts. Windows Vista was not in development for 5 years. "Project Longhorn" went on for many years, but as was discussed in the press the "Longhorn reset" in 2004 is the true start date for the development of Windows Vista. Some technologies created for the original Longhorn project were put into Windows Vista, and it did carry on the codename, but it's not the same product at all. Windows Vista started from Windows Server 2003 SP1 in August 2004, and the final version was declared in time for the November 2006 release of the corporate SKUs. That's just over TWO years of develompent. Not FIVE+.
During those five years, Microsoft did have several major releases of Windows, but they came in the form of Service Packs rather than new products. Windows XP SP2 was the result of several years of security work and new security features. Windows Server 2003 SP1 / Windows XP Pro x64 Edition took a few years of work to get Windows running on x64, including many basic drivers that had to be rewritten for 64-bit native. Windows Vista includes the fruits of these efforts because the reset started with Server 2003 SP1.
Certainly the software industry is full of large software projects that ran amok. The original "Longhorn" project falls into this category. Windows Vista is not that product, and neither is Windows Server 2008. That "Longhorn" never shipped.
One can always count on any thread on/. about Windows Vista to generate posts full of verve, passion, and technical ignorance. So far the responses have included long rants about NVIDIA's (and other video vendor's) policy towards Linux drivers, the usual anti-Vista FUD from posters who are proud of their lack of actual experience with the OS, and even the old "DRM sux" chestnut.
XPDM (the current nomenclature for the Windows Driver Model for Windows XP video) was the end-point of a decade of side-by-side work between the DirectX graphics technology (DirectDraw/Direct3D) and the core Graphics Device Interface (GDI). It worked, but only when the OS itself never used 3D features at all. In fact, 3D applications were extremely limited in their ability to multi-task the GPU, and writing XPDM drivers had become extremely complex. After years of experience writing & optimizing drivers for Direct3D9, it was obvious that the bottlenecks for future performance growth were in the driver stack itself. Many years of work lead to the development of WDDM (the nomenclature for the Windows Display Driver Model for Windows Vista video) to address GPU-sharing, 'small-batch' performance overhead, and to unify the GDI/Direct3D APIs to simplify driver development.
Drivers have always been a major source of crash reports. This is fairly obvious for any OS that has a 3rd party plug-in model: MSFT can test the OS with the drivers it ships with, but it cannot test every possible combination of hardware in the market. Windows Error Reporting (aka WATSON) provides numerous data points that help MSFT find these problems, and video drivers crashing in kernel-mode remains a key source of crashes on XPDM. Part of this comes from the complexity of supporting both GDI and Direct3D DDI at the same time, but a lot of it comes from the problem space inherent in programmable shader GPUs. XPDM drivers include shader compilers, and these code bases are like most compilers for non-trivial cases: difficult to get right 100% of the time. Therefore, one of the design features of WDDM was segregating the video driver into a kernel-mode piece and a user-mode piece, so that crashes in complex shader compilers would result in user-mode applications crashes, not BSOD. I note that the original article cited in this thread doesn't state if these are application crashes or BSOD crashes. WDDM didn't just change for the sake of change, but to invest in the needs of the next 5-10 years of video graphics performance, stability, and security.
While MSFT, the hardware vendors, and end-users would all like to have seen 100% rock-solid WDDM drivers and full performance optimizations across Direct3D9 (XP-era games), Direct3D9Ex (the new Windows Vista Shell), and Direct3D 10 the day Windows Vista shipped, the work involved was immense and the timing very tight. AMD/ATI & NVIDIA were developing major revs of their hardware which market realities demanded worked well on XP (and all the benchmarks at the time would judge them on XPDM), at the same time they were supporting an entirely new driver model and new API, had to support both 32-bit x86 and 64-bit x64 native kernel-mode drivers to get full coverage for the transition to 64-bit mandated by the Windows driver logo programs, and deal with the technical challenges 512 MB+ VRAMs created for SLI/Crossfire and PC BIOS compatibility. All that while investing in their own initiatives (CUDA, OpenGL, Linux, etc.) and dealing with things like the AMD / ATI merger.
The transition from XPDM to WDDM is no more messy than the transition from Windows 9x/ME was to NT/2000. There are a lot of moving pieces, a lot of actors to coordinate, and a great deal of technical challenges to overcome and new optimization expertise to develop. As with the previous transitions, it took a year or so to get the kinks worked out, and today the latest WDDM drivers are in pretty good shape overall.
Now back to your regularly scheduled Schadenfreude...
Exchange 5.5 was released 11 years ago in 1997. MS spent most of 2001-2003 in a major engineering training effort and a huge security push precisely because of the malware/virus problems that became endemic on the Internet in the late 90s. Large corporations don't change on a dime, but things do change over a decade. Appcompat and features were MS's mantras through the first 20 years. Now security and privacy are now considered more important than those traditional parameters. As I said,/. is stuck in the world of the 90s when it comes to Microsoft.
MS has supported PAE for many years (the technology referenced in the Pentium Pro), although 36-bit addressing mode breaks a large number of 3rd party drivers which is why its off for most versions of Windows. This is a PHYSICAL addressing technology, which is distinct from the VIRTUAL addressing technology that leads to the 2 GB limit for 32-bit standard processes. Even the Pentium Pro only has 32-bits for VIRTUAL addressing. x64 technology and versions of Winodws support 44 lines of PHYSICAL addressing and 64-bits of VIRTUAL addressing given everyone plenty of room to grow the PHYSICAL addressing over time. The high-bit reserveration for kernel-mode exists for both 32-bit and 64-bit processes.
The repeated usage of the word "hobby" here is actually somewhat ironic. The majority of contributions to Linux come from people who have day jobs that pay their bills, and they use their free time to support Linux and other Open Source products. This actually fits the definition of a "hobby".
This thread suffers the same problem as every other thread on/. that in any way touches upon Microsoft products and technology. The opinions expressed are not only biased but ill-informed. It's to be expected I suppose from a community that prides itself on being willfully ignorant of Microsoft products. The/. community is perpetually stuck in the mid-90s with respect to Microsoft, embodied by the continued use of "BillG as a Borg" icon as both cultural artifacts are laughingly outdated. I suppose I should simply be grateful you didn't side-track into the usual DRM FUD rant that seems to be engrained into/. whenever the word "Vista" is used in any context.
David Cutler when first approach by Microsoft is quoted as saying he wouldn't work on "toy" operating systems in reference to MS-DOS and Windows 3. This characterization could be applied to all the 32-bit Extended DOS products in the Windows 9/ME line. As of Windows 2000, Microsoft's operating systems were all built from the NT codebase David Culter architected, and cannot be characterized as a "toy" operating system. Windows Vista unifies with the Windows Server 2003 Service Pack 1 codebase, and the kernel is a fully modern multi-user, multi-threaded, multi-processor OS supporting x86, x64, and IA64 processor architectures.
Microsoft's per-socket licensing policy has been around for several years, and updates for the radical shift in the market. MP used to be the realm of servers and workstation machines, and the price-points of the business were built around this fact. With the mulitcore shift, this no longer applies by counting 'processors' or 'cores' but still holds with respect to 'sockets'. Machines with more than 1 or 2 physical sockets are typically servers, not workstations. Windows XP will work on dual, quad, and octcore multicore systems, although the OS itself was tuned based on the realities of the market in 2001: single-core and Hyperthreaded single-core machines were the 99% case, with a few high-end workstation machines sporting 2 single-core CPUs. A more serious architectural limit was the way the NT OS used a relatively fixed layout for the 2 GB of kernel-mode memory, and therefore had hard limits on the potential sizes of important kernel memory pools used when allocating a large number of resource handles. The Windows Vista kernel includes dynamic kernel-pool sizes, so this eliminates this problem which is endemic on Windows XP. Running Windows Vista on an 8-core machine is therefore a much better technological choice.
The 2 GB limit of 32-bit processes is not unique to Windows. Using the high-bit to indicate kernel-mode privileged memory is a long-standing technique, and has the benefit of ensuring that all pointer math actually works (i.e., the difference between two user-mode addresses or two kernel-mode addresses fits into a 31-bit signed integer without over/underflow). A 32-bit OS can make use of 32-bits of addressing lines on the physical memory to address up to 4 GB, but standard 32-bit processes are limited to 2 GB of user-mode address space. The problem is that some of those addresses must be used for adapters with the way PC architecture was designed years ago with some of the 3 to 4 GB ranged allocated by video cards and other devices. Therefore, a 32-bit OS can actually only support about 3 to 3.5 GB worth of physical memory, meaning it can support multiple 2 GB limited processes reasonably well.
2 GB was once a stupendous amount of memory address range. In fact, this was the realm of hard disk sizes for many years. Moore's Law has continued its growth, and we are now well into a another transition. There are some transition technologies like Large Ad
It's so nice to see a post in a/. thread on Vista from someone who actually has a clue what the hell they are talking about because they use the software before expressing opinions about it.
We can certainly quibble about the design of UAC's prompts. The root problem is that Adobe was asking for admin elevation before even asking if you really wanted to install anything!
That's called a "PC". You installed the Adobe software. If not, then the OEM did and the finger should be pointed at OEMs who load up computers with crapware.
The Mac is a closed platform. It works well because the number of variations is small, and as long as you fit into the narrow target market them you are golden. You do. Fab for you.
Thank you so much. It just wouldn't be a technically inaccurate FUD-filled thread on/. about Windows Vista contributed largely by people who are willfully ignorant of Microsoft Windows technology without someone bringing up the stupid "DRM is why Vista sux" rant.
No really, there is no such thing as "built-in DRM" for Windows Vista. There's a new kernel process type that isn't trivially debuggable with admin rights, and there are some hooks in the driver stack for verifying the Authenticode signing status of drivers involved with the video and audio playback, but that's about it. All of the "evil DRM" actually lives in code launched by a media player so if you aren't running one and playing DRM content, there's nothing running related to DRM.
The fact a PDF viewer has permission to stop the show by having Windows Vista stop it to ask permission for an update without a net connection convinced me that Vista is unsuitable for presentation and digital audio workstation applications.
So how exactly is it Microsoft Windows Vista's fault for the fact that Adobe releases poorly written software and nagware patchers that demand admin rights to run even when you don't interact with them? If you want to rant about Vista, then complain about the OS. Really if people would hold third parties to account for the poor experiences they generation instead of blaming Microsoft and giving them cover, they might actually be forced to fix them.
I realize that when it comes to Microsoft, the Slashdot community is much happier feeling superior than actually having any factual knowledge about Windows. It seems like the best way for Microsoft to make a version of Windows "cool" is to release a new one. Slashdot has been full of "Windows XP is crap, why use it when Unix/Linux/OS/blah is far superior. Windows 2000 is also fine." for years. Now its "Windows Vista is a dog, just use Windows XP SP 2."
It is certainly true that Microsoft's marketing and PR groups spent five years hyping "Longhorn". That does not mean that there were dev teams working on it for five years straight. Between the RTM of Windows XP in October 2001, and the RTM of Windows Vista in November 2006, the Windows division actually had a number of other major undertakings. The majority of 2002-2004 was spent on the security push. This entailed basically taking every single Windows component team offline, mandatory security training for every developer at Microsoft, and developers being told to prioritize security bugs over all other work. Every few weeks the average component team was given a few hundred to a few thousand bugs filed by code analysis tools and told to triage, fix, and test them. Windows XP SP 2 and Windows Server 2003 SP 1 were shipped with the results of these massive scrubs, plus a bunch of new security components. Windows Vista went further and components were pulled if nobody was willing to clean up the potential security issues.
2004-2005 was spent getting Windows to support the new x64 technology, which was also released in Windows Server 2003 SP 1 / Windows XP Pro x64 Edition.
Then there was the Longhorn restart. The existing "Longhorn" build was thrown out, the Windows Server 2003 SP1 codebase was the new starting point, and teams spent the next two years integrating new technologies into that. The vast majority of UI elements had to be rewritten to eliminate a dependency on the.NET framework technology that wasn't ready. The result is an OS that includes a lot of new underlying technology, the fruits of years of proactive security efforts, but a less polished user experience than was originally envisioned. You can certainly point the finger at Microsoft's leadership team here for letting things get off track for so long, but Windows Vista is not a ' 5 year project'. It's a '2 year project'. The "disaster project" was the original Longhorn that was shot in the head in 2004.
Windows XP was written for PCs with 256-512 MB of RAM, a single-core processor, a VGA card with 16-32 MB of VRAM, and maybe a modem or 10/100 MB NIC. Windows Vista is written for PCs with 1-4 GB or more of RAM, a multicore x64-capable processor, a GPU-based video processor with 256 MB to a 1 GB or more of VRAM, and a Gigabyte NIC. If you still have a system that fits the first description, then you shouldn't be installing Windows Vista.
It's apparently mandatory for some Slashdot troll to complain about DRM every single time a Windows Vista thread comes up. It's almost always someone who is proud of being completely ignorant of what Windows Vista is really like because they've never used it, and has absolutely no understand of Windows internals or archtiecture. The very nature of DRM, it is claimed, must have spread evil tendrils throughout the operating system.
It's pure FUD.
The only OS facilities that exist to support DRM in Windows Vista is a process type that isn't trivial to examine with debugging tools as an admin, and checking the Authenicode signing state of kernel-mode drivers currently loaded. All the actual "DRM" lives in opt-in software used by licensed media players.
Linux may be able to thumb its nose at the terms of the content providers and codec license agreements, and just assume every user will violate DMCA by cracking the mandatory DRM imposed by the DVD, HD-DVD, and BluRay agreements. This is not really an option for a commercial OS. Neither is ignoring the importance of the PC as a media playback device a real option.
The pointer model for x64 native development isn't a big deal. The whole point of the Windows x64 technology is that for the most part, existing 32-bit apps just work as is. This is the major advantage over Itanium which required emulation or recompiling.
The vast majority of compatibility issues come from the fact that lots of software out there is ancient crusty crap. X64 versions of Windows removed the 16-bit subsystem from the Win 3.1 days, and that broke some installers and old software that still carry around Win32s baggage. Kernel-mode drivers have to be written in 64-bit x64 native AND be Authenicode signed. Beyond that 32-bit code in user mode works just fine. The problems usually come from more sutble issues like hard coded paths, completely failing to use Win32 APIs properly, relying on undocumented behaviors, etc. In general an application following modern Windows XP best practices should have no problems on Windows Vista x86 or x64.
For porting to 64-bit x64 native code, the pointer issues are pretty straight-forward, as are the structure alignment changes. The real problems come from the fact that Microsoft agressively blocks the use of deprecated components for 64-bit native applications. The thinking is that these old things may still be needed for legacy 32-bit apps, but new apps shouldn't be using them. This makes it hard to just 'port' old apps. You have to rewrite portions of them. This should improve the quality of 64-bit native software substantially, but it makes the jump from 32-bit to 64-bit more costly.
This article mentions "kernel patching" which is definitely an area that was locked down in Windows Vista for improved security. If Apple was hacking the kernel as part of their DRM implementation, their technique could well run afoul of this change.
I personally equate the conspiracy theories in this thread with the idea that a secret cabal is really running the entire world. It's appealing to some people and it makes them feel safer than the more likely reality that nobody is doing this stuff intentionally or that any specific intellect is truely behind it all, much in the same way our ancestors found it comforting to think they were being boned by Zues or Hera on purpose instead of bad things just happening. Microsoft is not the same company it was in 1995, large numbers of the old timers from those days have retired or at least moved on to other areas of the company, and much of the daily work on the code is being done by people who've only been with the company on the order of 2 or 3 years. There is an entire department concerned with legal compliance, and between them and the security groups have most of the real authority these days.
Microsoft did more than best effort to educate the world about the changes coming in the new OS. Lots of companies either convinced themselves that it would never ship, that their software was too "important" for Microsoft to break and not hack up their OS to make it work, choose willful ignorance, or saw it as an opportunity to shiv each other and/or Microsoft in the press for their own gains. The final builds of the OS were available to MSDN Subscribers and through the Beta programs in November of last year, so it was technically possible to have most compatibility issues resolved well before Jan 30th.
The reality is that corporations do not typically operate on a rational, logical basis. More often priorities are set based on mandates from ill-informed executives in combination with reactive in-bound support issues. Even many Microsoft teams took the same "we'll deal with it after the building is on fire instead of before" attitude, so it really shouldn't' surprise anyone that the entire software industry has a similar attitude.
Still, you have to start somewhere and after a five year lull, things in the world of Windows software has gotten "interesting" (in that Chinese proverb kind of way for some) again.
I'm thinking that we should already have games that are raytraced.
Why bother? All that computational power is being put to use dealing with the real challenges of interactive real-time 3D games: collision, animation, physics, AI.
My understanding is that the Patent Office is not allowed to hire people trained in 'soft science', so all these Patent Examiners are at best Electrical Engineers and not Computer Scientists. Many of them are other brands of Engineers, Physicists, etc.
It hasn't been demonstrated to me that the primary reason the PS2 is popular is because it run PS1 games. It is popular there have been a lot of very cool games, which causes good sales of PS2, which in turn drives more publishers to fund games for the PS2.
For the hand-held games like GBA, GB backwards comp ability is a major bonus given that there is not a huge library of hand-held games or a flood of publishers funding titles for them...
Slashdot Mirror
The key features are the Windows Store, Windows Style apps, and the touch-enabled UI. I was just listing some other technical features that are present in the OS that are useful, relevant to developers, and used for/by traditional desktop apps.
So the focus on consoles in the industry, plus the lingering zombie life of Windows XP, had basically kept everyone stuck at Direct3D 9/Shader Model 3 and 32-bit for years. With next-generation consoles moving to Direct3D 11/Shader Model 5 and 64-bit, we should see more PC titles that take advantage of the latest generation PC hardware. BTW, for some technical background on 64-bit and gaming, see http://www.gamasutra.com/view/feature/3602/sponsored_feature_ram_vram_and_.php
So does a GUID in registry format... but nobody is going to remember that one either.
I had my first computer at 13, and learned to program in BASIC, high-level languages (C/C-like languages), and 6502 assembly well before high-school... Spent years BBSing, playing games, typing in programs from magazines & books, creating varoius graphics-related programs, and generally 'hacking' in the old-school sense. I don't think, however, I'd consider having any real training in 'computer science' until my second year of high-school CS class with an introduction to data-structures. Before that it was all 'hacking' or perhaps 'computer literacy'. Probably the most useful thing in that time was learning to touch-type and that was on an actual type-writer... Being comfortable with technology, and able to learn new systems quickly is important and comes from hours immersed in the 'culture' of computers, but many "prep for college" skills are not computer-related: writing, linear algebra, probability, geometry, organizational skills, communications, etc.
Netbooks with 32-bit only CPUs, legacy printers with 32-bit only drivers, and the corporate upgrade cycle all contribute to the decision to keep 32-bit versions of Windows 7 around. By requiring x64 support in the Windows 7 logo program, the hope is that 32-bit only devices will phase out over time a bit faster so that Microsoft can switch to x64 only at some point in the near future. Hardware vendors would in general want to not do double the work for every driver, but at least for software developers the x86/x64 transition is really not that hard.
The Windows 7 SKU design is improved over Windows Vista. The feature set is strictly a super-set as you move up the chain; you get almost everything you'd need as a developer with Windows 7 Professional (in Windows Vista, you had to have Ultimate to support domain join and consumer media scenarios at the same time); and Windows 7 Ultimate is idetical in terms of features to Winodws 7 Enterprise except for how they are licensed instead of being weirdly different. And the retail boxes for Windows 7 include both x86 and x64 media instead of being limited to the Windows Vista Ultimate retail box or ordering 'alternate media'.
retiring the stupid BillG as The Borg icon! ST:TNG has been in reruns since 1994, there isn't a Star Trek show in production, he hasn't been involved in the daily running of MSFT for years, and as of today he isn't even an employee.
I'm not suggesting that anyone in the /. community consider updating their perceptions of the company for the last 10 years; to acknowledge that anyone who has gone to work for the company since 2000 has had any influence on the company's approach to business, markets, customers, or technology; or to suggest that the investment in software engineering practices, security tools and training, developer outreach, or a monstrous R&D spend could have any value what-so-ever to the PC industry, the software industry, or have improved any MSFT product. It does seem, however, like today would be a good day to update the thumbnail to something that at least reflects the cultural constructs of the 21st century.
While it may make the \. community feel a shared warm fuzzy of schadenfreude, the comparison of Windows Vista to Windows ME is completely lacking in any technical basis or comparison. Windows ME was a end-of-life release, the final gasp the death throes of MS-DOS-based versions of Windows. It was created for basically the same reasons that Windows 95 OSR2 was made: to address some important hardware support requests from PC hardware OEMs ahead of the release of the next major Windows release. The many shortcomings of Windows ME were well-known at the time the project was underway, and were to be addressed in the consumer release of Windows 2000 (aka Windows XP). The two main lessons of the project are: (a) giving OEMs too much opportunity to customize the desktop results in a poor consumer experience and (b) OEMs, like most of Corporate America, will fight against major change with their last breath even if it improves their product.
What Windows Vista and Windows ME do have in common is an immense amount of press and developer negative perception, but the basis of the negative perception is entirely different. Windows ME's bad experience came in large part because it was usually deployed via OEMS in a "customized" form that was basically crippled. Most developers and tech savvy people never used it because Windows 2000 was far superior being an NT-based product and not MS-DOS.
Windows Vista is burdened by the FUD around "Project Longhorn" which was really shot in the head back in 2004 in the "Longhorn restart". There were the much discussed project management problems in the Windows division, the immense impact of the security push effort, the efforts for x64 support, and failures managing extremely deep dependency chains between various component groups most famously seen in WinFS and Avalon. The "5+ years for this?" FUD completely ignores that Windows Vista took just over 2 years from start to finish. During "Project Longhorn", the security push resulted in Windows component teams doing almost nothing but fixing a backlog of security bugs for 2 years. Windows XP SP2 and Windows Server 2003 SP1 / Windows XP Pro x64 Edition were major development efforts from teh same component teams.
From a purely technical point of view, Windows Vista is perfectly fine as it is with the usual caveats of bugs endemic to all large software projects. It is, however, an extremely disruptive release: a complete rewrite of the graphics stack integrating the GPU into the OS scheduling; a new desktop shell; a new audio stack; major changes in the security model for applications, services, and drivers; and the first mainstream release of x64 for consumer systems. That's an immense amount of change for the PC industry to absorb. Many companies are happy to keep their head in the sand about these changes, and all the anti-Vista FUD continues to give them cover in this behavior. "Windows 7" (which is a codename more than anything else) will likely be much more the 95 => 98 or 2000 => XP releases, which were far less disruptive and coincide with stronger 3rd party support and expertise to back up the consumer experience. As for the theory that Windows Vista is being "thrown out in favor of XP", I invite you to look at the debugging symbols packages for Windows Vista SP1. They are identical to Windows Server 2008 RTM for a reason. The investment in the Windows Codebase made for Windows Vista set up the next decade of development, and unifies the codebases in a rationale, scalable way.
As for the "DRM in Vista is the devil" folks, all I can say is head down to Barnes & Noble and while buying yet another copy of Catcher in the Rye, browse through the latest edition of Windows Internals. The "DRM facilities" in the kernel are basically non-existent and the Protected Media Path is just leveraging some already existing security facilities like Authenticode signing and a non-debugging process type. That's it. The "Heart of DRM" is still in Hollywood, so if you don't like it: complain to the content producers who force DRM support in their licensing terms, and stop buying their protected content.
This little bit of FUD has been floating around for some time, and basically the argument goes "I don't see 5 years of work here, ergo Vista sucks". It's true that Microsoft evangelists oversold "Longhorn" for a very long time, so the roots of the FUD do in fact go back to Redmond. However, this particular argument falls flat in the face of the facts. Windows Vista was not in development for 5 years. "Project Longhorn" went on for many years, but as was discussed in the press the "Longhorn reset" in 2004 is the true start date for the development of Windows Vista. Some technologies created for the original Longhorn project were put into Windows Vista, and it did carry on the codename, but it's not the same product at all. Windows Vista started from Windows Server 2003 SP1 in August 2004, and the final version was declared in time for the November 2006 release of the corporate SKUs. That's just over TWO years of develompent. Not FIVE+.
During those five years, Microsoft did have several major releases of Windows, but they came in the form of Service Packs rather than new products. Windows XP SP2 was the result of several years of security work and new security features. Windows Server 2003 SP1 / Windows XP Pro x64 Edition took a few years of work to get Windows running on x64, including many basic drivers that had to be rewritten for 64-bit native. Windows Vista includes the fruits of these efforts because the reset started with Server 2003 SP1.
Certainly the software industry is full of large software projects that ran amok. The original "Longhorn" project falls into this category. Windows Vista is not that product, and neither is Windows Server 2008. That "Longhorn" never shipped.
One can always count on any thread on /. about Windows Vista to generate posts full of verve, passion, and technical ignorance. So far the responses have included long rants about NVIDIA's (and other video vendor's) policy towards Linux drivers, the usual anti-Vista FUD from posters who are proud of their lack of actual experience with the OS, and even the old "DRM sux" chestnut.
XPDM (the current nomenclature for the Windows Driver Model for Windows XP video) was the end-point of a decade of side-by-side work between the DirectX graphics technology (DirectDraw/Direct3D) and the core Graphics Device Interface (GDI). It worked, but only when the OS itself never used 3D features at all. In fact, 3D applications were extremely limited in their ability to multi-task the GPU, and writing XPDM drivers had become extremely complex. After years of experience writing & optimizing drivers for Direct3D9, it was obvious that the bottlenecks for future performance growth were in the driver stack itself. Many years of work lead to the development of WDDM (the nomenclature for the Windows Display Driver Model for Windows Vista video) to address GPU-sharing, 'small-batch' performance overhead, and to unify the GDI/Direct3D APIs to simplify driver development.
Drivers have always been a major source of crash reports. This is fairly obvious for any OS that has a 3rd party plug-in model: MSFT can test the OS with the drivers it ships with, but it cannot test every possible combination of hardware in the market. Windows Error Reporting (aka WATSON) provides numerous data points that help MSFT find these problems, and video drivers crashing in kernel-mode remains a key source of crashes on XPDM. Part of this comes from the complexity of supporting both GDI and Direct3D DDI at the same time, but a lot of it comes from the problem space inherent in programmable shader GPUs. XPDM drivers include shader compilers, and these code bases are like most compilers for non-trivial cases: difficult to get right 100% of the time. Therefore, one of the design features of WDDM was segregating the video driver into a kernel-mode piece and a user-mode piece, so that crashes in complex shader compilers would result in user-mode applications crashes, not BSOD. I note that the original article cited in this thread doesn't state if these are application crashes or BSOD crashes. WDDM didn't just change for the sake of change, but to invest in the needs of the next 5-10 years of video graphics performance, stability, and security.
While MSFT, the hardware vendors, and end-users would all like to have seen 100% rock-solid WDDM drivers and full performance optimizations across Direct3D9 (XP-era games), Direct3D9Ex (the new Windows Vista Shell), and Direct3D 10 the day Windows Vista shipped, the work involved was immense and the timing very tight. AMD/ATI & NVIDIA were developing major revs of their hardware which market realities demanded worked well on XP (and all the benchmarks at the time would judge them on XPDM), at the same time they were supporting an entirely new driver model and new API, had to support both 32-bit x86 and 64-bit x64 native kernel-mode drivers to get full coverage for the transition to 64-bit mandated by the Windows driver logo programs, and deal with the technical challenges 512 MB+ VRAMs created for SLI/Crossfire and PC BIOS compatibility. All that while investing in their own initiatives (CUDA, OpenGL, Linux, etc.) and dealing with things like the AMD / ATI merger.
The transition from XPDM to WDDM is no more messy than the transition from Windows 9x/ME was to NT/2000. There are a lot of moving pieces, a lot of actors to coordinate, and a great deal of technical challenges to overcome and new optimization expertise to develop. As with the previous transitions, it took a year or so to get the kinks worked out, and today the latest WDDM drivers are in pretty good shape overall.
Now back to your regularly scheduled Schadenfreude...
Exchange 5.5 was released 11 years ago in 1997. MS spent most of 2001-2003 in a major engineering training effort and a huge security push precisely because of the malware/virus problems that became endemic on the Internet in the late 90s. Large corporations don't change on a dime, but things do change over a decade. Appcompat and features were MS's mantras through the first 20 years. Now security and privacy are now considered more important than those traditional parameters. As I said, /. is stuck in the world of the 90s when it comes to Microsoft.
MS has supported PAE for many years (the technology referenced in the Pentium Pro), although 36-bit addressing mode breaks a large number of 3rd party drivers which is why its off for most versions of Windows. This is a PHYSICAL addressing technology, which is distinct from the VIRTUAL addressing technology that leads to the 2 GB limit for 32-bit standard processes. Even the Pentium Pro only has 32-bits for VIRTUAL addressing. x64 technology and versions of Winodws support 44 lines of PHYSICAL addressing and 64-bits of VIRTUAL addressing given everyone plenty of room to grow the PHYSICAL addressing over time. The high-bit reserveration for kernel-mode exists for both 32-bit and 64-bit processes.
The repeated usage of the word "hobby" here is actually somewhat ironic. The majority of contributions to Linux come from people who have day jobs that pay their bills, and they use their free time to support Linux and other Open Source products. This actually fits the definition of a "hobby".
This thread suffers the same problem as every other thread on /. that in any way touches upon Microsoft products and technology. The opinions expressed are not only biased but ill-informed. It's to be expected I suppose from a community that prides itself on being willfully ignorant of Microsoft products. The /. community is perpetually stuck in the mid-90s with respect to Microsoft, embodied by the continued use of "BillG as a Borg" icon as both cultural artifacts are laughingly outdated. I suppose I should simply be grateful you didn't side-track into the usual DRM FUD rant that seems to be engrained into /. whenever the word "Vista" is used in any context.
David Cutler when first approach by Microsoft is quoted as saying he wouldn't work on "toy" operating systems in reference to MS-DOS and Windows 3. This characterization could be applied to all the 32-bit Extended DOS products in the Windows 9/ME line. As of Windows 2000, Microsoft's operating systems were all built from the NT codebase David Culter architected, and cannot be characterized as a "toy" operating system. Windows Vista unifies with the Windows Server 2003 Service Pack 1 codebase, and the kernel is a fully modern multi-user, multi-threaded, multi-processor OS supporting x86, x64, and IA64 processor architectures.
Microsoft's per-socket licensing policy has been around for several years, and updates for the radical shift in the market. MP used to be the realm of servers and workstation machines, and the price-points of the business were built around this fact. With the mulitcore shift, this no longer applies by counting 'processors' or 'cores' but still holds with respect to 'sockets'. Machines with more than 1 or 2 physical sockets are typically servers, not workstations. Windows XP will work on dual, quad, and octcore multicore systems, although the OS itself was tuned based on the realities of the market in 2001: single-core and Hyperthreaded single-core machines were the 99% case, with a few high-end workstation machines sporting 2 single-core CPUs. A more serious architectural limit was the way the NT OS used a relatively fixed layout for the 2 GB of kernel-mode memory, and therefore had hard limits on the potential sizes of important kernel memory pools used when allocating a large number of resource handles. The Windows Vista kernel includes dynamic kernel-pool sizes, so this eliminates this problem which is endemic on Windows XP. Running Windows Vista on an 8-core machine is therefore a much better technological choice.
The 2 GB limit of 32-bit processes is not unique to Windows. Using the high-bit to indicate kernel-mode privileged memory is a long-standing technique, and has the benefit of ensuring that all pointer math actually works (i.e., the difference between two user-mode addresses or two kernel-mode addresses fits into a 31-bit signed integer without over/underflow). A 32-bit OS can make use of 32-bits of addressing lines on the physical memory to address up to 4 GB, but standard 32-bit processes are limited to 2 GB of user-mode address space. The problem is that some of those addresses must be used for adapters with the way PC architecture was designed years ago with some of the 3 to 4 GB ranged allocated by video cards and other devices. Therefore, a 32-bit OS can actually only support about 3 to 3.5 GB worth of physical memory, meaning it can support multiple 2 GB limited processes reasonably well.
2 GB was once a stupendous amount of memory address range. In fact, this was the realm of hard disk sizes for many years. Moore's Law has continued its growth, and we are now well into a another transition. There are some transition technologies like Large Ad
It's so nice to see a post in a /. thread on Vista from someone who actually has a clue what the hell they are talking about because they use the software before expressing opinions about it.
We can certainly quibble about the design of UAC's prompts. The root problem is that Adobe was asking for admin elevation before even asking if you really wanted to install anything!
Do you mean this analysis? There's nothing there that contracts my assertion that DRM support in Windows Vista is minimal and opt-in!
That's called a "PC". You installed the Adobe software. If not, then the OEM did and the finger should be pointed at OEMs who load up computers with crapware.
The Mac is a closed platform. It works well because the number of variations is small, and as long as you fit into the narrow target market them you are golden. You do. Fab for you.
Thank you so much. It just wouldn't be a technically inaccurate FUD-filled thread on /. about Windows Vista contributed largely by people who are willfully ignorant of Microsoft Windows technology without someone bringing up the stupid "DRM is why Vista sux" rant.
No really, there is no such thing as "built-in DRM" for Windows Vista. There's a new kernel process type that isn't trivially debuggable with admin rights, and there are some hooks in the driver stack for verifying the Authenticode signing status of drivers involved with the video and audio playback, but that's about it. All of the "evil DRM" actually lives in code launched by a media player so if you aren't running one and playing DRM content, there's nothing running related to DRM.
So how exactly is it Microsoft Windows Vista's fault for the fact that Adobe releases poorly written software and nagware patchers that demand admin rights to run even when you don't interact with them? If you want to rant about Vista, then complain about the OS. Really if people would hold third parties to account for the poor experiences they generation instead of blaming Microsoft and giving them cover, they might actually be forced to fix them.
I realize that when it comes to Microsoft, the Slashdot community is much happier feeling superior than actually having any factual knowledge about Windows. It seems like the best way for Microsoft to make a version of Windows "cool" is to release a new one. Slashdot has been full of "Windows XP is crap, why use it when Unix/Linux/OS/blah is far superior. Windows 2000 is also fine." for years. Now its "Windows Vista is a dog, just use Windows XP SP 2."
It is certainly true that Microsoft's marketing and PR groups spent five years hyping "Longhorn". That does not mean that there were dev teams working on it for five years straight. Between the RTM of Windows XP in October 2001, and the RTM of Windows Vista in November 2006, the Windows division actually had a number of other major undertakings. The majority of 2002-2004 was spent on the security push. This entailed basically taking every single Windows component team offline, mandatory security training for every developer at Microsoft, and developers being told to prioritize security bugs over all other work. Every few weeks the average component team was given a few hundred to a few thousand bugs filed by code analysis tools and told to triage, fix, and test them. Windows XP SP 2 and Windows Server 2003 SP 1 were shipped with the results of these massive scrubs, plus a bunch of new security components. Windows Vista went further and components were pulled if nobody was willing to clean up the potential security issues.
2004-2005 was spent getting Windows to support the new x64 technology, which was also released in Windows Server 2003 SP 1 / Windows XP Pro x64 Edition.
Then there was the Longhorn restart. The existing "Longhorn" build was thrown out, the Windows Server 2003 SP1 codebase was the new starting point, and teams spent the next two years integrating new technologies into that. The vast majority of UI elements had to be rewritten to eliminate a dependency on the .NET framework technology that wasn't ready. The result is an OS that includes a lot of new underlying technology, the fruits of years of proactive security efforts, but a less polished user experience than was originally envisioned. You can certainly point the finger at Microsoft's leadership team here for letting things get off track for so long, but Windows Vista is not a ' 5 year project'. It's a '2 year project'. The "disaster project" was the original Longhorn that was shot in the head in 2004.
Windows XP was written for PCs with 256-512 MB of RAM, a single-core processor, a VGA card with 16-32 MB of VRAM, and maybe a modem or 10/100 MB NIC. Windows Vista is written for PCs with 1-4 GB or more of RAM, a multicore x64-capable processor, a GPU-based video processor with 256 MB to a 1 GB or more of VRAM, and a Gigabyte NIC. If you still have a system that fits the first description, then you shouldn't be installing Windows Vista.
It's apparently mandatory for some Slashdot troll to complain about DRM every single time a Windows Vista thread comes up. It's almost always someone who is proud of being completely ignorant of what Windows Vista is really like because they've never used it, and has absolutely no understand of Windows internals or archtiecture. The very nature of DRM, it is claimed, must have spread evil tendrils throughout the operating system. It's pure FUD. The only OS facilities that exist to support DRM in Windows Vista is a process type that isn't trivial to examine with debugging tools as an admin, and checking the Authenicode signing state of kernel-mode drivers currently loaded. All the actual "DRM" lives in opt-in software used by licensed media players. Linux may be able to thumb its nose at the terms of the content providers and codec license agreements, and just assume every user will violate DMCA by cracking the mandatory DRM imposed by the DVD, HD-DVD, and BluRay agreements. This is not really an option for a commercial OS. Neither is ignoring the importance of the PC as a media playback device a real option.
The pointer model for x64 native development isn't a big deal. The whole point of the Windows x64 technology is that for the most part, existing 32-bit apps just work as is. This is the major advantage over Itanium which required emulation or recompiling. The vast majority of compatibility issues come from the fact that lots of software out there is ancient crusty crap. X64 versions of Windows removed the 16-bit subsystem from the Win 3.1 days, and that broke some installers and old software that still carry around Win32s baggage. Kernel-mode drivers have to be written in 64-bit x64 native AND be Authenicode signed. Beyond that 32-bit code in user mode works just fine. The problems usually come from more sutble issues like hard coded paths, completely failing to use Win32 APIs properly, relying on undocumented behaviors, etc. In general an application following modern Windows XP best practices should have no problems on Windows Vista x86 or x64. For porting to 64-bit x64 native code, the pointer issues are pretty straight-forward, as are the structure alignment changes. The real problems come from the fact that Microsoft agressively blocks the use of deprecated components for 64-bit native applications. The thinking is that these old things may still be needed for legacy 32-bit apps, but new apps shouldn't be using them. This makes it hard to just 'port' old apps. You have to rewrite portions of them. This should improve the quality of 64-bit native software substantially, but it makes the jump from 32-bit to 64-bit more costly.
This article mentions "kernel patching" which is definitely an area that was locked down in Windows Vista for improved security. If Apple was hacking the kernel as part of their DRM implementation, their technique could well run afoul of this change. I personally equate the conspiracy theories in this thread with the idea that a secret cabal is really running the entire world. It's appealing to some people and it makes them feel safer than the more likely reality that nobody is doing this stuff intentionally or that any specific intellect is truely behind it all, much in the same way our ancestors found it comforting to think they were being boned by Zues or Hera on purpose instead of bad things just happening. Microsoft is not the same company it was in 1995, large numbers of the old timers from those days have retired or at least moved on to other areas of the company, and much of the daily work on the code is being done by people who've only been with the company on the order of 2 or 3 years. There is an entire department concerned with legal compliance, and between them and the security groups have most of the real authority these days. Microsoft did more than best effort to educate the world about the changes coming in the new OS. Lots of companies either convinced themselves that it would never ship, that their software was too "important" for Microsoft to break and not hack up their OS to make it work, choose willful ignorance, or saw it as an opportunity to shiv each other and/or Microsoft in the press for their own gains. The final builds of the OS were available to MSDN Subscribers and through the Beta programs in November of last year, so it was technically possible to have most compatibility issues resolved well before Jan 30th. The reality is that corporations do not typically operate on a rational, logical basis. More often priorities are set based on mandates from ill-informed executives in combination with reactive in-bound support issues. Even many Microsoft teams took the same "we'll deal with it after the building is on fire instead of before" attitude, so it really shouldn't' surprise anyone that the entire software industry has a similar attitude. Still, you have to start somewhere and after a five year lull, things in the world of Windows software has gotten "interesting" (in that Chinese proverb kind of way for some) again.
I'm thinking that we should already have games that are raytraced.
Why bother? All that computational power is being put to use dealing with the real challenges of interactive real-time 3D games: collision, animation, physics, AI.
My understanding is that the Patent Office is not allowed to hire people trained in 'soft science', so all these Patent Examiners are at best Electrical Engineers and not Computer Scientists. Many of them are other brands of Engineers, Physicists, etc.
It hasn't been demonstrated to me that the primary reason the PS2 is popular is because it run PS1 games. It is popular there have been a lot of very cool games, which causes good sales of PS2, which in turn drives more publishers to fund games for the PS2. For the hand-held games like GBA, GB backwards comp ability is a major bonus given that there is not a huge library of hand-held games or a flood of publishers funding titles for them...