Forget everything you know about Windows Mobile. Seriously, throw the whole OS concept in a garbage bin or incinerator or something. Microsoft has done what would have been unthinkable for the company just a few years ago: started from scratch. At least, that’s how things look (and feel) with Windows Phone 7 Series. This really is a completely new OS — and not just Microsoft’s new OS, it’s a new smartphone OS, like webOS new, like iPhone OS new. You haven’t used an interface like this before (well, okay, if you’ve used a Zune HD then you’ve kind of used an interface like this). Still, 7 Series goes wider and deeper than the Zune by a longshot, and it’s got some pretty intense ideas about how you’re supposed to be interacting with a mobile device. We had a chance to go hands-on with the dev phone before today’s announcement, and hear from some of the people behind the devices, and here’s our takeaway. (And don’t worry, we’ve got loads of pictures and video coming, so keep checking this post for the freshest updates).

First the look and feel. The phones are really secondary here, and we want to focus on the interface. The design and layout of 7 Series’ UI (internally called Metro) is really quite original, utilizing what one of the designers (formerly of Nike) calls an “authentically digital” and “chromeless” experience. What does that mean? Well we can tell you what it doesn’t mean — no shaded icons, no faux 3D or drop shadows, no busy backgrounds (no backgrounds at all), and very little visual flair besides clean typography and transition animations. The whole look is strangely reminiscent of a terminal display (maybe Microsoft is recalling its DOS roots here) — almost Tron-like in its primary color simplicity. To us, it’s rather exciting. This OS looks nothing like anything else on the market, and we think that’s to its advantage. Admittedly, we could stand for a little more information available within single views, and we have yet to see how the phone will handle things like notifications, but the design of the interface is definitely in a class of its own. Here’s a few takeaways on what it’s like to use…

Start screen: the Start experience is completely revamped, now focusing on sets of tiles which represent links to applications or contacts. It’s a completely contextual experience which can be customized both by users and carriers, and allows people to “promote” items higher up in the list. To the right of this screen is a long, vertical list of all your apps for quick jumps. It will take some time getting used to this layout; one or two tiles per line, and that long list which goes up and down rather than left and right, but honestly — this does have some advantages. Things seems less out of reach in this configuration, and Microsoft swears that they’ll be working closely with developers to build widgets that make use of the concept.

General phone navigation: If you’ve used the Zune HD, you know what this is like. Lots of bold text on the device, lists with text cut off on the sides of the phone, and additional screens to the left and right driven by arrows pointing you in either direction. For the most part this works, though in instances like email, it feels like there’s a bit of wasted space. Everything else is super stripped down — the calendar app looks like vector line art, the browser seems to be using the bare minimum to show its content (which isn’t necessarily a bad thing), and the phone application is essentially monochromatic. On the other hand, you’ve got a beautiful and robust photo app (with pinch to zoom, as in the browser), and the Zune experience is perfectly integrated… but what did you expect?

Today there was my session on ASP.NET MVC at DAIICT, Gandhinagar. And an amazing seminar it was for me..

It started with Vivek giving a brief introduction about me to the crowd.

Then we had a session on ASP.NET MVC where I bored the poor kids to death for 1 hour and 20 mins <Evil Grin>

Then cane a session on Windows Mobile by Kaushal.

To wrap it up, we had an HOL on windows mobile where we showed some nifty tricks that can be done on windows mobile.

The resources of my presentation can be found here: ( Presentation , Code Sample )

To run this sample you will need:

• VIsual Studio 200 Or Visual Web Developer 2008 Express Edition (Download Express Edition)
• Visual Studio 2008 SP1 (Download)
• ASP.NET MVC Framework (Download)

Keep watching this space for a detailed walk-through of the contact manager I made in the presentation.

You can see the gallery of the photos of this event here: ( Uploading Soon…)

Learning Resources:

•C#
–MSDN
–C# 3.0, A Beginner’s Guide   | Herbert Schildt   | TMH

•ASP.NET Fundamentals
–MSDN
–ASP.NET, A Beginner’s Guide   | William Sanders   | TMH

•MVC
–Http:// asp.net/mvc
–Http://weblogs.asp.net/ScottGu
–Professional ASP.NET MVC 1.0   | Scott Guthrie et.al.   | Wrox
–Pro ASP.NET MVC Framework   | Steven Sanderson   | Apress

User: Recently I found out about a peculiar behaviour concerning division by zero in floating point numbers in C#. It does not throw an exception, as with integer division, but rather returns an “infinity”. Why is that?

Eric: As I’ve often said, “why” questions are difficult for me to answer. My first attempt at an answer to a “why” question is usually “because that’s what the specification says to do”; this time is no different. The C# specification says to do that in section 4.1.6. But we’re only doing that because that’s what the IEEE standard for floating point arithmetic says to do. We wish to be compliant with the established industry standard. See IEEE standard 754-1985 for details. Most floating point arithmetic is done in hardware these days, and most hardware is compliant with this specification.

User: It seems to me that division by zero is a bug no matter how you look at it!

Eric: Well, since clearly that is not how the members of the IEEE standardization committee looked at it in 1985, your statement that it must be a bug “no matter how you look at it” must be incorrect. Some industry experts do not look at it that way.

User: Good point. What motivated this design decision?

Eric: I wasn’t there; I was busy playing Jumpman on my Commodore 64 at the time. But my educated guess is that it is desirable for all possible operations on all floats to produce a well-defined float result. Mathematicians would call this a “closure” property; that is, the set of floating point numbers is “closed” over all operations.

Positive infinity seems like a reasonable choice for dividing a positive number by zero. It seems plausible because of course the limit of 1 / x as x goes to zero (from above) is “positive infinity”, so why shouldn’t 1/0 be the number “positive infinity”?

Now, speaking as a mathematician, I find that argument specious. A thing and its limit need not have any particular property in common; it is fallacious to reason that just because, say, a sequence has a particular limit that a fact about the limit is also a fact about the sequence. Mathematically, “positive infinity” (in the sense of a limit of a real-valued function; let’s leave transfinite ordinals, hyperbolic geometry, and all of that other stuff out of this discussion) is not a number at all and should not be treated as one; rather, it’s a terse way of saying “the limit does not exist because the sequence diverges upwards”.

When we divide by zero, essentially what we are saying is “solve the equation x * 0 = 1″; the solution to that equation is not “positive infinity”, it is “I cannot because there is no solution to that equation”. It’s just the same as asking to solve the equation “x + 1 = x” — saying “x is positive infinity” is not a solution; there is no solution.

But speaking as a practical engineer who uses floating point numbers to do an imprecise approximation of ideal arithmetic, this seems like a perfectly reasonable choice.

User: But surely it is impossible for the hardware to represent “infinity”.

Eric: It certainly is possible. You’ve got 32 bits in a single-precision float; that’s over four billion possible floats. All bit patterns of the form

?11111111???????????????????????

are reserved for “not-a-number” values. That’s over sixteen million possible NaN combinations. Two of those sixteen million NaN bit patterns are reserved to mean positive and negative infinity. Positive infinity is the bit pattern 01111111100000000000000000000000 and negative infinity is 11111111100000000000000000000000.

User: Do all languages and applications use this convention of division-by-zero-becomes-infinity?

Eric: No. For example, C# and JScript do but VBScript does not. VBScript gives an error if you do that.

User: Then how do language implementors get the desired behaviour for each language if these semantics are implemented by the hardware?

Eric: There are two basic techniques. First, many chips which implement this standard allow the programmer to make float division by zero an exception rather than an infinity. On the 80×87 chip, for example, you can use bit two of the precision control register to determine whether division by zero returns an infinity or throws a hardware exception.

Second, if you don’t want it to be a hardware exception but do want it to be a software exception, then you can check bit two of the status register after each division; it records whether there was a recent divide-by-zero event.

The latter strategy is used by VBScript; after we perform a division operation we check to see whether the status register recorded a divide-by-zero operation; if it did, then the VBScript runtime creates a divide-by-zero error and the usual VBScript error management process takes over, same as any other error.

Similar bits exist for other operations that seem like they might be better treated as exceptions, like numeric overflow.

The existence of the “hardware exception” bits creates problems for the modern language implementor, because we are now often in a world where code written in multiple languages from multiple vendors is running in the same process. Control bits on hardware are the ultimate “global state”, and we all know how irksome it is to have global, public state that random code can stomp on.

For example: I might be misremembering some details, but I seem to recall that Delphi-authored controls set the “overflows cause exceptions” bit. That is, the Delphi implementors did not use the VBScript strategy of “try it, allow it to succeed, and check to see whether the overflow bit was set in the status register”. Rather, they used the “make the hardware throw an exception and then catch the exception” strategy. This is deeply unfortunate. When a VBScript script calls a Delphi-authored control, the control flips the bit to force exceptions but it never “unflips” it. If, later on in the script, the VBScript program does an overflow, then we get an unhandled hardware exception because the bit is still set, even though the Delphi control might be long gone! I fixed that by saving away the state of the control register before calling into a component and restoring it when control returns. That’s not ideal, but there’s not much else we can do.

User: Very enlightening! I will be sure to pass this information along to my coworkers. I would be delighted to see a blog post on this.

Eric: And here you go!

Food for thought…. innit??