I always wondered would MS do something like this. Make a new Zune based off WP7 which can run all the same apps.

I'd consider it *very* unlikely at this point given how much the MP3 player market has been in decline. A Windows Phone is more or less a Zune with a phone in it in so many ways anyways. They would be far better off just bringing any missing Zune features to Windows Phone 8.

I very much doubt anyone has been "furiously ripping out legacy code". The start menu code would have been planned to have been removed from the very begining I'm sure. It was only present in builds upto not to ease the transition of various aspects of the OS with dependancies on it. It is most likely there primarily so there was a robust backup to use when developers were working though issues with the new metro start screen. But now that we're into the RC it's time to cut out anything that doesn't have any use. Microsoft were never going to keep lecacy start menu code and maintain it just for the purpose of power users who want to hack it back into life.

It's most likely the same situation where when VS2010 was developed it worked in GDI mode and WPF mode up until near the very end until the finally removed all the GDI code that didn't have any purpose.

The idea that Microsoft have been "furiously ripping out legacy code" that was never going to be usable my anybody besides being hacked back into the OS is laughable. I gather though there's nothing stopping anyone from writing an alternative classic style start menu from scratch however.

Even if the web is the last place to adopt it I would still like to see an effort sooner than later simply to fill the gap in functionality left by jpeg/png/gif that jpeg xr nicely fills.

From what I understand, there's relatively low interest to photographers in jpeg-xr at the moment. Camera memory has become so cheap in recent years it's now practical to shoot everything in RAW. Photoshop CS6 does not support JPEG XR. Though I do think Jpeg XR would be useful in this area, I don't think it's something camera manufacturers are rushing to adopt.

"Is there any benchmark, audit available?":

Some basic ones here:

"1. Performace. From my initial tests, it looks like the reference JPEG-XR implementation is about 10x slower to decode than libjpeg.
2. Security. I don't know that the reference implementation has been hardened against malicious inputs and from my quick look it appears that it has not." -Jeff Muizelaar, Mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=500500#c18

As opposed to the FCD ballot Jpeg XR reference software recommended in that linked thread I would recommend the final published version found here: http://www.itu.int/rec/T-REC-T.835

I don't beleive I implied that the libjpeg based Jpeg XR codec discussed was being maintained.

I'd have to disagree with you on codecs being shipped with browsers. If there's a jpeg decoder for example that's faster, more memory effiecient and at least as stable and secure as the WIC jpeg decoder, then is there any reason at all why the former should not be used instead? I would also expect this exact scenario is the case as although the WIC codecs are not bad, I don't beleive they stand up well against the best open source image codec libraries. Also, although Windows does have WIC, I'm not so sure if mac osx or linux have similar libraries made easily available to third party applications. Even Windows XP doesn't have WIC, one reason why IE9 is not available of XP. Now even if osx, xp and most linux distros did have WIC counterparts, that would mean if a browser chose to use those different libraries on different platforms they'd all have to be individually tested for bugs, and of course if a bug is found internal to the imaging library it can't be fixed and a case specific work around must be worked out instead. It might be easier then just to use a performant open source library accross all platforms which only needs to be tested once. Now if firefox were to only use WIC on windows and nowhere else you then have fragmentation issues. A page that uses jpeg-xr on Windows will not render correctly on mac osx or linux. Browsers like firefox and chrome try to ensure they render identically across all platforms, web development is hard enough having to test a page in many browsers without having to test those same browsers across multiple os's aswell. This is the very reason I gather that firefox declined to support H264 on windows via the native OS codecs.

"I'm interested, but there's a lot of work that would need to be done.[...] If Microsoft is looking to help, I think releasing a high quality encoder/decoder under the same license as libjpeg would go along ways to improving adoption." -Jeff Muizelaar, Mozilla

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ea39f74581072ca3/43fae1cc25b5f1c3

Microsoft do have an open source reference codec, but it's not performant or secured. Why then should Microsoft not take the lead (supposing they are interested) and release a performant, stable and secure Jpeg-XR codec of their own with a liberal (GPL Compatible) open source licence? If Microsoft is interested in getting the format more broadly adopted, especially in the web, then what better way then to do this? No new code would even need to be written, they could just open source the codec included with WIC.

My thoughts are that if this format became broadly supported in web browsers it could make a significant improvement to the kinds of things possible in web development. Most people seem to agree the format is the right one for the job, and it seems like it could become broadly adopted if Microsoft made just that much easier for people to implement.

I'm not sure how interested Microsoft is in promoting Jpeg-XR however. Seems like all the momentum behind it died the day they made the licencing free permanently and killed any means of making any real money off of it. Perhaps I'm wrong though and there's some people left in there who want to see this format adopted in more places. I'd love to hear someone from microsoft's two cents on this and whether or not this is a practical possibility.

I see the whole Toolbar vs. Ribbon as a classic design problem of "Less is Less". Yes the tool bar takes less clicks to find things, but finding a function in a wild nest of menus and context menus can be frustrating to anyone who hasn't spent a lot of time memorising the where everything is. The only reason the Ribbon was developed was in response to the toolbar system in office becoming overrun with to many items. The original design for the toolbar specified that toolbars shouldn't contain more than 7 items for usability. Although the Ribbon is more taxing on people who've learned to use the toolbar very efficiently, I don't think the toolbar is appropriate today, or going forward, as consumers expect easier and more self explanatory user interfaces.

A little less important to most people.. but I found it a bit annoying that the build in jpeg-xr decoder in windows 7/vista doesn't decode all the images in the jpeg-xr test suite correctly. The ones it doesn't decode right are ones that use obscure colour formats, so it's not something most people would ever notice. But it does annoy me that if anyone else coded a decoder like this they would be liable to be sued for patent infringement by Microsoft as they would not be covered under Microsoft's "community promise" due to not completely implementing the jpeg-xr spec. Seems poor that Microsoft can't implement their own standard correctly on this one. Another issue with the decoder is, with certain images, it creates excessively large file sizes, with poor image quality. Comparatively, significantly worse compression than a jpeg. A bug like that completely defeats the point of most people wanting to compress their images like that.

Right now IE9 supports jpeg-xr, but so far they have not followed through and supported it in IE9 on windows phone. Given they got jpeg-xr support for free by using WIC on desktop for image decoding I wonder if they'll bother with the effort.

Interesting too to see jpeg-XR support in the next flash version. I'd agree it will probably sneak its way into CS6 too. I know adobe were actively working on native Jpeg-xr support in Photoshop for a while after the plugin by Microsoft was released, but shelved it after implementing jpeg2000 support and realising very few people used it yet still having to maintain the code for people who did. They were more cautious about support jpeg-xr allegedly after that.

Another cool project is a summer of code project to develop a jpegXR version of jibjpeg for use with firefox. Would be cool if we saw this grow into something usable in the near future. There seems to be a big lack of open source jpeg-xr decoders out there.

Doesn't mango do OCR natively?

http://www.youtube.com/watch?v=Qq0yVxoVY1w#t=104s

http://www.youtube.com/watch?v=WERWFXQqgZo#t=97s

Number of apps in the marketplace has not only seen steady and strong growth since launch, but has been accelerating. I understand it reached 10,000 apps faster than android did in the same time frame:

Form the video it sounds a lot more like he just didn't feel he had permission to talk about it. That seemed to happen with a lot of people at mix even though those details had already been given by others.

Could be wrong there all the same, but I'd still be shocked if mac didn't have full support for silverlight 5 features. I won't be losing any sleep over it personally.

I would not worry about the mac silverlight beta being late, I understand the silverlight 4 beta for mac was also a few months late but the RTMs came out the same time.

6 days ago, Dr Herbie wrote

Perhaps coffeehouse lurkers should say hello in this thread so we can see who else is around?

Hello ;]

I remember having the exact same problem at work where all the computers were xp 64-bit. I found after a bit of research there was a work around. I think it was you have to find an msi version of the installer, from that you can extract individual installers for different components of messenger, non of which check for 32-bit xp. I'm not sure if this trick still works with the latest version though, but I had no problems once i got it running.

It's my understanding (though I may be wrong), that IE9 does repect system wide settings to disable ClearType for font rendering. It doesn't however respect any settings to disable font smoothing. This is at least what I gathered from the IE blog and havn't seen anything to convince me they are wrong about that so far.

I don't see anything wrong with the IE9 rendering in the pic. IE9 uses sub pixel positioning for letters. This causes some letters to blur. Say if a letter "I" starts 0.5 pixels, it's going to blur over 2 pixels. The advantage is that letters and words are rendered with more accurate spacing and
can be animated much better. The debate between whether this kind of rendering is better or not has been doing on since Microsoft first demod DirectWrite. But this is how mac OSX renders fonts, it's how photoshop renders fonts and I understand it's how most modern linux distros render them.  Personally, I think this type of font rendering is the way to go even if it takes some getting used to.

The picture also highlights a problem with regular GDI rendering. If you look at the digit 9 in "179,000" you can see the top is very aliased. That's due to GDI only performing anti-alias on the y-axis. DirectWrite naturally anti-aliased both axes.

The big problem is most peoples bottom line is it's lacking a lot of features android and iPhone have had for awhile, so it hard to recommend to people. Though there's a lot of people who just want something that feels nice and isn't complicated, but those aren't generally the people with $500 phones. I think Microsoft are just going to have to grin and bear a rough start. Xbox made a loss, but they got it right with Xbox 360 commercially. Hopefully windows phone 7 won't need so much time to find a healthy place in the market.

WLM2011 isn't a WPF application.

I would beg to differ. it doesn't show up on snoop, but I would be absolutely stunned to find the vast majority of the UI was not driven by wpf. If you have any source regarding it not being wpf driven I'd genuinely love to see it.

horrendously anti-aliased

This problem was fixed with wpf 4. Though the font rendering mostly looked bad because it jarred with font rendering in the rest of windows. Text rendered with GDI is not sub pixel positioned, in contrast to mac osx and linux. Whether this is a good or bad thing is a matter of taste. Many people prefer not to use anti-aliasing of any sort. IE9 will be using sub-pixel positioning and I'm willing to bet all text rendering will all be sub-pixel positioned going forward.

The biggest problem with wpf afaics, is that it's easy to create interfaces that are unperformant. There's nothing intuitive to the programmer as regards to what they need to do to make sure the application always run fast on the targeted hardware. It takes a programmer who knows alot of the ins and outs of the framework to write a good app using it. knowing when to use bitmapCache is one major example.