Slashdot Mirror
Developing WINE-Friendly Windows Software?
Michael Fourdraine asks: "I'd like to hear the Slashdot community view on if there is any merit in trying to develop a Windows compatible software and trying to make it compatible with WINE. Personally I have had no experience in Win32 or Linux software Development, but I still wonder if it is possible to develop a game to run under Windows and optimize it for WINE at the same time. If so, why don't developers take advantage of that option? Or does it simply make more sense to stick to developing one product and then port it to multiple platforms? Finally if there is anyone developing any software in this form what do developers keep in mind during development in order to ensure smooth usage under WINE?"
Programming specifically for an emulator (I know WINE Is Not an Emulator) is counterproductive. Emulators tend to introduce its own ideosyncracies that the programmer must wrap around. Programs written with an emulator in mind will be dependent on two artifical limitations: that of the intended API and the emulator environment and in many instances, these two environments can be exclusive of each other so you can be stuck with satisfying only one option.
Writing specifically for Windows gives Microsoft more validity. Supporting WINE implies that you are pretty anti-Microsoft and that your actions are meant to negate the purpose of Microsoft's framework. By making an application fall under both Windows and WINE, you are supporting Microsoft while trying to lead away Microsoft users, a bad idea. The whole reason for WINE's existance is to provide a temporary bridge between Windows and Linux so that users entrenched applications can migrate over. WINE is meant to support older applications only. Pre-existing applications normally require a high cost of porting. When you write your application, you have the freedom to choose which operating systems you want to support and therefore the entire WINE paradigm is moot.
The best approach would be to make the core of your application portable while implementing OS-dependent support modules that handle every function that depends on a specific OS, either Linux or Windows in this case. If the Windows module is conservative, it should be able to run under WINE.
I port video games to Linux for a living, so I am probably qualified to comment on this.
Do NOT optimize for Wine. You probably can't anyhow, since both Win32 (at least, DirectX) and Winelib are moving targets to varying degrees, what works and works well in one version of Wine will not necessarily do so in another.
I think Wine is an excellent piece of work, but I'd imagine even the Wine developers would rather have native Linux applications than emulated win32 apps (and if they don't, they should).
This is doubly true for game development, where you need every CPU cycle you can reasonably get.
Wine, Winelib, and WineX are really meant to be bridges to make Linux more feasible in the short term by letting Win32 programs run in some form, even if they just limp along. They are afterthought solutions to running software that we have no real ability to use, but think we can't do without.
The ideal solution is to write portable code in the first place. Be mindful of what you write, and follow some basic principles:
1) Don't tie yourself to a compiler. If you build on Visual C, take time to build on a different compiler (specifically, GCC) every now and then. Getting code to compile on various platforms is half the battle.
2) Don't tie yourself to a platform's API. Use cross-platform libraries and toolkits where you can, use abstraction layers in your own code where you can't. If you do this right, a good chunk of the porting work is just filling in stubs for a new platform. For game development, you should be looking at Simple Directmedia Layer for most of your needs. Other libraries like my own PhysicsFS can abstract file handling for you. OpenAL can give you 3D positional audio if SDL's stereo output is insufficient, and OpenGL gives you 3D accelerated graphics if SDL's 2D linear framebuffer is insufficient.
3) If PowerPC (MacOS, specifically) is of interest to you, be conscious of byte ordering. Always be conscious of structure packing regardless of platform. If 64-bit platforms (Alpha, Itanium, Hammer) are of interest to you in the future, don't do silly things like cast pointers to ints and such.
4) Don't use assembly code. Ever. If you _must_ use it, you better have a C fallback. Be smart and use NASM on win32 and Linux, so you don't have to deal with the massive differences in inline syntax between Visual Studio and GCC.
If you are more than one developer, the easiest way to do this is to have a devcrew made up of at least one person for each targeted platform. This makes it easy to make sure that things aren't silently breaking on MacOS while you write code for Win32, since that developer will catch it in his next code sync (you _are_ using source revision tools, right?).
Good luck to you.
--ryan.
Don't say, "don't quote me," because if no one quotes you, you probably haven't said a thing worth saying.
Just develop for WINE. If it doesn't work on Win32, it's Micro$oft's fault for not being standards compliant!
Ali
Ph33r m3!!!
If a little thought went into the the game design, and it used only open API like:
OpenGL, OpenAL, SDL...etc (which are available for Windows, MacOSX, Linux and the other UNIXs)
Then you wouldn't need to spend the extra effort in porting it (in the sense of spending a month or so to convert the game). It would be pretty much compatable, and many companies do this already.
eg ID dont use DirectX (except maybe for trivial stuff like input) so the fact they release Linux versions of Quake aint that much extra effort for them.
All UT2003 needed was an OpenGL renderer and then it was pretty much working in Linux too (esp since UT2003 used OpenAL already)
Now games developed with Closed/Proprietory API are very difficult to port, and in the case of DirectX wouldn't work well in WINE (unless you used an older version like DX5, not talking about WineX here) So designing your game to work well in WINE would be redundant, since a good game design would be natively Linux compatable anyway. But while the ARB sits on there hands and not push OpenGL forward, all those spangly new features in DX is always going to attract game developers, and thus make their games dificult to run in linux.
I have a better suggestion! Use Qt instead! That way you can compile your software with little or no changes for Windows, MacOS-X and Linux/Unix, and get the native look and feel on all platforms..
There are alternative crossplatform GUI-kits such as wxWindows, GTK2, FLTK and more, but they are only GUI-kits. Qt is a complete development plattform with crossplattform support for databases, networking, components, regexps, OpenGL, localization and much more, besides just the look and feel...
My other account has a 3-digit UID.
I don't know what version of WINE you are using, but it's quite fast here. The only thing slow seems to be the initial loading of apps. Games also run at a reasonable speed. RTCW runs at 50fps in winex while it runs in 61 fps in the native port (but I use winex because the native port is more unstable (it's also completely unsupported))