DNA Sequence Assembler on Linux

Now, you can run DNA Baser on Linux via WinE.

What is WinE?

Think of Wine as a compatibility layer for running Windows programs on Linux, FreeBSD, Solaris and Mac OS X. Wine does not require Microsoft Windows, as it is a completely free alternative implementation of the Windows API consisting of 100% non-Microsoft code.

How much does it cost?

Nothing. WinE is like many other Linux programs 100% open source and 100% free.

Do I need also Windows to run DNA Baser on Linux?

Absolutely no. WinE offers all API support that our tool needs to run on Linux.

Do I need an antivirus program if I run Windows software in my Linux computer?

Absolutely no! You are not running the whole Microsoft Windows OS in your Linux machine, but only one single Windows based application: DNA Baser. DNA Baser has been scanned with several top antivirus products and it absolutely clean. However, if DNA Baser is clean or infected is totally irrelevant because you are running it in a "sand box". Because of this isolation, there are no security concerns.

Debunking Wine Myths

Here are some common Wine "myths" that are either completely wrong or not very correct:

• "Wine is slow because it is an emulator"
• "Wine is bad for Linux"
• "Emulators like VMware are better"
• "You need Windows anyway"
• "Wine is bad, Winelib is better"
• "Wine will always be playing catch up to Windows and can't possibly succeed at running new applications"
• "Because Wine only implements a small percentage of the Windows APIs, it's always going to suck"
• "Wine is only for Windows 3.1 / Wine will never support Win64"
• "Wine is for Linux only"
• "Wine is for Intel x86 only"
• "My game has copy protection that doesn't work with Wine"

Myth 1: "Wine is slow because it is an emulator"

Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine's name says: "Wine Is Not an Emulator": Wine does not emulate the Intel x86 processor. It will thus not be as slow as Wabi which, since it is not running on a x86 Intel processor, also has to emulate the processor. Windows applications that do not make system calls will run just as fast as on Windows (no more no less).

Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that's theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.

Myth 2: "Wine is bad for Linux"

One undeniable fact exists: there is a vast software library that works with Microsoft's operating systems. Many of these applications already have Linux equivalents, however for most people there remains a handful of programs keeping them tied to Windows. Some of these programs have almost no chance of getting ported to Linux (e.g. Microsoft Office), others simply can't be ported because they've become abandonware (e.g. TurboTax 1999). Would I want to have Windows just because someday I may need to access an old tax program?

The fact that Wine exists won't prevent companies from porting their software, but having less than a few percentage points of marketshare will. Wine puts more free software into the hands of people who would otherwise not use it. In turn, history has repeatedly shown that larger marketshare leads to more commercial development. More commercial development has always led to more efforts to develop better free software equivalents.

Myth 3: "Emulators like VMware are better"

Sure they're better.. if you like purchasing a full copy of an operating system just to run it under a virtual machine. Not to mention you need to purchase a copy of VMware to make it work.

Oh, and don't forget the huge performance hit you take to run an application on a full-blown operating system running on top of an operating system.

However, having said that there are instances where emulators are quite useful. Developers can create sandboxes to run applications in, test other operating systems without rebooting, etc. But having a full-blown emulator just to run a word processor probably isn't the best solution.

Myth 4: "You need Windows anyway"

No. The goal of Wine is a full reimplementation of the Windows API which will make Windows unnecessary.

You can already run a lot of applications without having Windows installed. But you have to realize that because Wine is still far from completion many applications will indeed require Windows for some functionality that Wine does not yet provide itself.

Myth 5: "Wine is bad, Winelib is better"

This seems to be a quite popular myth on Slashdot. Basically some people think that running a regular Windows application with Wine is much less reliable and yields much lower performance than recompiling this same application with Winelib. It seems to be a variant of the 'Wine is slow because it is an emulator' myth.

There is really no reason for this. For starters I certainly did not observe any performance difference between Wine and Winelib for the (relatively few I admit) applications I tested in Winelib. Furthermore you have to realize that bugs are not in the way Wine handles PE, i.e. Win32's executable format, programs. Bugs, and performance issues alike, come from the implementation of the Windows API and this is shared anyway.

Myth 6: "Wine will always be playing catch up to Windows and can't possibly succeed at running new applications"

The architecture of Wine makes adding new APIs (or DLLs) fairly easy. Wine developers rapidly add functions as needed, even applications requiring the latest functionality are usually reported working within a few months of release. Examples of this include Office XP and Max Payne (a DirectX 8.0 game) - both of which were fairly new as of this writing (5/2002.)

In addition, Wine supports using native DLLs when the built-in versions don't function properly. In many cases, it's possible to use native DLL versions to gain access to 100% of the functions an application requires.

Myth 7: "Because Wine only implements a small percentage of the Windows APIs, it's always going to suck"

APIs are like a library - it's always nice to have as many books on the shelves as possible, but in reality a few select books are referenced over and over again. Most applications are written to the lowest common denominator in order to have the widest audience possible. Windows XP support is simply not that important - most applications only require Windows 95 or Windows 98. Currently Wine supports over 90% of the calls found in popular Windows specifications such as ECMA-234 and Open32. Wine is still adding Win32 APIs, but a lot of the work right now involves fixing the existing functions and making architecture changes.

Myth 8: "Wine is only for Windows 3.1 / Wine will never support Win64"

Wine started back in the days when Windows 95 did not exist yet. And although Windows NT (and thus the Win32 API) already existed, it only supported Windows 3.1 applications. Anyway, almost no-one used Windows NT in that time anyway.

But these days are long gone. Since August 2005, Wine advertises its version as Windows 2000, and for several years before this it was Windows 98, so really Win32 is the primary thing Wine supports. Support for Windows 3.1 applications is still around, of course, as is some support for DOS applications.

Win64 support would allow Wine to run native Windows 64-bit executables, and as of February 2006, Wine does not yet have this support. That's okay, since there are very few commercially available Win64 applications. One exception, Unreal Tournament 2004, is available in a native Linux 64-bit version, so nobody (except maybe a Wine hacker) should want to run the Windows version anyway.

This doesn't mean that Wine will not work on 64-bit systems.

Myth 9: "Wine is for Linux only"

This is just plain incorrect. Ok, as of now Wine does not run on many platforms: just Linux, FreeBSD and Solaris. Still, this is not 'Linux only'.

It is true too that most developers work on Linux. So you run a higher risk of having a specific release of Wine not compile/work on a non-Linux platform. But this is usually fixed in the next release. Also Wine has been known to be missing some important functionality on non-Linux, e.g. good multi-threading. As far as I know these problems are now solved and Wine works just as well on any of the three platforms mentioned above.

There also is a Win32 compatibility project for OS/2, which makes use of Wine code.

Myth 10: "Wine is for Intel x86 only"

Well, it is true that Wine only runs on Intel's x86 processors. Unfortunately it will also require quite a lot of work before it runs on other processor architectures.

But what do we mean by 'running on a non x86 processor'.

First it can mean 'I can compile a Windows application on Sparc, link it with Winelib, and have it run on Solaris'. I know, this is not what you had in mind. This may seem very restrictive and yet would be very useful: it means easy porting of Windows applications to almost any Unix architecture. In any case this is the first step towards allowing Wine to run on other processor architectures. Unfortunately Wine's code is not very portable to other processor architectures, partly because some parts of it have to know a lot about the processor, and partly because most of it makes assumptions like 'sizeof(int)==sizeof(pointer)' and 'byte-sex==little-endian'. This is being worked on though, and progress is being made albeit slowly.

Then we could take it to mean 'Wine on Alpha should be able to run Windows NT Alpha applications'. The prerequisite for this is that Winelib compiles on Alpha (or MIPS, the other defunct Windows NT platform). Now, would it be really useful? I don't think many people have Windows NT applications for the Alpha or MIPS processor. So this is probably not that useful and also rather unlikely to happen since we would need a programmer who has just this combination of hardware and software to work on it.

Then there's what everyone has been waiting for: 'I want to be able to run my x86 Windows applications on any processor architecture I like. That's the most complex one. Again the prerequisite is that Winelib works on this architecture, which will definitely happen someday. Then 'all that is needed' is to integrate an x86 emulator with Wine (and also change Wine's name :-). Ulrich Weigand just did that as an experiment some time ago when he had 'some spare time'. He even managed to get some Win16 applications to run. His code was not in a state where it could be integrated into Wine yet and I don't know how much work has been put into pursuing it. His attempt did spark many discussions on Wine's mailing list though. The result is that we would need a sophisticated emulator including a JIT in order to get something really viable (i.e. not too slow). And developing such an emulator is a whole project in itself.
Does it mean it will never happen? Not sure. Maybe we'll get some motivated developers once the Winelib problems are solved. Of course, it would happen much faster if, for instance, Compaq made its Fx32! Intel x86 emulator Open Source and financed the development of Wine for their Alpha machines. As with all Open Source projects, if enough people are interested and pool their resources together, it will happen.

Myth 11: "My game has copy protection that doesn't work with Wine"

Currently SecuRom works in Wine, and directory objects support has been added to get us toward implementing an ntoskrnl.exe that will support loading copy protection drivers like Safedisc. Once ntoskrnl.exe is implemented Wine will have full support for Safedisc versions 1 and 2.

Note:

  DNA Sequence Assembler is a Windows native application. Even though we will try our best to offer you support, we cannot make any warranties.

  In case DNA Sequence Assembler refuses to run under Mac or Linux, please delete all skin files (*.skn) in "DNA Baser\System" folder and run it again. This should solve the problem.

You may also want to try CrossOver