Developing WINE-Friendly Windows Software? 33
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?"
How to be a slashdot troll - FAQ version 1.00 (Score:0, Informative)
1. What is trolling?
Trolling is the art of pissing of people with too much free time, namely moderators. It's a highly amusing sport. A sucessful troll can cause tons of havoc.
2. Sound good. How do I troll?
The best trolls are somewhat subtle. For instance, posting "linux sucks!" and you will be immediently modded down. A smart troll might post
"Linux on the desktop is simply not an option right now. It's simply too hard to use. Forget what the typical microsoft hating linux zeolot says - the truth is linux is not a viable alternitive".
The above post is longer, and not a blatent troll. While it will piss off the typical long haired hippie it might even be modded up as insightful!
3. Hmm. Can you give me any tips on my first troll?
Certainly. Don't post typical troll phrases such as "Imagine a beowulf cluster of these!" or include a link to goats.cx. These are far too obvious, and will be modded down without comment. Likewise, whilst gettng first post is fun, don't say fp! I suggest using a little imagination, such as setting up a free redirector (like cjb.net) to point to goats.cx. Try and make the site relevant too the story, such as "Joe MIT hacker making his XOR gate out of water is pretty cool, but it's been done before here . Most moderators are lazy and won't click the link. Chances are you will be modded up as insightful.
4. Any other dirty tricks?
Sure, there's plenty. Whenever anyone includes a link, follow up and say 'Don't click here! it's a goats.cx link!' this will earn you karma whilst getting the sucker modded down. Another one: When the site featured in the story gets slashdotted, claim you have a mirror. Give the IP address of goats.cx as the mirror.
5. What should I avoid doing?
Please *don't* post stuff incolving disturbing sexial experiences of comments. We don't want to hear about what you did with a dog last week, nor what michael (the editor) does with 5 pounds of ice and a shovel a day. Not only is it sick but you give all trolls a bad name. Also, speaking in l337 makes you look like a teenage acne scarred moron. Finally, think carefully before you troll. You are trying to cause havoc. This will not happen if you are modded down within 30 seconds of posting. Be subtle.
Have fun, trolling is an honorable sport.
Please, don't. (Score:5, Informative)
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.
Use Open APIs (Score:4, Informative)
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.