We’ve all heard of (and, quite unfortunately, experienced) the infamous Blue Screen of Death. Some of us who tested the earlier Windows Vista beta builds had the unique experience of trying out the Red of Screen Death, which occurred when the bootloader experienced an un-handled exception (we experienced more than our fair share of these during the early days of EasyBCD development!). And then there’s Vista’s Purple Screen of Death, which few have seen.
Microsoft [[MSFT]] has just released another version of its most-eagerly anticipated Service Pack 1 for Windows Vista, labeled as Release Candidate 1; along with another build of Windows Server 2008: the November CTP. Both releases are available to official testers from Microsoft Connect.
This is the third SP1 release made “available” to the public, starting with the leaked build back in August, followed closely by the first official release of Windows Vista SP1 beta in September.
Vista SP1 RC1 (build tag: 6001-17042-071107-1618) has been available as both an slip-streamed ISO image and a standalone upgrade utility. The slip-streamed ISO image is available in either English or Japanese, while the upgrade utility supports the five main Windows Vista localizations (Arabic, English, French, German, and Japanese).
The Windows Server 2008 November CTP (build tag: 6001-17042-071107-1618) is only available as an ISO in English in multiple flavors (Web Server & Standard Edition) for multiple platforms (x86, x64, and IA64).
We previously covered the final release of the IIS FastCGI module, jointly developed between Microsoft and Zend… But just this week, Microsoft [[MSFT]] announced the availability of the RTM of the IIS FastCGI module.
So what’s going on? We’ve downloaded the current release (which, by the way, is not compatible with the old one, you must uninstall then install the new version) and checked the version number on \Windows\System32\inetsrv\fcgiext.dll – it came out to be 6.1.36.1.
By contrast, the version we downloaded and installed a month ago (which seems to have been dubbed the Go Live release) was checked and found to be 7.0.6001.16606.
Obviously the Go Live release was using the numbering from the Microsoft Windows Server 2008 releases, but it’s got us confused.
Most people take a look at these three facts, and instantly come to a conclusion.. the wrong conclusion: you can’t properly manage a Windows server because it’s inherently lacking in the shell scripting department.
Hopefully Monad (Microsoft Power Shell) will provide a solution, but so far the results are mixed; and it’s not popular enough to be considered a viable substitute at the moment. ↩
We’ve been working on moving to a new server all week, and we’ve just finished the transition. Best of all, we’ve switched to the new servers without any downtime in-between. Our new server is a 1.86 GHz Core 2 Duo and with 3GB of DDR2 RAM – all thanks to the awesome guys and gals at Lunarpages, the best host there is.
A lot of work has gone into this transition in hopes of raising the performance – and more importantly, the reliability – of our server. In the past year (since we first started our hosting with LP), we’ve gone from several million hits a month to dozens of millions, and our old server took quite a hit. To that end, we’ve focused on deploying lightweight and highly-optimized code all around; hopefully there will be no more un-expected downtime… ever.
Our current software setup is very complicated, but hopefully it’ll take us all the way to 0.00 minutes of downtime – that’s our goal! We have multiple application servers and programs running in the background each doing what they best – instead of the traditional have-the-web-server-do-it-all way. At the moment, we currently have a software stack comprising of a tightly-knit mesh of these products:
Congratulations are in order for Microsoft’s IIS development team – today they’ve just announced the public availability of the final version of the IIS-FastCGI ISAPI Extension – a long-awaited and much-improved way of running just about any open-source scripting engine on IIS, safely and quickly.
The Microsoft [[MSFT]] FastCGI module for IIS 5.1, 6, and 7 (with Windows Vista and Server 2008) have been in the works for quite a while now, and we’ve been using them since the first beta release – they’re good. While the biggest benefit will be seen in using FastCGI w/ IIS7 to take advantage of the new kernel-mode caching, it’s still a huge improvement over the old way of running scripting engines for languages like PHP on Windows.
The Problem: Most open-source scripting engines like PHP and Ruby on Rails were initially developed on/for the *nix world. On Unix-based platforms, the easiest way of creating multi-threaded applications is just to run the same app twice or more (The CGI model). On Windows, that doesn’t work out so well, because it takes a lot more resources to create another process. So these engines released Windows-specific single-process multi-threaded engines; the only problem was, they weren’t stable. Too many race conditions in some very non-thread-safe code wreaked havoc on many Windows systems, with the PHP developers themselves giving “Stability on IIS” the lowest level of concern.
Following our coverage of the Windows XP SP3 beta leak almost a month ago in August, here’s some more info on the official beta, which just had its first authorized distributable released earlier today. Say hello to Windows XP SP3, build 3205!
While Microsoft’s [[MSFT]] newly-released build and the one leaked a month ago (Build 3180) may share the same name, we can exclusively reveal that they are not identical releases. This release, also shipped as windowsxp-kb936929-sp3-x86-enu.exe, is 334.2 megabytes and has been made available to tier-one Windows Server 2008 and Windows Vista SP1 beta testers. Hashes are as follows:
CRC: 56e08837
MD5: c8c24ec004332198c47b9ac2b3d400f7
Along with the standalone installer redistributables (in English, Japanese, and German), Microsoft also provided the usual release notes and a list of all the hotfixes included in this release. Contrary to popular belief, Windows XP SP3 does ship with all-new features – not just patches and hotfixes, most of them backported from Windows Vista:
Steve Reynolds, program manager of the Microsoft [[MSFT]] Internet Explorer development team, has just announced an “update” of sorts to Internet Explorer 7 a year or so after its original release in 2006. Never mind the fact that we were promised regular updates and that “Internet Explorer 7 won’t be like IE6” with regards to lack of new features and updates, what’s up with the list of the things that have changed with this new version!? Have a look for yourself at the “changelog:”
- No need for WGA verification in order to get Internet Explorer 7
- The menu bar is now visible by default.
- The Internet Explorer 7 online tour has updated how-to’s. Also, the “first-run” experience includes a new overview.
- We’ve included a new MSI installer that simplifies deployment for IT administrators in enterprises. Learn more about it here.
Interesting… Here’s our take on these “updates”
Mono is the open-source version of Microsoft’s .NET Framework. It implements most of the backend framework features, but unfortunately, falls flat on its pretty little face when attempting to display the user interface – which is what desktop apps are all about.
Wine on the other-hand, is a Linux port of (major parts of) Microsoft’s Win32 library – the core dependencies of the Windows development libraries, and more importantly, the win32 interface elements. With Wine, you can run many traditional C++ win32 executables on Linux, with certain limitations.
Mono’s biggest stumbling block is the GUI and .NET programs that use P/Invoke to call native non-managed win32 dlls – Mono is a pure .NET environment, and can’t handle them. But from the description above, that’s exactly what WINE excel at… So can’t we use WINE + Mono to make just about any .NET program run on Linux fresh out of the .NET compiler?
Unfortunately, the answer is no. Back when the Mono project was first starting out, the Mono development team considered using WINE to implement the System.Windows.Forms namespace of the .NET Framework (which is practically 100% native C++ unmanaged win32 code in .NET wrappers). But they made the right choice in deciding to not take the easy way and go that route, leaving the integrity of the Mono project intact and focusing on true cross-platform user interface libraries instead (the GTK# is now the UI Library of choice for cross-platform .NET applications).
For all the Windows-bound PHP users out there, consider yourselves warned: even if you’re running the (supposedly) thread-safe PHP Win32 binary redistribution, you’re still susceptible to PHP Access Violation Errors, race problems, heap corruption, and much worse if you use the popular eAccelerator opcode-caching extension.
We did our testing with the binaries compiled by SiteBuddy using the latest versions of both PHP and eAccelerator. Almost immediately after initiating a stress test on our test servers we experienced the dreaded “PHP Access Violation” error – which brings down the entire IIS Worker Process to its heels.
