I spoke to Carl + Richard on .NET Rocks! last week about using HTML5 and Silverlight together. We also covered a bit of Azure toward the end.
The episode is now live here:
http://www.dotnetrocks.com/default.aspx?showNum=687
JT – Sorry, I referred to you as “the other guy I presented with” and never intro-ed you. 😦
Everyone else – JT is awesome.
Thanks to Sharkie’s ongoing organisation efforts, SydJS is a thriving monthly JavaScript meeting here in Sydney. This evening they welcomed me along to talk about Node.js on Windows. Afraid of a mostly non-Microsoft crowd I rocked up with all the anti-Unix jokes I had but they turned out to be all quite friendly and it was a fun little talk.
Here’s what I ran through…
Update 18th July 2011: The latest official builds of node.js now come with a Windows executable. This is thanks to support from Microsoft.
Cygwin gives you a full POSIX environment on Windows. It’s great for running apps designed for Unix, but it’s pretty heavy and not very … Windows-ey. It’d be like creating a “My Documents” folder on Ubuntu.
All that being said, it’s the simplest and most reliable way of getting node running on Windows.
Works for 0.2.6 -> 0.3.1 and 0.4.0+. Anything between 0.3.1 and 0.4.0 won’t compile.
The steps (and common pitfalls) are well documented at https://github.com/joyent/node/wiki/Building-node.js-on-Cygwin-(Windows)
Once you’ve got it running in Cygwin, if you jump out to a standard Windows command prompt and run c:\Cygwin\usr\local\bin\node.exe you’ll get a nice big error. More on this later.
The next step up from Cygwin is to compile it under MinGW. MinGW (Minimal GNU for Windows) provides the bare minimum set of libraries required to make it possible to compile Unix-y apps on Windows, avoiding the full POSIX strangehold environment that Cygwin provides.
Works for 0.3.6+.
Again, there are well documented steps for this: https://github.com/joyent/node/wiki/Building-node.js-on-mingw
Once you’ve got it running in MinGW, jump out to a standard Windows command prompt again and run c:\wherever-you-put-your-git-clone\node.exe you’ll get a nice big error.
Now that we’ve compiled it with MinGW (you did that in the last step, right?) we’re ready to run it on Windows natively.
From a native Windows command prompt:
Next up, I wanted to host node as a service, just like IIS. This way it’d start up with my machine, run in the background, restart automatically if it crashes and so forth.
This is where nssm, the non-sucking service manager, enters the picture. This tool lets you host a normal .exe as a Windows service.
Here are the commands I used to setup an instance of the SydJS website as a service:
nssm.exe install sydjs-node c:\where-i-put-node-standalone\node.exe c:\code\SydJS\server.js net start sydjs-node
We now have node.js, running natively on Windows, as a service. Enjoy!
(Just please don’t use this in production – it’s really not ready for that yet.)
I blogged this morning about how I think WebDAV deserves to see some more love.
I found it somewhat surprising that doing a search for iis7 webdav “invalid parameter” only surfaces 6 results, of which none are relevant. I found this particularly surprising considering “invalid parameter” is the generic message you get for most failures in the Windows WebDAV client.
I was searching for this last night after one of my subfolders stopped being returned over WebDAV, but was still browsable over HTTP. After a quick visit to Fiddler, it turned out that someone had created a file on the server with an ampersand in the name and the IIS7 WebDAV module wasn’t encoding this character properly.
It turns out that this issue, along with some other edge cases, has already been fixed. If you’re using the IIS7 WebDAV module, make sure to grab the update:
Update for WebDAV Extension for IIS 7.0 (KB955137) (x86)
Update for WebDAV Extension for IIS 7.0 (KB955137) (x64)
Because the WebDAV module is not a shipping part of Windows, you won’t get this update through Windows Update. I hope they’ll be able to start publishing auto-updates for components like this soon.
I’m a massive fan of WebDAV.
At Fuel Advance (the parent company behind projects like Tixi), we operate a small but highly mobile work force. We don’t have an office, and we need 24/7 access to our business systems from any Internet connection. VPN links are not an option for us – they suck over 3G and don’t work through most public networks.
Enter WebDAV. It’s a set of HTTP verbs which give you read/write access to a remote folder and its files, all over standard HTTP. The best part is that Windows has native support for connecting to these shares. Now, we all have drive letter access to our corporate data over the public Internet. It’s slim and fast without all the management overheads that something like Sharepoint would have dealt us. It’s also cross platform, allowing us to open the same fileshares from our machines running Mac OS X.
IIS6 had reasonable support for WebDAV, but for various (and good!) reasons, this was dropped from the version that shipped as IIS7. In March this year, the team published a brand new WebDAV module as a separate download. This module is built using the new integrated pipeline in IIS7 and is much more nicely integrated into the management tool.
Kudos to Keith Moore, Robert McMurray and Marchel Cohn (no blog) for delivering this high quality release!
This is the demo I made for the Microsoft Demos Happen Here competition. The criteria was that it had to be under 10 minutes, and show one or more of the features from the launch wave technologies – Visual Studio 2008, SQL Server 2008 and Windows Server 2008.
I chose to demonstrate PHP running on IIS7 using FastCGI, then integrating this with an ASP.NET application before finally load balancing the whole application between two servers in a high availability, automatic failover cluster.
I managed to do all that with 2 minutes to spare, so I think it’s pretty clear that Windows Server 2008 is the best web stack in the world.
Update 5-Sep-08: I won. 🙂
Are you getting this error trying to install the WebDAV extensions on your Windows Server 2008 box?
The IIS 7.0 CoreWebEngine and W3SVC features must be installed to use this product.
It could mean that you tried to install the wrong architecture (x86 vs. x64). Noob.
(Of course, I haven’t just spent the last 5 minutes working that out.)
This was the question I was faced with last week. I was configuring a VPC image in Sydney, that I was later going to load on to a physical box in San Diego, then use it from anywhere in the world. So which time zone to use?
I decided upon UTC, and now, the more that I think about it, I don’t know why all servers aren’t configured that way.
Advantages to using UTC:
Disadvantages to using UTC:
My recommendation: Run all your servers in UTC (that’s “GMT – Greenwich Mean Time” with “Automatically adjust clock for DST” turned OFF).
Maybe Adam can add this to his standards? 😉
I can’t say this feels right to me:
Notice the 603 terabyte value in the “I/O Other Bytes” column for csrss.exe. Oh yeah, and the box has only been up for 24 hours. The number seems to climb by 50 or 60 GB a second when I’m connected via RDC. If I logoff then back on, the count starts again.
I’ve tried Googling it, but found no solutions.
Anybody got any ideas? It doesn’t actually seem to be causing a problem, it’s just out of the ordinary.
The box is a 1.8GHz Core2 Duo running Windows Server 2003 R2 Standard x64 Edition.
Update – I (think) I found the solution!
Following some suggestions in this post’s comments and on Google that this might be a virus, Edward suggested I fire up a copy of SysInternals Process Explorer on the server. I’ve used the SysInternals tools in the past, but not being a server guy by trade meant that I’d forgotten about them.
After finding the process, I was quickly comforted that this wasn’t a virus. The signature was verified, it was executing from the correct path (system32) and it was running under NT AUTHORITY\SYSTEM where I expected it to.
If we recall the original symptoms, the count was reset if I logged off RDC and back on again. This didn’t really prove much other than the fact that the process restarted at login. Swapping to the “Performance Graph” tab is Process Explorer did however show some interesting results.
Whenever I minimized my RDC window, it stopped requesting data and the I/O bytes graph was stagnant. As soon as I brought the RDC window back up and started interacting with it, the values skyrocketed. My screenshot doesn’t show it, but that graph was peaking to 80GB!
The end result would seem to be: “that’s just how much stuff is going on to support RDP”.
To me that’s an incredible amount on information being shuffled around and process, but I guess this is why the actual data on the wire is so efficient. Unless anything else comes up, I’m happy to file this in the “amazing but normal” pile.
Tatham Oddie 