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?"

Schitzo

[Anonymous Coward]

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.

Re:Schitzo

[Orthanc_duo]

Supporting WINE implies that you are pretty anti-Microsoft
Oh contrare.. money makes the world go round. If your game can run on both Windows and Linux without a port (such as by supporting WINE) you increase your possible market, hence more sales, hence more moolah.
Then again maybe I'm just sinicle.

-Orthanc
Don't bother fixing my spelling, I know it's wrong

Re:Schitzo

[Babbster]

This would be a good point if gamers who prefer Linus weren't already either dual-booting or possessed of an extra machine with Windows on it for gaming. As things are right now, Linux gamers are so likely to come to Windows for a game they want to play that it doesn't make sense for companies to go to the trouble of making their games compatible with other operating systems (though admittedly this is far more true for actual Linux ports than for Windows emulators).

I think the concentration of effort - if people are really interested - should be to make WINE more compatible with games rather than asking [or wishing] for games to be more compatible with WINE.

Re:Schitzo

[1010011010]

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.

This is an extremely Microsoft-centric view. Perhaps he simply wants to make his software usable by more people in the easiest way possible.

By making an application fall under both Windows and WINE, you are supporting Microsoft while trying to lead away Microsoft users, a bad idea.

And why is that? It's not like Microsoft is the Promised Land.

Re:Schitzo

[Babbster]

And why is that? It's not like Microsoft is the Promised Land.

It certainly is the promised land if you're a developer who wants to make money on a PC game. :)

Re:Schitzo

[ealar dlanvuli]

Hello,

Can I ask what company your under the payroll of? This post reaks of AstroTurfing. I cannot imagine anyone honestly thinking the way you apparently do.

Please reply,

Ealar.

Please, don't.

[netfunk]

I port video games to Linux for a living [icculus.org], 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 [libsdl.org] for most of your needs. Other libraries like my own PhysicsFS [icculus.org] can abstract file handling for you. OpenAL [openal.org] can give you 3D positional audio if SDL's stereo output is insufficient, and OpenGL [opengl.org] 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.

Re:Please, don't.

[norwoodites]

For Number 3, you have to worry about 64bit on PPC also, as the Power4 and PPC 970 are both 64bit.
Also it you are going to make a linux app compile it for more than just ia32 (x86) because people will hate you if you don't.

Re:Please, don't.

[Charlton Heston]

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.

Point one: Wine Is Not an Emulator. Wine Is Not an Emulator. It's a native Linux library that implements the Windows OS calls.

Point two: Since Wine is Not an Emulator, and is in fact native, it's just as fast as the Linux stuff that is written with the UNIX API.

That may sound right in theory

[mselmeci]

but it doesn't hold up in practice. WINE is really slow, even for non-gaming purposes.

Re:That may sound right in theory

[fault0]

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))

Re:don't

[agnosonga]

correction: sorry, its late. WINE is a great tool for running binaries that can't be ported

Here it is:

[standsolid]

This is fully the goal of transgaming -- have windows game boxes sysreq box read "Requires DirectX 8 or WineX 2.2".

And with this, the "optimization" turns in to lucritive-zation

Re:Here it is:

[DavidTC]

Actually, the best thing would be to compile to wine, and then have a Linux binary and a Windows binary, with the Linux binary (statically?) linked to winelib.

Of course, that's just silly, you really should just write to GTK or something cross platform in the first place.

That's an easy one!

[The_Guv'na]

Just develop for WINE. If it doesn't work on Win32, it's Micro$oft's fault for not being standards compliant! ;-)

Ali

Use Open APIs

[Trevelyan]

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.

Cute

[Per Wigren]

I have a better suggestion! Use Qt [trolltech.no] 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...

Re:Cute

[8BitWimp]

Have you checked the pricing of Qt???? Requires a second mortgage on your house for the desktop version alone....

Re:Cute

[Per Wigren]

Sorry.. Last time I looked at wx it only was a GUI kit.. I admit that that was over 2 year ago though.. It might have changed since then.. If it's true, that's great!

Anyway, my point was that he should design it crossplatform from the start instead of Windows-only and then try to make it run in an "emulator" (yes, "reimplementation of the win32 api", i know) afterwards..

Re:Cute

[Nicolay77]

wxWindows has "databases, networking, components, regexps, OpenGL, localization and much more, besides just the look and feel...", you should check what you say.

Qt is a fine product, I know, but what you said is nothing more substantial than a press release from trolltech. Ahhh but you work for trolltech don't you ?

Just wait till something can be done in .NET and watch the MS zealots screaming.

Modular development?

[abdulla]

Why not build the program to be modular from the start, that way environmental dependancies can be isolate and it make porting a _much_ simpler chore. Although this does require a lot of discipline and abstraction on the developers side, but it's usually well worth it in the end.