Sad times

[ErnieE]

I am not sure how I feel about all of this. In my entire career I have used Microsoft technologies and have not had any issues with Beyond Compare. I was introduced to this fantastic product because the (rather large) software company I was working for had a site license for V2 and I have installed either that site lic, or my own personal license more times than I want to count. I find BC so "right" that any other comparison tool hasn't "been right" for me.

As a software professional I completely "get" how hard it can be to chase dozens of targets and a company NEEDS to make reasonable choices to support the platforms that actually make them money.

Within the last year (and even more so in the last 4 months) my career has taken me on a trajectory that moves the vast majority of my development tasks into Linux (Debian 7.1 for Development/Ubuntu 12.04 LTS production servers) and OS-X for iOS/Android platforms. If I still had a Windows 7 VM on my machine the only program I would use is likely BC3.

I have been hoping that Scooter would be able to "do something" to improve this situation, but I guess that "other" platforms are still not generating enough revenue for the company to really give them support. In the last 3-4 years I haven't installed a 32bit OS (for development) and MS does a reasonable job of supporting "old" code. (Heck, Visual Studio was still 32bit the last time I checked.) However... for all production code that I have written in the last 2+ years has been 64bit.

Why am I sad? Beyond Compare is a fantastic tool and I really WANT to continue using it for code reviews and check-in control. I can't be the only developer in the world that has made the move to 64bit and not really looked back. The effort required to use the tool and "deal" with all the platform restrictions is just too much. Every time I go looking for another tool, I've come back to BC when working with Microsoft platforms.

It is my sincere hope that Scooter Software survives and that Beyond Compare makes the transition. I ~know~ how "f-ing" hard cross platform development is. Linux and OS-X/iOS/Android have moved past "it is a fad" and "nobody got fired for choosing Microsoft" (yes, I am stealing that phrase from the old "IBM" version) is no longer true. I hate how fractured the Linux world is and Apple isn't a developer's best friend either. I am not certain that MS "can't win me back" but at this point even Windows 8.1 looks "sad" to me.

My point? Back when it was ~clear~ that Windows 3.1 was going to dominate the market I was at a company that refused to acknowledge the "winds of change" (Scooter obviously isn't as blind) and because 100% of our customers were still using DOS, "management" refused to invest in the future seriously. We had pilot programs, but a competitor that eventually hired me ended up taking a huge percentage of the previous companies business as clients began to make the move into Windows and found that the "old and crusty" wasn't "good" anymore.

At the moment, AWS Linux based cloud servers dominate our production and it is increasingly easier to have a development platform that is more inline with how the server environment works. More and more opportunities are in the mobile space, and again the dominate platforms are better supported on anything ~but~ "Windows."

Will Microsoft pull it together? Would I bet ~my~ company on a single platform today? Nope. It is still a crap shoot between Linux/OS-X and MS. (The highly modified Darwin kernel is still "Linux enough" IMO.)

Again, why am I complaining? The latest releases ~still~ don't support ~my~ setups and I guess I am whining.

If you got this far, thanks for reading.

[Zoë]

Hi Ernie,

I'm not normal tech support, so if you've been going back and forth with them, I can't comment on that. I will say that we want to support Linux as well as possible within our capabilities, and if there are specific issues that you haven't reported please do so so we can look into them.

That said, we are supporting both Linux and OS X as best as we possibly can, but some decisions that we made in the past haven't worked out like we hoped.

Beyond Compare is written in Delphi, which, fancy graphics aside, is still an excellent Windows development tool and in the 90s and early 00s was definitely the best choice for the product. Unfortunately, Delphi is Pascal based, which greatly limits the number of compilers we can choose from and BC itself is not small (when compiling the current developer branch it's ~2.4M lines).

When we started porting to Linux Borland/Inprise had version of Delphi for Linux named Kylix, which allowed us to share most of our code between the platforms and, with careful work and compatibility shims, even allowed us to share the GUI code. At the time we decided on the platform Kylix was still being developed, and even after it was discontinued Borland was making noise that they'd open source part of it and allow the community to keep developing it. Unfortunately, that never materialized, and the product was thoroughly dead by the time we released v3, but by then it was too late to change things. We haven't been able to create a 64-bit build because the compiler doesn't support it and the GUI layer we have is built off a Pascal wrapper for Qt3 that we don't have the expertise to update to Qt5.

After v3 it was getting increasingly obvious that we needed better Linux and OS X support, and that Delphi would need to re-introduce that support, so we held off on serious porting work until Borland (now CodeGear/Embarcadero) revealed what their plans were.

We were in the beta for their first OS X for Delphi release, which was based on Qt4 and an updated version of the GUI layer we already had, and which would have allowed us to bring BC up to speed on both platforms extremely quickly. We were expecting to release BC for the Mac soon after they finalized their code, in 2010. A month before RTM they pulled the plug the Mac support from the release. At the time we thought it would only cost us another year, but the beta for the next version, 6 months later, removed that support entirely, and replaced it with a new 3D accelerated widget set they bought from a third party and which was completely incompatible with our existing code. Unfortunately, it was also extremely buggy and slow, and that hasn't significantly improved in the last 2 years.

Once we realized how bad things were started looking for alternatives to get BC on the Mac as quickly as possible. For it we've switched to an open source alternative which is mostly compatible, and we've been working on it for almost 3 years now. Initial work progressed very quickly, but it's buggy and less supported than we'd like, and getting the release to the point where we're happy with it has taken us far longer than we expected.

We're alpha testing OS X support right now. Unfortunately (again), while this work does help with eventual Linux updates, we've had to hold off on those to get the Mac version out, and it doesn't get us to either iOS or Android. AFAICT, though, it is the only viable approach that we could take to get BC on OS X without rewriting it from scratch.

All that said, once we get there, the technologies we're using today are still largely dead ends, and once BC4 comes out we will be seriously evaluating what it will take to rewrite BC in either C++ or C#. I hope that Delphi gets its act together by the time we're seriously working on that, but I'm not holding my breath anymore. I wish we'd done that rewrite either immediately after BC2 shipped or immediately after BC3 did, but in both cases it didn't seem like it was necessary until it was too late.

[ErnieE]

Craig,

Wow. Thanks for the history. I completely understand. "Many, Many moons" ago I re-wrote/ported an application (1989!) from Turbo Pascal to Turbo C. That was "pre-GUI" and it was painful enough. I really dig C# (more precisely I think that IL, the underlying "code" that lives in assemblies produced by C#) is a far superior technology to Java Bytecode (This is my opinion and both have merits.) The major negative (IMO, again) is that the technology has made little real progress beyond the halls of "Microsoft platform's." If all you are targeting was MS platforms C#/Managed/IL would be a great choice. However... the "story" beyond MS is less than awesome.

I am not a huge "fan" of Java, but it has a "better cross-platform" support story.

That being said, I think that LLVM has a REAL chance to trump even my "vast" preference (which may be influenced from being a staunch supporter of ".NET" from the very early days in the late 90's) of managed code. The key is "vendor buy in" and now that Apple has pulled the trigger on "dropping" GCC from XCode5 in favor of LLVM/LLDB there is some heavy weight behind the technology. LLVM is a much better JIT platform (in a number of ways) than Java Bytecode or IL. (Again, this is ~MY~ opinion and many might get "all up in my face about it.")

My only comment is that if you ~have~ to "start from scratch" pick a "modern" language that is likely to survive. I cut my teeth on Basic, Assembly (6502) and Pascal, but quickly moved on to C then rapidly C++ in the early 90's when Borland introduced the "first affordable" compilers. To this day, I ~still~ declare all my functions ABOVE where they are called (a habit I picked up from Pascal, and also from being lazy about not wanting to have to ALWAYS forward declare my functions) even in C++ class declarations!

The last company I worked at, has some projects that are built with Delphi as well, and trying to do any real development in Pascal is a massive challenge. I looked at some of the code and it brought back memories, but the code was poorly written (not Pascal's fault!) and I wouldn't touch it with a 1 billion meter poll. ;-P.

Picking a platform is hard and prone to risk. One of the goals of the C language was "portability" and that gave it a little of an edge. I didn't see the same focus with Pascal, but the Language has always had the ability to be "portable."

"You guys" have some extraordinarily difficult choices ahead. I know what ~I~ would do, and even THAT is risky. Given the investment (both mental and monetary) in Pascal I understand the desire to want to avoid the upheaval of making the jump. If you are lucky, you will choose wisely and make "insane" amounts of money.

Good luck!

[Aaron]

I'd like to add that while BC3 is a 32bit application, we do support the 64bit versions of these operating systems (Windows and Linux) due to their backwards compatibility support. BC3 can run on a 64bit Linux OS, with the proper libraries, and be interacted with normally. It would just lack some of the advantages of a 64bit application, like increased memory access.

[abraxa]

Hello,

I'd like to say that it's rare for companies to be honest with their customers, and so I would like to applaud you for being honest. While I do understand the tough situation you were in a few years ago (and can continue using Qt4 for now), I'd like to know if you have found a solution to the dilemma. Personally, I assume a re-write in C++ to be the only viable option and looking at the time that BC4 has been around, I wouldn't be surprised if that's the way you're going. If so, is there some kind of alpha or beta test program that I could join?

[Zoë]

Hi abraxa,

In Beyond Compare time, v4 hasn't been out for that long. We've historically gone 6 years between major versions (v1 in 1996, v2 in 2002, v3 in 2008, and v4 in 2014), with lots of featureful x.1, x.2 upgrades in between. Apple removing 32-bit support next year, and Qt4's deprecation, has forced some shifts to our schedule regarding v4 and v5, but we're dealing with the changes. We don't have anything to announce regarding a alpha or beta yet, but there will be one eventually, and we will post in the News & Announcements forum and Facebook/Twitter when signups or a download are available.

The Delphi situation is better now than it was in 2013. The open source project I mentioned in my earlier post (Lazarus) allowed us to finally upgrade the Linux version to Qt4 and 64-bit in v4.1. Lazarus now has a Qt5 backend and the macOS Cocoa one is fairly far along. We're moving off the Qt4 and Carbon backends as quickly as we can, but we've had to bypass the abstraction layers a lot to make BC work the way we want (especially on macOS), so it's been slow going. Looking forward, Delphi's 3D accelerated replacement has had 5 more years to mature, and they recently added a Linux compiler. Re-doing the entire GUI would still be a ton of work, and that's not currently a priority, but if it comes to it, I believe it will be a viable path forward.

[abraxa]

Thanks for the feedback, Zoë

While not quite what I expected to hear, I'm glad you found a way to continue development. Looking forward to a Qt5-based build!