November 9, 2009 9:30 a.m. to 5:00 p.m. St. Pius V University (Rome)
In Response to Pope Benedict XVI’s Call for Both Sides to be Heard

http://sites.google.com/site/scientificcritiqueofevolution/

 Great concept, and clean implementation, impossible to stop clicking until you beat it.

So…

• if you want a custom action to be executed only when uninstalling, add “AND NOT UPGRADINGPRODUCTCODE” to your condition
• if you want a custom action to be executed only when upgrading, add “AND UPGRADINGPRODUCTCODE” to your condition
• if you want a custom action to be executed only when being upgraded by a specific product (generally relevant only when multiple “editions” of a product exist), refer to the specific product code, e.g. AND UPGRADINGPRODUCTCODE=”{ABC-123}”

Peter Hallam commented on what consumes most of a developer’s time between the following:

• Design Code
• Write New Code
• Understand Existing Code
• Modify Existing Code
• Verify Existing Code Still Works

He argues that most developers spend most of their time understanding, modifying, and verifying that existing code still works. His focus is primarily upon how this balance impacts (or should impact) editor (Visual Studio) features, but the discussion is interesting outside that context also.

Why do we hire developers based upon how well they can write some lame from-scratch sample code? My current employer did something unique in my experience: they gave me some unfamiliar buggy code and asked me to discuss what was wrong with it, discuss some possible solutions, and implement one of them.

Hello? Test driven development? How about even starting with automated unit tests, even if they’re written after the code?

Does the whole thing make the wacky world of literate programming less whacky?

The upside of this is that game designers have an additional tool to apply consciously in the quest to entertain and educate. The downside is the ugly intersection of this pleasurable failure with the unhealthy psyche. For individuals convinced at some level that they deserve to fail, whether by neurochemical imbalance, environmental factors, or an agent of the enemy of their soul, this quick and repeatable source of failure can be dangerous. The endless treadmill of MMPOGs are perhaps the most dangerous. It’s like putting a crack-dispenser in an addict’s bedroom.

This doesn’t mean I think games are evil or should be eliminated or restricted in some way. I am firmly convinced that games, storytelling through games, and the art of game design offer benefits to society, technology innovation, education, etc. that outweigh the associated dangers. Additionally, I suspect that perhaps this pleasure in failure may underly other addictive behaviors. Similar patterns appear to exist in addictions to work, unsuccessful relationships, spending, approval from others, food, pot, and other psychological (vs. chemical) addictions.

What I do suggest, is that mentors, parents, pastors, and others who care about someone demonstrating symptoms of addiction consider this as a possible underlying cause. In my experience, games stopped being a snare for me when I came to grips with my belovedness in the eyes of God. Human approval, even intense human love, was insufficient. People can be deceived or mistaken; God cannot. Only recognizing that the same God who knows everything about me loves me intensely was sufficient to drive the changes that took me from addicted and depressed to joyful and free.

Oh, and speaking of thought-provoking check out Paul Graham’s latest essay on Software Patents. I actually beat SlashDot to this one by 24 hours or so which was nice. It gave me a chance to ponder this before being utterly corrupted by the SlashDot community’s followup. I find Graham alternately insightful and annoying, but almost always thought-provoking.

My friend Adam pointed out this link, and it is too critical to world history not to mention. J

http://www.history.navy.mil/photos/images/h96000/h96566kc.htm

I misunderstood the question, so my results aren’t precisely relevant (hence the posting here and not in his comments). I thought that (0,0) (0,0) for example, would define the bottom left-most point on the grid, and therefore not define a valid area. It looks like he is actually considering that to define the bottom-leftmost square, where I considered the space between (0,0) and (1,1) to be the bottom-leftmost square.

So, my results may not correspond directly to his, but they might still be interesting. Play with this a bit and then compare your results to ours.  My best effort so far is 1.17 calls to CountBlocksSet per grid.

One pointer to verify algorithm correctness. We know that the number of squares should equal 204, the number of rectangles (including squares) should equal 1296, and the number of non-square rectangles would therefore be 1092.

Attached are testdrivercs.txt, the test driver and sample implementation, and gridcs.txt, the sample IGrid implementation.

mysolutioncs.txt is also attached, and includes my iterative improvements.

Don’t have the time to read a 10-page how-to article or watch a full length webcast? Try an MSDN Nugget, a webcast that takes you step-by-step to discovering new functionality or exploring a hot developer topic, all in 10-15 minutes. View them online or download for later reference.

http://www.microsoft.com/uk/msdn/events/nuggets.aspx

The few I’ve watched so far were “not lame.”

Here’s a quick summary of the bug:

• Install two assemblies Binding.exe and ClassLibrary1.dll, with Binding dependent upon ClassLibrary1.
• Delete ClassLibary1.dll.
• Launch Binding.
• MSI is not invoked for a repair, and the load fails with “Unhandled Exception: System.IO.FileNotFoundException: File or assembly name ClassLibrary1, or one of its dependencies, was not found.”

The problem is that Fusion allows the assembly binding to fail rather than invoke MsiProvideAssembly (…INSTALLMODE_DEFAULT…). The MSDN article describing how assemblies are located says that “If the assembly is not found after probing, the runtime requests the Windows Installer to provide the assembly.” This is referring to dependent assemblies, not to how Fusion attempts to locate assemblies directly invoked via Explorer.

Junfeng Zhang’s response is:

“We don’t invoke MSI install every time we see a binding failure. There are many by-design binding failure for resource probing. If we do that the perf will go to hell.

Instead, we query MSI before we invoke MSI install. If MSI says it has the component we then will invoke MSI install. In John’s case, the query returns nothing because ClassLibrary1.dll is in the wrong context/component.”

To address each point without hijacking that post. . .

There are certainly by-design binding failures, but these are most often for .resource assemblies, and do not result in a final Unhandled Exception attempting to load (right?). In this case, Fusion knows that the assembly is going to fail to load and that it is because there was an unhandled exception while attempting to load a dependency. The probing process already consumes significant time at this point, so investing additional time necessary to ask MSI to provide the assembly and repair if necessary seems like a good return on investment. The only time we’d take the hit of actually running a repair would be when MsiProvideAssembly detects that a repair is necessary.

Without knowledge of Fusion’s implementation, I can only speculate about how they are querying MSI in this scenario to see if it “has the component”. It doesn’t appear that Fusion ever loads MSI into it’s process, and no separate msiexec process is started. If Fusion used MsiProvideComponent (…INSTALLMODE_DEFAULT…) then the directly invoked assembly and any components in the component’s feature or feature parent would be reinstalled. Even if Fusion is somehow querying MSI in this scenario, doing so for only the directly invoked component would be almost useless in a real-world scenario. Very rarely would we have an assembly with no dependencies.

I’m not sure what “the query returns nothing because ClassLibrary1.dll is in the wrong component” means. MSI only allows one assembly per component, so I assume that “wrong component” just means “not the component we’re specifically verifying”. Even that is suspect, however, since a Component’s state can only be accurately evaluated in the context of a Feature. The “wrong” thing here seems to be Fusion’s implementation of the described functionality. Fusion should be using the MsiProvideComponent method rather than directly referencing a component out of the context of the associated feature.

The best solution would seem to be that if an assembly fails to bind dependencies after probing, the runtime requests that Windows Installer provide the assembly; the same solution that the documentation indicates has been implemented.