Updated July 31, 2015

Synergex®, which began as DISC in 1976, has been writing cross-platform development tools for over 30 years. We sell our tools (Synergy/DE®) to a network of ISVs and corporate end users that range from small businesses to Fortune 100 companies.

Synergy/DE is built around Synergy DBL, a flexible, object-oriented language with roots in ANSI DIBOL that runs in multiple environments, including .NET. Synergy/DE runs on many UNIX platforms, OpenVMS, all Windows systems and devices, as well as Mono on Android, iOS, and Linux. These tools are based around a set of tried-and-tested core runtime technologies, which were originally written in C, but are increasingly written in C++. We and our customers have been involved in cross-platform development since the early 1980s. Our first 64-bit-compatible release, which was based on our common code base, came a few years later in 1992. In 2010 we extended our support to .NET, and in 2014 we added support for Mono on Android, iOS, and Linux. This year we added support for Windows Phone and Windows Store.

Originally our involvement with Visual Studio was limited to debugging for Windows. We used command line build tools, vi, and local system debuggers (such as GDB) for development. This changed when we started developing for the .NET stack in 2010, where we had a mix of Make-based builds for cross-platform development and MSBuild for Windows-only development. At this point we also started using Visual Studio as our IDE for Windows development and integrated our language with it so our customers could use Visual Studio as the IDE for their .NET development. This integration has gone very well, and thanks to the extremely helpful VSIP team and VSIP dev labs, our language integration is complete enough to compare favorably with the C# integration. Ours is the only integration (outside Microsoft’s) that includes an expression evaluator for the new Visual Studio 2015 debugger (Concord), and we were probably the first to build a language service entirely based on MEF editor extensions. We are currently working in conjunction with Microsoft as we re-implement our project system.

When we moved to Mono, which expanded our cross-platform support to Android and iOS, we set up an Ubuntu Linux machine to build Android and iOS clients. Setup for the development environment was complicated, requiring a number of third-party tools, and we used a different build system (CMake) to make the clients. We then used a Windows machine to create NuGet packages for our managed runtimes and their unmanaged counterparts. Native debugging in this environment is very poor and generally relegated to using printf statements (a flashback to our 1980s roots). We still use this development setup and approach for iOS, but for Android we’ve been able to move much of our development to Visual Studio, which has greatly simplified the process. For Android we now use a Visual Studio solution (based on the C++ Android project template), we use MSBuild to build it, and we are able to use Visual Studio and Xamarin debugging for managed code debugging tasks.

There is no native-only debugging in processes that interact with managed code, and there is no mixed-mode debugging to enable us to step from managed to unmanaged code in the x86 emulator. So in many situations we’re still forced to use the primitive debugging methods we use for iOS—e.g., printf statements.

Printf-style debugging is a time-consuming hit-and-miss process. For every iteration (and there can be many), we have to rebuild and redeploy multiple components, run the app, get the log file from the device after the program fails, analyze the results, and then engineer a new set of printf statements for the next attempt to narrow down the suspects. There’s no shortage of examples we could use to illustrate this, but here’s a recent one: We had a bug caused by a misunderstanding about case sensitivity on iOS. Our application contained managed and unmanaged code, and Visual Studio debugging quit where the unmanaged code began. The problem was in unmanaged code, so we had to go to great lengths to root it out. We modified our unmanaged runtime so that it printed debugging statements to a channel with an open file and then used the output to work our way to the problem. An integrated Visual Studio debugging experience (fixed with VS 2015 RTM for Android) would have exposed the problem in minutes rather than hours.

Now we’re focusing our efforts on moving our customers and our own development to Visual Studio 2015. Initially, we ran into problems with the Linux-built unmanaged runtime, which would not work with the new, faster Microsoft Android emulator. To work around this, we created a shared project for our runtime and added the Android components, which enabled us to build them directly under Visual Studio 2015, rather than Linux. The Clang compiler distributed with Visual Studio 2015 exposed problems in our source base that Clang for iOS and GCC failed to uncover (but given the importance of alignment on ARM, we were surprised at the lack of alignment warnings reported by default on Windows). We’re using this approach to build our iOS, Windows Store, and Windows Phone components as well.

We are currently working with Microsoft on the debugging issues discussed here for iOS. Addressing these will make Visual Studio the clear winner in cross-platform development.

Thanks to this partnership with Microsoft, we continue to bring our development processes and our products forward to new platforms and technologies. This has enabled us to pave the way for our customers to move their enterprise applications forward, leveraging their investment in their current code as they also move to these new platforms and technologies.