Microsoft Shuts Windows On Bluetooth Support

kilrogg points to "a story from eetimes.com on Microsoft's refusal to include Bluetooth support in their next versions of Windows. They seem to think (as most of us) that 802.11b has a better chance of succeeding." The article cites the recent flopped Bluetooth demo at CeBIT. I'm pretty neutral on Bluetooth, but when's the last time a new technology's first big public demo was perfect?

Comments

Bluetooth and 802.11 are for different uses

[JanneM]

802.11 is a wireless replacement for ethernet. Bluetooth is a replacement for short-haul cable like serial cables, wireless phones, and such. They are not in direct competition, but complement each other. 802.11 is high speed, but expensive and power-hungry, while bluetooth is short range, low speed, cheap and power efficient (an important requirement for PDA:s, phone handsets and other gadgets with a limited battery life). You wouldn't use Bluetooth as a replacement for cable networks, and you won't want to use 802.11 as a replacement for serial or parallel cable.

I don't want either 802.11 or Bluetooth, I want both -- and use them for the different things they are meant for.

/Janne

Re:Bluetooth and 802.11 are for different uses

[Spruitje]

802.11 is a wireless replacement for ethernet. Bluetooth is a replacement for short-haul cable like serial cables, wireless phones, and such. They are not in direct competition, but complement each other. 802.11 is high speed, but expensive and power-hungry, while bluetooth is short range, low speed, cheap and power efficient (an important requirement for PDA:s, phone handsets and other gadgets with a limited battery life). You wouldn't use Bluetooth as a replacement for cable networks, and you won't want to use 802.11 as a replacement for serial or parallel cable.

Doesn't surprise me at all.
Windows 2000 doesn't support IrDA.
At least, not the old way.
And Apple is working to support Bluetooth with MacOS X.
Second, IBM has made a small Bluetooth transceiver which fits into an USB-plug.

Several vendors backing off

[decaym]

Microsoft isn't alone here. Several vendors are getting squirrely when it comes to Bluetooth support. 3Com had an actual products page for Bluetooth up until about a week ago. Now, the link just circles back to their home page. Intel took their Bluetooth info down somewhere before that.

I've been collecting links for Bluetooth under Linux for the last few weeks. Oddly, some of the information is going away as fast as new information is coming online. The good news, however, is that with Microsoft's latest move we will see Bluetooth for Linux support well before Bluetooth for Windows support at the kernel level. If Microsoft doesn't include support, it will be up to each individual vendor to come up with their own OS API implementation.

For people wanting to get more information on Bluetooth, there is a topsites list of links to information resources. Please, help to keep the Linux links high on the list. :)

This doesn't seem right.

[hey!]

From the article:

Because 802.11 uses the Internet Protocol (IP) for communications, it can rely on IP systems services in the operating system. Bluetooth, however, does not use IP, and thus must rely on application-level support for communications.

Isn't this backwards? That is to say IP over 802.11 uses 802.11 for link level and physical connectivity, and 802.11 looks at the IP packet headers as just another kind of meanignless payload? You should be able to put any kind of protocol built to be layered this way on top of 802.11, shouldn't you? In fact I have an 802.11 LAN cards in my SOHO and it appears that I can bind any protocols I want to them.

If what I learned way back in school about this stuff is correct, the issue is whether 802.11 is a good way to share the wireless medium -- in this case a piece of radio spectrum.

Somebody who understands 802.11 is welcome to correct me, but I've been told that 802.11 is basically Ethernet over radio. It seems to me that if this is true, I'd expect 802.11 to be a poor thing for ubiquitous interdevice networking. You could gin up small demonstrations that'd work great, but they just wouldn't scale. The reason why is Ethernet's Listen Before Talk method of sharing the medium. Managing wire LANs that work this was is a bit easier, because collision domains have limited numbers of devices, have limited extent, and can be easily separated. Without this ability, as the packet rate grows larger devices spend more time waiting to talk (and this is nondeterministic, to boot). As the LAN gets physically larger, the number of unavoidable collisions also increases.

Back in the late 80s when thinwire Ethernet was still common and large 10BaseT hubs were a common backbone solution (and when I was more up to date;-) a lot of people had doubts about the scalability of Ethernet over the next decade. The advent of cheap 100BaseTX and affordability of large switches with massive backplane bandwidth solved this problem for most people by keeping collision domains small and capacious.

However, if you imagine a large convention center full of bluetooth cell phones, computers, pdas, and miscellaneous peripherals, all sharing a common transmission medium, anything that worked remotely like Ethernet is going to fail: too many devices waiting to talk -- no guarantee of fair queueing -- no defined physical LAN extent.

Even leaving aside issues of cost, complexity, and power consumption, 802.11 would be a poor choice. It might work well in a SOHO or small LAN environment where there wasn't much interference from nearby wireless LANs.