Apolon's Software Torq

I was looking at the purchase of a new Intel Core 2 Duo based system and was somewhat annoyed at the pricing structure. It looked like the premium paid for the higher speed models was out of wack with the low end pricing. To help the analysis some quick and dirty calculations were made to get an idea of how much of a premium was being paid. The figures shown here are based on:

• www.ple.com.au $AU pricing as of 27–Sep-06.
• www.spec.org SPECint_rate2000 figures for Dell based machines

The intent was to get a basic indication of the sweet spot for the Core 2 Duo pricing, so all the nuances of benchmarking are not a huge issue (lies, damn lies and benchmarks!). The SPECint_rate2000 value was chosen based on the typical style of application that will be running on the machine. The pricing curve across the various models is sort of like a hockey stick i.e. the price shoots up as you go towards the higher end models.

The performance increases across the models, but virtually linearly and from quite a high base performance for the lowest end model.

The $/rate value provides some indication of the effective cost per achieved performance result. The E6300 is excellent value at the low end, but there is a clear hike in the $/rate for the two higher end models. The E6600 is the model I’ll go for. It then provides an option to upgrade once new models come out or the pricing structure changes. Personally I think Intel made a mistake with the large increase in pricing for the E6700 and E6800. Its just too much of a jump in pricing compared to the other models and I feel “ripped off” when seriously considering purchasing the high end processor. Its worth paying some premium to get the fastest desktop processor from Intel, but “some” is the operative word.

Posted by Apolon at 10:50 AM | Permalink | Comments | links to this post

This post relates to the following forum post:

 http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=721735&SiteID=1

I’m attempting to be able load XAML files into a Windows forms application at run time but for the WPF graphics to be automatically scaled to fit into the available form area. The intended approach is to place whatever UIElement is loaded from the XAML file within a Viewbox to perform the graphics scaling. The Microsoft forums don’t allow file attachments, so my blog is being used as an attachment staging point. A sample winforms project link follows.

http://torqsoftware.com/blogs/apolon/attachments/ElementHostExperiment.zip

The solution was built using the September RC1 bits. Run the application and then load up an all XAML files such as the Petzold clock. In Viewbox mode, I want the clock to scale with the form. Currently it doesn’t display anything in Viewbox mode.

http://www.charlespetzold.com/blog/2006/04/AllXamlClock.xaml

Posted by Apolon at 5:27 PM | Permalink | Comments | links to this post

There is the potential for utilizing XAML functionality as an extension to the MacroView product line. As such I’ve been experimenting with various XAML tools including Microsoft Expression Interactive Designer. The direction for XAML use as part of MacroView is likely to be more oriented towards standalone XAML files rather than a XAML+.NET application class combination. By default EID (interactive designer) automatically creates a .xaml.cs file associated with any new scene. One approach to allow you to create standalone XAML files that I have found to work with the September CTP of EID is to:

• Remove the <x:Class> markup from the XAML header and
• Remove the .xaml.cs file from the project.

After these steps you can edit the standalone XAML file in EID and still be able to load it in more runtime oriented XAML environments.

Posted by Apolon at 11:32 AM | Permalink | Comments | links to this post

I’ve been experimenting with the Microsoft ClickOnce technology that is part of .NET 2.0. Its intended use is as a deployment option for a new package called MacroView Windows Desktop that is being developed. For large MacroView installations, the use of ClickOnce technology would save an IT department work by having a central point where the software package is updated and made available to all users automatically. The Visual Studio 2005 Build-Publish functionality was fairly easy to use in the first have-a-go experience. The first problem encountered was setting up the Linux apache server I’m using to know about the mime types used by click once. The httpd.conf file was modified to include the following lines:

AddType application/x-ms-application .application
AddType application/x-ms-application .manifest
AddType application/x-msdownload .dll

This got me to the stage where an installation web page (generated by VS2005) provided a launch point for clickonce installation:

The next problem was that clicking the install button just brang up the .application file’s XML contents and didn’t start an install process. I scoured the web attempting to find a solution but didn’t find anything specific. There were a number of mentions of the problem but no solution that worked in my scenario. The test environment was an Windows XP Home system running in a VMware virtual machine. As a test another Windows XP Pro virtual machine was used and that worked fine. This is a bit disconcerting as both were patched up with the current windows update patches and very similar other than the home versus pro difference. As a hunch, the Internet Explorer cache was cleared on the XP home machine. After this the Click Once launch proceeded as expected. All I can conclude at this stage is that before the server side had been set up correctly, one of the launch tests caused files to be cached which then affect subsequent launch attempts. Note that this was even with browser page refreshes, browser restarts etc. So if you ever have trouble getting a ClickOnce app to launch on Internet Explorer trying clearing the local cache as one of solution options.

Once a launch started, it downloaded the click once application files and initiated the install process. The security warning comes up since no publisher certificates have been set up for these experiments. It will be needed for a final MacroView Desktop package.

After that, the application just started up. The MacroView Windows Desktop is basically a graphical shell where .NET based application modules can be plugged in for site specific applications. The standard application modules that will come with the product will include a VNC viewer, report viewer, data grid viewer and embedded web browser. All modules can communicate via a basic messaging system and all modules have accessed to a managed set of connections to MacroView servers. More on all that once the product is finished though! This post is primarily about my initial experiences with ClickOnce.

One aspect of ClickOnce that I loved was that it was run as a limited user on XP, but the Add-Remove programs list was actually updated just for that user. The support info shows the application details and the web server that the files were obtained from. Clickonce apps are installed on a per-user basis and management of those apps is handled by the individual users seemingly without the need for admin access. Now getting it all running in a development environment is fine and dandy but I get the feeling that putting it in practice in the field will be a completely different kettle of fish. But thats something for another post.

Posted by Apolon at 2:45 PM | Permalink | Comments | links to this post