Xojo Desktop vs Xojo Web App Development

The question comes up every now and then on what’s the best target to develop for:  desktop or web.  The answer is sometimes pretty straightforward but, in reality, the answer should be “it depends.”  You see, each target has some very good strengths and also some bad weaknesses that you need to evaluate before you start coding.  Let’s go over some of those issues.  Let’s start with desktop apps.

Xojo has been making desktop apps for it’s entire history.  Thus it is very stable and mature and there are a lot more 3rd party libraries and plugins available.  You get most, if not all, of the goodies that come along with the desktop environment and this can mean your desktop apps can have most of the buzzers and bells that modern users demand.

With desktop apps, if you need 10 more copies, it’s as simple as installing them on new machines.  These days there’s not a lot of issues deploying to Mac OS X and Windows and most versions of Linux, but still, you need to test on all supported platforms.

The major downside to desktop apps is deployment.  Each user has a copy of the software and depending on your needs/requirements you might need to ensure that everyone be on the same version.  Example:  You’ve created a desktop app for a veterinary clinic that handles everything from pet checkin to billing.  All of them connect to the same database so when you introduce a schema change in the database you need all the clients to use the newest version.    For a small organization this might not be so bad but scale that up to a corporation with several hundred copies of your software.  A good organization might have a good IT department and can deploy your software to everyone at once, but my experience says that most organizations don’t handle this well.  So your software has to be programmed to be cognizant of database versions and check at startup and complain if it’s not what it’s expecting.  From experience it’s a pain to deal with.

Desktop apps that are part of an n-tier system also need to be programmed differently.  You can program each client with all the logic it needs, but then you have to worry about record locking issues (i.e. who wins if two users are editing the same record at the same time).  You also have deployment issues, again, since you’re back to the issue of updating every client every time there’s a little change in logic.  The better solution is to have a middleware application that handles the business logic and is the go-between between the client apps and the server.  The middleware app does all of the business logic and handles the transactions between the database and the client apps.  It’s a fair bit of work and is not what I would consider a simple undertaking.  But at least you generally only have to update the middleware app most of the time and the clients can stay the same.

Web apps, on the other hand, have several advantages over desktop apps.  First, they are n-tier by design.  Each client has its own set of logic via Xojo WebSessions even though there is only one application running.  The user runs in a browser and everything is processed on the server.    So when you need to update your web app you shutdown the old one, replace the executable and the next time someone hits the URL the newer version is there and running.  Having only one instance to update is really nice (and quick).  Web apps eliminate many deployment challenges.

Web apps aren’t perfect though.  Since they are generally exposed to more random user interaction via the web you spend way more time dealing with security and making sure nefarious users don’t get into your system or abuse it.  All of your database operations should use PreparedStatements to make sure SQL injection attacks cannot happen.

Web apps run in a browser.  That’s both good and bad.  Users can access your app as long as they have internet access.  In some areas this is no big deal and for others it’s a huge deal.  Browsers also have a lot of built-in security to keep bad things from happening on your computer.  This security also limits what your browser can do in terms of file handling local.  Xojo does not currently support drag and drop operations with the browser.

Xojo web apps are also not as stable and mature as the desktop side simply because it’s younger.  That’s not the same as unsafe but it does mean there are not as many 3rd party options for Xojo web apps.  Some controls, in particular the listbox, are vastly inferior to their desktop counterparts in terms of capabilities and may not be good enough for your needs.  Web Containers go a long way towards solving this issue but it’s not ideal.

Not all web browsers are created equal.  Some perform better than others and all of them have gone through tremendous growth in the past ten years as the internet has become ubiquitous.  This means there are a lot of different browsers, and versions of those browsers, being used by the general public.  Testing the various browser type and version combinations is critical and despite all the efforts of Xojo to get it all right, the speed of new browser releases does mean issues pop up now and then.  Mobile browsers have their own set of issues that you might need to take into account as well.

Desktop apps have a huge advantage in that they don’t have to convert text to UI like web apps do.  For example loading 1,000 rows in a desktop listbox, while slow is blazingly fast compared to doing the same thing in a web app.  1,000 row list boxes in web apps are SLOW simply because the server has to create all that html data, send it through the internet to the browser, and then the browser has to reassemble it for the user to see.  To get around this most websites do data paging where they only show you 25 to 50 records at time.  Again, not hard to do but one more thing to develop.  Also keep in mind that mobile browsers try really hard to minimize data connections over cell connections so what seems fast on your desktop might be incredibly slow on a mobile phone.

Perhaps the biggest issue with web apps (not just those made with Xojo) is scaling.  Your app will react differently when accessed by 1000 simultaneous users than when it has 10.  The way around this is to do load sharing and balancing using NgInx and works well on Apache web servers.  Finding a good web server to host your web app can be challenging too.  Until Xojo releases their 64 bit support for web apps it will be increasingly difficult to find and install 32 bit compatibility libraries that work with Xojo web apps.

As you can see, there’s is no right answer.  Both desktop apps and web apps have their place in the world since they each have strengths and weaknesses.  Before you start development work you need to think through the implications of doing each.

Happy coding!  Was there anything I forgot to mention in the debate of desktop vs web apps?

BKS Spell Checker 1.0.2

picBKS_SpellCheckerWe released a new version of our Mac/Windows spell checker plugin today.  Version 1.0.2 works better with foreign language Hunspell dictionaries that are in different encodings.

The Spell Checker plugin has two different spell checking modes.  In the first mode it  works with the native spelling dictionaries on each platform.  On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries.  If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries.  There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.

There is no Linux version at this point due to lack of interest.

More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/

Debugging Your Xojo Applications

Your customers and clients expect your Xojo applications to be as bug free as possible.  What mechanisms do you have in place to handle an error and report it?  Bugs occur – that’s a fact of life – and even the best error handling in the world can’t prevent bugs from occurring.

Thoroughly testing your application is your first and best line of defense.  However, it’s very time consuming and without good testing procedures it may even be a waste of time.  I would also add the it’s very hard for the developer to be a good tester of their own code.  You programmed it to do a certain task in a certain way.  Someone else will have a different set of expectations.

Regression testing is the only way to really make sure that changes in one part of your code doesn’t change other parts of your application (or a new version of Xojo doesn’t affect you either!).  An excellent way to do regression testing on your software is to use the open source unit testing module called XojoUnit (it’s now part of Xojo).  It allows you to test your code with known inputs and test them against the actual output.

A common question from the forums is that people get an error message saying, “The application has encountered an error and must now shutdown,” and they have no idea what the error is or where the error happened.  They need to learn as much as they can about the Exception class and in particular the Stack property.  The stack was introduced way back in 2006 and is a string array that contains the methods that have run from the entry point into your code until where the exception occurred.  Be aware that the Include Function Names property has to be true in your application for the stack to be human readable.

Use the UnhandledException event in the application class to capture any errors that weren’t handled elsewhere.  The exception stack allows you to determine where the error occurred and from there it’s a simple matter to send an email, post to a web form or write the error out to a log file that includes important details such as platform, operating system version and the version of your application.

Some applications will require files be in a specific location and when debugging your application those files might not be in the proper (final) location.  Use the DebugBuild constant along with conditional compilation, #If,  to handle things differently at debug time and runtime.  For debugging purposes you can have the required files in the local project directory for convenience sake.  A feature added in 2007 allows you to place your debug build in a particular location which eliminates the need to have non-project files in your project directory.

Cross-platform applications require additional handling but now that Xojo with (or without) a desktop license can do remote debugging and it’s very easy to do.  I run the Xojo IDE on Mac OS X on an iMac and use VMWare running various versions of Windows and Linux so I can debug my applications in those environments.  The remote debugger works exactly like the regular debugger except that the debug application is running in another environment.  It’s a little slower to initiate since the app has to be transferred to the other environment but otherwise it’s the same process.

I highly recommend testing early and often on the other platforms you’re developing for.  Don’t wait until the end to do extensive testing.  While Xojo does a great job on cross-platform applications there ARE platform differences you need to be aware of.

New developers coming from Visual Basic 6 are often irritated by the perceived lack of database error in Xojo.  An incorrect SQL statement when opening a recordset results in nil recordset objects instead of a throwing a runtime error.  The unexpected nil recordset then causes NilObjectException errors.  You must get in the habit of checking your database object for errors after every database operation.  Once you catch the error you can at least be more graceful on how to recover from it.

That’s a lot of information so do your research.  Debugging your application isn’t as hard as you think.

What things do you do to make your life easier hunting down or preventing bugs?

Happy Birthday, Macintosh!

There have been a number of trips down memory lane this week regarding the Macintosh so now you’ll have mine.  If you’ve been living under a rock you may not know that the Macintosh was introduced 30 years ago this week.  It truly changed computing and it certainly changed my course in life.

I entered college in the Fall of 1985 to become an electrical engineer.  While PC’s weren’t unknown at the time they were still expensive enough where they weren’t common.  In the fraternity that I joined, they had two(!) IBM PC’s sitting in the basement ‘computer room’.  We were praised by the national fraternity for having all of our books on Lotus 123.  Looking back how quaint.

As with any fraternity we had our various committees and in the Fall semester of 1986 I ended up being the chairman of the Parents Committee and it was one our charges to send a newsletter out to parents to inform them of all the great things their kids (and money) were doing.  For many years we had people that worked at the newspaper and had access to the Linotype machine where we could print out the text at high resolution, lay it out on boards for printing.  That semester we had no one on staff and I was scrambling to figure it out.

One of the older Brothers worked at the school computer lab.  He mentioned they had these new Macintosh computers and this thing called a LaserWriter printer that was ‘very cool.  He handed me a copy of MS Word and Aldus PageMaker and told me to go figure it out (ah the days before anti-piracy solutions).  I was reluctant but curious and got to play around with the two apps on a Macinoths plus.

I was intrigued and hooked.  I had used quite a few different types of computers, TRS 80, Apple II, IBM PC’s, Atari to name a few but the Mac was something special with its 9 inch black and white monitor and its mouse where you pointed and clicked and dragged things in a What You See Is What You Get (WYSIWYG) environment.  It was SO intuitive.  If you didn’t know the exact command you could find it in the menu’s.

My parents newsletter went out with relative ease and our chapter won an award for innovative newsletter.  The following semester I was in charge of the Alumni Committee and we won an award for the newsletter we did then too.  From then on I can’t tell you how many newsletters I did for the fraternity.  Again, looking back on 30 years they’re pretty cheesy but superb for the time.

This was an engineering school so we were predominantly IBM PC’s (this is long before Windows came into play).  Our classes expected us to use PC’s, the software was PC only and I stuck out like a sore thumb.  It was common practice at the time to do all lab reports by hand and to use very expensive chart paper to hand draw lab results and it took many hours to make nice graphs.  I pissed off more than a few classmates off by turning in my lab reports done on a LaserWriter where I used Word, PageMaker and a charting app to chart my data.  The lab TA’s were impressed with my reports despite having crap data and questionable results.  This is when I learned that making it user friendly and looking pretty counts.

The rage of the era was attending Mac User Groups, or MUG’s, where you could meet with like minded Mac geeks and talk about the software you were using, get questions answered, etc.  I started one at school.  I had my own MUG newsletter (for the 30 engineering students that actually liked the Mac).  I hooked up with other MUG’s in the Chicago area and got involved with them and because of that involvement was able to help pay my way through school doing Mac training and graphic design (okay I wasn’t very good at it but I was better than most desktop publishers of the day).

One Fall (I think ’88, or maybe ’89) I went to a MUG conference in Ann Harbor, Michigan.  The keynote speaker was Bill Gates (really!) and he spoke about how well Microsoft Word, Excel, and PowerPoint versions 1.0 were doing on the Mac.  His engineers held breakout sessions that lasted ’til the wee hours of the night listening to what Mac users thought needed improving.  I even shook Mr. Gates’ hand when I passed him in the hallway.  Despite having more money at that point than I’ll probably ever have, he was just your average computer geek.  Go figure.

That conference also happens to be the first place I saw my first 1 GB drive.  It was the size of a suitcase and cost a couple of grand.  As we all filed past we kept muttering, “What the hell would you have that needed something that big?”  Remember, operating systems lived on a 1.5 megabyte floppy drives back then.  We were so naive.

At times it’s been a very long 30 years.  I remember the mid to late 90’s.  It was an ugly time to be a Mac user.  Windows was king of the hill and every year there were fewer and fewer of us.  Even though I was using a Windows PC at work I always came home to a Mac where I was writing software for fun.  I used Think Pascal and Metrowerks CodeWarrior.  I had learned Pascal in college but learned C and C++ on my own.  CodeWarrior was a great development environment in my opinion.

When I finally was smart enough to switch careers – okay my soon to be wife told me to find a job I liked before we got married – I found Visual Basic and Access gig.  It was decent and I did learn to appreciate what Microsoft had done in terms of wiping out alternatives and becoming ‘the standard’.  However, DLL hell and compatibility problems were still issues that plagued even 100% Microsoft shops.

I landed a development job working for an exclusive CodeWarrior shop doing very early Mac OS X development work.  They did a lot of fun stuff but they wanted to do some rapid prototyping of an app idea and since I was the new guy in the office they told me to look at this thing called REALbasic.  I did and without too many issues I created a proof of concept for a photo storage and management application – the iTunes for photos if you will.  Sadly for all of us, iPhoto came out just a few months later and killed the project.  But my intrigue for REALbasic remained and I kept working on small projects and when it could do Macintosh AND Windows builds with just a click of checkbox I was sold!  It was the best of both worlds.

One thing that I recall vividly was my reaction when Microsoft was officially convicted of being a monopoly.  I was sure they would NEVER again have 95% marketshare because the only way they got it initially was to do it illegally.  So far history has proven me right.  Of course the iMac, iPod, iPhone, and iPad have had something do with it.

When I started doing REALbasic (now Xojo) consulting 13 years ago few people cared about Mac versions of their apps.  A few years later when the iMac and iPod started to reinvigorate Apple it was a common theme to do a Mac version to keep the boss happy.  Nowadays, nearly all of our consulting clients want a Mac version first and if we can do a Windows version to keep the accountant happy (who is running some accounting app that’s still Windows only) that’s great.

Thirty years is a good chunk of my life.  I can remember life before the Macintosh but working on that first Mac literally changed my outlook on life and put me in a different path.  There are a lot of things about the Mac that made me a rebel, but also set the quality bar high.  I’m still willing to pay more for things that are of better quality from cars, to tools, to hiring contractors that work on my house because I firmly belied that you get what you pay for.

The Mac inspired me for 30 years.  I’m hoping it will for another 30.  Happy birthday, Macintosh!

Visual Basic 6 on Windows 8.1

Not a month goes by where we don’t get a prospective client asking about the possibility of converting their old (but working) VB6 application to Xojo.  They always tell me that their project is working great in Windows 7 and Windows 8.  Then comes the but.  But, they feel that they’re living on borrowed time and it’s only a question on WHEN Microsoft pulls the plug on compatibility not a matter of IF.

Let’s face it.  VB6 Service Pack 6 was released in 1998 and official support ended in 2008.  I think it’s a testament to its power and popularity that developers are still using it five years after support was ended.  It may also be an indictment of how many felt abandoned by Microsoft in the move to .NET.

So the questions I end up answering for many are these:

Can we convert their VB6 application to Xojo?

The answer is generally yes.  I’ve come across few projects that can’t (or shouldn’t) be done in Xojo.  There are some caveats, though, because Xojo is a cross-platform programming tool.

If you’re looking for fancy grids that you rely upon in Windows you’ll be disappointed.  As a cross-platform tool some controls are the least common denominator simply because Mac OS X doesn’t support or encourage the same types of grid components.  Apple encourages simplicity which forces different design considerations.  Linux has differences too that force compromises.

Reporting isn’t nearly as robust in Xojo as in VB6 either.  While it’s true that Xojo has built-in reporting components most developers I know find it too weak for anything beyond simple reports.  There are a number of third party reporting tools (including BKeeney Shorts, our particular solution) but none of them are as easy, mature, and integrated as Crystal Reports.

Can we easily convert their project to Xojo?

This answer is a definite no.  I don’t care what anyone says, running your VB6 project through any of the available converters will not result in good Xojo code.  From experience, you’ll end up spending more time fixing the things that it didn’t convert properly than if you had just started from scratch.  In our opinion it’s much easier to rewrite the application in Xojo rather than convert it.

That’s not saying you can’t reuse major portions of the VB6 code in Xojo but, as a developer, I want to analyze it and choose what I want to port rather than having it bring over everything.  There are a couple of reasons for this.

  • This first is that Xojo is really good at subclassing controls.  VB6 was horrible at it and many developers have extensive classes and modules to work around this fact.  Little to none of the code that’s in those classes and modules is necessary in Xojo.
  • The second is that Xojo is pretty good at threading.  Much of the app.doevents code you’ve had to add in your VB6 project because of tight loops to avoid the UI from freezing you’ll do away with and put into a thread in Xojo.  There are some caveats with threads in Xojo but generally it’s a better way to deal with time consuming operations that might otherwise freeze the user interface.
  • The third is that the VB6 best way to do something may not be the best way to do it in Xojo.  A number of years ago we converted a simulation application from VB6 to Xojo (then called Real Studio).  The project used an insane number of control arrays  with various levels of overlapping controls.  The logic was very convoluted.  Rather than try to duplicate the exact same functionality in the same way in Xojo, we were able to greatly simplify the logic and put everything in simple classes.  The ‘unit’ in the simulation handled all of its own actions and generated events for the UI to respond to.  The UI simply passed the user action into the appropriate class instance.  Everything was encapsulated in the classes and in the long run they could have used the same UI front end for any number of different simulations.  It wasn’t the VB6 way and it took some convincing that it was a better Xojo way.  In the end they were happy with the results with a solution that ran on Windows and Macintosh (and Linux if they had requested it).

Windows 8.1

So why bring all this up?  For some reason a lot of people have hit a previous blog while searching about Windows 8 and VB6 during the past month.  I did some checking and while Microsoft has said Windows 8 would still have VB6 compatibility built-in, some developers have had issues in Windows 8.1  The workarounds seem to be fairly simple, but I think most people still using VB6 are wondering if this will be the last version of Windows that will still have that.  VB6 does work in Windows 8.1 but will this be the last version?  Only Microsoft can answer that but given their stated intentions of doing annual updates like Apple it seems likely at some point they’ll jettison some backwards compatibility.

Also a consideration for many of them is Mac compatibility and to a lesser extent Linux.  Ten years ago the Mac version was an afterthought for many of our clients.  Now, not so much, in that they need a Mac version to satisfy their customers or personnel.  The past couple of desktop projects have actually been Mac first and then Windows.  How times change.

Finding Xojo Developers

I’ll put a plug in for ourselves https://www.bkeeney.com/bkeeneyconsulting/.  We’ve converted dozens of VB6 projects to Xojo.  Contact us if you’d like a quote.  You can even put your application through our VB6 Analyzer (https://www.bkeeney.com/vb2rbconversion/) so we can get some metrics about what all is in your VB6 project.  The beauty of the analyzer is that we never have to see your project to give you a rough estimate of the cost to convert.

You can also request the Xojo Developers Network to get in touch with you.  Simply fill out the request at http://xojo.com/support/consultants.php and Xojo developers will contact you if they’re interested in your project.

Support for VB6 ended a long time ago but based on the number of contacts I get it is certainly not dead yet.

Xojo: Inspector in Windows

Based on one of the comments from this morning I captured some screenshots of Xojo in Windows 7.  Hopefully this time you can get the side-by-side comparison in the post.  The only thing I’ve done is stitch together the Inspector image so it’s one continuous image.  I think I would have to agree that even in Windows it ‘looks’ like a Mac OS X app and I’d say that’s probably not a good thing for most Windows users.

 

RealStudioWindows XojoWindows

eSellerate Issues with Real Studio

Even though I’m a consultant, I still believe in the axiom that “Time equals money”. So while I don’t have a problem creating my own solution, if there are existing solutions out there I’ll use them. This is why I have the full suite of Einhugur and MonkeyBread Software plugins (including Chart Directory and DynaPDF) to name a few. I acquired the Formatted Text Control and Simple Help Editor when they became available because they scratch an itch that we have as Real Studio developers and they save me time in one form or another.

One item that seems to come up with regularity in our products and for our clients is licensing and registration. Add in web store functionality and it becomes a can of worms. Not that you can’t do it yourself, but most developers (and clients) are in the business of selling their products, not coming up with solutions for web stores, licensing and registration.

For several years we used a web only solution called phpAudit. It worked okay, but the the software wasn’t designed with desktop applications in mind. We made it work but it wasn’t ideal. For one, it required a web connection to check registration and the only way to purchase was through the web and the only payment option was PayPal. Again, we weren’t unhappy with that solution. Heck, several of our clients still use it and are happy with it.

We made the switch to eSellerate for our own products a few years back. It’s a decent solution with a web store solution AND an integrated store so users never have to leave your app to purchase the software. It can accept payment from credit cards in addition to PayPal and several other forms of payment.

It has an offline mode where you can still activate the software even if the end user machine doesn’t have an active internet connection. This came in handy when someone purchased our software while on a ship traveling the South Pacific.

I have had many conversations over the years with people who despise third party solutions like eSellerate because if their service gets broken/hacked then their apps get broken too. This has happened at least once in eSellerate’s history but not recently. While I can’t disagree with their reasoning I find it amusing that they’ve spent an inordinate amount of time trying to come up with their own unique licensing/registration solution. Remember my opening statement about time equals money?

eSellerate requires a plugin for Real Studio and it works on Macintosh and Windows. Until recently there have been zero issues using this plugin. The switch to Cocoa took eSellerate a while to come up with a solution (that you have to ask Support to get, by the way) but that’s okay since Real Software’s Cocoa solution has been in beta for a while.

In Real Studio 2012 Release 1 the plugin API was changed slightly to make applications a bit safer. Until then it was possible for a plugin developer to do some unsafe things and this might have caused instability and hard crash issues. Many plugins worked just fine in this transition but the eSellerate plugin was one of the casualties. Ironically, the Macintosh (Carbon and Cocoa) version works fine but the Windows side of things crashes the application when certain plugin calls are made.

I know there are others who have reported the issue as well, but I first reported it in October of 2012. Since then I have received several updates from them with this being the latest:

I’m afraid I have some bad news.  As you know, we’ve lately had an engineer working on a daily basis to try and resolve the issue with Windows apps crashing if compiled with REALStudio 2012.  The folks at Real Software had been awaiting the results of our engineer’s investigation to try and troubleshoot further.

Unfortunately, as of last week, our engineer who had been working diligently on this case is no longer available.  I’ve taken this matter up with my manager, the director of eSellerate, and she has escalated it above her as well, trying to get some dedicated engineering resources to get this taken care of.  However, it doesn’t appear that we’re going to be able to continue the investigation in the immediate future.  We’re not sure when we may be able to resolve this.

We do understand how important this is for your continued integration with eSellerate, and we sincerely apologize for the trouble.  I’m very sorry I don’t have better news for you.  If it might be possible for you to integrate with a 2011 version of REALStudio, that might be your best bet for the time being.

This is not good news and their proposed solution is less than ideal. As the 2013 release nears completion this issue will continue to grow. Eventually Cocoa will be the defacto build for Macintosh and there will be features in Real Studio that can NOT be reverted to 2012 R2.1.

Because we’ve developed plugins for Real Studio I offered our services to eSellerate. I also contacted Geoff Perlman, CEO of Real Software, to see if they could help. RS has also offered to fix the plugin for eSellerate. So far neither RS or I have received any additional feedback.

So now I’m stuck between a rock and hard place. I can assume that eSellerate will fix their plugin but I’m currently advising one client NOT to do so. What’s the point of converting their entire user base over to eSellerate if they’re going to abandon the Real Studio market. Now, I’m not suggesting that they are, but it’s been four months and they don’t appear to be any closer to fixing this bug then they were in October of 2012.

If I go with my motto that time equals money what are the other solutions out there that handle payment, licensing, and registration in one package with Real Studio applications? I know of Kagi and FastSpring that are being used by some Real Studio developers. What are you using?  I’ll look at just about anything.

Mountain Lion and GateKeeper

Yesterday Apple announced Mountain Lion and released a Developer Preview. It was announced to world through the press which is very un-Applelike. Welcome to the new Apple. As a developer I like that – less uncertainty.

One of the major new features in Mountain Lion is called GateKeeper and I won’t attempt to butcher the explanation. I’ll let the fine folks from Panic tell you via their blog post at http://www.panic.com/blog/2012/02/about-gatekeeper/. Come back when you’ve read it.

I think this is a very good thing from a developer standpoint. GateKeeper seems to be a much wanted middle ground that we’ve been waiting for. It seems to give the best of both worlds for both casual and power users (and most that are in the middle).  Security shouldn’t be so painful that mere mortals (and the average developer) should be punished.

Mountain Lion also integrates iCloud into the OS in a big way. A troubling thing, though, is that to use iCloud services you must be in the App Store (either iOS or Mac). That limits my options as a developer. If I want to make iCloud part of my application then I am forced to sell it through an Apple store.

I know plenty of Mac developers that have no desire or intention of putting their apps into the Mac App Store because they don’t want to pay Apple 30% off the top. Some also dislike Apple’s ‘walled garden’ approach. It feels as if Apple is punishing us by cutting off access to iCloud.

Most of the readers of this blog use Real Studio and many are concerned with non-Mac platforms in addition to Mac OS X. I don’t know the answer to these questions: Can we currently include iCloud services in our Windows builds? And will this change for the Mountain Lion release?

Does the move to GateKeeper change the March 1st deadline for SandBoxed Applications sold through the Mac App Store? It seems that this hasn’t been answered yet and I’m not the only one that feels this way. See http://www.pcadvisor.co.uk/news/software/3338240/developers-unsurprised-but-cautious-about-gatekeeper/ for more details.

While it’s still too early to have an opinion about Mountain Lion, GateKeeper and iCloud integration are both exciting and mysterious at the same time. I’m hoping the new Apple does a better job of telling developers what our options are.

 

Will VB6 Apps Continue to Work in Windows 8?

Will VB6 Apps Continue to Work in Windows 8?  That single question has driven more traffic to this website in the past month than nearly any other question.  I believe VB6 still has a very large user base so it’s very pertinent question for many organizations and developers.  Perhaps Real Studio is an option for them, but we’ll get to that at the end of the post.

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.

Is Windows 8 the End of VB6 Support?

I was a Visual Basic developer for many years.  Despite the perception that VB 6 made crappy apps, I know of many successful commercial apps that were written in VB6 and, what matters more, is that those apps are still in service.  Despite Microsoft dropping support for VB6 years ago developers were able to limp along and get their apps working in Vista and Windows 7 with few headaches.

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.