Windows Mobile Team Blog

I have used the ICS on the BlackJack (US Version) and it works quite well, I usually use the USB Cable option to take advantage of the trickle charge.  It is somewhat hard to find, but still manageable to get to on the devices.

I would have thought that the DUN profile would be a request of the carriers, since it would seem that the ICS may be bypassing many of the imposed "tethering" restrictions on devices, especially those that connect to high speed or 3G networks.

Some of the devices, like the BlacJack, also have the ability to be detected as a modem through the USB connection.  This is a wired connection, however it can be helpful if someone just really really wants or needs to connect via a modem.

The only instance in which I would enjoy a Bluetooth DUN connection would be if I were using a Windows Mobile 6 phone, for voice, and I wanted to connect to another Windows Mobile 5 for a data connection.  So I wouldn't have to have two data connection plans, only one.  Don't ask why I carry two Windows Mobile devices...

I have seen some instances, like the one above, would it be beneficial to have the Bluetooth PAN connection go both ways, rather than just a one way data connection.

So, your explanation as to the question "Why did you remove bt dun?" is that just because ICS is "cooler" ?

Regardless of what the users think or want?

OK, ICS works, but you should have left the bt stack unchanged and let us decide which one to use. BT PAN is a pain and slower on my setup than just using BT DUN.

Thank you anyway for your article.

The real head slapper with Bluetooth isn't DUN, it's why you guys removed bluetooth headset support from the final of Vista.

This is inane and needs to be fixed ASAP. Especially with your Office Live Communications Server stuff out, this is a no-brainer!

Once again I find that something was snatched away from under my nose, you just don't get do you, when you take a feature away without phasing it out it causes great disharmony - in MS case from you, to manufactors, to carriers, to users - gee did MS think of that - NO.

Your bluetooth stack is already second rate to that of Widcomm, now you hampered it more, I cannot buy any of the stereo bluetooth headsets that I want because the MS stack does not play nice, I'm talking clicks and poor use of features that should work, e.g. being able to resume after a call, most of features are not working with a MS bluetooth stack but with a Widcomm stack, why oh why is this?

You (MS) should firstly make your stack a working stack, then add features not delete them and then make note of all the forums around the net with disgruntled users that have bought a headset that does not work because of your stack.

Have you guys really read the full article before complaining?

Microsoft did not remove the feature, just made it non default for the OEMs. Complain to the OEMs and they will bring the feature back.

Microsoft seems to not have any dialog with the actual end users but with the OEMs.

I find it very strange that Microsoft keeps implementing new features in AKUs making devices with the same Windows Mobile version different. Some devices are still on AKU 2 and will probably never ever see AKU 3.

Personally I'm all for new useful features, but maybe Microsoft should wait until the next major release insead of sneaking in the features in AKU updates that may or may not be in the devices on the market.

It's also sad that Microsoft does not provide a feature addition list for new AKUS for end users.

On an OEM note, since the feature is optional for OEMs, usually the OEM defers to whoever they are making the product for (e.g. carriers).  

As far as releasing it in an AKU version, that can prove problematic for people who want those features, but don't have the capabilities to upgrade to a new AKU, which would require a re-flash on a unit.  Would it possible to have this feature be an optional Windows Mobile Update feature?  Seeing as how there are some people who would use, and those who wouldn't, perhaps the users could decide for their selves and download it via the Windows Mobile Update function in WM6?

If my understanding is correct the features downloaded using this functionality will remain in the ROM, and not be deleted after a hard reset.  Of course if adding BT DUN support causes drastic changes in the OS perhaps it would be better, or more stable to release an entirely new AKU for that feature.

I like JasperM's idea.  I would really like to see the AKUs become more like a Windows Update.  If the carrier sees that it is rock solid and no problems, then they can release it as a ROM upgrade and have it be always installed but my phone that is 8 months old has AKU2.3 and no plans to go any further since Wm6 is out.  If I had the option to download AKU3 over the top of my current install I would be willing to try it. If it didn't work, then I would hard reset it back to how the carrier decided it would work on their network and away we go.

I like internet sharing in PocketPCs. I have seen it and used it and found it to be very reliable, and mostly simple for the simple user.

I am still trying to find it in my Blackjack Smartphone. While I can see the USB Modem mode in USB, I can find no parallel for Bluetooth. This is not so relevant here, but maybe someone in the comments will help me find it.

Anyway, I think that the big problem is that the OEMs and the Mobile Operators have more control on the OS that will be released than Microsoft does. JasperM suggests an utopic suggestion, that would actually be the best solution for it, but at least for what I see around, I don't see MS being able to implement it in the next 5 years without breaking ties with all OEMs and Operators. And unfortunately, operators put in their released devices mainly what is good for them, and less of what is good for the user.

Following the line above, the only way to deal with that is to diminish the range of freedom the operator has on some features, having less optional modules. This should be strongly felt in modules that Microsoft has been bashed on though they say it was optional and operator is responsible.

Let's agree that the Microsoft Bluetooth stack isn't the king of functionality yet. I like its stability (specially compared to Widcomm's memory leaks), but it is still missing many things. In this case, it should be unthinkable to remove a feature which is basic like DUN, or even let the operator remove it. That because the operator will put the one that leaves him less support calls. It doesn't matter that many users want to use DUN.

The result is that you don't find DUN in almost any device since AKU3.

Greg says "Bluetooth DUN is a legacy technology that is likely to disappear over time", and with that he agrees that it hasn't disappeared yet and many peripherals still need it. So, my recommendation in this case, is that "MS should wait until a technology is dead to remove it from its products, instead of trying to artificially kill it by removing it when they decide it is "likely to disappear over time".

To finish this: last time I have used DUN was one and a half years ago. When I compared Internet Sharing in the Trinity to what I used to do, I was thrilled. It is really a great improvement, and I will probably never use DUN again. But it should come as an addition, not as a substitution, since there are still many people that not only use it, but need it.

Yes, don't remove features until its use is actually dead. I know that MS thinks MS centric. Which might explain this miopic view.

Other OS's (like MacOSX) don't support BT PAN and Mac users relied on BT DUN for cellphone connectivity. You broke my mobile connectivity solution when you removed BT DUN and made it an optional component for ODM/OEMs.

First, thanks for the article - it explained a lot. This question has been bugging me (along with a lot of other WinMob users) right from the introduction of AKU3 and this is why I've written a full overview & comparison of the new model on the Pocket PC Magazine Expert Blog at http://www.pocketpcmag.com/blogs/index.php?blog=3&p=1415&more=1&c=1&tb=1&pb=1  (also frontpaged by Pocket PC Thoughts).

It's also nice to know cell phone rebranders / manufacturers could include DUN if they wanted to.  You should consider *forcing* them to include it as the lack of DUN is, in my opinion, decidedly a problem.

However, there are some things in the article I disagree with.

1. You state "Bluetooth DUN is a legacy technology that is likely to disappear over time.  Especially when you look at the great experience Internet Sharing provides with Bluetooth PAN.  It also does not make sense for cellular radios to continue supporting a legacy interface just to enable Bluetooth DUN.  In the past we received a lot of criticism about Modem Link, especially related to usability.  For this reason we decided not to include it by default."

I'd add that you don't need Modem Link (see for example my related DUN tutorials - for example the one at http://www.pocketpcmag.com/blogs/index.php?blog=3&p=510&more=1&c=1&tb=1&pb=1 ) for internet dial-up. This (the lack of need to do anything on the PPC for the dial-up) is a BIG advantage of the old, DUN-based approach. I use a GPRS+ connection from my notebook a LOT and found having to start internet sharing manually very tiring on the long run (this is why, finally, I've switched back to using an old, DUN-based Sony-Ericsson t68i for dial-up.)

2. PAN client is NOT supported on many platforms; therefore, I wouldn't call BT DUN a legacy technology. Microsoft BT stack on Windows Mobile (while the Broadcom BT stack, naturally, works great with the BT PAN-based connection sharing); several older (non-MS / Broadcom) BT stacks even on the desktop; the Nokia 770/800, Palm OS, older versions of Mac (fortunately, as has been also pointed out in my AKU3 article, never versions of Mac OS X already support PAN). Also, Linux can be harder to configure to use PAN than DUN (for example, on my Sharp Zaurus C760, I've never managed to make BT PAN connections work, unlike BT DUN ones).

That is, it'd be REALLY great if Microsoft DID *force* phone manufacturers to make DUN available again, if it is already available. Not an optional package but an obligatory one.

Removing DUN also stops for your phone from connecting to GPS devices such as the tomtom1 which use DUN as the connection method.  Now I have no traffic alerts etc when I am driving.

While your listening to feedback, please will you pass onto your relevant colleagues that since active sync 4 you have removed without explanation the syncing of categories in contacts.

Now in my mobile phone I have all of my business partners contacts and he has all of mine.  Quite pointless.  It's an important feature that should come back.

Sorry for hi-jacking this thread!

Kenny Oldenskov, while I agree that A2DP could be better and more standards-compliant (many (but not all!) current A2DP stereo BT headphones don't really support the MS BT stack, which does result in quality problems as is explained in, for example, http://www.pocketpcmag.com/blogs/index.php?blog=3&p=1744&more=1&c=1&tb=1&pb=1 ), I've never encountered music resuming problems. Which headphones model are you having problems with?

Alos, you may want to consider making DUN support a downloadable update for Windows Mobile. If some carriers don't want their users to use DUN at all, then, there can even be some lock-out mechanism in the update so that it wouldn't run on the devices released by these carriers.

Such a move would REALLY improve the usefulness of the platforms. (Again, I have to point out that the DUN-based approach, on the long run, is WAY more convenient if you often connect/disconnect your client. With DUN, you don't need to manually start IS all these cases. This is why I've reverted back to using a very old S-E phone for dial-up purposes.)

I blogged about your decision to remove DUN <a href="http://eugenia.blogsome.com/2007/04/17/dun-vs-pan/">here</a>.

While I prefer PAN instead of DUN, the point remains, Mac OS X, Linux and older Windows OSes with older BT software *WILL NOT* be able to use PAN (at least not easily).

Yes, you should have added PAN, as you did, but you should have *ALSO KEPT* DUN. Let the new users all use PAN, but let the users who are RELYING on DUN because of the operating system and BT drivers they are running to also have the ability to do so.

The above correct link is:

http://eugenia.blogsome.com/2007/04/17/dun-vs-pan

Legacy or not, Win98, old Bluetooth dongle software, OSX and Linux requires DUN. You should never had removed it. You should just left it in there and let new people use PAN and old users to use DUN. Right now, you created one big mess by removing a major feature that exists on ALL cellphones.

As I see it, this is another case of MS deciding for us how to use technology, rather than the letting us decide for ourselves.  The WHOLE point of bluetooth is to connect to other "things". It exists for no other reason, yet, the Windows Mobile team decided that one of the primary methods currently supported by large numbers of devices for this purpose no longer was a necessary, and would only be installed as an extra. Much like how we don't need a close button I guess, despite years of proof otherwise, or how we can no longer sync over WiFi, or how we can no longer chose to sync only specific categories, the list goes on and on.

It doesn't matter if it's legacy technology and cellular radios don't need modem commands.  What matters is that the devices that these cellular radios need to communicate with often require these commands!   Did all of our existing DUN devices vanish from the face of the earth when AKU3 when was released, of course not.

I would hope the development team understands how users of the software actually use the devices when making these decisions, but then we see these types of decisions made over and over again. As a long time PPC/WM user, I can tell you right now I am fed up with you constantly removing features without thinking of me, and my needs. I currently own 8--yes 8 WM devices, but I suspect I may have purchased my last. I am finding myself less and less attracted to this platform as the WM team contineus to try and dumb it down to the lowest common denominator.

I'm afraid I'm going to have to side with everyone who is ranting about Microsoft's tendency to remove more features than it adds with every new Windows Mobile release. I was very disappointed to find out that my new smartphone doesn't have Bluetooth DUN, since I need that to connect with my PC and my Axim Pocket PC.

Why does Microsoft insist on removing features with every new release? Every new version of Activesync has more features removed than added, I can't sync Money 2007 with my Pocket PC, I can't do sync over wifi, and now I can't do dialup with my phone. Looks like WM6/AS 4.5 will bring yet another litany of "Nope you can't do that anymore."

I also find your comment very disingenuous:

You're correct that Mobile Operators and OEMs have more control over the OS that will be released than Microsoft does.  It's a fact of life that Mobile Operators call the shots in the Mobile phone space.  Phones require their networks to run and are sold in their stores.  It's natural that they'll decide which devices to allow on their networks and which devices to sell in their stores.  For all people complain about MOs, I'm pretty sure that anyone who had spent the billions required to set up a network would want to have some control over what happens on it.

The problem is that while mobile operators do unfortunately control a large part of the average user's mobile phone experience, it is not the case in every market - phones sold in Europe, Australia, Middle East etc are mostly sold non-restricted and with most features left enabled. You could have handled it differently and you know it - instead of making DUN an optional extra, you could have made Bluetooth PAN an optional extra. It doesn't make sense how you can make an established technology optional. At the very least, you could let users download a patch to enable Bluetooth DUN functionality. Just because a technology is probably going to die, you don't try and kill it off by not letting the users decide for themselves.

AT&T can't control what I plug into my landline RJ-11 jack, why should they have such strict control what I plug my SIM card into? You won't find any sympathy for the carriers here, sorry.

MikeCal, great to hear you'll make DUN mandatory again.  (Will this update be releeased for all current WM5 AKU3 / WM6 devices?) DUN IS currently a must and OEM's MUST understand this. Without DUN, you can't have for example other Windows Mobile devices use other AKU3+ WinMob devices as dial-up modems (and the list, of course, continues: the Nokia 770/800, older, non-MS/non-Broadcom BT sticks and CF/SD cards for the desktop, some flawors of Linux etc.)

Also, please PLEASE do redesign BT PAN / Internet Sharing in order NOT to have to manually start it each time (!) we want to use the mobile as a modem. This issue, currently, greatly hampers its usability.

Finally, any plans to implement full BT PAN support (not only for IS) in the MS BT stack as is the case with the Broadcom BT stack? (I've also elaborated on this stuff pretty thoroughly in my article so I won't list in here what I'm referring to.)

In your statement I noted a lot of references to the "Carriers" which want this and do not want that.

Please keep in mind that the US is the market where Carriers can dictate to users what to buy etc. In more mature markets, like Europe, phones are mostly bought in stores and are Sim free.

personally I never bought a subsized, crippled phone and I have no intention to do it in the future.

The updates about the OS should be handled by Windows Update and not by carriers or hardware manifacturers because these subjects have no incentive to extend the life of a device they have sold, actually the opposite.

Dell does not rule the updates I can install on my computer and the same policy should be applied to PD and Smartphones.  

MikeCal, great to see it will be in by default.

The result of the previous situation was that the phone was closed for work with any non-MS computer.

This will fix the situation. Good to hear.

Recently bought a new Ipaq to pair with my Blackjack and had to return it since it doesn't support PAN. Kind of ironic that one MS powered device can't talk to another. Bought a Nokia N800 which runs Linux. Doesn't support PAN out of the box however it can be hacked to. The decision to remove DUN was a bad one.

MikeCal: You asked "We've already said that we're putting it back to "in by default."  Is there something else we can do?"

Yes, you can release a patch that will enable DUN support on AKU3 devices.

And while I'm requesting things that will never happen, you can re-enable category syncing in ActiveSync/Mobile Device Center.  I'm very curious to hear an explanation of the benefit of removing this feature?  Was that also too complicated for users to understand? Sorry to be sarcastic, but the too complicated argument doesn't hold water, if it's too complicated users will ignore it anyway.

whydidnt:  What was the reason given for removing category syncing?  I need it back urgently.  Complicated? Never!!  You checked a box and it synced that category.  Simple.

For the most part I do like the way that Internet Sharing works; it is very easy.  But I don't like that I have to go through so many steps on the phone to turn it on.

I wish there was a way to have the phone turn on USB Internet Sharing by default, so every time I plug in a USB cable to a computer it provides an internet connection.  I sync only via Exchange and the only time I ever connect my phone to my computer via USB it is so I can connect to the Internet.

For Bluetooth, the phone should be able to tell devices that it supports PAN, and automatically connect to the Internet whenever a PAN connection is requested, instead of having to set it up on the phone each time.

For legacy applications I would love to see DUN brought back too.  As mentioned above, Macs and Linux don't support PAN so devices with IS only enabled they have no way to connect.

The other concern I have (though it isn't a big one) is that connections using Internet Sharing use private IP addresses rather than the IP provided by the carrier.  In the case of my T-Mobile Dash, I pay for the VPN plan and actually get a real public IP address, but because the IP seen by my computer is private some applications just don't work.  Fortunately the biggest one that would cause problems actually does work (PPTP VPN), so this isn't a huge issue for me.  Just kind of annoying that I am paying for a real IP address but I can't use it.

"Dell does not rule the updates I can install on my computer and the same policy should be applied to PD and Smartphones."

Truer words were never said. Dell doesn't tell me that the brand spanking new PC I bought with XP won't be updated to run Vista, why should the carriers get to decide what OS updates their phones are eligible for? I myself would love to have WM6 on my Q, but it looks like Motorola, Sprint and Verizon are backing out in order to sell more new phones.

Deplorable.

My men's rights blog: http://petepatriarch.blogspot.com/

djdj, yes, you get a private address (as on any LAN's), which may indeed be problematic. However, you can configure many (PC) clients (for example, most p2p apps) to report any other IP address as the "real" IP address of the machine it's running on. If you do provide your (that is, your WinMob phone's) public address (by overriding your private one), even incoming requests will work on your public address (IS does a full port forwarding - as has also been explained in my all-in-one AKU3 Dial-Up Bible ( http://www.pocketpcmag.com/blogs/index.php?blog=3&p=1415&more=1&c=1&tb=1&pb=1 )).

You may want to check this out - your particular apps may also let for supplying another IP address.

"Pete, imagine if you had a Dell laptop with a special piece of display hardware that only Dell knew how to write the driver for.  And, imagine if the XP driver for that hardware didn't work on Vista.  Finally, imagine if Dell didn't write a Vista version of their display driver for that laptop.  At that point, Dell most certainly DID rule which updates you can put on your computer.  Or, at least, you'd be welcome to upgrade to Vista, you just wouldn't see anything on the screen."

This is where I bow to your superior knowledge. I don't have any idea about the hardware in question, but the way I was thinking is this:

- Windows Mobile would ship in a CD just like a regular OS, with Professional and Standard versions separate.

- As WM installs on your device, it checks to see what drivers it needs and installs only those on the device since all the drivers are bundled in the Windows Mobile installation CD.

- As it turns out which manufacturers don't write drivers for their devices, we stop buying from those manufacturers. Just like if I buy a phone at the shop I know whether I'm buying a Samsung or a Sanyo, so too I'll know whether I'm buying a Motorola or an HTC and which company is good about releasing drivers.

Take care,

Pete

I tried to connect an Ipaq 5915 Windows Mobile device with my Samsung Blackjack (the Ipaq would like to use the connectivity to provide traffic updates for it's internal GPS ) and no go. That leaves me with the rather non elegant solution of having to use a non-windows bluetooth phone to connect to the Ipaq.

"windowsmobile" (see "According to various web sites, Mac OS 10.4.9 supports Bluetooth PAN."): - yes, it does - it has been confirmed by me too (see http://www.pocketpcmag.com/blogs/index.php?blog=3&title=latest_version_of_mac_os_x_and_wm5_aku3_&more=1&c=1&tb=1&pb=1 if interested).

"windowsmobile" (see "I believe there may also be some 3rd-party DUN solutions for certain devices."): unfortunately, it seems it's only the Blackjack  that is AKU3+ and still supports DUN - but only over USB, not Bluetooth (see http://www.howardforums.com/showthread.php?t=1041555&page=2&pp=15 for more info  on this q). Also, there are no third-party DUN servers for Windows Mobile (I've been searching for such a solutions too - see for example http://www.pocketpcmag.com/blogs/index.php?blog=3&p=1673&more=1&c=1&tb=1&pb=1 )

"R" (see "I tried to connect an Ipaq 5915 Windows Mobile device with my Samsung Blackjack (the Ipaq would like to use the connectivity to provide traffic updates for it's internal GPS ) and no go. That leaves me with the rather non elegant solution of having to use a non-windows bluetooth phone to connect to the Ipaq.") you mean the hw6915? Strange it doesn't work - the hw6915 has the Widcomm BT stack with full BT PAN client functionality - strange it didn't work (the same configuration - with other Widcomm-based Windows Mobile clients - worked great with me). How did you try to set up the PAN?

Up until now, I was considering buying the upcoming PPC 6800 from Sprint. It is supposedly coming with WM5 AKU 3.3.

It sounds like I should wait and see if they ever update the phones to WM6.

So whatever the reasoning is for the DUN decisions, it's costing the carrier the sale. I can wait to update my phone. I kept my last one for 4 years and it worked fine.

I agree with everyone who says that there should be some way for Microsoft to deal directly with the public when it comes to smartphones. Microsoft can hardly be a company that should be a beggar at the table in this industry. It's acting like a desparate upstart trying to get a foot in the door.

The great thing that MS did in the 80s, was to decouple the OS from the equipment. That needs to happen again with smartphones.

If Microsoft can't provide consumer needs to the consumer, maybe it's a sign that it's time for government intervention to deal with the cell carriers and take away their equipment monopoly, as happened with land carriers in the 80s.

Hi Greg,

It has been enlightening for me to read your posting on BT DUN and ICS.

The reason I'm posting here is bcos I am having intermittent connecton problems to the Internet using ICS on my brand new SGH-i600. My Internet connection works for a few minutes, then I encounter connection problems for a few minutes and then connection is restored and this cycle seems to continue perpetually.

When I hit this problem, I immediately used back my Nokia 6630 for DUN connection and the Internet connection was stable. So, I don't think it's my service providers RF problem but may have something to do with ICS.

I did not have such problems previously when I was using my Nokia 6630 (Symbian 8.0) to connect to the Internet via BT modem or USB modem thru DUN.

I access the Internet thru my PC using my mobile phone as a modem as I am subscribed to my service provider's unlimited data plan (EDGE network).

I've been scouring the Net in vain to find out if anyone has the same problem as me using SGH-i600 and how the problem can be resolved.

Hope you could help me out here. Thanks.

KS Lim, did you give a try to for example pinging any Web site in the background? It MIGHT fix the issue.

Also see http://www.pocketpcmag.com/blogs/index.php?blog=3&title=how_to_combat_automatic_disconnecting_fr&more=1&c=1&tb=1&pb=1 . Note that "ping" is built into desktop operating systems; that is, you won't need to install third-party apps (like vxUtil on Windows Mobile) in order to make permanent pinging work.

Also, if it's an IP issue (for example, the SGH is constantly trying to give you a new private IP though DHCP), could you check out your local IP every time you enounter connection problems? Do you see "Acquiring network address" showing DHCP is in the process of giving you a new IP?

MikeCal,

Would it be possible to distribute the DUN via the Windows Mobile update feature in WM6?  Or is this not what the Windows Update feature was designed for?

This would solve the problem of someone getting a WM6 devices with an AKU previous to whatever AKU implemented the DUN Profile is implemented in.  It would also give the user the ability to choose if they wanted DUN or not.

-JasperM

MikeCal:

Doesn't the Windows Update feature write the updates to ROM?  That would be the only slight advantage that I could see, in case of the needs for a hard reset.

But I believe the end is the same, the user gets the functionality they desire.  Its great to see that there are avenues for the average user to be able to comment on something as low level as adding features into Windows Mobile.  The fact that you listen to comments, both good and bad, bode well for the Windows Mobile group, and the responsiveness to the community that you do have.

-JasperM

How would the removal of BT DUN affect mobile dial-up access to landline numbers via GSM CSD or HSCSD via Smartphone?

This service is used not only for mobile access to ISPs (possibly independent of the mobile network provider) where GPRS or 3G is not available but also for data telemetry to landline connections and for wireless alarm systems independent of connection via the IP network of the mobile 'phone ISP. (The mobile 'phone network provides the interface to the PSTN.)

As others have implied above, to leave the decision whether to include BT DUN in the hands of mobile 'phone providers appears to be promoting monopolistic behaviour. Especially where as seems to be the case in the USA but not so much internationally, 'phones are often provided by and locked to the mobile network providers.

Filed under: Windows Mobile , Misc Something that has probably caused quite a few Windows Mobile 5 customers

and another question, how can I remove internet sharing(IS) if I found it conflict with my application?

Thank you for the article.  I echo everyone's continued criticism -- the need to initiate the PAN connection from the client and server (phone) is ridiculous.  Please IMMEDIATELY provide a patch either to restore DUN by default or enable client side (only) ICS (can this really be that hard for the almighty MS to do??)  ICS is good, but it doesn't make up for this oversight.

The only new thing I can add is a response to:

"2) Uninterrupted connectivity: ICS can continue to be connected when you get an incoming voice call.  Modem Link will give up the cellular radio for the phone to answer the voice call.  Internet Sharing will stay connected in this scenario.  On some cellular networks it is not able to send or receive data.  The cellular network needs to support simultaneous voice/data to provide the best user experience.  This is supported on 3G networks."

I haven't used 'Modem Link', but BT DUN *does* support simultaneous voice and data on 3G networks.  I had been using this with my Cingular LG CU500 for several months, works like a champ.  Then I bought a Blackjack and now I must perform 3 steps to connect.  BIG bummer.

Thanks, Ryan

Microsoft's flagship OS, Vista, completely failed on BT PAN support with Windows Mobile. On my BlackJack, I used to be able to use BT PAN in XP to connect to internet. Now, I upgraded the same PC to Vista, the PC just can't find BlackJack as BT PAN device anymore.

This is so lame!! I'm now no longer able to use any online services from my TomTom GO 910i device....

Let's go further. Suppose I can use TomTom device with a WM6 phone because:

- TomTom delivers an update that support BT PAN

- I run TomTom on a PDA that already supports BT PAN

Now, I will have to fumble with the phone WHILE DRIVING every time the connexion is dropped because my car went through a poor signal area and the brand new super cool ICS (damn it) simply can't let the client initiate the connexion by itself.

Well, just my 2pc: please tell your developpers that MOBILE devices are to be used by really mobile users and not by people that are comfortably seated in their office all day long. Thanks!

"Eugenia and whydidnt, we changed a feature from "in by default" to "optional."  We've already said that we're putting it back to "in by default."  Is there something else we can do?"

You said you are putting it back in WM6 AKU. Well, guess what, only a handful of people even have WM6 stuff. All of us who are pissed have WM5 devices that we (foolishly) updated to AKU3. Make AKU3.1 with DUN back by default in addition to PAN, and shove it down the carriers throats. The only reason DUN went away is you turned it off by default. The carriers don't even look at the options.

"First, it's not true that mobile operators don't pay attention to this stuff."

The OEMs shove this trash out the door as fast as possible. It boots? Ship It!

I've seen production devices that in some USB modes throw back strings like "PROTOTYPE -- REMEMBER TO CHANGE THIS" and Microsoft's VID during enumeration.

I've seen a device that didn't have a icon for CAB files.

I've seen devices that pop up messages like "Not yet implemented" when certain buttons are pushed.

I've seen devices with piles of linker output files (maps files, sometimes even debug symbols) in \Windows.

All these are examples of slop that takes about 2 seconds to notice. The fact that EVERY device I've used has some little thing wrong is a pretty clear indication that they just don't care.

Given that, you do have power. You set the defaults and they take those. If you can't understand that, then you are retarded.

Hi MikeCal,

 One feature I used to use all the time with Bluetooth DUN is that I was able to connect to it from my laptop or another smartphone without having to enable it. So I could just keep my phone on my pocket and connect it to it. With ICS I have to go in an start it and then I am able to connect to it. If the connection was broken by any reason I would have to do it again. I am assuming this cannot be added to ICS.

So if it is just a matter of turning it back on, why not share it with us (leak it to the web)?

I used BT DUN w/ my car kit - would love to see it back - I have actually switched to my Nok phone while in the car...

Clarification?  2) Uninterrupted connectivity: ICS can continue to be connected when you get an incoming voice call.  Modem Link will give up the cellular radio for the phone to answer the voice call.

Is this correct?  I had thought DUN was used as the protocol used just between the PC and the phone; it's up to the phone to decide how to connect to the Internet/provider.  I would like to understand.  Thanks.

This must be costing sales of Windows Mobile devices. I've just got a Samsung i600 - a lovely phone but it's going to have to go back as it won't work with my Nokia N800 or Tomtom.

So, the Samsung gets returned and I'll be looking at getting a Nokia Symbian device.

You just can't abandon a technology which is in so widespread use! - something that I think Nokia realise and Microsoft don't...

ICS Sharing is great on my PPC6700 (homemade AKU 3.5 upgrade on the internet that does work)  - it must be performing NAT - Why not allow us to leverage the ability of the built in 802.11b stack by allowing the creation of an ad-hoc network and installation of a DHCP server on the device?

Can this be done manually in any ip configuration way?

Currently all wifi-sharing implementations out there involve using a java socks proxy.

Wallah, instant wifi hotspot.

I dread to think how many sales have been lost because of this one issue - I know at least 9 people who have decided against a WM Smartphone because they *needed* a phone that supported the BT DUN profile. So they bought Nokia/SonyEricsson instead.

Making BT DUN a non-default option was just asking the OEMs or carriers to drop this feature - hiding behind this argument is disengenuous at best. As already stated, Microsoft should not drop a feature until the feature is at Death's door - in this case you effectively dropped the feature by making it non-default, yet BT DUN is by far the most common form of inter-device connectivity.

OEMs and carriers will take their lead from Microsoft in most cases, and if they see you have made an option non-default and are telling them "the future is ICS" then the OEMs and carriers are not going to enable the feature and spend more time testing what they are being told is a legacy feature.

Let this be a lesson to you - don't make a feature a non-default option until it's truly dead.

I have tomtom go device which only supports DUN.

Paying tomtom 40€ a year for traffic service and my phone carrier 10€ a month for data connection.

Thanks to Microsoft that i can not use this service anymore with my new WM5 device, but still paying it...

When will be an uptate availible to add BT DUN again?

So come on, tell us when you can get this back.

Even better, we users out here are really hurting and losing money everyday because of this. What we really need are instructions to add this back, or even better, a cab file that automatically adds this back to our phones that can be run from Extended_ROM so that even if we have to hard rest, or upgrade our OS again it will be applied.  Why can't Microsoft offer this kind of patch support to its paying users. Any other software company would support their software in this way.

LJ

I am not seeing many answers to how TomTom users will be able to function going forward.

TomTom has a product placement in the millions globally are RELY on Bluetooth DUN connections for it's services.

I have a TomTom910, a product that is less than 6 months old in the market place and yet my new phone doesn't support Bluetooth DUN... that is just bizarre!!

There is no support from TomTom on this one, and no answer from MS? Who owns this issue, and how are the millions of TomTom service customers going to justify the purchase of a new ph