Visual Basic 6 is 20 years old.  It’s stood the test of time and it while it’s showing its age it still functions and apps written on it still run in Vista and Windows 7.  To its credit, Microsoft has made sure that this venerable product still runs on modern computers.

But the question of Windows 8 compatibility has hit the fan, so to say, in the past month or so with Microsoft saying that apps can be written in html and javascript.  That threw many developers into a tizzy.

I don’t believe for a second that Microsoft is abandoning .NET, Win32 or COM simply because those are the foundation for nearly everything ever written at Microsoft.  It simply doesn’t make sense for Microsoft to move to another set of API’s even if you believe that Microsoft moves to a new technology every now and then to make themselves a moving target.  If anything, I believe that this might simply be a new way to develop apps but not replace anything.

While doing research for this post I ran across an unattributed quote supposedly from a person in Microsoft Support:

“We can’t make an official comment on our Windows 8 plans yet but it would be a likely outcome that VB6 applications will continue to work. “

I believe that statement but it’s not exactly a definitive statement.  The real question, I think, is how bad will it suck?  VB6 apps work in Windows 7 but without some work they look like they’re from the 90′s.  Most app developers I know don’t want their apps to look that dated.

Microsoft has stated that the Visual Basic 6 runtimes will not ship after Window 7.  This presumably means Windows 8 and beyond.  I have heard that Windows 8 will be 64 bit only and that means that the VB6 runtimes will either not work at all or will have to be run in some sort of compatibility layer.  So this means that existing apps MAY work, but only after jumping through hoops to install the runtime libraries and making sure the compatibility is set.

Let’s face it.  VB6 is an old, old development environment.  It was written in an age where computers didn’t have much memory and only one processor.  Threading isn’t impossible, but the few times I tried to get it working in a VB6 app the result was instability and crashes.  Threading is such an important thing in modern applications.

VB6 is object oriented – somewhat.  For the time it was state of the art but since subclassing controls is impossible it makes for interesting workarounds and wrappers.  Frankly it makes life more complicated than it needs to be.

Twenty years ago, VB6 was the cats-meow.  The Macintosh was around but it was considered a toy (I disagree but that’s not the argument) and few cared about it.  Microsoft was pretty much the only game in town.  Linux hadn’t been invented yet and the internet was for a few hard core geeks.

This is where Real Studio starts to look more attractive.  It works the same on Mac, Windows, and Linux.  Web Edition brings some of the same ease of developing desktop apps to the web.  In Real Studio I can subclass controls and objects (for the most part) all day long.  It’s a modern object oriented programming language.  Is it without foibles and inconsistencies?  Certainly not, but it’s way more powerful than VB6 in many ways.  Threading isn’t perfect, but it’s still light years ahead of VB6.

We’ve seen an uptick recently with people asking us to convert their VB6 application to Real Studio.  Our VB6 Analyzer utility (found at http://www.bkeeney.com/consulting/vb2rbconversion) has been downloaded a lot recently.  It allows users to scan their VB6 project and sends us a simple report detailing the number of forms, classes, libraries and OCX’s in use and lines of code and some other simple metrics.  It’s no substitute for seeing the whole project but it gives us a nice way to guestimate the costs of rewriting the app in Real Studio.

Notice that I said rewrite the application.  The only thing that Visual Basic and RealBasic have in common is that they have ‘basic’ in the name.  It’s like comparing a computer from twenty years ago to a modern computer.  Real Studio does things so much easier, better, and faster than Visual Basic that it’s really not worth trying to convert it line by line or even form by form.  Believe me we’ve tried – the end result is that you end up spending as much time fixing VB6 code that has a better equivalent in RB than it would be to just rewrite it from scratch.

Is Real Studio a suitable replacement for every app?  The answer is simple:  no.  Real Studio makes a really good cross-platform app, but that doesn’t always mean it will have all of the buzzers and bells available in development environments meant for each platform (grids in Windows come come to mind).

We are Real Studio consultants.  That’s what we do and we’ve been doing it for ten years.  Most of us spent a fair amount of time in Visual Basic before moving to Real Studio.  If you decide to do the transition yourself you will hate it at first because Real Studio is different than VB.  We all went through it and for a while you want Real Studio to be just like Visual Basic – trust me it’s not – and after you stop trying make Real Studio function like VB6 you’ll start to like it and get it.  Transitions are never easy.  For training videos, we have over 30 hours available at http://www.bkeeney.com/realbasic-training-section plus you could always hire us to come on site for training.

If you have VB6 project you want to transition please drop us a line and we can talk.  If you want to get multiple Real Studio developers looking at your project, make a post at http://www.realsoftware.com/support/consultants.php which gets sent out to the Real Studio developers network.

Does this change with Windows 8?  I don’t know, but I’m already seeing an uptick in developers that are looking to convert from Visual Basic 6 to Real Studio.  Uncertainty is a bad thing and even the full-time Windows developers I know don’t seem to know what’s going on.  Some of them are even worried that .NET and Silverlight support is up in the air.

The only thing that’s been mentioned for Win8 is JavaScript and HTML5.  No mention of .NET, Silverlight, or even Win32.  It’s very uncharacteristic of Microsoft to be so secretive and up-in-the-air over a future product.  Are they trying to be more Apple-like?  Perhaps that’s why people are freaking out.

Do I think MS is going to drop support for .NET, Silverlight, or even Win32?  Not a chance.  They have way too much invested in each of those to abandon them.  From a corporate standpoint there would be a revolt since almost everyone has invested, heavily, in one or more of those technologies/platforms.

But are Visual Basic 6 apps still safe?  That is a very good question and from the research I’ve done it appears that the VB6 runtime will not be shipped with Win8 though some in the community suspect that a hack will be found before release.  Other comments I’ve seen indicate that Win8 will ship as only 64 bit.  The VB6 runtime is 32bit only so that will mean running in compatibility mode which adds to the possibility of it not working properly for all applications.

Microsoft, at some point, has to kill compatibility.  Visual Basic is an old development environment that doesn’t take advantage of many new technologies.  It’s also not a very good object oriented language – it just wasn’t designed to be that way.  If the MS dev tools of the future are Silverlight, .NET, and JavaScript/HTML5 (does anyone really believe that!?), then it sure seems that VB6 might be on its way out.

So while VB6 apps might work with Win8 using hacks and compatibility mode, I believe developers have every right to be worried.  They’ve invested heavily in VB6 tools and controls and now the (long) honeymoon is over and it’s time to look at alternatives.

If you are only interested in Microsoft then the options are easy with .NET or Silverlight (assuming they aren’t going away).  If you’re thinking of a Mac or Linux version than the options are limited.  You could do Java, but as a long-time Mac user I’m not a big Java fan and try to avoid them because their UI generally isn’t native (I’m a Mac snob, but then most of us are).  Qt is a possibility but it’s not a RAD option either.

I am a little biased but I think Real Studio is a good choice for those coming from Visual Basic.  They are very much alike in how they work though REALbasic is MUCH better at object oriented programming than VB ever was.  It’s newer and is on a regular update schedule.  And, with just a little work, you can easily make apps for Mac, Windows, and Linux that look the same on all three platforms.  And now that Real Studio can make Web Apps there’s a fourth platform that you could potential support (though making a web app involves different controls, editors, etc so it’s not as easy as clicking a checkbox).

Is it a quick and easy conversion?  No.  Don’t trust any conversion program and, from experience, any converter will be just as time consuming (if not slightly worse) as rewriting from scratch.  We’ve found that taking a look at the UI and making it a bit more object oriented to take advantage of the strengths of REALbasic is always worth the investment.  We like to say you’re writing the apps for the next ten years and not only for right now.  So doing the extra work now will pay off for years.

Is Real Studio perfect?  Absolutely not.  It currently is not 64 bit compatible either though I know of many developers that have no issues with running in Windows 7 64 bit.  I do know that 64 bit compatibility is the next big upgrade for Windows after Real Software finishes up on Cocoa builds for the Macintosh side.  If memory serves they are on track for late 2011 64 bit compatibility (though that’s always subject to change).

With Win8 on schedule to be released next year (does anyone really believe that either?), you might need to be proactive and start thinking about the alternatives now.  Waiting until Win8 is released might be too late for your product.  Do you really want to be under the gun from management to get something that works on the CEO’s new shiny Win8 laptop?

If you would like to get a rough estimate on cost to convert from VB6 to Real Studio, we (BKeeney Software) have a VB6 Analyzer Tool for you to download (written in RB of course) that analyzes your project and gives us some metrics on lines of code, controls used, numbers of classes, etc, that help us give you an estimate.  More information can be found at http://www.bkeeney.com/consulting/vb2rbconversion.

Real Studio is a cross-platform development tool.  It runs on Mac OS X, Windows and Linux.  In the Professional/Enterprise versions you can build for other platforms and debug on the other platforms as well while staying your native environment (using remote debugging).  It’s really an awesome experience running Real Studio on the Mac and running the executable via VMare (or even on another machine in the office) running Linux or Windows.

We see it time and time again (and we’ve been guilty of it ourselves a time or two) where someone does all their development on Mac OS X and tests on Mac OS X but their app looks awful once they get it into Windows.  Text backgrounds looks like crap and the flickering is atrocious whenever they resize the window or move controls around at runtime.

The reason?  Mac OS X and Linux have double buffered windows while Microsoft Windows does not.  Mac OS X and Linux always draw to a buffer first and then draw to the screen.  Windows does not which is the cause of much flickering.  Real Studio has some easy workarounds for a bulk of the flickering and some simple rules of thumb to reduce, if not eliminate, Windows flickering issues.  Among them:

• Canvas objects should have Double Buffering turned on
• Do not erase the background of Canvas and Container Controls
• Be wary of using Refresh – perhaps Invalidate is a better choice
• Layering of controls will almost always get you into trouble.  Putting anything over a Canvas control (that draws anything) is almost a sure way of getting into trouble

So the lesson is that you really should be testing your app in all of the environments you plan on supporting early in your development process.  If you wait until you’re about ready to ship it’s too late.  You might have some fundamental assumptions in the project that’s hard to fix now that you’re almost done.

Cross platform development is easy using Real Studio, but that doesn’t mean there aren’t differences.  You need to test for those differences early and on a regular basis.

Since I spend most of my time on the Mac side I’m assuming Windows and Linux RB developers have the same issues going to the other platforms.  What are some of the issues you see?  Did I miss any reasons for Windows flickering?

Spirit is Calling features a perpetual calendar allowing the user to make use of the journal this year and for years to come. In addition, the program can be scheduled to automatically open every day at a scheduled time. Technical features include a full-featured word processor with spell check and the ability to insert graphics into your journal entries.

Many people find journaling to be very powerful.  It’s a way to get their thoughts and feelings out and into the Universe.  That can be a very liberating experience.  To get the most out of it, it does require some daily attention.  From the book:

Lesson Quote:

Daily practice has an advantage over sporadic practice, in that regular attention to your spiritual life builds up a rhythm in your awareness. This rhythm allows deeper insights to emerge that are not possible with a random program. This journal presents one of many possible devotional activities that you might use to establish a regular, daily rhythm of introspection.

To aid in the process of making it habit we added an autostart preference setting so that at a time of your choosing Spirit Is Calling starts automatically.  In the beginning that can be helpful to get into the habit of journaling.

One of the reasons why I created the electronic version of the journal is that I don’t write by hand much any more.  Writing by hand is very slow and somewhat painful for anything of length.  But I can type 80 words a minute (if I don’t care about the mistakes on the first pass) so having a word processor built-in to the journal (with spell checking) makes sense.

Spirit Is Calling’s home page is at www.bkeeney.com/spirit-is-calling

Direct Download Mac OS X:

www.bkeeney.com/downloads/macintoshdownloads/64-spirit-is-calling-for-mac-os-x/download

Direct Download Windows:

www.bkeeney.com/downloads/windowsdownloads/63-spirit-is-calling-for-windows/download

If you are looking to try something different in your spiritual practice, please try Spirit Is Calling.  Perhaps the journal will help you define your goal and get you out of your daily trivia.

Inspirational Quote:

In the absence of clearly-defined goals, we become strangely loyal to performing daily trivia until ultimately we become enslaved by it. – Robert Heinlein

More info on Windows Functionality Suite at http://arbpmembers.org/windows-functionality-suite.  We at BKeeney Software have found the Windows Functionality Suite to be very valuable in creating excellent Windows applications.  It has many functions that add the finishing touch to a Windows app that many users expect.

It was originally written by Aaron Ballman, a former engineer at REAL Software.  Since he no longer works for the company it has languished from lack of attention and in recent releases of REAL Studio it no longer works out of the box.  We are looking for a few individuals to help spearhead the effort to update it for use with modern versions of REAL Studio.  I don’t think it will take much work, just someone to be in charge of tracking and merging changes and maybe creating some new documentation and example projects.

Not good at any time, but this mean that both 3 and 3.1 are not usable for me, at least for Windows builds.  R 3 has some issues and a memory leak as well.  Thankfully, the leak is not as bad. I would go back to R 2.1 but since *that* release also has a nasty Windows bug I can’t go back to it.  Dare I go back to R 2?

Initial indications are that RS will not be issuing an interim 3.2 release, however.  This is why I think their Rapid Release Model stinks.  I’ve got two bugs that keep me from using the latest and greatest release and now have to wait to get a fix.

Your plan runs out in the next 60 days or so?  Sorry.  You’re S.O.L.  It might be great for RS but the Rapid Release Model is becoming the Rapid Bug Model for me.  Pretty soon, it’s going to start costing me clients.

———-

A couple people have asked me what I think about Apple changing their stance on letting 3rd party development tools for developing iOS apps and what that means for REAL Software.  Meh.

Really, there are so many items RS has to get done before thinking about iOS that it’s not even a concern right now.  The only thing that would concern me is if they decided to jump both feet first and devote a lot of resources to it.  Cocoa has taken way longer than anyone ever dreamed of (I feel that personnel changes have bit them hard on that one) and now the highly anticipated Web Edition will distract them too.

Don’t get me wrong, I’m looking forward to the Web Edition.  I think being able to leverage all my RB knowledge for iOS apps is a great idea too.  But, as they say in Missouri, “Show Me!” – I’ll get excited when I see them and can work with them and keep my business in the black.

Here are the facts as I knew them this morning.  Given a hardware configuration (serial port to fiber optic converter to fiber optic converter to Serial to USB converter), I could reliably talk to my device in Mac OS X and Windows XP.  In Vista and Windows 7 it failed.  The serial port monitor software that I running in Windows was able to see the messages with 100% accuracy while the RB serial control was not.

Sounds like an RB bug, right?  I submitted it, with video proof, and had a reasonably happy weekend.  The client was not happy, understandably, and after consulting with REAL Software (who, by the way, responded to my email promptly this morning) agreed that it might be a bug and they would be happy to try to reproduce (and ultimately fix it) if we sent them the hardware and a sample program and some money to do it for the R4 release.  R4 will come out sometime this fall, by the way.

The client was not happy about the additional cost and the time delay as you can understandably imagine.  So I said I’d do some research and figure out if other people are having serial issues too before issuing a recommendation to send all the materials to RS.  I’m sure some of you are guessing where this is going.

It just so happens that the specific manufacturer of the Serial to USB Converter (Prolific) has some serious issues with their Windows 7 (and Vista) drivers.  After a few more specific web searches I found an alternative (perhaps older) driver that works fine if you do the following in Windows 7:  Right click on the properties of the installer, select Run as Administrator and select Vista SP2 under the compatibility popup.

Run the installer, restart Windows 7 and Voila!  We now have a fully functioning driver – that works – in Windows 7.

Hindsight, as they say, is always 20/20 and I *should* have thought about this last week.  I had “something in the middle” that I assumed worked.  I had evidence that it did work (the serial port monitor) but my assumption was false (obviously).

Debugging serial communications (and network communications for that matter) is a royal pain in the behind.  When something isn’t working, work the problem backwards.  When there’s hardware involved, verify that the hardware works or try to eliminate the hardware.  In my case, my Windows 7 doesn’t have a true serial port (it’s running on my Mac in VMWare).

So maybe you’ll learn something from my experience and pain.  Maybe you’ll keep yourself from having a bruised forehead (from banging your head up against a brick wall).

Happy coding!

The data packet the hardware device sends is very small – 4 characters to be exact.  What I was experiencing was that RB captured the first character on the first send – but not the whole packet.  Then it would complete the first message on the 2nd message and only get part of the 2nd message.  It would go something like this:

1. A
2. B | A
3. C | A
4. D | A

Where A is common to all messages so they should be AB, AC, AD and so on.

These messages in the real world are sporadic and with the exception of a regular hardware pass message it might be days or weeks in between messages so as you can imagine, this problem mucks up the logic quite a bit.

If you are not familiar with the Serial control, the DataAvailable event fires when there is data available (duh) and there you can check what’s in the serial buffer by using the LookAhead function.  LookAhead in this case showed just the first character.  The other property to check is  BytesAvailable which should tell you how much is still in the buffer.  It simply returned zero so I should have a complete message.  Definitely something screwy going on there.

Invoking Serial.Poll via timer did not produce any different results.  Neither did forcing a ReadAll.

One other thing that I discovered was the Serial Port Monitors are worth their weight in gold.  Using one, you can at least verify that the data got to the computer.  A free 14 day trial was good enough but if I do any other serial projects it will be worth it.

The good news is that I wasn’t crazy.  The client is okay with Windows XP for now.  The bad news is that it might take a release cycle (or more) to get it fixed. Oh well, battles for another day….

For those that care, the Feedback id is 12723.

To duplicate, put two pushbuttons on a window.  Put a message box in the Action event saying which one has been pushed.

Test it with the mouse.  Works fine.  Now tab to each pushbutton and press the spacebar.  Works fine.

Now, tab to each one and press the Return or Enter key.  Nothing.  If you happen to have a default pushbutton the Enter/Return key will activate that button regardless of where the focus is.

Nasty bug that leads the average Windows user to curse your name in vain if they rely on the keyboard to navigate.  I spent hours trying to figure this one out because it manifests itself in the MessageDialog class too.

Yeah, I’m a little pissed.   I have to revert to RB 2010 R1 where it does not manifest itself.  The hard deadline for the project I’m working on is today.  Gives me a black eye for a problem outside of my control.

For those that care, Feedback ID 12626

Using RB for Windows was…different.  I’m not sure that I can quantify it other than that it seemed less polished.  It just doesn’t feel like a normal Windows app and it certainly was not as smooth as the Mac OS X version.

The reason I was in Windows to begin with was of tracking down a printing bug that was affecting my product.  Turned out it was the Application.UseGDIPlus property that had been set to true.  The end result was that my reports were ‘blown up’ about 10 times bigger than they should have been.  This has been documented and is <feedback://showreport?report_id=10399>.  Turning off the property fixed the problem.  Some fix, eh?

I don’t think that Windows gets as much attention as the Mac OS X.  Why do I believe this?  The ARBP surveys consistently show Mac users being about 80% of the membership.  Likewise, traffic to this website is roughly 80% Macintosh.  What this means is that beta testers are predominantly Mac based.  I believe that most of the developers at RS are Mac users as well.

Currently, RS is in the transition to get Cocoa out.  It won’t be happening for 2010 R1…so it’s obviously a much tougher nut to crack than they originally thought.  Honestly, I’m not surprised.  Going from Carbon to Cocoa is like creating an entire new platform.  Eighteen months to two years isn’t out of the question for such a big undertaking.

I’m hoping that when Cocoa is out and working great (you think it won’t have some bugs in the first release?) that RS pays a lot of attention to Windows.  They’ve said in the past (sorry no reference for this) that a vast majority of new licenses are Windows users.  But yet, based on observation, the professionals and beta testers are mainly Mac users.  Does that not say something?  Would better Windows support translate into more Professional and Studio licenses?  I don’t know, but I suspect so.

Perhaps it’s time to kill support for Windows 2000.  I’d even suggest killing off XP but I know a lot of places in the world are still actively using it so that’s probably a non-starter.  I believe Cocoa support will effectively kill support for anything less than Mac OS X 10.4 so why not for Windows too?

I suggest that everyone that has a Studio license do a bulk of their work in Windows for a couple of weeks.  More Windows-specific bug reports will (hopefully) get some of the more obvious (and painful) bugs fixed.

What are your feelings about this?  Am I right, wrong, or somewhere in-between?