Tuesday, March 28, 2006

Pinvoke Convenience

I had to investigate a support query related to the lack of sound for a MacroView operations session running via remote desktop to a Windows Server 2003 server. The interesting aspect of the process was that I chose to write a quick .NET application in Visual Studio as part of the fault resolution process rather than configure the operations program for a particular scenario or write a simple C win32 application to do the same. It just seemed quicker and easier to create a quick C# program and grab the MessageBeep code from pinvoke.net – even given the interaction with the WIN32 API that was needed.

Monday, March 27, 2006

WPF/E and IL Code

When I first heard about WPF/E (WPF/Everywhere) it sounded like a waste of time. My interpretation was that it was just a XAML display engine with no support for .NET code. Check out Tim Anderson’s post for some more info from the Mix06 conference: http://www.itwriting.com/blog/?postid=387

Being able to execute .NET code – even a small subset like the compact framework makes it a way more useful proposition. There’s probably some relationship to the Xbox 360 CLR murmurings. Both are good directions for .NET code deployability.


Thursday, March 23, 2006

A real choice?

I just upgrade to my Real player to a later version. Even with some bad (real pushy) experiences many moons ago, the player has some usability features that are quite handy. Regardless the following player setup screen made me laugh. I interpreted the screen as:

a) Let Real takeover all your media playing needs OR ELSE

b) we’ll make you work hard by clicking a gazillion checkboxes to just leave the existing settings in place.

Sunday, March 19, 2006

Xbox 360 CLR Possibility

It looks like there’s a possibility of the .NET CLR being available for XBox 360 development. Check out these Microsoft blogger posts  from Mike Zintel and David Weller. This is good news for me, as I am one of those weirdos that like a cross platform story. The ideal is to be able to develop managed code and be able to run it on many platforms. Sure Write once, run anywhere (WORA) has become a bit of a joke but its more a case of excessive expectations rather than impracticality.

Supporting an application on another hardware/operating system platform is a non-trivial decision as it does require additional development, testing and support resources. A platform that has some aspect of WORA functionality just eases a lot of the burden on the development side. A design that separates out the GUI portion from the Domain Model allows platform specific GUI code to be minimized, if a platform specific approach is needed. A good automated test suite helps on the test side of the equation. So though the idealized WORA world may not exist, cross platform managed code development has a heap of application reach advantages.

Being involved in the development and maintenance of a cross platform SCADA product called MacroView since the late eighties has skewed my thinking towards a cross platform approach. A lot of code can work well with little modification across a number of platforms – especially in the purely managed code worlds of Java and CLR implementations. It’s just a shame when vested interests of extremes of the WORA debate spoil the party.

Wednesday, March 15, 2006

Meandering thoughts on thin clients, objects etc.

Check out the following video on Zdnet: http://zdnet.com.com/1606-2_2-6048186.html

The thin client concept is one of those technologies that keeps resurging every so often like waves on the technology landscape. It finds niches where it’s well suited but then subsides in terms of media or industry attention. Regardless, the argument that the “perfect storm” currently exists for the widespread adoption in the business arena fits well with my current experience.

The bandwidth taken up due to the asynchronous transfer of graphical bitmap change information is pretty minimal for most business applications given the bandwidth available. Couple this with the processor power available today and in the near future with multi-core processors and you have a strong argument for the widespread adoption of thin clients for businesses. It’s just so much easier for IT support departments if they have strong control over the environment in which the software they support runs.

This brings to mind Microsoft’s plans for the RDP protocol with respect to the WPF graphics functionality. Since WPF/Avalon is fundamentally vector based, the likelihood is that the RDP style protocol for WPF will involve the asynchronous transfer of graphic object property changes. Yet another example of what’s old is new again (e.g. X Windows)!

Following on with this windy thought road, if a WPF based variation of RDP is practical then why can’t we have a distributed object implementation based on the same basic protocol concepts? There currently appears to be a sentiment to move away from “objects” given the work done in the SOA arena and issues people have with an O/R mapper approach.

So what’s the point of this post? I suppose it can be summarized as:

  • The thin client area is worth watching over the next couple of years for business IT.
  • I’m really interested in how RDP will operate with respect to WPF functionality? Will it be bitmap change oriented or vector change oriented?
  • I’m not ready to give up my object addiction for software development analysis, design and implementation.
  • I don’t think the software industry has fully realized the potential of OO. In particular, the database, platform and middleware companies have not really stepped up to the plate. Its difficult and complex work, but man the money flow they have is there to justify it.

Now, if my blog was widely read (it’s certainly not) I’m sure there would be comments questioning why live in the past? Maybe I should hop on to the SOA bandwagon or get real and also let the RDBMS drive the internal software design? There was a video from the 2005 PDC conference with Don Box telling someone off camera to basically get over OO and move on. It’s likely to be tiring having OO zealots questioning an SOA approach but a whole-of-industry direction that means giving up some of the benefits of OO development is worth questioning. I suppose just waiting a few years and relying on the “everything that is old is new again” principal will bring back the core OO benefits as some newly named paradigm.