Widget Anatomy The Keys for a Great User Experience

Previous post: Widget Anatomy The Manifest This is part two of my Widget Anatomy series which will explain the ins and outs of the Widget Framework that is shipping as part of Windows Mobile 6.5. In this Article we will discuss the major challenges of creating a great user experience that not only looks great, but it integrates nicely with the phone and its snappy and fun to use. The dark side of choice dealing with screen DPIness One of the coolest things about the Windows Mobile ecosystem is that there are many different devices with all shapes and forms for me to pick up the one that matches my lifestyle best. All those choices do have a dark side though, there is a variety of screen resolution/sizes we need to make sure our Widgets work and look great on. The table bellow shows all the supported Resolution/DPIs Windows Mobile 6.5 supports and as you can see it is a big table. Thankfully for widget writing, there really are only two options, one that we will call HiDPI (for 192) and then LoDPI for the rest. The reason is that, in practice, a document designed for 96 DPI (Internet Explorer on the desktop at 100%) will look fine on 96 DPI, 131 DPI and 128 DPI but it will look way too small on a 192 DPI screen. Now that we have reduced the supported DPIs to only two, then the best (and easiest) way to handle this in your widget is as follows: 1) Generate two CSS Style Sheets for your widget. You can call them something like HiDPI.css and LoDPI.css, and the basic rule is, for HiDPI, things should be about twice as big to look the same way as they do on the desktop. 2) Detect the screen resolution at runtime to determine which CSS to load. Here is an example: 1: function applyCSSStyle() { 2: var width = document.documentElement.clientWidth; 3: var cssFile = "css/LoDPI.css"; 4: if (width >= 480) { 5: // The document is wider than 480 pixels 6: // it must be a High DPI device 7: cssFile = "css/HiDPI.css"; 8: } 9: 10: // Add the correct CSS style sheet to the document 11: var headID = document.getElementsByTagName("head")[0]; 12: var cssNode = document.createElement('link'); 13: cssNode.type = 'text/css'; 14: cssNode.rel = 'stylesheet'; 15: cssNode.href = cssFile; 16: cssNode.media = 'screen'; 17: headID.appendChild(cssNode); 18: } 19: 20: function onLoad() { 21: applyCSSStyle(); 22: } How to best utilize those SoftKeys The Widget API gives you full control over the soft key menu bar, but since we want our widgets to behave as native applications do there are a few guidelines we should try follow: 1. The left soft key should always represent the default action and it should be context sensitive to what the user is supposed to do at that particular step in the User Scenario. 2. The right soft key can be either a menu or a button, when there only are two possible actions you should save the user one click and make it a button that said, if you do this there should be a way for the user to exit the widget somewhere on your UI. Just as a quick reminder, calling widget.menu.append(menuItem) Adds a menu item to the right SoftKey, if it was a button it will turn into a menu with the non configurable label Menu, also, the Exit menu item is added automatically and cant be renamed nor removed. calling widget.menu.setSoftKey(menuItem, widget.menu.rightSoftKeyIndex) removes all menu items from the right SoftKey and turns it into a button. Best practices The following are some of the best practices we have found really help greatly widgets be the best they can be: When possible, integrate with the phone skin by using theme able colors like highlight (details) Use art assets that match the screen DPINess, or, just provide a high resolution set (shrinking is always better than expanding) Minimize scrolling, vertical scrolling is ok on some cases, horizontal scrolling in almost all cases is a general NO NO Handle the screen rotation event, remember that this must be fast Load fast, generate all dynamic content after the widget is loaded. Give visual feedback to all user actions. Next post: Widget Anatomy - Performance the final frontier

Incorporating Accessibility into the Engineering Process Engineering

I am posting this on behalf of Jason Grieves who is a Program Manager on the Windows Accessibility Team. He and his colleague Masahiko Kaneko co-authored a book about our engineering process for accessibility. This is a great example of us helping the ecosystem build great software. Our expectations of software are very high (as they should be!). We expect that the software we use will be reliable, secure, and perform well - we expect the software to just work. There are many ways that we experience software, some of us use the traditional input method of keyboard and mouse. I and many other people augment this with accessible solutions such as larger screens, speech recognition, and screen readers. In Windows we consider accessibility just like reliability, performance, and security to be fundamental to all software in the operating system. Our feature teams create their software to meet these and other core requirements, which combine to create an operating system that meets the essential expectations of our users. In Windows 7 we continued the integration of accessibility requirements into our software engineering process. Accessibility, like the other fundamental requirements, has been planned, designed, implemented and tested in Windows 7. In an effort to enable software developers to create accessible Windows applications, we wanted to share our process with the community. We have captured this engineering process in a new book, Engineering Software for Accessibility. The book addresses three basic questions: How do you plan for accessibility? How do you design your software for accessibility? How can you implement and test to your software to confirm it meets the accessible design? We encourage software developers and anyone with an interest in accessible software to get a copy of our book. You can download a free DOC version of the eBook (right-click to download), or order a paper copy from Amazon. You will learn that properly implemented accessibility enables access to Windows applications for users with a variety of capabilities. We are pleased to offer you the ability to follow much of process our engineers used to make Windows 7 the most accessible operating system Microsoft has yet produced! Engineering Software for Accessibility is the latest of several efforts to assist Developers and Testers create accessible solutions. Early in the Windows 7 development cycle we released two accessibility testing tools as open source on CodePlex. UI Accessibility Checker and UI Automation Verify are designed to check the accessibility of applications that implement programmatic access via the MSAA or UI Automation APIs. We look forward to trying you accessible Windows software!

Version Checking (Just Dont Do It)

Version checking is probably one of the most common Application Compatibility issues that both developers and users are facing. This is another post in a series of posts about Getting Ready for Windows 7. As said, this is probably the most common application compatibility issue that users as well as developers face is when an application fails upon checking the operating system version. A lot can go wrong when version checking is misused. A user might experience a silent fail where the application simply fails to load and nothing happens. Or, a user might see a dialog box indicating something to the effect of you must be running Microsoft Windows XP or later when in fact, the computer is running Windows 7. Many other consequences to poor version checking can inconvenience users as well. Applications fail due to version checking for two main reasons: A flaw (bug) in the version checking code, which fails if the minor version is decreased, even if the major version is increased, for example, changing versions from 5.1(Windows XP) to 6.0 (Windows Vista), or if the expected service pack (SP) is not installed, even if you're running a newer operating system (for example, changing versions from Windows XP SP 2 to Windows Vista SP 1). We recommend that you check functionality rather then checking version, as you can read in this post. An intentional blocking that prevents the application from running on operating system versions not tested by its developers. We recommend that you do not block applications from running on future operating systems. When an application runs on an "incompatible" (due to poor version checking) version of Windows, it will generally display an error message, but it may also exit silently or behave erratically. Often, if we work around the version checking, the application will run well. End-users and IT professionals may apply a fix to let the application think it is running on an older version of Windows. Working Around The Problem (not really solving the bug) Compatibility mode: Designed for end users (not for developers to not fix their bugs), compatibility mode is an easy way to work around compatibility issues. When enabled, it applies a set of compatibility fixes that provide a runtime environment more compatible with applications written for older versions of Windows. One of those fixes is the "version lie," which makes the version query functions return the operating system version the user chose in the Compatibility tab of the Properties dialog box instead of the actual Windows version. To enable compatibility mode: Right-click the executable or shortcut to the executable. Click Properties. Click the Compatibility tab. Enable Run this program in compatibility mode for: and select the operating system version you think the application should be able to run on. Some applications consist of several executables. You may need to apply this fix to each one. Click OK to close the dialog box. Run the application. Checking for Features Rather Than Version As mentioned previously, checking the operating system version is not the best way to confirm that a specific operating system feature is available. This is because the operating system may have had new features added in a redistributable DLL. Rather than using GetVersionEx to determine the operating system platform or version number, it is more effective to test for the presence of the feature itself. For example, we plan to make the Direct2D and DirectWrite APIs and the Ribbon API available in Windows Vista, so there is no need to block your application from using these APIs when running on Windows Vista. You just need to check if these features are available on the Operation System that you are running. If possible, your application should still run if the feature is unavailable, though with reduced functionality or performance. You can use one of the following techniques to find out if a specific features is available on the given OS. For Win32 developers: Use LoadLibrary() to load a library which is not yet loaded into your application. If you are interested in a new function of a DLL which is already loaded (for example, kernel32.dll), then call GetModuleHandle() to obtain the module handle. If either of these functions return NULL, then this indicates an error. Use GetProcAddress() to obtain a function pointer. If GetProcAddress() returns NULL, then the function may not exist. Cast the pointer to a function pointer of an appropriate prototype. Some functions, although they exist may actually be stubs that return a "not implemented" error. Be such to check for such errors. Windows 7 introduces a new timer API - SetWaitableTimerEXProc, which adds one more input variable to the regular SetWaitableTimerProc. The TolerableDelay lets you specific a time tolerance window in which the timer can expire. This is a new in Windows 7, that we will use to demonstrate how to check for feature. // define function pointer type typedef BOOL (WINAPI *SetWaitableTimerExProc)( __in HANDLE hTimer, __in const LARGE_INTEGER *lpDueTime, __in LONG lPeriod, __in PTIMERAPCROUTINE pfnCompletionRoutine, __in LPVOID lpArgToCompletionRoutine, __in PREASON_CONTEXT WakeContext, __in ULONG TolerableDelay ); LARGE_INTEGER liDueTime; liDueTime.QuadPart = 0; nt period = 1000; unsigned int tolerance = 1000; HANDLE hTimer = // Get timer handle REASON_CONTEXT reasonContext = {0}; reasonContext.Version = 0; reasonContext.Flags = POWER_REQUEST_CONTEXT_SIMPLE_STRING; reasonContext.Reason.SimpleReasonString = L"MyTimer"; // Get module handle to a module which is already loaded HMODULE hKernel32Module = GetModuleHandle(_T("kernel32.dll")); if (hKernel32Module == NULL) return FALSE; // Get Address of function SetWaitableTimerExProc pFnSetWaitableTimerEx = (SetWaitableTimerExProc) ::GetProcAddress(hKernel32Module, "SetWaitableTimerEx"); // Check if the function exists if (pFnSetWaitableTimerEx == NULL) return FALSE; // Call function if (!pFnSetWaitableTimerEx(hTimer, &liDueTime, period, NULL, NULL, &reasonContext, tolerance) { // handle error } Alternatively, you may use DLL delayed loading and call functions in a __try...__except block. (For more information, see Linker Support for Delay-Loaded DLLs.) For COM APIs, handle errors returned by CoCreateInstance and QueryInterface.NET framework applications that call Win32 APIs via P/Invoke should handle EntryPointNotFoundException and DllNotFoundException exceptions. If You Must Check OS Version Number Identifying the current operating system is not the best way to determine whether a particular operating system feature is present. However, if you cant design your application to check for specific feature availability and the only way to ensure compatibility is through version checking, then please consider the following. For native applications, you will need to ensure your application's logic will work with newer versions of Windows. Please DO NOT BLOCK on version change! The following is a Win32 code example that uses GetVersionEx. If the major version is greater than 5 (Windows Vista, Windows Server 2008 R2 and Windows 7), the check passes. If it equals 5, then the minor version should be 1 or greater (Windows XP or Windows Server 2003). #include <windows.h>#include <stdio.h>void main(){ OSVERSIONINFO osvi; BOOL bIsWindowsXPorLater; ZeroMemory(&osvi, sizeof(OSVERSIONINFO)); osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); GetVersionEx(&osvi); bIsWindowsXPorLater = ( (osvi.dwMajorVersion > 5) || ( (osvi.dwMajorVersion == 5) && (osvi.dwMinorVersion >= 1) )); if(bIsWindowsXPorLater) printf("The system meets the requirements.\n"); else printf("The system does not meet the requirements.\n");} However there is a better way to verify the minimum OS version required using VerifiyVersionInfo(). This function compares a set of operating system version requirements to the corresponding values for the currently running version of the system. The following code example uses VerifyVersionInfo to check the operating system version against minimal requirements (Windows XP SP2): #include <windows.h>BOOL Is_WinXP_SP2_or_Later () { OSVERSIONINFOEX osvi; DWORDLONG dwlConditionMask = 0; int op=VER_GREATER_EQUAL; // Initialize the OSVERSIONINFOEX structure. ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX)); osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX); osvi.dwMajorVersion = 5; osvi.dwMinorVersion = 1; osvi.wServicePackMajor = 2; osvi.wServicePackMinor = 0; // Initialize the condition mask. VER_SET_CONDITION( dwlConditionMask, VER_MAJORVERSION, op ); VER_SET_CONDITION( dwlConditionMask, VER_MINORVERSION, op ); VER_SET_CONDITION( dwlConditionMask, VER_SERVICEPACKMAJOR, op ); VER_SET_CONDITION( dwlConditionMask, VER_SERVICEPACKMINOR, op ); // Perform the test. return VerifyVersionInfo( &osvi, VER_MAJORVERSION | VER_MINORVERSION | VER_SERVICEPACKMAJOR | VER_SERVICEPACKMINOR, dwlConditionMask);} In this code you can see how we use the VerifyVersion with a set of conditions to return TRUE incase we run on any OS grater than Windows XP Service Pack 2. For .NET Framework developers, use the ==, !=, <=, <, >, >= operators of the Version object returned by Environment.OSVersion.Version: // This code checks if the OS is at least Windows XP if (Environment.OSVersion.Version < new Version(5, 1)) { MessageBox.Show("Windows XP or later required.", "Incompatible Operating System", MessageBoxButtons.OK, MessageBoxIcon.Error); return; } It is highly recommended that you dont check for version at all and try looking to work with features. It will prove valuable for the future Just incase you want to read more, here are some useful links Application Compatibility Cookbook: http://msdn.microsoft.com/en-us/library/bb963893.aspx Version Lie and Managed Applications: http://blogs.msdn.com/cjacks/archive/2007/09/10/version-lie-shims-and-managed-code-on-windows-vista.aspx You can also download a HOL and code sample for this topic.

Using Custom Icons in Windows Mobile 6.5

If youve seen the any of the plethora of Windows Mobile 6.5 screen shots, likely youd agree that it looks much better than previous versions. A component of this face lift, is support for PNG files in the Window Mobile 6.5 Start screen. Including a nicely rendered PNG file as your application icon is important to ensure the highest quality user experience across different devices. If you plan to distribute your application via Windows Marketplace for Mobile (and I dont know why you wouldnt) the requirements document requires that you use a 45 x 45, 60 x 60, or 90 x 90 Start screen icon for your application. This post will cover how to use PNG files as icons in the Windows Mobile 6.5 Professional Start screen. For information on creating PNG icons, see my previous post on Creating Custom Icons for Windows Mobile 6.5. The sample code I will be referring to in this post can be found here. Contents: Start Screen: Resolution / DPI and Icon Size Registry Keys Setup: Static or Dynamic Cached Icons Start Screen: Resolution / DPI and Icon Size The Start Screen is one of the huge improvements in Windows Mobile 6.5 Professional. This replaces the Start Menu in previous versions. The improvements include: enhanced touch screen navigation (tap, tap and hold, pan, and flick) and more options for organizing and presenting Start menu items. If you are an experienced Windows Mobile developer, you know that depending on the DPI and resolution of the device, the shell extracts the appropriately sized icon from the EXE for display in the Start screen. Windows Mobile 6.5 still supports this; however now it also supports the display of PNG file icons. The shell does not automatically select the size of the PNG icon based on the device DPI. This dynamic selection of the icon is done in a setup dll. (See dynamic setup below.) The table below illustrates the DPI / resolution and icon size relationship. Windows Mobile Platform Resolution DPI Orientation Small Icon Large Icon Start Menu PNG Icon (6.5) 6.x Professional 240x240 96 Square 16x16 32x32 45x45 6.x Professional 240x320 96 Portrait & Landscape 16x16 32x32 45x45 6.x Professional 240x400 96 Portrait & Landscape 16x16 32x32 45x45 6.x Professional 320x320 128 Square 21x21 43x43 60x60 6.x Professional 480x480 192 Square 32x32 64x64 90x90 6.x Professional 480x640 192 Portrait & Landscape 32x32 64x64 90x90 6.x Professional 480x800 192 Portrait & Landscape 32x32 64x64 90x90 6.x Professional 480x864 192 Portrait & Landscape 32x32 64x64 90x90 6.x Standard 176x220 96 Portrait 16x16 32x32 N/A 6.x Standard 240x320 131 Portrait & Landscape 22x22 44x44 N/A 6.x Standard 240x240 131 Square 22x22 44x44 N/A 6.x Standard 240x400 131 Portrait & Landscape 22x22 44x44 N/A 6.x Standard 440x240 131 Landscape 22x22 44x44 N/A Registry Keys To have the Start screen use a PNG file instead of an icon embedded in the EXE, you need to provide the following registry entries: [HKEY_LOCAL_MACHINE\Security\Shell\StartInfo\Start\Phone.lnk] "Icon"="\Application Data\My App\newphoneicon.png" Here are the definitions of the value pair settings: Name Type Description Name REG_SZ Specifies the display name of the item. If the value is not specified, the file name will be displayed without the extension. Group REG_DWORD Specifies whether the item is a folder. The value can be set to TRUE or FALSE. Set the value to TRUE to indicate that the item is a folder. If the value is not specified, the system will determine the Group value by verifying whether the registry key has any subkeys. Icon REG_SZ Specifies the path and file name where the icon is located. The icon can consist of a PNG file or an embedded icon resource module. If this value is not specified, the default icon of the shell will be used. Rank REG_DWORD Specifies the rank of the item. An item that specifies a larger value for Rank will be displayed before items that specify a lower value. If this item is not specified, the Rank will be set to 0. Security note: This requires creating a registry key underneath HKLM\Security. This is a protected registry location. To write to a protected registry key, the CAB file needs to be signed. This will not be a problem for Marketplace applications, since by definition they are signed. As mentioned, this article only applies to Windows Mobile Professional devices. However, if your use the same CAB for a Standard device installation, you will need to make sure your application is signed privileged, otherwise setup will fail. Setup In the next two sections, Ill walk through two deployment scenarios, static and dynamic. Static Setup: If you know the resolution of the device your application will be installed onto, you can simply specify the registry key as part of your CAB file configuration. For example, I know my hypothetical application will only be installed on the Touch Pro (480 x 640), so I will use a 90 x 90 PNG file as the Start screen icon. In my Smart Device CAB project, I have added the following registry key: Note: This registry key supports CE strings and .INF file strings. Above %InstallDir% maps to the \Program Files\SMS Intercept directory. My CAB file also includes the AppIcon.png and a shortcut of the same name as the registry key above (SMS Intercept.lnk). See below: Dynamic Setup: Detecting DPI: The preferred way to configure the Start screen icon is dynamically: copying the appropriately sized PNG file based on the DPI of the device. We will use a setup dll to detect the DPI, and copy the appropriate PNG. You may know that WCELOAD (the EXE that process the CAB file) or a DLL that is loaded into its process, will return the same DPI (96) no matter the actual DPI of the device. To workaround this, we launch a very small helper EXE that quickly exits, without UI, and returns the DPI. The SDK sample ResDLL uses this technique as well as demonstrates how to install DPI specific resource DLLs. Here is the code used to detect the DPI: int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { HDC hdc = ::GetDC(NULL); INT ans = ::GetDeviceCaps(hdc, LOGPIXELSX); ::ReleaseDC(NULL, hdc); return ans; } Copy DPI specific files: Our dynamic CAB file contains four png files: 45.png 60.png 90.png AppIcon.png Based on the DPI detected, we copy the appropriate PNG file to the filename AppIcon.png. AppIcon.png is included in the CAB as a fallback in case our DPI detect logic fails. The unused icons and the DPI detect EXE are deleted. Here is a code snippet from the sample setup dll (SetupDPI) implementing this: wsprintf(szFile,_T("%s\\%s"), pszInstallDir, _T("\\GetRealDPI.EXE")); // Launch DPI Detector ::CreateProcess(szFile, NULL, NULL, NULL, NULL, 0, NULL, NULL, NULL, &pi); ::WaitForSingleObject(pi.hProcess, 10000); // DPI is returned in exit code of detector app ::GetExitCodeProcess(pi.hProcess, &nSystemDPI); ::CloseHandle(pi.hProcess); ::DeleteFile(szFile); // Based on DPI, copy xx.png to AppIcon.png and delete unused files wsprintf(szOutFile,_T("%s\\%s"), pszInstallDir, szTargetFilename); for (INT i=0;i<ARRAYSIZE(DPI_Icon);i++) { wsprintf(szFile,_T("%s\\%s"), pszInstallDir, DPI_Icon[i].lpstrIconSize); if (DPI_Icon[i].DPI==nSystemDPI) { ::CopyFile(szFile, szOutFile, FALSE); } ::DeleteFile(szFile); } Create Shortcut: As mentioned, we do the post-processing of the files after the CAB is installed (in the Install_Exit function). That is, because the icon image in the Start screen is created when the shortcut is created (see the cached icons section below), we need to create the shortcut in the setup dll instead of in the CAB file as was done in the static CAB sample. Otherwise, the Start screen will use an icon extracted from the EXE instead of the PNG file. Here is the language independent code that creates the shortcut: // Build lnk filename PTCHAR pAppDir = wcsrchr(pszInstallDir, '\\'); TCHAR szShortcutPath[MAX_PATH]; // CSIDL_PROGRAMS == \Windows\Start Menu\Programs SHGetSpecialFolderPath(hwndParent, szShortcutPath, CSIDL_PROGRAMS , false); wsprintf(szFile,_T("%s%s%s"), szShortcutPath, pAppDir, _T(".lnk")); // Build exe filename // CSIDL_PROGRAM_FILES == \Program Files SHGetSpecialFolderPath(hwndParent, szShortcutPath, CSIDL_PROGRAM_FILES , false); wsprintf(szOutFile,_T("\"%s%s%s%s\""), szShortcutPath, pAppDir, pAppDir, _T(".exe")); SHCreateShortcut(szFile, szOutFile); Note that the dynamic CAB sample does not not contain the file system declaration that creates a shortcut as the static sample CAB does. Cached Icons During development, you will likely want to change the PNG file as you experiment will different artwork. You will notice that if you overwrite the PNG file, the Start screen will not use the new image. This is because when the Start screen shortcut is created, the icon image is cached by the shell. Thereafter for better performance, the shell retrieves the image from the cache. The cache is rebuilt a boot time. Here is one possible workaround: Delete the shortcut Rename (or copy) target EXE name. For example, rename hello.exe to hello1.exe Recreate shortcut pointing to new EXE name. Here is provisioning XML that does this. You can run this using RapiConfig.exe: <wap-provisioningdoc> <characteristic type="FileOperation"> <!-- Delete Shortcut --> <characteristic type="%CE11%\SMS Intercept.lnk" translation="install"> <characteristic type="Delete"> <parm name="ForceDelete"/> </characteristic> </characteristic> <!-- Copy EXE name to new EXE --> <characteristic type="%CE1%\sms Intercept\sms Intercept1.exe" translation="install"> <characteristic type="Copy"> <parm name="Source" value="%CE1%\sms Intercept\sms Intercept.exe" translation="install"/> </characteristic> </characteristic> <!-- Create new shortcut pointing to new EXE name --> <characteristic type="%CE11%" translation="install"> <characteristic type="MakeDir" /> <characteristic type="SMS Intercept.lnk" translation="install"> <characteristic type="Shortcut"> <parm name="Source" value="%CE1%\sms Intercept\sms Intercept1.exe" translation="install" /> </characteristic> </characteristic> </characteristic> </characteristic> </wap-provisioningdoc> Conclusion You should now understand how to configure your CAB file projects to include PNG files as icons in the Windows Mobile 6.5 Start screen. Share this post :

App-V 4.6 Beta Released

Our friends over in the MDOP team just released the beta version of the Microsoft Application Virtualization (App-V) 4.6 today. We know that many of you are looking at application virtualization in both the context of your existing environment and also as part of your migration planning to Windows 7. Besides some enhancements to the sequencer to simplify the workflow for creating virtual application the team has added the ability to sequence 64 bit applications. As 64 bit computing becomes more common place in the Enterprise this first to market feature removes another challenge in your planning and rollout strategies. Customers who want to get familiar App-V 4.6 Beta can register and download via Microsoft Connect. As always, we want to hear from you. We build great products by including feedback from our customers, so go ahead, test App-V 4.6 and give us feedback via Connect. For customers who are currently using App-V 4.5 CU1 with their 32-bit Windows 7 systems, we will release an update to the 4.5 version of the product. App-V 4.5 SP1 will be available within 90 days of Windows 7 general availability and provide full support for running App-V 4.5 and Windows 7 (32-bit) in production. Enjoy! For more information head over to the MDOP teams blog post here.

Early Adopter, Baker Tilly, Completes Windows 7 Deployment

As weve been saying for a while, we continue hearing feedback from our customers that they are excited to test and deploy Windows 7. Baker Tilly, an accountancy firm in the UK, has taken this to the next level and has already completed deploying Windows 7 across their infrastructure. I chatted with Simon Harding-Rolls, Director of IT at Baker Tilly, to get more information on their Windows 7 deployment. Rich Reynolds: What operating system was Baker Tilly using before their Windows 7 deployment? Simon Harding-Rolls: Windows XP. This formed the basis of what we called "Standard Build 4" which was deployed to all desktops and laptops used throughout the firm. We have a policy to standardise and commoditise the provision of IT as much as possible hence the imaginatively named "Standard Build." Rich Reynolds: Why did Baker Tilly choose to deploy Windows 7? Simon Harding-Rolls: We needed to change, feeling that there was little more business benefit we could squeeze out of XP. After evaluating the beta versions of Windows 7 we found it to be robust, compatible with the vast majority of our applications and delivering greater performance. This was the platform we needed for (an also imaginatively named) "Standard Build 5." Rich Reynolds: How many seats of Windows 7 did you deploy? Simon Harding-Rolls: We have deployed to 2,318 seats over some 30 sites. Rich Reynolds: When did you complete your deployment? Simon Harding-Rolls: Deployment was organised by site with the last being "hit" on 17th July. Rich Reynolds: What version of Windows 7 are you running? Assuming youre using Windows 7 RC, when will you upgrade to the final version of Windows 7? Simon Harding-Rolls: We have based our "Standard Build 5" on the Enterprise Edition of Windows 7 and deployed using build number 7201. This contains a number of improvements on the standard RC and was released just in time for us to deploy - but only just! A little midnight oil was required to assimilate it into our build and complete our regression testing. We plan to deploy the final version of Windows 7 during November at the same time we are rolling out Windows Server 2008 R2. Rich Reynolds: How long did it take you to deploy Windows 7? Simon Harding-Rolls: We deployed the system to the first site on 22nd June, so the whole task took exactly four weeks. All the work was done outside of normal office hours so as to minimise the disruption to our users. About three hours of evening effort was required for a site of about 100 users. Rich Reynolds: I believe Baker Tilly has a strong partnership with Dell; how did this partnership enhance your Windows 7 deployment experience? Simon Harding-Rolls: Our relationship with Dell was absolutely crucial in that it gave us access to the technical resources and knowledge we needed to ensure the project's success. Rich Reynolds: What steps did you take before deploying Windows 7? Any application compatibility testing? Did you have an IT Solutions provider help outline your deployment process? Simon Harding-Rolls: Preparation started in February and involved detailed planning, prioritising which benefits we were attempting to realise for our users, developing test builds, deploying these to a selection of users representative of the different disciplines within the firm as well as our own formal testing. Application testing started early by completing the tests and developing regression test plans under Vista. These were then ported to the release candidate when it became available. We have a long tradition of "self sufficiency" and therefore did not employ an "IT Solutions Provider. Rich Reynolds: Did you use any tools to help deploy Windows 7 across your infrastructure? Simon Harding-Rolls: CA's Unicenter, which we have used for many years. Rich Reynolds: Did you encounter any issues with your Windows 7 deployment? How did you overcome them? Simon Harding-Rolls: We didn't hit any significant issues during the deployment itself. This was almost entirely down to the amount of testing we had performed prior to pressing the "green button. Prior to the deployment there were, as you would expect, a number of issues particularly with the early builds of Windows 7: functionality not behaving quite as expected and some application compatibility issues. The former were overcome with assistance from Dell and Microsoft and the latter issues have mostly been resolved in more recent builds of Windows 7. Where this has not proved possible in the time allowed, we have deployed Terminal Server based solutions as a temporary measure to cover a couple of apps whilst the suppliers are making their software fully compatible. Rich Reynolds: What benefits are you expecting from Windows 7? Cost savings? Energy efficiencies? Simon Harding-Rolls: While there will be cost and energy savings, these are not our prime drivers. Windows 7 delivers greater performance and flexibility to our users. That means they can do more, wherever and whenever is most appropriate to meet the needs of our clients. Rich Reynolds: Have you seen any benefits from your Windows 7 deployment already? Simon Harding-Rolls: Thus far we have received over 300 emails from users. Over 70% have mentioned improved performance. That's without any prompting! Rich Reynolds: Are there specific features you expect may save your company money? Simon Harding-Rolls: We will be deploying DirectAccess, BitLocker and BranchCache later this year. Again, rather than pure cost saving, we will be looking to maximise the performance and flexibility of the system for our users enabling them to be more responsive to our clients' needs. Rich Reynolds: What is your favourite Windows 7 feature? Simon Harding-Rolls: As a partner: more productive members of staff. As Director of IT: a system that is manageable. As a user: I just love the uncluttered task bar! Rich Reynolds: Are you using Windows Server 2008 or planning to migrate to Windows Server 2008 R2? Simon Harding-Rolls: We are currently using both 2008 and 2008 R2 for specific production tasks. We plan to standardise our estate on R2 with the migration projects currently in development / testing with deployment planned for November. Rich Reynolds: Are you using Internet Explorer 8? Simon Harding-Rolls: Yes - and the users love it, both for its speed and tabbed browsing. Rich Reynolds: What advice would you give to another corporation looking to move to Windows 7? Simon Harding-Rolls: I'd love to say "go for it, but every corporation's needs will be different as will their resources. For us, having seen the results of our initial evaluation, the decision was a no-brainer. In our case, programme and project risk was identified as coming from the scale of the enterprise and NOT from the fact that we were deploying new or "bleeding edge" technology. If you do "go for it, at the risk of stating the obvious: plan, develop, test, test again and DONT take steps that are too big its just like climbing Everest really! Rich Reynolds: Thanks for your time, Simon! To the other Windows 7 early adopters out there: leave a comment and let us know how youre deployment is going. We love hearing from you and would be happy to share your story.

Windows 7 Taskbar Dynamic Overlay Icons and Progress Bars

We covered the basics of the Windows 7 Taskbar in Developing for the Windows 7 Taskbar Application ID, and how you can create a Jump List for your application in Developing for the Windows 7 Taskbar Jump into Jump Lists Part 1, Part 2, and Part 3). In this post, we will explore how you can leverage the cool Taskbar functionality of dynamic overlay icons and multi-state progress bars. A central Windows 7 tenet is that the "User Is in Control"; that is, we empower users to take ownership of their desktop looks and functionality. From little things, like allowing users to arrange their Taskbar icons as they see fit, to enabling users to control the number of icons on the Taskbar. Windows 7 removed the System Tray Icon area. By default, almost all the tray icons are concealed. Consequently, it is safe to assume that large number of the notification balloons will also not be visible and most users will not see them. You can read more about the updates to the Notification Area here. To compensate for this lack of notification, Windows 7 Taskbar offers Overlay Icons and Progress Bars. By using overlay icons and progress bars, your application can provide contextual status information to the user in spite of the lack of a System Tray Icon area and even if the applications window does not display. The user doesnt even have to look at the thumbnail or the live preview of your app the Taskbar button itself can reveal whether you have any interesting status updates. This functionality is part of our commitment to provide users with easily accessible information about an application's status without any extra clicking. Overlay Icons The ITaskbarList4 interface, specifically its SetOverlayIcon function, exposes the native overlay functionality. The function takes a window handle, an icon handle, and optional description text, as you can see in the following code snippet. HICON hIcon = NULL; // for IDM_OVERLAY_CLEAR hIcon = LoadIcon(g_hInstance, MAKEINTRESOURCE(IDI_OVERLAY1)); // Set the window's overlay icon, possibly NULL value g_pTaskbarList->SetOverlayIcon(hWnd, hIcon, NULL); if (hIcon) { // need to clean up the icon as we no longer need it DestroyIcon(hIcon); } Make sure you obtain ITaskbarList3 *g_pTaskbarList = NULL;as we did before, and CoCreate it: CoCreateInstance( CLSID_TaskbarList, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&g_pTaskbarList)); When running the above code in the proper context (you can download the application) the result looks like the following pictures. On the left, you see the application without any overlay icons, and on the right you can see the application with a red icon overlay. The managed wrapper for this feature resides in the Taskbar class that is part of the Windows API Code Pack for the .NET Framework. All that you need to do is use the OverlayImage property (Taskbar.OverlayImage). Simply call: Taskbar.OverlayImage = new OverlayImage(TaskbarDemo.Properties.Resources.Red, "Red"); Doing so allows you to provide an OverlayImage for the taskbar button. The TaskbarDemo project is a WinForms demo, and you can find the above code in the TaskbarDemoMainForm.cs. Its equally easy to provide an extension method that does this to a WPF Window. Note that the only thing that you need to do is get the right icon, which is easy using .NET resources. Progress Bars If you already use a standard progress bar in your applications top level window, the DMW will pick it up and, by default, display its progress as an overlay on top of your application. However, you can programmatically control the progress bar behavior on your applications icon. The native functionality is again found in the ITaskbarList3 interface, this time in the SetProgressState and SetProgressValue functions. The functions are quite self-explanatory. You can set the progress bars state (SetProgressState) to, for example, indeterminate or error, and use SetProgressValue to set the progress value. The following code snippet illustrates how to use these functions: case WM_TIMER: g_nProgress++; if (g_nProgress == 1) { // First time through, so we'll set our progress state // to be indeterminate - this simulates a background // computation to figure out how much progress we'll need. g_pTaskbarList->SetProgressState(hWnd, TBPF_INDETERMINATE); } else if (g_nProgress == MAX_PROGRESS_IND) { // Now set the progress state to indicate we have some // normal progress to show. g_pTaskbarList->SetProgressValue(hWnd, 0, MAX_PROGRESS_NORMAL); g_pTaskbarList->SetProgressState(hWnd, TBPF_NORMAL); } else if (g_nProgress > MAX_PROGRESS_IND) { if (g_nProgress - MAX_PROGRESS_IND <= MAX_PROGRESS_NORMAL) { // Now show normal progress to simulate a background // operation g_pTaskbarList->SetProgressValue( hWnd, g_nProgress - MAX_PROGRESS_IND, MAX_PROGRESS_NORMAL); } else { // Progress is done, stop the timer and reset progress // state KillTimer(hWnd, g_nTimerId); g_nTimerId = 0; g_pTaskbarList->SetProgressState(hWnd, TBPF_NOPROGRESS); MessageBox(hWnd, L"Done!", L"Progress Complete", MB_OK); } } break; Note that on the first timer tick, we set the progress bar to TBPF_INDETERMINATE, and only after that did we set it to TBPF_NORMAL, which set the progress indicator to grow in size from left to right in proportion to the estimated amount of the operation completed. For managed code, we use the Windows Code Pack API. Much like the native progress bar, the managed code Taskbar class includes a progress bar property (it is in its own a class), which allows you to set current value, max value, and statethe progress bar state. The progress bar states (found in the TaskbarButtonProgressState class) are: NoProgress equal to the TBPF_NOPROGRESS native state Indeterminate equal to the TBPF_INDETERMINATE native state Normal equal to the TBPF_NORMAL native state Error equal to the TBPF_ERROR native state Paused equal to the TBPF_PAUSED native state You can find a WinForms demo in the TaskbarDemo project and in the TaskbarDemoMainForm.cs, you can find the UpdateProgressBar function that is called by a timer to update the progress bar. Taskbar.ProgressBar.State = (TaskbarButtonProgressState)Enum.Parse( typeof(TaskbarButtonProgressState), (string)comboBoxProgressBarStates.SelectedItem); if (Taskbar.ProgressBar.State != TaskbarButtonProgressState.Indeterminate) Taskbar.ProgressBar.CurrentValue = progressBar1.Value; As you can see, the code enables you to choose the state of the progress bar. Changing it to the error state turns the color of the progress bar on the Taskbar Icon to red. The icing on the Taskbar progress bar "cake" is that you get this functionality FOR FREE if you use the standard progress dialog for file operations. (As we advance in this series, youll see that you get lots of functionality for free if you follow the standard guidelines of Windows programming.) For example, if you invoke a file operation using the SHFileOperation API or IFileOperation interface, the Taskbar button progress bar automatically displays the progress information (including errors) of that operation. This is what Windows Explorer does with great success. Original post from Sasha Goldstein

Ready to Port your iPhone App to Windows Mobile?

Hello, my name is Constanze Roman and Im a Community PM with the Windows Mobile Community Team. If youve been curious about porting an iPhone app to the Windows Mobile platform, then I have exciting news for you! We have just published a new technical article on MSDN titled Porting the Amplitude Application from the iPhone to a Windows Mobile Device a Case Study which outlines the real-world experiences of a developer who ported the popular Amplitude application. Amplitude picks up any sound in a users surroundings through the microphone and then amplifies the sound, rendering it into a rich graphical representation on the device. Amplitude can be used to amplify any sounds, such as human or animal heartbeats, that usually wouldnt be picked up by the human ear. Amplitude provides a cool user interface featuring an oscilloscope that allows users to view and visually quantify, signal voltages, as you can see the volume of the sound that you are listening to. Amplitude is well suited for a porting project because it combines a rich user interface with features such as alpha blending and transparency with specific audio and sound requirements, which makes it challenging to port the app but, at the same time, provides a number of helpful learning experiences. Luke Thompson, a software developer with Gripwire.com, a Seattle-based mobile and social application development company, took on the challenge to find out what it takes to port the iPhone version of Amplitude to a Windows phone. The case study now published on MSDN outlines Thompsons experience, and provides some key takeaways for developers who want to get into the porting business. Thompsons account of his porting experience is especially interesting because it outlines the Community resources he has used to get the information he needs. In his conclusion, Thompson credits the Windows Mobile Developer Community for helping him resolve the issues he encountered along the road, stating that: The large development community, both within Microsoft and outside, and the various whitepapers, blogs, virtual labs, websites, and other online documentation, offered a wealth of information that provided direction and greatly facilitated problem resolution. The only real challenge was assuring total portability between screens, and that was assured by utilizing the concept of aspect ratios. Although Thompson did encounter some roadblocks while porting the Amplitude app to Windows Mobile, he was able to successfully resolve all issues and get the application to work on a HTC Touch Pro phone that runs on a build of the Windows Mobile 6.5 operating system. One of Thompsons main takeaways was that the Visual Studio 2008 Development Environment really made a difference for him because it provided most of what he needed at one place, such as the security certificates (certs.cab) for installing the application on your device. Thompson noted that the MSDN Virtual Labs were especially helpful in getting him started with the development process. When porting the app from the iPhone to Windows Mobile, Thompson had to pay attention to major differences in the OS, such as the fact that the iPhone does not support running applications in the background, while background operation is a requirement for all Windows Mobile applications. Adjusting the screen orientation as well as accommodating phones with keyboards was another area which required additional investigation, which led Thompson to MSDN, which ended up providing a workable solution. Porting the UI posed some challenges, especially since the UI for the Amplitude app on the iPhone makes use of transparencies and alpha blending. Since some of these functionalities are not available in the .NET Compact Framework, Thompson had to look for community resources to find the information he needed to complete this task. When searching for a resource, Thompson discovered the UI Framework, which is posted on Code Gallery and turned out to be a major asset for Thompsons porting efforts. Thompson depended on community content as well to help him port the audio and sound features of the Amplitude app to Windows Mobile. The Code Project turned out to be especially helpful for Thompson efforts, as he found an article that explained how to create a framework for implementing audio effects in C#. Thompsons case study shows, that even though there are some challenges in porting a multimedia-rich application from the iPhone to Windows Mobile, the task can be accomplished, especially with the help of developer-friendly tools like Visual Studio, the richness of community content that is available for Windows Mobile, and last but not least by planning the project ahead and doing all the necessary research in advance. Thompsons experience should save you time as you port your own applications to Windows Mobile. With Windows Marketplace for Mobile getting ready to open its doors to millions of potential new customers, the opportunity is compelling.

Windows Mobile Developer Camps

Hello, my name is Loke Uei Tan and I am the Senior Technical Product Manager for the Mobile Developer Experience (DEX) team at Microsoft. I blog regularly on MSDN, and will also post on this team blog from time to time. You can also connect with me on Twitter @wmdev and @lokeuei. Given our strong commitment to the developer community, we're excited to announce the first in a series of barcamp-style events for Windows Mobile 6.5! WinMoDevCamp is a series of not-for-profit gatherings to develop applications for the upcoming release of the Microsoft Windows Mobile 6.5 OS. Our first Windows Mobile Developer Camp event is scheduled for August 19th in Redmond, Washington at the Microsoft Campus Conference Center. The event is also being planned in at least 5 additional cities around the world: Austin, London, New York, San Francisco, and Singapore. We also encourage our extended mobile developer community to host events in the cities that we will not be visiting this time. The http://winmodevcamp.org website will soon have facilities for you to organize events. Dates: Our first event will be held on 8/19 Venue: Microsoft Campus in Redmond, Washington at the Cascade Auditorium Check back at the WinMoDevCamp Web site for updated event information.

Windows Mobile MSDN Blog Archives

As of today the Windows Mobile Blog has officially joined The Windows Blog. Not only have our bloggers made the transition, but much of the high impact content has been brought forward for your convenience. SDK, DTK, DRK: WTF?! | MSDN Windows Mobile RampUp Track Is Now Available On MSDN | MSDN Carry Your Office in Your Pocket #1 | MSDN Windows Mobile Facebook Application Update | MSDN Microsoft Tag Update | MSDN Resolving Common Crashes Seen in Windows Mobile Watson Data | MSDN Samsung’s Web Site for Windows Mobile Developers | MSDN developer.windowsmobile.com | MSDN Windows® Marketplace for Mobile Developer Strategy Announced! | MSDN DreamSpark for Students | MSDN Introducing Windows® Marketplace for Mobile… | MSDN Microsoft My Phone | MSDN Mobile Manager for Netflix | MSDN Microsoft Tag | MSDN Developing Location Aware Applications for Windows Mobile | MSDN New Version of Live Search Mobile | MSDN Survey of Web Browsers for Windows Mobile | MSDN Windows Mobile Development Forum | MSDN Press, Click, Select, or Choose?!? | MSDN

7 Ways to Get Free Tickets to PDC 2009 Plus up to $17,777

Do you want to win a free trip to Los Angeles and a free ticket to PDC 2009? Do you think you have what it takes to win $17,777? Do you think you can write an amazing Windows 7 application? Well, if your answer to any of the above question is "Yes!" then say hello to the Code7 Contest. The Code7 contest is where your application design ingenuity gives you the opportunity to get millions of eyes on your work, plus a trip to LA for PDC09, and up to $17,777 in cash! Code7 is a special coding contest for developers. It is a great opportunity to show the world your creativity and coding powers. It is a way for you to cash in on your knowledge and skills. This is not just another standard code contest; this contest gives the finalists the opportunity to present their application at PDC 2009 in LA. The first prize is a real gem: $17,777 in cash, the opportunity to present the application to Microsoft executives at PDC 2009, plus worldwide interest in your application including a massive marketing bump for your application. To enter, you must: Build an original, consumer-oriented client application prototype that runs natively on Windows 7 (for example Win32, WPF, MFC or WinForms not an Air application or just a gadget) and addresses one or more of the following topic categories: Simplify My Life More Media, More Places Gaming Work From Anywhere Safeguard Your Work Applications for a Better Tomorrow The application must use at least one of the following Windows 7 technology features; however, judging will give more weight to entries that take advantage of more than one of these features: Libraries Windows Touch Shell Integration DX11 (DirectX 11) Sensor and Location Platform So if you have being following my blog you have some advantage. The contest has several stages and few rules you need to be aware of: To enter this contest you must create and submit a video in which you describe and demonstrate your application. The first qualifying round starts at 12:00 a.m. Pacific Time (PT) on July 13, 2009, and ends at 11:59 p.m. PT on October 10, 2009 (Entry Period). You will be able to able to submit your video until midnight October 10, 2009. Your entry will be included in a pool with all eligible entries based on your geographical region. Entries received by 11:59 p.m. PT on August 15, 2009, will be eligible to win an Early Bird prize described in the Winner Determination section below. Following the close of the first qualifications, a panel of judges will select two runner-up winners and one Finalist from each Region. Following judging, Microsoft will notify all winners and finalists and provide instructions for submitting their applications for evaluation. Finalists will be invited to present their applications to a panel of judges at the Microsoft Partner Developer Conference 2009 (PDC09) in Los Angeles, CA, USA. For the complete contest rules and legal notice, please refer to the RULES section on the Code7 Contest Web site - https://www.code7contest.com/. So, what are you waiting for? Get going and start working on your Windows 7 application!

Expression Encoder 3 Announced, Comes with Built-in Screen Capture

---

Today the Expression Encoder Team has announced Expression Encoder 3. Expression Encoder 3 is part of the upcoming Expression Studio 3 suite and comes packed with new features such as support for H.264 and the new Smooth Streaming technology.

And it also brings another super cool feature: Screen Capture.

Today, screen-casting has become quite popular with bloggers. Screen-casting allows bloggers to share what they are looking at on their PC screen with readers of their blog. Its a great way to show off really neat software experiences that people should see for themselves.

With Expression Encoder 3, they are introducing the Expression Encoder Screen Capture feature. This feature can be launched right from the Start Menu (Ive pinned it to my Taskbar in Windows 7). People can choose a specific region of their screen they want to record (or the whole screen) and choose to record audio from their microphone and video from their webcam too. It records in a special light weight codec developed by Microsoft Research that when recording video, it doesnt use up so much system resources during the capture process. That means the actual recording process doesnt steal so much system resources on your PC that what youre recording doesnt look so hot. After recording, you can import the capture into Expression Encoder for final encoding and publishing (including some awesome new Silverlight templates).

Ive been trying this feature out for the last couple days and it is fantastic. I am definitely planning to do a lot more screen-capture videos with Windows 7 features.

Speaking of Windows 7 features, Expression Encoder utilizes the new Windows Taskbar in Windows 7 with encoding progress being displayed. The first encoding pass appears in yellow, and the second pass appears as green. Pretty slick!

Encoding First Pass:

Encoding Second Pass:
 

(Screenshots from Expression Encoder Team Blog)

For availability of Expression Encoder 3, keep your eyes on the Silverlight Team Blog for the official Expression Studio 3 announcement. Oh, and you should also check out

For more information on Expression Encoder 3 and the Expression Encoder Screen Capture feature, click here to read the Expression Encoder Teams blog post.

Real Problems in Software Development Life Cycle

You may already know that software doesn't just appear on the shelves by magic. If you run a software development company or you are one of employees you already face the problems of software development cycle. That is a product process which start from scratch and continuously change until the real product (confirmed by the stakeholders, customers and clients) arises from middle managers and programmers sweat and night work. Here, shared with you to the general public, are the inside details of the software development cycle, which as you can see is not easy thing to be done. Initial functional requirements and design are done. Programmer produces code he believes is bug-free. Product is tested. 20 bugs are found. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs. Testing department finds that five of the fixes didn't work and discovers 15 new bugs. See 3. See 4. See 5. See 6. See 7. See 8. Due to marketing pressure and an extremely pre-mature product announcement based on overly-optimistic programming schedule, the product is released. Users find 137 new bugs. Original programmer, having cashed his royalty check, is nowhere to be found. Newly-assembled programming team fixes almost all of the 137 bugs, but introduces 456 new ones. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs. New CEO is brought in by board of directors. He hires programmer to redo program from scratch. Programmer produces code he believes is bug-free....

The power of Sorting Algorithms examples in Java

If you are programmer, especialy Java programmer, and you need to implement some of known sorting algorithms in you code, following link can be very helpful. Site I recommend will offer to you one of the cleanest implementations I have found on the net of sorting algorithms codes and their visualization on-line. Here you can find clean Java code examples of The "generic" sorting algorithm, The BozoSort Algorithm, The PermSort Algorithm, The StoogeSort Algorithm, The QMSort Algorithm, The BubbleSort Algorithm, The SelectionSort Algorithm, The CocktailSort Algorithm, The InsertionSort Algorithm, The ShakerSort Algorithm, The ShakerSort 2 Algorithm, The ShellSort Algorithm, The QSort Algorithm, The HeapSort Algorithm, The JSort Algorithm, The MergeSort Algorithm. In the page you can also visually notice the speed of different types of sorting algorithms which can be used in your code. Personally I am a fan of quick sort (QSort) which in some situation can be the fastest algorithm ever. To feel the power of sort algorithm, the power of java code, and much more dramatic demonstration of algorithms click on this link: http://cg.scs.carleton.ca/~morin/misc/sortalg/!