Another crazy little Windows tip – I can’t remember if this was a Windows XP problem or whether I’d also seen it in Vista, but I’m cleaning out my blog drafts and wanted to flesh this out.

Basically I had a network printer set up that would work until I rebooted my machine, then it would fail. I couldn’t figure out for the life of me what was going on (I think it said something about me not having permission, though – I should have written down the error message). If I removed and readded the printer it’d work again.

Anyway, the problem turned out to be that my user account name was different on my other machine, and the printer wasn’t shared for just anyone to print on. Because of that, I’d had to present alternate credentials when I added the printer, and each time the computer reset, the credentials would get lost and it’d get confused. I don’t know why it didn’t just ask again, but it didn’t.

The solution is convoluted. I browsed to a shared folder on the other machine, and added it as a mapped drive. There’s an option in there to connect with alternate credentials. Since Windows shares the saved credentials between all shares and printers on a remote machine, and it’ll reconnect the mapped drive at startup using the alternate credentials, the printer will start working again.

Every time I try to set up IIS7 on a Windows Vista machine I run into the same series of problems. You’d think I’d have learned by now, but I usually just struggle through the cryptic error messages and get it working one way or another, then forget about it until the next time I need IIS7 on a machine that doesn’t have it. Finally I’d had enough and so I decided to write myself a little guide here so I won’t waste as much time next time. These instructions are basically the same as these, but with additional detail and screenshots.

The first step is to actually install IIS7. Unlike in Windows XP, IIS isn’t installed by default. That’s great, but it can be kind of hard to find it when I need it.

You’ve got to click this link that says “Turn Windows features on or off” which will (after some time) bring up a big tree of features you can check or uncheck.

You’re going to want most of “World Wide Web Services”. If you are also interested in installing PHP, make sure everything I’ve circled in red is checked. I just added everything to be safe. What’s important is that you have the ISAPI and CGI stuff. I also checked the IIS6 compatibility bit so that installers for things like PHP might have a better chance at automatically configuring things (fat chance).

At this point you can start dropping things into C:\inetpub\wwwroot and everything should be peachy. I don’t put my sites there since I have them checked out into various folders in my Documents folder. So I need to create some virtual directories to point to my sites. This probably won’t work off the bat - you’ll get 403 errors that complain about wrong permissions or something. You need to make sure that the “IIS_IUSRS” and “Authenticated Users” users have read access to the directory. I’m not sure why “Authenticated Users” needs to be there but it made it work. Make it look like this:

At this point your folder should be accessible from the virtual directory, and any ASP.NET stuff will probably work. If you’re not interested in installing PHP, you can stop here.

Installing PHP on IIS7

PHP doesn’t really play well with IIS. However, we can get it going good enough for local testing of your PHP code. First, go install PHP5 from php.net. Choose to install it as an ISAPI extension for IIS, but don’t worry too much, since it won’t work anyway. Now open up IIS Manager. If you’ve followed the steps above (specifically, selecting the correct “Windows features”), your IIS manager should look something like this:

What’s important is that you have the parts outlined in red - the “CGI” icon, the “ISAPI Filters” icon, and the “ISAPI and CGI Restrictions” icon. Those mean the right bits are installed.

Now double-click the “Handler Mappings” icon, and click “Add Script Map…” Fill out the form like this:

Make sure it’s pointing to your real copy of php5isapi.dll. At this point your Handler Mappings screen should look like this:

Also make sure that your “ISAPI Filters” screen looks like this:

If not, add PHP like this:

If you’re running the 64-bit version of Vista like I am, there’s one last thing to do in IIS Manager. Since the PHP ISAPI extension is a 32-bit app, you’ll need to set your app pool to run in 32-bit mode. I’ve already written one blog post on this (to get MySQL working with ASP.NET), and the instructions are the same. Basically open up the app pool’s advanced settings dialog and flip it to 32-bit mode:

If you forget this you’re likely to get errors that look like “Calling LoadLibraryEx on ISAPI filter "C:\Program Files (x86)\PHP\php5isapi.dll” failed".

If you load up your PHP files you’ll probably get something like “failed opening required” blah blah. This is because the PHPRC environment variable isn’t set correctly by the PHP installer. We’ll have to do it ourselves. Go to the Control Panel and search for “env”:

Now add a System environment variable like this (point it at the directory PHP is installed):

At this point you must reboot your computer to get the environment variable to take effect. Annoying but true. At this point PHP should work, more or less.

I still have some problems with PHP the way I’ve described configuring it. The most obvious is that the IIS worker crashes every once in a while:

I suspect reconfiguring PHP to be run as a CGI handler instead of an ISAPI module would help here, but it hasn’t been annoying enough to make me go change it. Another avenue to investigate is the new FastCGI support that’s available for IIS7.

The other problem I’ve had is that I have a handful of image files in one of my sites that are managed by Subversion and get locked and unlocked pretty frequently. After I’ve committed an image, it loses its permissions and can’t be served from IIS anymore, and I need to go reset the permissions. That’s pretty annoying, and I’m not sure if it’s a bug in Subversion or in one of my SVN clients (TortoiseSVN and Subclipse).

At least this setup works enough to try things out quickly. I hope it helps anyone else who’s struggling with one of these setups.

Update: You might want to try out the new Microsoft Web Platform Installer which purports to set up PHP along with anything else you might need.

The other day I tried to move my Hogmonitor application to my Vista x64 machine, so that I could shut down the XP machine that has been running it. I thought it’d be a nice way to save the power used by running the XP box 24/7, since it is otherwise used infrequently. However, I quickly hit up against a brick wall - Windows Vista 64-bit doesn’t allow you to run drivers that haven’t been digitally signed. Since the Hogmonitor uses the InpOut32 library, which relies on a custom driver, I’m out of luck. InpOut32 even has a 64-bit port, so I could have used it fine on a Windows XP 64-bit machine, and it would work on a 32-bit Vista machine. But on 64-bit Vista, there is no way around driver signing.

I understand why Microsoft chose to require driver signing - it’s to keep home users from messing up their systems with weird drivers. But making signed drivers a requirement on 64-bit only is really weird. Aren’t the 64-bit users going to be the power users? I’d be fine with requiring signing by default if I were allowed to turn it off through Group Policy or something, but as far as I know there’s no way to disable this at all in Vista RTM (in the Betas there was a way to disable it, but it doesn’t work anymore). This is the first thing I’ve hit that I can do with an XP machine that I can’t do with a Vista machine (OK, printing too, but that’s HP’s fault). And I don’t hold out hope for the drivers getting a signature, either - those certificates cost $895! That basically prevents any drivers written by people in their spare time from being used in Vista x64. This includes stuff like InpOut32, overclocker fan and temperature monitors, hardware tweakers, and a host of other goodies.

This is really awful, Microsoft. I want to use my computer’s hardware however I want. And if that involves voiding my warranty by installing unsigned drivers so I can communicate with my hobby-project hedgehog sensor, then let me do that. Don’t make me keep around another computer just so I can use simple hardware.

Update: It does work! See the note at the bottom of this post.

I’ve had this post in my “drafts” for about a month now. Originally it was titled “How to use Macintosh shares from Windows Vista”, but I was waiting to actually figure out how to get them working. Unfortunately it looks like it’s simply not going to happen.

Here’s the problem. You’ve got a Vista machine, and you try to visit a network share on a Mac OS X machine that has been shared using Windows Sharing. This share worked just fine with your XP machines. However, in Vista, you try to log in and it just spits back, again and again, that your username and password are incorrect.

The problem lies with the fact that in Vista, Microsoft made the gutsy but correct decision to go hardline on security. One of the targets on their list was the weak Lanman and NTLM network authentication schemes that were the default on earlier versions of Windows. The main problem with these authentication schemes is that, if a hacker can get ahold of your password that has been hashed for Lanman or NTLM (and it’s just sitting there on the drive, by the way), they can connect to remote machines using your credentials without even having to know your unhashed password. Pretty scary. So in Vista both of these schemes are disabled in favor of the much more secure NTLMv2 scheme.

There’s a problem with this on the Mac’s side though - it doesn’t support NTLMv2. Rather, the version of smbd that ships with MacOS X, even 10.4, does not support NTLMv2. You should be able to configure your smbd.conf file like Jon Belanger explains in this forum post, but it doesn’t actually work.

The problem with this is that if you do a Google search on why your Mac shares don’t work in Vista anymore, the suggestions that come up all tell you to simply decrease the security of your Vista machine. That’s really not the best idea - it just brings you back to the old insecure XP level. Unfortunately, until Apple ships a new smbd, this isn’t going to be fixed. So far I’ve just mounted my Windows shares from the Mac and it’s good enough, but I hope (and expect) that Apple will fix things in 10.5.

Update (7/16/07): In the comments, Osvaldo points out that by entering your username as “machinename\username”, with machinename being the name of the remote Mac, it works. So for me, logging in from Daedalus (my Vista machine) to Samus (my Mac), I need to type “SAMUS\brh” and it works! Thanks Osvaldo!

One of the first things I noticed in Windows Vista were the toolbars. Certainly they’re prettier now, and the fact that the main menu is on the way out is exciting. But the most interesting thing is that they’re different colors. Windows Explorer gets a blue-green toolbar, Windows Mail and Windows Calendar are blue, Windows Media Player and Windows Photo Gallery are black, and Internet Explorer gets a silver variant. This seems like a cool way to divide up the built-in apps, but the question that comes immediately to my mind is what color a third-party app should choose. It turns out that the Vista User Experience Guidelines are silent on this issue.

Fortunately everettm over at the Shell:Revealed blog was able to answer this question in the comments. To summarize, the recommendation is that all third-party apps use the silver toolbars. The colors are reserved for Windows branding, with blue-green standing for core Windows components like the shell, black for media apps, and blue for PIM/organization apps.

While I appreciate the response, I’m not sure I like that answer. I really like the colored toolbars, and I’d love to have my apps integrate more with the general look and feel of Vista by picking the toolbar color that is most appropriate to my application. For example, if I went to a toolbar-only UI for PNGGauntlet, I might consider going with the black toolbar, since it is an image manipulation app. Hopefully by that time the UX Guidelines will have been updated to give more explicit (and more permissive) guidance on toolbar colors.

I’ve recently given up Dreamweaver entirely in favor of Aptana, a great (and free!) Eclipse-based web development IDE. It features great JavaScript IntelliSense, document outline view, AJAX library function autocomplete, and an FTP component that should make Dreamweaver users very comfortable. Even better, with plugins like Subclipse, you get source control for your websites. Basically, it’s one of my favorite programs.

However, all is not rosy. The Aptana documentation’s guide to installing and running Aptana on Windows Vista recommends turning on XP compatibility mode, disabling desktop compositing, and always running it as Administrator. If you haven’t had an app turn off Aero Glass for you before, you’re in for a shock - it really sucks after you’ve gotten used to Glass. And running as Administrator isn’t that great an idea with a product as connected as Eclipse.

Fortunately, all is not lost. First, go to Sun and download the JavaSE 6 JRE (32-bit). It’s a huge upgrade from the Java 1.4.2 JVM that Aptana usually comes with, and it includes some major Vista compatibility features. Next, download and install Aptana minus the JRE from the Aptana downloads page. Already installed Aptana? Just go into the program directory and delete the “jre” folder. Now, make sure the Aptana shortcut doesn’t have any compatibility features checked. (Disclaimer: you might actually need to run as Administrator the first time you use Aptana, but certainly never again.) Start up Aptana, and everything should be glassy and smooth.

If Aptana complains that it can’t find the JRE, go into your Aptana program directory and open up aptana.ini. Add the line -vm='C:\Program Files (x86)\Java\jre1.6.0\bin\java.exe' to the top of the file, and save it. I had to do this mainly because I have both the 64-bit and 32-bit JREs installed, and while most Java apps work on the 64-bit JRE, Eclipse (and thus Aptana) doesn’t support 64-bit yet.

Update: Newer versions of Aptana come with Java 1.6, so this isn’t a problem anymore.

A little while after setting up 64-bit codecs for Windows Vista, my Windows Media Sharing suddenly died (taking my ability to connect to Windows Media Center from my Xbox 360 with it) with what might be the most infuriating error message ever displayed:

Great. Which Windows setting or component has changed? Why does that stop sharing from working? How do I fix it? The “Web Help” link is no more useful. On top of this, whenever I tried to launch Windows Media Player from the Start menu, nothing would happen - inspecting the Task Manager, I could see WMP running, but it wasn’t doing anything. Killing that process would allow me to start Media Player, but if I selected the sharing option, all I got was that despicable error dialog. Anyway, after a ton of trial and error, I found a way to fix things. Seems neither a Windows setting nor a component had changed - the Windows Media Player library database had gotten messed up. Simply going to C:\Users{username}\AppData\Local\Microsoft\Media Player and deleting all the files there allowed me to start up Windows Media Player. I had to re-specify which folders I wanted to watch, and let it re-create my library. Then I could start sharing again, and re-register my Xbox 360 as a Media Center Extender. I don’t know whether switching Windows Media Player to 64-bit killed things, or whether it was some crashes I had (related to improperly set memory timings), but I’m glad to have music in my living room again.

Update: Apparently this happens on Windows XP, too. On XP, you can find the same folder at: C:\Documents and Settings{username}\Application Data\Local\Microsoft\Media Player

A few months ago Microsoft released an update to the Remote Desktop client that, among other things, added compatibility with Vista. I’ve just recently had the chance to try this out, and it’s pretty neat - it looks better, and seems to perform better too. I did hit one snag though. When I enabled Remote Desktop on my Vista machine, I checked the box that said only clients using Network Level Authentication (NLA) could connect. I thought this would work, since the release notes for the new Remote Desktop client said that it supported NLA. However, upon connecting from my XP laptop, I got this:

“The remote computer requires Network Level Authentication, which your computer does not support. For assistance, contact your system administrator or technical support.”

I did a little research, and here’s the deal. NLA simply isn’t available on XP (or at least, isn’t installed as a part of the new Remote Desktop). So to connect to Vista from your XP machines, you’ll need to uncheck the “requires NLA” box in Vista. After that it’s smooth sailing.

I’ve been spending the past couple weeks playing with a brand new machine I made for Windows Vista, and it’s been great. One of the things I’ve been looking forward to the most is Windows Media Center. Aside from the fun I can have developing WMC addons, I’ve been meaning to try out the Windows Media Extender functionality of my Xbox 360. Hooking up my laptop to my TV every time I want to watch things just doesn’t cut it. Unfortunately, I have one problem - most of what I watch is already encoded in XviD format, which the Xbox 360 lacks a codec for.

But that’s not my only roadblock. Being a sucker for the bleeding edge, I decided that my shiny new Core 2 Duo, being a 64-bit processor, should run Windows Vista Ultimate x64. Right off the bat this presented a problem - after installing DivX and XviD, Windows Media Center would complain that any file I threw at it was unreadable. This didn’t make any sense, since those same videos played just fine in Windows Media Player. Perplexed, I happened upon Task Manager, where I noted that Windows Media Center was running in native (64-bit) mode, while Windows Media Player was running in 32-bit mode. The problem was that I only had 32-bit video codecs, and Windows Media Center couldn’t use them from its 64-bit ivory tower.

However, no problem is a problem for very long. Both of my issues can be resolved with freely available software, and here’s how it works. First, you need to install the ffdshow Vista Codec Package. This will put video codecs for just about every known video format onto your machine. No worrying about downloading this codec and that codec - they’re all here. Next, install the ffdshow x64 components. This makes all those codecs usable from 64-bit programs, as well as giving you a handy shortcut that will set Windows Media Player to always run as 64-bit, too!

Now all your videos work in Media Center. To close the gap with the Xbox, you need Transcode360. This app will transcode your videos, on the fly, into a format the Xbox 360 can understand. It takes a hefty machine, but you’ve got a 64-bit processor anyway, right? Once this is installed, just fire up Media Center from your Xbox, navigate to a movie, hit “Info” on your remote, select “More…”, and select “Transcode 360”. It’ll pause for a while as it crunches through the first few minutes of your video, then it’ll start. Voila!