Tuesday, September 30, 2008
Monday, September 29, 2008
Wine is a program that runs MS Windows applications on Unix-based systems by providing a compatibility layer by implementing some of the Windows APIs and wrapping the others to call native Unix functions, X server, and OpenGL. Wine implementation is all in userland (outside the kernel and doesn't need special privileges).
Wine was originally short of WINdows Emulator, but I a am not sure about if that's still the case. "Wine" is originally a recursive acronym "Wine Is Not an Emulator"[A]. (Update) Wine is more of a compatibility layer than of an emulator. An emulator usually emulates hardware, like a Playstation emulator (offtopic: I know a good one called pSX).
Wine doesn't only implement Windows system calls, but also most of the DLLs that comes with
Windows. Most notably DirectX (which is one of the top reasons to use Wine; playing Windows games on Linux). If you are a windows license owner you can use some of the native Windows DLLs instead (but others can't be used).
ReactOS is to Windows as Linux is to Unix. A free and open source alternative. It uses Wine code. Several other commercial projects uses Wine too, like TransGaming Cedega and CodeWeavers CrossOver (and others). The former is a fork of Wine specially for gaming, they do NOT send their patches to the main-stream Wine. The latter is both a general-purpose and gaming-purpose dedicated development for Wine. Unlike the former, the latter sends it patches instantly to the main-stream Wine. It relies mostly on support for profit (as for what I understood).
Google have paid CodeWeavers to make Wine able to run Photoshop CS 2 on Linux. CodeWeavers also have acted quickly to to make Wine able to run Google Chrome on Linux, and they made it in 11 days. Google has actively encouraged Wine development through their interns  and through student participation during the Summer Of Code 2008 .
The only Microsoft acknowledgment about Wine, is to state it is not Genuine Windows and therefore deprived from Windows Genuine Advantage (some downloads).  Generously, Microsoft still allows some updates, like Office updates to Wine users. [same source]. (See  for instructions how to install Office 2003 on Linux.)
Wine is not small at all. WINE 1.0 have over 1.8 million lines of C code (with blank lines and comments), ~300,000 of which are tests, and ~87000 are related to Direct3D (a subset of DirectX) implementation[original research]. I am not sure how big is the Micorsoft Subsystem for Unix-based Applications (SUA)(*1), but I am sure it is much less. That's because what a Unix program assumes to find in a system is much less that what a Windows application assumes to find (which are thousands of Windows APIs).
Due to the large amount Wine has to implement, it doesn't implement all of the Windows APIs yet. A program that depends on an unimplemented API might not function correctly. Wine developers try to implement high-priority APIs first. Those are the ones used by the most popular applications. (For a list of which programs are compatible with Wine check Wine AppDB)
Wine have been in development for more than 16 years (since 1992); even before Linux was born. Wine's still not complete, because it faces the problem with catching up with more recent Windows systems. For example (not saying that this have actually happened), when they completely supported Windows 95 applications, they were struck by XP, and then XP SP 1 and Windows 2000 (just an example, I know there are several editions in the middle). Wine development is indeed much slower than the real development pace of the real Windows (thousands of organized developers vs. hundreds of random contributers - ~700 have contributed to Wine somehow ).
Wine is binary compatibility layer, which means the binary executable can be executed both on Windows and Linux without modifications. While MS SUA is source compatibility layer, which means the same program will have two executables, compiled differently, but from the same source, in order to run on both platforms.
Wine's web page: http://winehq.org/ .
Other references and links:
 Linux Unified Kernel is a project to implement Windows system calls (only, not the entire set of APIs) natively in Linux kernel.
 Unlike Windows system calls (http://www.metasploit.com/users/opcode/syscalls.html), which are less than 400 in Windows Vista, the entire set of the windows APIs are much more (http://www.codase.com/windows.html)
Saturday, September 20, 2008
NOTE: This text (part I and part II) is just an introduction to the existence of an alternative, not a guide to use that alternative.
Because I -personally- believe that an example is worth a thousand words, I will tell you my personal experience with iterative development; the story of our graduation project. We only tried iterative development when other ways failed.
Our graduation project was a clustered server for massive multiplayer online games. The entire period for the project to come out was approximately 10 months, overlapping an academic year.
We've spent almost 9 months of them in the design phase; the project turned out to be very big and needed some research and novel techniques. For 5-members team who doesn't know anything about clustering we needed that much time.
Anyways, having only one month left to hand the project, there was no single line of code. We thought that we already have an exhaustive list of classes and functions and it's only a matter of implementation.
Trying to implement the classes we designed, we had no idea how to start, and just -exactly- after 4 functions we totally lost contact with the design and didn't know how to proceed. We were overwhelmed by the complexity and inter-dependencies between modules that it was NOT possible to see anything running before at least thousands of lines of code, which will need even more time to fix (cuz they were not tested).
That seemed inappropriate for the 1-month due time. Our main problem was the inter-dependencies of the modules. That's where iterative development kicked in. (Note that changes in the server and the game affect each others so they have to be done according to each-other step by step).
You will notice in the following sequence that at any point of time we could
A. Hand something that worked, not complete, but works.
B. Features are added incrementally. That means at the dead line we will have N features working, compared to a complete set of features that doesn't work at all.
1- The ping server
The first thing we did is to implement a simple server and test if the game (which was not practically a game then :D) can connect and exchange messages with it. - day 1
2- Simple actions
Then we implemented simple actions to make the game work and players interact - the server is not clustered and there is no state persistence or anything. - day 3
(Starting from here, the server development and game development was going in parallel)
A. Server development
3- Splitting the server
After that we implemented a simple layer above Java Remote Method Invocation (RMI) to be able to split the server on the set of computers in the clusters, and to make debugging easier (that layer could be disabled to run the whole server on a single machine). - day 9
4- Persisting the state
Also, we've developed something we called Object Store to provide transparent persistence using aspect oriented programming. - day 26
5- Work that was not complete until we handed the project
Proper Object Store synchronization between several machines, database replication, security checks, traffic control and traffic load balancing, server peer to peer load balancing, distributed administration.
B. Game development
3- Adding a few actions each day to extend the things the player can do. First walking, then attacking, then riding a car etc. (That's very simple view, the actual actions are numerous and much more complicated than that). - Until we handed the project
Using iterative development, we've faced the overwhelm we had from the extreme complexity and actually delivered something that was working and people can actually play and enjoy. Compared to waterfall model, nothing would have been delivered in the deadline, and there would have been an implementation paralysis, and an elongated testing phase which might require lots of parts to be reimplemented too.
It's like splitting a big project into smaller projects with limited set of features, and doing that over and over until it's enough or you meet the deadline.
More visibility, for the developer and for the client, the client can make changes early (cuz client don't know what they want !
Can deliver at any point of time
Adding new features later can result in modifying existing code or removing it, which is the cost tradeoff of using iterative development