Shedding Some Light

My copy of MSDN Magazine arrived in today’s mail. As I do when it arrives, I browse through the pages looking for interesting articles to read. Normally what I read is interesting information about things in .NET that people on my team throw around during team gatherings, and I see presented at user groups and conferences.

But today I read two thought provoking articles discussing Visual Basic 6, which was released in 1998 and off Microsoft’s extended support in 2008. Not exactly what I would call cutting edge material.

• Don’t Get Me Started, by David S Platt
• Old Soldiers Never Die, editorial by Michael Desmond

The articles discuss how in January Microsoft extended “It Just Works” compatibility and support of VB6 applications through the full lifetime of Windows 8. This means the VB6 core runtimes are getting 5 more years of mainstream support followed with 5 more years of extended support into 2022 (a total of 10 years of Windows 8). Note: the VB6 IDE is not supported, just the runtimes. Still, this has an super important impact on VB6 developers who can talk to their customers and assure them that Microsoft is backing the investment in applications their customers have come to depend on. Platt even speculates: “I’ll bet you a beer that Microsoft has to extend Visual Basic 6 support through Windows 9 and 10.”

Here is a link for all the details on “It Just Works” for Visual Basic 6.

So let’s look at a simple timeline comparison here:

• The last release of VB6 was in 1998, and extended support ended in 2008.
• The last release of VFP 9 SP2 was October 2007, and extended support goes through January 2015.

The theme of the two articles is that VB6 apps continue to thrive in the business world, and in governments, and they are likely to thrive for a long time to come. Sounds familiar. Visual FoxPro applications are doing the same in both sectors, and in non-profits. Not every business can just afford to stop and rewrite their mission critical apps. Some applications do not support a business model for a rewrite. Just because Microsoft decides they no longer support development platforms and runtimes does not mean business does not continue as is.

One thing that made me chuckle is in Desmond’s article as he cites Platt, “Platt says he sees “pockets” of support on the Internet for Borland Delphi, Microsoft FoxPro, and Sybase PowerBuilder.” Pockets. Funny.

I want to be clear on one point. I don’t think this is important from the technical side of things as the testing I have done is not revealing any issues on Windows 8. Visual FoxPro applications I have tested are working fine on the Windows 8 Consumer Preview release from earlier this year. I have not tested on the Windows 8 Release Preview released this week. This is purely a marketing issue so Visual FoxPro developers can reassure their customers that Microsoft cares about their software, AND allows them to upgrade to Windows 8 if they choose to do so. Assurance equals new revenue for Microsoft. It also might help stem the tide of choosing alternative non-Microsoft platforms when it comes to the v.Next rewrite of the existing business software.

So Microsoft, I ask – How do the Visual FoxPro runtimes get “It Just Works” support extended through the life of Windows 8? I am certain this would be helpful to the customers who have come to depend on their software just as much as the software created in VB6, and Visual FoxPro has been supported longer.

Or am I wrong?

Before you read this, I want you to know I really have been interested in Windows 8 and thought Microsoft was showing some serious chutzpah by messing with the Windows bread and butter revenue generator. I find it an interesting exercise to bring one OS to the three major computing platforms. In general I don’t think the Metro UI really works for business desktops. I also believe the tablet and phone OS are used differently than a desktop and laptop machine so they should be different. Still I do not want to discount it completely without trying it. I went into this with a completely open mind, and even after venting some complaints below, I feel Windows 8 has some interesting aspects.

I recently installed Windows 8 on a spare netbook computer. Nothing fancy, but up until a couple of months ago this was my wife’s primary computer running Windows 7 Ultimate (upgraded from the initial Starter edition). I am mostly interested in seeing if some legacy apps still run on the Windows 8, but it is a good opportunity to kick the tires on the new operating system.

I have already run into my first problem. It apparently is not a problem most of the world is going to hit, but the small percentage of people it might bother the most are important nonetheless.

The spare netbook runs at 1024×600 resolution. Not a great form factor for an 8 hour day, but it worked well as a Windows 7 machine for my wife. Also a perfect travel machine for trips where you might want to connect to email or an occasional Web search. The process of upgrading from Win 7 Ultimate to the Win 8 Consumer Preview was a little slow, but a painless experience. I blame the slowness on the Atom processor and low memory config, not the update process.

The first thing I did was click on a Metro tile and get presented with the message of not being able to run in this low resolution. In fact every tile specific to Windows 8 gives me the same message. During the install it warned about not being able to run the Windows Store, but I figured I could live without the experience on this box for this pass at testing the OS.

Just to let you know, the OS is working fine on the netbook. It runs Office on the desktop just peachy. IE10 works too in classic mode. I can read all the tiles on the Start screen. I can work with the OS through the charms and settings. So the Metro UI partially works. But when I click on things like Weather and People and just about everything else on the Start screen I get the message that the resolution is just too small to run the app.

Metro requires 1024×768 or higher. This wipes out the netbook form factor or platform for Windows 8. Maybe Microsoft thinks it is dead, and this might be true. I am not sure this is the case, but it definitely wipes out any potential upgrade revenue, and if people install it and get the experience I am getting they are going to be support trouble for the Microsoft Product Support Services (PSS).

But it got me thinking. I have developed apps for 800×600 for some of our customers because of visually handicapped people. I know one person who has a family member that has macular degeneration and runs to a 24” or 30” monitor at 800×600 to see the screen. It is ugly, ugly for you and me. He literally will not be able to run Windows 8 Metro UI and see it. That seems bizarre to me considering the UI works on something as small as a Windows 7 Phone.

I don’t see the point where Microsoft cannot make the tiles scroll or adjust to the 800×600 screen. Windows 7 Phone scrolls. Scrolling is not hard and for visually impaired people, it is an acceptable tradeoff to run the latest and greatest. I am sure the engineers have considered this, but I am just not grasping why this would be a design decision and limitation.

Another question I have is the tablet market. Obviously Apple upped the ante with the Retina display, but there is still room for 7” tablet platform. If my netbook is a 10” what is the 7” platform going to run at resolution wise.

One other question I have is the colors of the tiles. I have not spent a lot of time poking around, but can the tile colors be customized? I saw the theme selection, but I thought that was just the background color. Again, I played with the OS for about an hour on Sunday so I am not sure. Red tiles are going to be a problem for 10% of the male population with red/green color blindness.

Note: If you want to understand Microsoft’s side of this discussion, check out their Building Windows 8 Blog on this topic. This blog entry is well written and well thought out and covers a lot of interesting material. However, I point to one particular reason sited several times:

“We chose a minimum screen resolution of 1024×768 in order to make it as simple as possible for developers to create great apps that work on all the different screens that are available now and in the future.”

This is hogwash. Developers can easily build metro apps that run on scrollable screens. Don’t put this on the developers. Developers don’t need “easy”, users need usable, regardless of the computer or their physical ability to use the computer.

And don’t even get me started on scrapping the Start button. Argh. This easily will slow the adoption of Windows 8 in businesses. Change the core way people access shortcuts to their apps. Especially after introducing the search box on the start button in recent versions of Windows. This is easily the  biggest bad design decision of Windows 8. I am hoping people will scream loudly and this gets added back in before release.

One of these days I will be invited to the usability labs at Microsoft, but until then I will be happy to provide feedback through my contacts at Microsoft (some of whom actually listen), via the Windows 8 blog in the comments, and this blog.

Anyone else enjoying the Windows 8 experience so far?

I got a call from our longest term customer. We have worked together for some 13 years. Normally I like getting a phone call from them. But I dislike the calls that go something like this: “Rick, long time no see…heh, my computer got hit by a virus when the grandson played an Internet game on it over the weekend. My hardware person said the computer is too old and not worth fixing. He is ordering me a new Windows 7 computer, and upgrading Office from Office 97 to 2010. You don’t think there will be any problems with your Visual FoxPro 5 app, do ya?”

This computer is the only computer for the company and is close to 8 years old, and really did need to be replaced. This customer is running a Visual FoxPro 5 app that I developed in 1997 and has run without major issues since then. The app is so reliable I cannot convince the customer to upgrade it to Visual FoxPro 9.

So let me see, how much could go wrong with VFP 5 on Windows 7 64-bit, using Aero? The app uses Excel to import records via a remote view, and automates Word to generate letters and envelopes via VBA in Office 97. Hmmm, a few versions of Office, lots of potential glitches with Aero, and a handful of ActiveX controls and FoxTools.FLL. My response was: “I don’t have any idea the number of things that could go wrong.”

My greatest concern was the 32-bit ODBC drivers for Excel, followed by the VBA automation, and then the User Interface glitches we have seen in newer versions of Visual FoxPro on Aero. I also used a couple ActiveX controls and had no idea how well it would work on Windows 7.

I did immediately think it was my opportunity to update to Visual FoxPro 9, which means no more Visual FoxPro 5 apps to support. {big evil grin}.

I arrived at my customer’s home. He literally runs his business out of his basement. I start up the app and it immediately crashes on “API library is not found.” Easy one, FoxTools.FLL is not loaded with the run-time files. It took me a little bit of time to track down the location of the VFP 5 runtime files, and copy over a copy of FoxTools. Run-times were in the Window’s SystemWOW64 folder instead of the System32 folder. App up and running FTW. I tested out most of the data entry forms and there are no UI glitches. Customer is happy to see the app running.

Celebration lasted about 2 minutes when we tried to import the Excel file. Hardware dude who moved over “everything” forgot to set up the ODBC driver. This is easy to overlook and I had good documentation on setting it up. I dig around and find the 32-bit ODBC Manager and set up the ODBC driver. Import routine works just fine. Another round of premature celebration follows.

Surely something is bound to go wrong, right? I mean, would I even dare write a blog post about a perfect scenario for an upgrade? Probably not. {g}

Off to test the letter generation code. CRASH! It is not what you are thinking if you are thinking the VBA code was not working. It crashed on the silly progress bar update that runs as the letters are generated. It crashed on the progress bar setting the value to zero, as in zero percent. Odd. I futzed with the code and tried a few things and eventually determined the progress bar was unnecessary for the moment. The VBA code actually ran without a single hiccup once I got past the progress bar not making progress. I am curious about the progress bar, but that battle is for another day. It was more important that the letters and envelopes are generating so the business can meet their commitments to their customers.

Oh, and thanks Microsoft for keeping backward compatibility with VBA and the Excel ODBC driver in Office 2010 on Windows 7. Nice job! Kudos to everyone on the Office team for not making my life miserable and showing the customer that his investment in Visual FoxPro and Microsoft Office was a well placed investment.

The only things I wished I had today was the current error handler we use, and time to dig into the progress bar issue.  The error handler I wrote back in 1997 feels weak. The one we use today is way more robust. I am speculating that the progress bar only accepts integers and I am passing decimals, or it is looking for the percent.

The moral of this story is to add one more thing to consider the next time a customer calls and wants to upgrade to Windows 7: native Windows ActiveX controls. Silly thing is I avoid most of the Microsoft ActiveX controls these days because of the deployment headaches. Not a single issue I worried about materialized. It was the unexpected problem that consumed most of my time. That, should not be a surprise.