Microsoft's uphill battle in the public perception of Windows 8

If you haven't been living under a rock for the past 6 months you would know that Microsoft recently released a new operating system. Windows 8 came out nearly 3 years after Windows 7 and brings with it a massive overhaul in how users interact with their PC. The change, formerly called "Metro", essentially layers a touch-designed interface and tablet-style application model as part of the core Windows 8 experience. This design has had its naysayers.

This OS has been called the "Vista" of its generation. Many people consider Microsoft to be under a "tick tock" style of OS design. For every bad tick, there is a good "tock". They see this as the following:

• Win98 = Good
• WinMe = Bad
• WinXP = Good
• Win Vista = Bad
• Win 7 = Good
• Win 8 = Bad!!!

Never mind the fact that Microsoft had the NT-style OS' in use early on with Win98 and Me, NT4 and Windows 2000. And many of these users have been latching on to any straw they can to validate their fears of the OS. Perhaps one of the most interesting complaints is the lack of the once-beloved "Start Menu".

The Start Menu, introduced in Windows 95, at the time was designed as a gateway to your applications. The design of which was very different from Microsoft's previously released "Program Manager". Under the Program Manager environment, which existed in Windows 3.1; applications would "minimize" to icons on the desktop behind the core Program Manager window. Program Manager itself had little folder icons, grouped together, such as "Accessories", "Games", which you would double click to open and find your applications. For Windows 95, all of this functionality had been moved to the "Taskbar and Start Menu". The folders became folders in the Start Menu list, and running applications would display in the Taskbar.

Even this change was not well-received amongst the computing world of the time. Unfortunately, I cannot find the recent blog post by Raymond at Microsoft on "The Old New Thing" which detailed this hate affair with the Start Menu at its introduction.

Moving forward to Windows 8, the "Start Menu" as we once knew it is gone. In its stead remains the Start Screen, which provides a touch-friendly interface to your applications. Applications that formerly installed icons to the Start Menu will now install them to the Start Screen. And applications downloaded from the Windows Store will also display as "Live Tiles" on this same screen.

The perception of Windows 8 has also not been helped by the views of people whom are considered to be industry leaders in the enthusiast and gaming community. Mojang's own Notch (Markus Perrson), creator of Minecraft, tweeted his concerns about the operating system when Microsoft approached him to bring Minecraft to the forefront of the platform.

Even Valve's own Gabe Newell has slammed Microsoft's decision to release Windows 8 with its own Windows Store.

Most people fail to understand one thing about Gabe's opposition. His opposition has nothing to do with the "closed" nature of the Windows Store, but rather that it is a direct competitor to Valve's Steam delivery system. Interestingly, even I consider his fears to be unfounded. The Windows Store, while bringing a basic application delivery system to the Windows platform (something that has long existed in other OS', with the iTunes store in iOS and OSX, the Google Play Store with Android), is not quite a drop-in replacement for Steam. For example, the Steam overlay system provides an extremely convenient way for you to communicate with your friends that are not playing the game with you. Steam itself also has tight integration with its games for network play, where you can invite your friends to jump into the game with you through Steam. While Microsoft has similar functionality with the Xbox platform, they've had a decade to integrate this into Windows in a usable manner and they have shown they seemingly have no interest to do so.

The Good Things About Windows 8

Having used Windows 8 now for a number of months on my primary desktop and gaming laptop machines, I have personally come to the conclusion that the Start Screen isn't really as big of a deal as most people make it out to be. I click on the Desktop icon, and I'm now using the Windows desktop as I have always done so. I hadn't used the Start Menu since Windows XP came out with Quick Launch, of which I was a heavy user, so it never really bothered me to see it go away. The desktop operates pretty much the same it always has for years.

However, when I purchased my Surface Pro tablet (which I am using to write this post!), I have come to navigate Windows 8 in a very different manner than I do on the desktop. I make heavy use of the Start Screen and the "Metro" applications. I have become extremely fond of the Bing News app, I use the Mail App regularly, and I shift to the desktop only to run desktop-oriented applications. I have become a HUGE fan of the swiping functionality. I commonly cycle between my applications with a flick of a finger on the left edge of the screen. I push buttons with my fingers on websites. I tap between my conversations in the people app. I search the web and all of my applications with the awesome Search function on the Charm Menu. (To bring up Charms, put the mouse cursor in the bottom right corner and move it upwards; or on touch, simply swipe on the right edge)

The security model of Windows 8 has been improved dramatically. And while I won't go into it on this blog, this PDF (it's legit, I swear! but update your Adobe Reader anyway) into the impressive internal improvements. While no security is 100% perfect, it is nice to see the defensive strategies continue to evolve.

After seeing the Surface Pro devices that myself and a coworker recently purchased, our colleagues at work have now decided they want one. We are also in the process of validating Windows 8 for our secure environment with our IT staff.

More Deployment Tidbits!

One of the other challenges that IT Administrators face is that there are many applications out there that do not conform to operating system standards when being installed. This lack of conformity is usually the result of a few things:

• The cost of 'doing it right' is too high for most development teams. People who know the underlying operating system cost more than your average code monkey. Most development processes (such as AGILE) encourage functionality and features over sound application design.
• Developer ego. "I know better than Microsoft." "The registry sucks!"

As a great example, Java and Firefox do not lend themselves well to corporate deployment and management. Java, for example, uses a configuration file that is searched for under C:\Windows\Sun\. Not every option in the Java Control Panel is configurable through these configuration files, either.

So to you, I present the following guide:

• Use the registry, religiously. I don't care if you think you're better than Microsoft. If you don't want to write a Windows application, then don't create one. But when you write for the Windows environment, USE THE REGISTRY. You wouldn't use $HOME/ to store application-level (system-wide) configurations in Linux, why would you not use Microsoft's conventions?
• In Windows (Vista and above), system-wide application configuration and log files should go in C:\ProgramData\YourApplication. This location becomes your scratch space, and most importantly, C:\ProgramData is a high integrity location, which means it can only be accessed by users who are Administrators. (However, your subfolder is RW to your application).
• HKEY_LOCAL_MACHINE\SOFTWARE is the place to store your application's system-wide preferences.
• HKEY_CURRENT_USER\SOFTWARE is where you store configuration for the user installing the tool.
• %USERPROFILE%\AppData\ is where you store user-specific things such as user-specific logs, user-specific downloads, and so forth.
• %USERPROFILE%\AppData\Roaming is what you use if you wish to allow these things to be replicated with Windows Roaming User Profiles.
• %USERPROFILE%\AppData\Local is the location you use when you do not wish for your application's data to be replicated, or it's not necessary to be replicated. For example, user-specific log data might not need to be replicated from machine to machine.
• %USERPROFILE%\AppData\LocalLow is the location to be used when you run your application with a low integrity level (read: reduced system privilege). I encourage you to build your applications to run in this mode.

Java Deployment Woes

With the recent back-to-back, off-hours, and off-schedule security updates from Oracle and Adobe, Systems Administrators have never before been more in a bind than they are today with needing centralized software management tools in their environment.

Us IT Administrators have significant challenges to address with the ever evolving Information Security landscape which will require a regular security maintenance plan. Some of these challenges are inherent to the operating systems, some are also inherent to the applications that are used day-to-day.

I have searched online for answers to my questions with regards to Java deployment and have usually turned up empty-handed. Java itself has the following challenges:

• It does not like being deployed in-use. The JRE Executable installer forces you to close all applications that have Java loaded before it will let you continue with the upgrade.
• Many different applications often come with their own versions of Java installers. For example, some applications include JRE 5.0, and now your systems may potentially be vulnerable to attack. (Eclipse IDE come to mind, and any web application built on Tomcat).
• Java Auto Updater can cause deployment challenges for centralized administration tools. For example, the Dell KACE management appliance uses "Assignments" for application installs. If you "Assign" Java 6u39 (Java 1.6.0.39), and someone updates to Java 6u41; Kace will attempt to reinstall the earlier version.
• We have political battles with users who will often ignore the Java Update utility and leave the icon sitting in their task tray. We have a class of users who protest up the management chain every time IT does a deployment of Java, swearing that their particular application cannot be upgraded.
• The Java Executable installer does not allow for ALL of the MSIEXEC properties to be specified on the command line.
• Leveraging MSI for Java is an 'afterthought' to Oracle, who provides specific instructions to dig within your Application Data folder after launching the EXE to find the extracted MSI and CAB files.

So how do we address these issues? There are a few different answers with different solutions.

• You can deploy at startup. The challenge here is that with the ever increasing "BYOD" style devices and ultra mobility, network connections are often not made until after the user has logged in to the machine. In this manner, application installs will not work from most centralized tools because they require this connectivity to download and execute their installers.
• Microsoft, as an OS vendor, should encourage and enforce developers to use all of the platform's tools. MSI installers should be the rule, not the exception, for all Windows applications.
• Changes should be made to the underlying OS to allow for upgrade-in-place of applications.
• Microsoft should encourage developers to use their "Update" process that exists in Windows (You know, the one that says PLEASE DO NOT SHUT OFF YOUR COMPUTER while it installs updates). Interfacing with this functionality should be encouraged at both an IT and Developer level.

In the mean time, one of the tricks I have used for deployment is the following:

• Download the Windows SDK to obtain a utility called Orca. Orca will allow you to modify the MSI file properties and save MST (Transform) files to use for installation.
• Within your MST, set JAVAUPDATE=0, AUTOUPDATE=0,MOZILLA=1,IEXPLORER=1.
• Deploy at bootup, login, or prompt users to close applications using the Java Runtime.
• msiexec.exe /qn /i "jre_installer.msi" TRANSFORMS="mytransform.mst"