Classic Visual Basic Is Truly Dead

Developers love Visual Basic.  The site http://www.classicvb.org/petition/ has received well over 14,000 signatures since its inception in 2005.  In the user forums for Microsoft Visual Studio there is a place where developers can make suggestions.  This one http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3440221-bring-back-classic-visual-basic-an-improved-versi wants to bring back class Visual Basic.  Since December 2012 it had received over 7,400 votes.  Microsoft essentially told VB6 developers to kiss off this week.

The only bit of good news, in my opinion, for VB6 developers was that the VB6 runtime will continue to be supported through 2024.  So, VB6 users, you’ve got 10 years to figure out what’s next.

The VB6 runtime it is still a component of the Windows operating system and is a component shipped in Windows 8.1. It will be supported at least through 2024.

The 1100 (and growing) comments to this post are pretty much what you’d expect.  There are a lot of frustrated VB6 developers that feel Microsoft has abandoned them, at best, and, at worst, actively screwing over one of the most vibrant developer communities on the planet.

Many VB6 developers feel that .NET is inferior to VB6 but yet Microsoft is confident that VB6 developers will somehow migrate to .NET.  I just don’t see this happening.  Oh, I’m sure some will bite the bullet and learn .NET but the prospect of learning a new language and rewriting their apps does not make many happy.  VB6 was effectively killed 10 years ago and yet there are still lots of VB6 developers out there.

Many will be looking at alternatives because Microsoft is not the 95% market share behemoth it once was and VB6 was, after all, Windows only.  I you have to go to the trouble to learn a new language and rewrite all of your apps why not look at something that can work on Windows and Mac and possibly Linux as well?

I spent many years working in VB6.  I liked the language, I liked the IDE.  It had some awful quirks that drove us nuts but they were well documented quirks and were relatively easy to work around.  When I first encountered Xojo (then REALbasic) I felt like I found VB’s kissing cousin.  The IDE’s were similar, the language was similar and it was relatively easy to convert code and community was outstanding.

After twelve years of using Xojo I can say it’s superior in some ways.  First, it’s kept up to date and gets roughly 4 updates a year.  This is both a good and bad thing.  Good because when Apple (and to a lesser extant Microsoft and the Linux Distro’s) change things you’ll know that it’s just a matter of a few months, usually, before a new version of Xojo is released.  Unfortunately this makes Xojo a moving target which is part of the reason why there aren’t any books on Xojo.  It gets written and by the time it’s published it’s already out of date.

There are a number of things that VB6 was just not good at.  Subclassing controls was impossible and we never got threads to work right without causing serious crashing issues (I believe I recently saw a post where they got threading working properly in VB6).  But that still leaves all the other things that were feeling their age in VB6.

I’m biased for Xojo.  I think it’s worth taking a look at if you’re a VB6 developer.  Is Xojo perfect?  Hell no.  The developer community is much smaller and there aren’t nearly as many control options.  And some of the controls, the grid in particular, are inferior to what many are currently using in VB6.

Xojo is, in many respects, a compromise.  All of those fancy grids you see in Windows apps usually don’t exist on Mac OS X and Linux.  Mac OS X apps are generally built with a different UI mindset so the the grids aren’t nearly as busy.  If you planned on doing the same thing in Xojo you will be in for a rude awakening.  Not that you can’t make a complicated grid, but you’ll spend a lot of time getting it to work and even then I’m not sure you’ll be happy with the results.  Plus, Mac users are a finicky lot and if it looks like a Windows port they might reject your app.  But then again, does the utility you wrote for your company really need a fancy UI?

Xojo is very cool sometimes.  The ability to remote debug applications from my Mac to a Windows or Linux computer is very handy.  And the fact that a Windows machine can build for Mac OS X and Linux, for console, desktop and web apps, is also very nifty.

Take a look at Xojo (it’s free to try!).  It might be a good solution for you.  My advice is to not try to ‘convert’ your VB6 app using The Migration Assistant or any of the conversion tools available.  There are just too many language and control differences to make this feasible.  From experience, you’ll spend more time fixing code than if you had just started from scratch.

My other bit of advice is to not assume Xojo and Xojo made apps work just like VB6.  They don’t.  Take the time to read the documentation, look at the example apps, and visit the forums when you have questions (you’ll have many).  The Xojo community is very welcoming and eager to help.

Finally, I am a consultant and if you need assistance getting into Xojo we can help.  My team has rewritten dozens of commercial VB6 apps over the years.  If you’d like a quote feel free to download our VB6 analyzer tool at http://www.bkeeney.com/vb2rbconversion/.  We also have over 50 hours of Xojo and Real Studio video tutorials available to subscribers at http://xojo.bkeeney.com/XojoTraining/ where we’ve helped thousands of developers get a handle on Xojo.

If you are a VB6 developer, Xojo might be for you.  Welcome to the Xojo community!

 

Xojo 2013 Release 4(.1)

Xojo 2013 Release 4 hit the internets this week.  And they promptly pulled it after they discovered a crashing issue when it tried to verify licensing on their servers.  Release 4.1 was released today which fixes the issue.  As far as I know, it’s the only fix in 4.1.

I would characterize Release 4 as a maintenance release as it has several hundred bug fixes and just a few new items. I’m okay with this and if I had any say in the matter I would alternate releases with new features and bug fixes. One thing this release does NOT include is the Xojo Cloud that has been in development for over a year.  I expect Xojo Cloud will be released for the 2014 Release 1 (so it will probably go into beta soon).

The big change in this release is that the IDE and applications built for Cocoa require Mac OS X 10.7 (Lion) or later.  I think this is a pretty good move though it will make life harder for some.  Apple updates their OS regularly and many update their OS when they can because the upgrades have been safe.  I can’t find the statistics but it appears that a vast majority (in the neighborhood of 80%) of Mac users are on 10.7 and above now.  Obviously, if you have clients and customers that require 10.6 (Snow Leopard) you’ll need to stick with Xojo 2013 Release 3 (or continue building in Carbon).

New in Release 4 is new cryptography functions using the Crypto class.  The new class adds RSA encryption to the Xojo framework.  It has functions that allow you to generate public and private keys, verify the keys, encrypt and decrypt data, sign data blocks, verify signatures, and generate a random block of data.

For desktop users, the Canvas and ContainerControls now have a transparent property.  The default is true to maintain current functionality.  This change is particularly important in Linux as child controls on an opaque (not transparent) canvas or container control can be clipped.

The IDE can now use constants for the application identifier which can be useful if your application has multiple names or versions.

Release 4 has a ton of bug fixes and tweaks to the IDE.  This includes many fixes and changes to the Navigator and some of the copy and paste bugs that have afflicted the IDE since its first release.  It’s still not perfect, but it’s getting better.

Better is subjective, of course, but one of the bigger annoyances to many users (including me) is that changing text values in the Inspector (such as a control name) didn’t actually stick unless you tabbed out of the field.  This has been fixed and just this one change alone is worth getting and using Release 4.

There are a few debugger changes that are worth mentioning.  First, the debugger now catches exceptions raised in computed properties.  Before it wouldn’t, which could cause navigating in the debugger to actually change the control flow of the program.  Second there are some specific fixes to the debugger for Windows and Linux users, and finally a new DebugIdentifier property was added to the Thread class to make it easier to debug code that’s running in a thread.

One item of note that came through late in the beta cycle.  Several developers had issues with rejections from the Mac App Store (MAS) due to using QuickTime API calls (or the framework linking to them).  It appears that Apple, while only deprecating QuickTime in Mavericks, is actively rejecting apps that use it.  Release 4 no longer links to QuickTime but according to the Beta list testers this is still an issue.  In my opinion, this is more an issue with Apple, suddenly and with little warning, rejecting MAS submissions than it is Xojo doing anything wrong.

While I like Apple, sometimes getting apps into their store is like hitting a moving target.  Apple giveth and Apple taketh away.  <insert favorite negative Apple cliche here>  If you know more on this, please add comments below.

What are your thoughts about Release 4?  Are you happier with the IDE after 4 releases than you were initially?  Are you looking forward to Xojo Cloud?  What about the eventual iOS support?

[Edit:  Changed wording on the debugger changes for computed properties so it was more accurate.]

Has Microsoft Already Lost?

I say this with no malice when I say that Real Studio is a fairly small player (development tools-wise) when compared to Microsoft and Apple.  Those two behemoths have much bigger pockets and drive the development environments on their respective platforms.  It’s also fair to say that each has little interest in supporting the other platform.

Real Studio is a good cross-platform development environment that lets a skilled developer create nice Macintosh OS X and Windows applications using one code base.  Most things ‘just work’ and the language makes it easy to take into account the occasional (and sometimes not occasional) platform specific API calls and differences.  Sometimes the differences are a royal pain but rarely have we been stymied in a project as there always seems to be another option available.  And sometimes the trick is know which things to avoid when working on cross-platform apps.

When I started doing Real Studio consulting a decade ago most of the clients who found us were hard-core Apple users.  They had to satisfy their corporate bosses by developing mainly for Windows and if they could get a Mac OS X version as a side benefit that was great.  For the past couple of years it seemed that the clients who contacted us were the corporate IT folks that had legacy Visual Basic projects and didn’t want to convert to .NET (and yes, the boss wanted a Mac version too).

In the past year, however, we’ve been contacted – a lot – by clients invested in .NET and needing a Mac version.  This isn’t just for their internal business apps either – they’re talking about commercial applications.  What’s even more interesting is the number of calls we’ve fielded by existing .NET development shops needing help.

So it begs the question:  Has Microsoft lost the battle of mindshare?  Has Apple now wedged their way into consumer and corporate America to the point where not having a Mac version of your software is a detriment to marketing and sales?

Don’t get me wrong.  Microsoft isn’t going away any time soon, but I can remember a time when if you mentioned Apple (or any non-Microsoft technology for that matter) you were derided for your obvious stupidity.  I can’t tell you how many times I was laughed at for being an Apple developer.  Now, it’s hard(er) to find diehard 100% Microsoft-only IT person.

I decided to write this post after yet another phone call with a .NET developer.  They want Mac versions and they’ve already decided on Real Studio.  But, and this is always the catch, they’re good at .NET and know next to nothing about Real Studio and nothing about Mac development.

That’s where consultants like us come in as we can help bridge the gap in knowledge.  If you’re interested, we have 36 hours of training video’s (over 100 individual videos) available to subscribers at http://www.bkeeney.com/RealStudioTraining/realstudiotraining.cgi including several projects that start from scratch.  I’ve had experience Real Studio developers tell me they’ve learned a few things even by watching the 6 hours of non-subscription video.  Perhaps your .NET developers would get something out of the training?  Perhaps some one-on-one training would helpful?  Contact me – we can help.

I digress (sorry for the shameless plugs).  Have you Real Studio developers been seeing similar trends?  Does .NET seem to be losing its luster?

Mac App Store

The Mac App Store, so far, has been pretty good for sales of Task Timer.  We have been running double of normal sales of the previous version.  Technically, version 5 was out before it was approved in the Mac App Store so that’s even more proof that the Mac App Store is doing well for us.  So from that aspect we are very happy with what we’ve seen from a sales standpoint from the Mac App Store.

What’s not very good is the amount of time it takes to get an application – even an application update – approved (or rejected) in the store.  We’ve been lucky that the few bugs that have been reported aren’t affecting everyone and aren’t critical.  We submitted our update on January 12th and didn’t receive a rejection until January 28th.  That’s 12 business days!

The rejection was from not linking properly to the HXRuntime library.  The problem and fix is documented on REAL Software’s blog.  What’s worse is that REAL Studio applications don’t even use this library so this is a false-positive result from some automated test that Apple implemented between our first second submissions.

I realize that we’re not generating a ton of sales from Task Timer so we’re not even a blip in Apples sales figures, but 12 days is an eternity when a customer has a problem.  They won’t complain to Apple, they’ll complain to me.  At the best I can offer customers to update outside of the Mac App Store but that’s a half-assed solution, in my opinion.  At worst, I’ll lose customers for life because I’m ‘unresponsive’ or write ‘crappy’ software.  I predict most people will be relatively forgiving but I think it depends on the cost of the software and what it does.

We are not the first and only developers to face this problem.  Panic, makers of the popular Transmit, had a similar issue that was thankfully taken care of quickly.  One has to wonder if a public blog post from a very popular developer didn’t speed things up a bit, but the point is that the process has a flaw.

I can’t believe that Apple is oblivious to this problem.  The wait times for app approval is just too long.

I’m not sure what the solution is.  All I know is that the current situation is not good for smaller, independent developers like me.  Wasn’t the Mac App Store supposed to be a boon for us?

Anyway, I’m not really all that angry.  I expect that approval times will get better as time goes on.  I would also expect that the automation tools they’re using internally will be available to developers for testing purposes (before submission) or, at the very least, some sort of automated testing submission process that, if not instantaneous, is light years faster than it is now.

What say you?

Do Apple and Microsoft Really Care about REALbasic?

Apple has xCode/Cocoa which they give away for free.  Microsoft has Visual Studio and .NET which can be obtained for next to nothing.  Both products create (arguably) superior applications for their respective platforms.

REALbasic  makes a consistently good application for both platforms.  Keep in mind that RB is nothing but compromises for the supported platforms.  The Microsoft MSHFlexGrid is superior in many ways to what the Apple grid can do so REALbasic has to compromise and give us the lowest common denominator in grids and hence we have an underpowered (but functional) listbox control.  The Einhugur StyleGrid and DataGrid controls do essentially that same thing just wrapped differently with some speed enhancements.

It’s been argued many times in the forums that RB doesn’t make a good Mac application without doing a lot of extra work.  The same is true that Windows applications made in RB suffer from some of the same problems.  Why is this?  Two words:  Cocoa and .NET.

Each frameworks gives developers goodies that highlight the strength of the platform and hence our initial question.  Does Apple or Microsoft really care about REALbasic?  It’s not like RB is going to see extra copies of Windows or sell more Macintosh computers directly.  If anything, you could argue that REALbasic hurts both Apple’s and Microsoft’s plans for “world domination.”

That’s a bold statement but here’s my reasoning.  I’m in charge of Apple the argument might go something like this:  RB allows developers to make software that works on my Mac’s and on the Borg’s own Windows.  I want to show the world that the better platform is the Macintosh so why should I help RS with any bugs on the Mac?  Now developers won’t use Cocoa and all the goodies that it has so all the time and effort to make Cocoa is wasted and our users don’t get all the goodies they’ve come to expect from Mac software.  RB is not enhancing my users’ experience!

If I’m in charge of Windows the argument could go like this.  I have this huge market share that’s being eroded by that toy computer from Apple.  Here’s RS that makes the claim of being a basic, object oriented, development environment that lets it easily create software for Windows and the Mac.  There’s even a utility that converts from VB6 to REALbasic!  Now people aren’t locked into Windows and all that work I’ve done promoting .NET is wasted!

Okay, both arguments seem silly but I’m sure the sentiment exists in Cupertino and Redmond.  I’m sure that neither company is actively sabotaging REAL Software and REALbasic but are they helping it?  In the world of business what seems like a win for the consumer is often perceived as a lose for the company.

What are your thoughts?  Is this idea possible or is it really stupid?  What am I missing?