'Unexpected error 0x8ffe2740 occurred.' when starting IIS
I just installed IIS and ASP.NET 2.0 on my laptop, and I noticed I could not get IIS to actually start. Each time I tried to start it using the Internet Services Manager, I’d get a message box with this helpful message:
Unexpected error 0x8ffe2740 occurred.
Not immediately recognizing the meaning of 0x8ffe2740, I Googled, and came upon MS KB article 816944, which helpfully clarified that this message indicates TCP port 80 is already in use, and thus IIS cannot bind to it.
Naturally.
Next, I ran over to SysInternals to grab a copy of TCPView, an indispensable tool that dumps the TCP (and UDP) endpoints on your machine, like netstat, but then goes a bit further and shows you which process holds the handle to that endpoint.
Sure enough, it turns out Skype was listening on port 80. This seems odd, but Skype has alot of tricks to get through firewalls and NATs, one of which is to try to communicate over the standard HTTP (80) and HTTPS (443) ports. In my case I know this won’t help at all since the NAT on our VSat here in Baghdad will almost certainly decline requests to those ports, so I will disable this functionality, in the hopes of being able to use IIS once again.
In the Skype 2.0 beta, Options dialog, Connection tab, I simply uncheck ‘Use port 80 and 443 as alternatives for incoming connections’, restart Skype, and voila.
Why Bluetooth Sucks
While researching my idea for a Skype Plugin for Bluetooth Headsets, I came to realize just how much Bluetooth sucks. As a technology, it seems reasonable enough, albeit as complex and elaborately generalized as one would expect for a technology that emerged fully formed from a standards body.
However, it takes more than technology to yield a technology that doesn’t suck.
On PC side, you need a Bluetooth radio, obviously, but you also need a Bluetooth ‘stack’. This is akin to the third-party TCP/IP stacks you used to have to buy to use IP networks, back in the dark ages. There are competing vendors, of course, including Microsoft’s crippled BT stack in XP SP2, the dominant Widcomm stack, and others. Of course, there’s no common API like the socket API shared by TCP/IP stacks, so you have to pick one and code against it.
The APIs are not open (save for MS’s), so to code for the Widcomm stack you buy the Widcomm Windows development kit, to the tune of USD1400. The apps you produce with said stack won’t work with non-Widcomm drivers. Awesome.
Now, Widcomm had an opportunity to drive Bluetooth adoption by providing a free development toolkit for interfacing with Widcomm Bluetooth drivers, and selling the driver suite to hardware manufacturers, who notoriously suck as writing their own drivers. Instead, Widcomm opted for the short-term revenue-maximization approach typical of an Old Economy hardware vendor.
Now, if I want to write an Skype plugin which would increase the value of a Bluetooth headset for anyone who uses Skype, I have to shell out for at least the Widcomm development kit (since most BT hardware uses Widcomm), but even then I won’t be fully covered, since there are BT devices that don’t use the Widcomm stack.
Recall that it was the standard, cross-platform sockets API that allowed tools like FTP, gopher, telnet, and eventually Mosaic to be written once and used on a wide range of TCP/IP stacks. Imagine if Mosaic was tightly coupled to a specific vendor’s stack (say, NetManage), and Andreesen et al had to shell out $1500 for the privilege of coding to the NetManage API. It’s like that now with Bluetooth, and it sucks.
Will Microsoft please write a complete Bluetooth stack, maybe even incorporating the Bluetooth 2.0 profiles, kill Widcomm’s racketteering business, and open the door for compelling Bluetooth apps?
Skype Plug-in for Bluetooth Headsets
I recently got a bluetooth headset for use with Skype, since my laptop’s on-board MIC port is basically broken, and USB headsets are actually shittier and more expensive than the bluetooth variety.
Now, I want Skype to support the headset the way a phone does, letting me voice dial, answer and disconnect calls, and redial.
There’s a commercial app, the eponymous SkypeHeadset, but I don’t like it for a few reasons:
- Why reuse when you can re-invent?
- Fascist copy protection; each binary is tied to your Skype username
- Coupled to the Wicomm BT stack
- It’s commercial
I’ve rummaged around the Platform SDK, and found the Bluetooth section in Networking | Network Protocols, which covers the APIs at the high level. Len Holgate posted some sample code that he got working, as a guide. I’ve found surprisingly little coverage of this topic, which kind of surprises me.
Other feature ideas include:
- Using the presence/absence of the headset as a signal to clear/set the away status
- Switching Skype’s audio input and output devices to those bound to the headset when it’s present, and the default audio device when not present.
Perhaps I can use the 32feet.net managed library to implement the comms.
What’s not clear to me is if the Bluetooth API provided by MS will work when the hardware is using the Widcomm stack, as almost all hardware does since the MS stack sucks profoundly (it doesn’t support the Headset Profile; way to go, MS!) My guess is not, which is why everyone licenses the Widcomm SDK, but that’s not free, which sucks.