I've loved Firefox since version 0.93. It was so much better than Internet Explorer and the other alternatives that I couldn't imagine using anything else. But, then Firefox's memory leaks went from annoying me to ticking me off; I started having real stability problems with it on both Windows and Linux; and security holes started appearing far more often. I was about to switch to Safari on Windows and MacOS and Konqueror on Linux, when Mozilla got serious about not just fixing, but rebuilding Firefox.

read more

Enterprise Library is a collection of application blocks intended for use by developers who build complex, enterprise-level applications. Enterprise Library is used when building applications that are typically to be deployed widely and to interoperate with other applications and systems. In addition, they generally have strict security, reliability, and performance requirements.

The goals of Enterprise Library are the following:

• Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
• Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding their own code.
• Ease of use. Enterprise Library offers numerous usability improvements, including a graphical configuration tool, a simpler installation procedure, and clearer and more complete documentation and samples.
• Integration. Enterprise Library application blocks are designed to work well together or individually.

These are typically rationalized through:

• Online Guidance
• Scenarios or QuickStart samples
• QuickStart Walkthroughs
• Hands-On Labs
• Sample Source Code

There will be a webcast in June 2008  giving an overview of the new features of Enterprise Library 4.0. You can find more detail on the Enterprise Library landing page.

What's New

This release of Enterprise Library includes the following:

• Integration with the Unity Application Block
• Windows Management Instrumentation (WMI) 2.0 support and improved instrumentation
• Performance improvements (particularly, in the Logging Application Block)
• Pluggable Cache Managers
• Visual Studio 2008 support
• Bug fixes

Note: existing public APIs (v3.1) are still supported.

Links

• MSDN site: http://msdn.microsoft.com/entlib
• Community Forum: http://go.microsoft.com/fwlink/?LinkID=119312
• Community Extensions: http://codeplex.com/entlibcontrib

VIA : Mike Walker's Blog

First, if you are are developing exclusively ASP.NET 2.0+ applications, sorry, there is nothing interesting for you in this post.

Second, if you are involved in some ASP.NET 1.1 projects and have no plans to install new development environment, then, sorry again, there is probably no reason for you to read on either. Ok, I've done all I could to warn you against reading it. Don't blame me for wasting you time, because I am going to start from the very beginning.

One of my current projects is ASP.NET 1.1 Web Application. It is already released and rather stable. And yesterday I got new development machine on my workplace and migrated all my data to it. .NET Frameworks 1.1, 2.0, 3.0, 3.5 were preinstalled before I first logged in (thanks to our system administrators). I installed VS 2003 and SP1 for it, VS 2008, SVN client, some other necessary utilities and components. Then, updated sources from source control for the mentioned ASP.NET 1.1 Web Application and started it. Bang! Script error - some variable is undefined.

Actually there were a bunch of such errors on the page. As I intentionally mentioned earlier, the application is stable. And this particular page was not changed for quite some time.

Brief research of the generated HTML source, code-behind class and respective web controls revealed the cause of the exception: there was a sequence of similar Page.RegisterStartupScript statements which went in pairs. The first one in a pair registered some JavaScript object, and the second one - used the object in another declaration.

First I checked source control's log - no related changes. Then, the next suspect - application configuration changes that could cause such behavior. But no, all the related controls' declarations on the page are static.

Ok, code was not changed, application is working fine on QA environment. So, something is wrong with my new machine. But what? 

I had a dim recollection that there is something wrong with the sequence of script registration in ASP.NET 1.1. But common sense told me that if something wrong could happen then it would had happened long ago.

Still, I opened Reflector and found such code inside RegisterScriptBlock method of System.Web.UI.Page class:

     if (scriptBlocks == null)
    {
        scriptBlocks = new HybridDictionary();
    }

As you probably well aware of, HybridDictionary changes its internal storage from ListDictionary to Hashtable starting from its ninth element. So, of course we cannot rely on any specific order of script registrations if script blocks are stored in HybridDictionary. But how did it work earlier and how the same code works on development server and QA environment without any bugs reported? 

So, I copied Reflector to the development server and found following code in the same RegisterScriptBlock method that I reviewed on my machine:

    if (scriptBlocks == null)
    {
        scriptBlocks = new ListDictionary();
    }

The code was fixed. But where did the fix come from? I recalled that there is a service pack for .NET 1.1 that I installed on my old development machine several years ago. Google promptly gave me a link.

File name: NDP1.1sp1-KB867460-X86.exe, Version: 1, Date Published: 8/30/2004, Download Size: 10.2 MB

Why am I presenting all this information here? Because the fix did not help, though I was almost certain that it should. The same HybridDictionary.

That's was fiasco. My working day was over several hours ago. Finish.

But today I decided to reproduce the issue at home. Fortunately I had a virtual machine with Windows XP and fortunately the copy of .NET 1.1 System.Web.dll had the same version as the one at work (i.e. HybridDictionary is used in RegisterScriptBlock).

So I started googling again and found the second service pack. Strangely enough it has the same name (i.e. .NET Framework 1.1 Service Pack 1) though with a lengthy suffix (.NET Framework 1.1 Service Pack 1 SYSTEM.WEB.DLL and MSCOREE.DLL Security Update for Windows 2000, Windows XP, Windows 2003 Server x64/IA64 and Windows 2003 Server R2 x64/IA64) .

Like the previous service pack that I found, description for this one states that its purpose - security improvements. No mentions of ASP.NET-specific modifications. I could not find any documentation which describes the changes in detail.

But the main thing is that this second "Service Pack 1" done what I wanted. Eventually I had my ListDictionary back.

 
The summary is:

1) there are at least TWO patches called ".NET 1.1 Service Pack 1";

2) both of them state that they are focused on security improvements, but

3) one of them changes at least one fundamental aspect of ASP.NET 1.1 behavior. 

 
Thank you for reading. Good luck.

Roger Magoulas, our director of research, sent out the recent comment and graph as part of his weekly analysis of the latest load of our Bookscan-based data mart:

What's keeping Adobe up at night? Probably not Silverlight. I noticed the Silverlight topic looking bright red [in the treemap visualization that shows week-to-week changes by topic] and thought I would take a look - see the chart below. Since Silverlight and the somewhat related Expression Web books started appearing in October, we don't see much trendworthy activity. We do see Flash selling 6-7 times the units as Expression Web, Flash experiencing a holiday bump and Flex increasing steadily. Silverlight and Expression Web are young and Microsoft famously sticks by its products - should be an interesting topic to follow.

In short, if book sales are any indicator, traction for Silverlight appears to be quite low.

While Roger is correct in noting that it's never wise to count Microsoft out, so far it does appear that they haven't made much of a dent in Flash's dominance. SearchEngineWatch recently reported that even Microsoft is still not using Silverlight on many of its web properties.

'Bring me the head of the IPN admins!'

A glitch in PayPal's payment verification system is wreaking havoc on some ecommerce sites that depend on the service. For more than 48 hours, the bug in PayPal's instant payment notification has made it impossible for them to process orders, owners of these businesses complain.…

By now you've probably seen a lot of the brouhaha over a bug in the newest version of Excel, 2007. Basically, multiplying 77.1*850, which should give you 65,535, was actually displaying 100,000.

Before I try to explain this, I should disclose that I did work on the Excel team, but that was thirteen years ago. I haven't been there for a long time. I don't even think I know anyone on that team any more. I'm just trying to explain the bug a little bit as a public service.

The first thing you have to understand is that Excel keeps numbers, internally, in a binary format, but displays them as strings. For example, when you type 77.1, Excel stores this internally using 64 bits:

0100 0000 0101 0011 0100 0110 0110 0110
0110 0110 0110 0110 0110 0110 0110 0110

The display is showing you four characters: "7", "7", ".", and "1".

Somewhere inside Excel is a function that converts binary numbers to strings for displaying. This is the code that has the bug that causes a few numbers which are extremely close to 65,535 to be formatted incorrectly as 100,000.

If you use the number further along in calculations, for example, if you add 2 to the results, you'll get the right thing.

=77.1*850 -> displays 100000

=77.1*850+2 -> displays 65537, correctly.

Just to throw people off, this bug also exists for a few numbers which are extremely close to 65,536. They display incorrectly as 100,001.

=77.1*850+1 -> displays 100,001, incorrectly.

This is still only a bug in the number formatting code; if you try to make a chart with that number in it, you'll get a correct chart.

Now... you may have noticed that I said that this bug exists for numbers which are extremely close to 65,535, but not for 65,535 itself. Indeed if you enter 65,535 you see 65,535. But, you notice, 77.1 * 850 should be exactly 65,535, not extremely close to 65,535!

Look closely at the binary representation for 77.1:

0100 0000 0101 0011 0100 0110 0110 0110
0110 0110 0110 0110 0110 0110 0110 0110

See how there's a lot of 0110 0110 0110 there at the end? That's because 0.1 has no exact representation in binary... it's a repeating binary number. It's sort of like how 1/3 has no representation in decimal. 1/3 is 0.33333333 and you have to keep writing 3's forever. If you lose patience, you get something inexact.

So you can imagine how, in decimal, if you tried to do 3*1/3, and you didn't have time to write 3's forever, the result you would get would be 0.99999999, not 1, and people would get angry with you for being wrong.

The same thing happens in binary with  numbers ending in 0.1: they are repeating decimals, so when you do mathematical operations on them, very small insignificant errors creep in somewhere way to the right of the decimal point. (PS: same for .2, .3, .4, .6, .7, .8, and .9, but not .5).

The IEEE has a standard, IEEE 754, for how to represent floating point numbers in binary, and this is what almost everybody uses, including Excel, and they have for a really long time, and it means sometimes you get imprecise results when you add a lot of 0.1's together, but if you're rounding the numbers to a reasonable number of decimal points, you won't really care.

Back to the Excel bug, which is a genuine bug, not just an artifact of this IEEE 754 stuff. Since 77.1 has no exact representation, Excel stores it as

0100 0000 0101 0011 0100 0110 0110 0110
0110 0110 0110 0110 0110 0110 0110 0110

and then when you try to multiply it by 850, you get something very close to 65,535, but not exactly 65,535, because of the fact that 77.1 wasn't stored exactly because that would take infinite memory. And this number, which is very close to 65,535, happens to be one of only 12 possible floating point numbers which trigger this bug in Excel.

OK, Q&A.

Q: Isn't this really, really bad?

A: IMHO, no, the chance that you would see this in real life calculations is microscopic. Better worry about getting hit by a meterorite. Microsoft, of course, will be forced to tell everyone "accuracy is extremely important to us" and I'm sure they'll have a fix in a matter of days, and they'll be subjected to all kinds of well-deserved ridicule, but since I don't work there I'm free to tell you that the chance of this bug actually mattering to you as an individual is breathtakingly small.

Q: Shouldn't they be testing for these kinds of things?

A: I'll bet that most of the numeric testing done on the Excel team is done automatically with VBA code. Cells containing this value display as 100,000, but from VBA, they're going to look like 65,535 (since the number would be passed into the Basic runtime in binary, before the display formatting.) I'm sure there's plenty of code to test display formatting, but with a bug like this that only happens on 12 out of 18446744073709551616 possible floating point binary numbers, it's unlikely that any set of black-box tests would cover this case.

Q: What caused the bug?

A: I'm not sure exactly, since I don't have the code. Off the top of my head, I can't think of anything that would cause this behavior. Play around with Quanfei Wen's IEEE-754 calculator, maybe you'll find something.

Q: Why not use "exact" (decimal) arithmetic?

A: It's much slower than floating point arithmetic, since there's no hardware on your CPU chip to do it for you natively.

Over the years, Microsoft got so much heat for floating point rounding artifacts in the Windows Calculator that they rewrote it to use an arbitrary-precision arithmetic library. Since you have to poke at Windows Calculator with a stick, it doesn't have to be as fast as Excel. That said, CPUs have gotten pretty fast. I'll bet an arbitrary-precision version of Excel would perform pretty well these days. Still, the Microsoft Excel support team has spent the last 20 years defending IEEE 754, and it's not surprising that they've started to believe in it.

And let's face it -- do you really want the bright sparks who work there now, and manage to break lots of perfectly good working code -- rewriting the core calculating engine in Excel? Better keep them busy adding and removing dancing paper clips all day long.

Not loving your job? Visit the Joel on Software Job Board: Great software jobs, great people.