Case Study: SynaptiCAD

By Dan Notestein
President/Co-Founder, SynaptiCAD Inc

SynaptiCAD (http://www.syncad.com) makes electronic design automation (EDA) software: software for hardware engineers developing digital IC's. We've been developing our software since 1992. My partner and I wrote our first product, which ran on Windows 3.0 and was creating using the first Windows-based C++ compiler IDE, Borland C++. We currently employ about 20 C++ programmers, most with a background in digital hardware.

Product

We have a common GUI for 6 different products. The GUI is a C++ Win32 application that uses Borland's OWL library (similar to Microsoft's MFC library). The products include a Verilog simulator, a Hardware Description Language debugger (Verilog and VHDL), a HDL testbench generator, a digital waveform viewer for viewing gigabyte size data files, a timing diagram editor, and a waveform translator for transfering back and forth waveform data between simulators and digital test equipment such as logic analyzers, pattern generators, and oscilliscopes. The entire application is over a million lines of code and consists of 70 custom libraries (some dlls, some static libs) and 10 public domain or LGPL libraries (STLport, Boost, ACE, TAO, tcl lib, perl lib, CppUnit, zlib, expat, cryptoPP).

Initial situation

We do our primary development in Windows under MS Visual Studio .NET, then port it to Linux and Solaris using WineLib. On Unix, we use Scons as our make facility, g++ as our C++ compiler, and gdb and totalview as debuggers.

A large portion of the EDA market is Unix-based (a lot of Solaris, some HPUX, and a rapidly increasing amount of Linux-based systems), so it is important for us to support these platforms as well as Windows.

Problem

Given the huge amount of GUI code, a traditional port from Windows to Unix was simply not feasible and the maintenance effort to keep two such code bases in sync would be tremendous, so WineLib has been an excellent solution for us. If we were starting product development for the first time today, a cross-platform framework would be the obvious way to go, but trying to convert to a different framework API now would also be a huge undertaking.

The solution: Using WineLib

Prior to using WineLib, we used a commercial Windows porting library called MainWin, but the closed nature of this library (non-open source) forced us to rely on the vendor to fix any bugs and performance problems and we also found their licensing policies somewhat surprising, so we decided to make the switch to WineLib.

Synapticad's in-house programming staff did all the work. The primary work was done by three of us (the more Unix-experienced guys). Not surprisingly, we ran into Wine bugs along the way (especially in the Solaris port), but they were relatively easy to fix. We also had to add a feature to Wine ourselves so that the user sees "unix style" paths instead of drive letters in File Open dialogs. And, since our change didn't make it back into the main Wine tree, we have had to maintain that feature ourselves whenever we update to a newer version of Wine. We've only had to do that once.

We use a single binary for all our linux versions. This can be a bit of a challenge, but it keeps us happier in the long run. We guarantee support for RedHat 7.2, 7.3, 8.0, 9.0, Fedora Core 3 and 4, RHE 3, RHE4, and Fedora Core x86-64. We are also believed to run on Suse, but we don't test for this internally. We haven't done testing on any other versions of Linux as of yet.

We launch our application from a shell script which sets the WINELOADER, WINEPREFIX, and WINESERVER environment variables. This avoids problems when installing our application on a computer which already has Wine, and lets the user work on multiple types of X terminals simultaneously.

The performance of our application on Wine is quite reasonable, and the effort involved has been far less work than a traditional port!

[Back to "Shipping Your Windows Application for Linux using Wine"]
Last Change: 15 Dec 2005