King InuYasha

Originally Posted By: Celtic Minstrel I'm not quite sure if wxWidgets has switched to Cocoa either, but if they haven't yet I'm pretty sure they're in the process of doing so. I think a Cocoa version may be in alpha or beta stages. I know nothing about CMake and have no desire or motivation to learn at present. Even with CMake, project files for MSVC and Dev C++ should probably be included. Xcode project files and Dev C++ project files already exist. (The idea behind this is to make it so that anyone can download and compile the source, regardless of which compiler/IDE they use.) If we used wxWidgets (or even Qt), I bet we could use the HTML rendering system to display the dialogs, since I've already refactored the dialog format to XML (though most dialogs are yet to be converted). And clicks could probably be handled with DOM events or whatever those things are called... though I actually have no idea how that would work or if it could work when there's no scripting language (eg JavaScript) in the equation. There is MSVC support in CMake, and I would be willing to write the CMake scripts once we have a Windows, Mac, and Linux version in the source tree. CMake is extremely flexible, it supports both GCC, MSVC, and ICC (Intel C/C++ compiler). It might even support DMC (Digital Mars C/C++ compiler) and OWC (OpenWatcom Compiler). Dev-C++ projects would be the stick in the mud, since no project generator currently supports it. However, Dev-C++ project files could be provided separately, as they are now. Using HTML rendering system for the dialogs would be an interesting way to do it. I believe only Qt's built in QtWebKit control would suffice. wxWidget's built in HTML control is only HTML and CSS. There is a separate Gecko control, but Gecko is a huge beast, you don't really want to include Gecko in an application like this. WebKit is much lighter and I believe is only a single DLL in Qt. Obviously, WebKit has JavaScript support, so QtWebKit does as well. WebKit is available for wxWidgets in the form of an experimental (under active development and in a separate repository) control called wxWebKit. As for Cocoa support. wxWidgets has it in the SVN trunk, but it still isn't usable yet, according to the wxWidgets wiki. Given that the wiki is possibly out of date, it would be a good idea to download a copy of wxWidgets SVN trunk and try to build it for wxOSX/Cocoa instead of wxOSX/Carbon. If it builds and loads, then great! Otherwise, meh... Interestingly, there is a branch of wxWidgets that now includes a Ribbon UI implementation. Qt still doesn't have a Ribbon implementation, so wxWidgets wins on that one. Since I doubt you want to use a Ribbon in BoE, I would still say Qt would be a better choice because Qt's Cocoa and WebKit implementation is mature and working, quite well too. Additionally, Qt has 64-bit support on Windows, Linux, and Mac OS X. Unfortunately, you have to compile the Win64 libraries yourself currently...

Originally Posted By: Celtic Minstrel It's just another step to worry about, which means figuring out how to get Xcode to call it as necessary. On the other hand, I've taken a look at wxWidgets, and I liked what I saw there. I don't want to use Objective-C, by the way; I was just pointing out that Objective-C code could be mixed with C++ code in a file (Cocoa's binding is ObjC). Creating separate projects seems sort of redundant, when there are better ways of doing it. I would figure making a set of CMake scripts to handle it would be better, since CMake can generate MinGW makefiles, Unix makefiles, Code::Blocks project files, and Xcode project files. As long as the moc step is taken care of in CMake, it would be fine. Of course, qmake could be used instead, and it also supports generating Xcode project files. However, it does not generate Code::Blocks project files. I was aware that C could be mixed with Objective-C, given that Objective-C is supposed to be a "true superset" of C. My major problem with wxWidgets is that it doesn't work all that well under a KDE system. Other than that, wxWidgets and Qt are remarkably similar in their feature set. Although, wxWidgets uses Gecko instead of WebKit for their HTML rendering. I'm not sure if wxWidgets had switched from Carbon to Cocoa for wxMac as Qt had, but meh.

Originally Posted By: Celtic Minstrel I dislike the fact that Qt requires a separate preprocessor; if I were to choose a cross-platform GUI library, I'd almost certainly go for wxWidgets. Originally Posted By: Niemand switching BoE away from Carbon would require rewriting a vast amount of the code. It would also preclude merging with the Windows source, since it would involve rewriting the game in Objective-C. (To switch to Cocoa. Actually, I don't think you'd need to rewrite that much; GCC could be made to compile as Objective C++, and you could use Objective-C stuff for the user-interface code while staying with pure C++ for the main code. Of course, that would still require conditionals to keep Objective-C code out of the code seen by the Windows compiler; it would also require making GCC override the file type so that the extension can stay as 'cpp' rather than changing to 'mm'. (This assuming that the Windows ans Mac code are indeed merged.) I'm think that wxWidgets has an Objective-{C,C++} binding so you could still use Objective-{C,C++} on Windows since TDM-GCC and MinGW GCC 4 include ObjC compilers. What's wrong with the moc preprocessor? With Qt 4.5 and higher, you could have the game in C/C++ and still be able to compile to target Cocoa on OS X.

Originally Posted By: Celtic Minstrel Partly (mainly?) because he hasn't been around, I guess. In fact, if he does post the code, and it works, I would seriously consider using it to replace all the platform-dependent interface code in the game; that would mean we don't need so many conditionals. Well, when you guys were updating the Mac version, you did have the opportunity to do all that. You guys just didn't take it, that's all. You guys could probably still do it though. I don't think you would, but you COULD. It would make merging the Mac and Windows versions far easier. Also, considering that you guys used Carbon for the Mac version, something eventually will need to be done, since that API has been deprecated for quite a few Mac OS X releases and is probably scheduled to disappear soon...

It's been almost two months. Nikmind, if you can't continue working on the Linux port, why don't you have it imported into the Google Code project that Celtic Minstrel is managing so that other people can work on it too?

Originally Posted By: Niemand It would certainly be possible to use Qt, since it has improved greatly in recent releases (it used to lead to second-class applications on Mac OS that existed inside of the X11 application, as I recall). This will of course require thinking more about, as while I've formed an opinion, my conviction is not so great that I won't consider alternatives before starting to code something. AScript is a text editor specifically suited to writing Avernumscript. Qt requiring X11 on OS X was a long time ago, way back in Qt 3. At Qt 4.5, you can make 64-bit aware Cocoa applications without actually using Cocoa directly or Obj-C/C++. Meaning you could recompile the same source to be 32-bit Cocoa or 64-bit Cocoa applications on OS X, without editing the source at all, if you are careful enough. Another option that lends itself to native on Windows, Mac OS X, and Linux would be wxWidgets. Unlike Qt, wxWidgets has supported bindings for many languages other than C++. The only problem with wxWidgets is that its more like MFC than a complete abstracting library. MFC does abstract some of it, but not all. This is also true for wxWidgets. So for each platform, little tweaks at lower level code would probably be required. Given that of the three major platforms, only Windows is non-POSIX, it would probably only require two sets of tweaks at lower levels, one for UNIX and one for Windows.

What happened to BoE for Linux? Is it dead or what? Haven't heard a peep about it in a month....

Originally Posted By: Niemand I have thought a lot about creating a BoA IDE, and while you're right that those are the features that such an IDE should have, they can't very well be put together like blocks. The 3D Editor is old and crufty, with unsuitable limitations like only being able to manipulate a single town at a time. Graphic Adjuster is mostly built of code that needs to be thrown away; I hacked together whatever I could to get it to work, so there's virtually nothing there that could or should be reused. AScript has code that's good enough to reuse, but is written in a different language than the other two, and what's worse is built on a totally different set of (Mac OS only) libraries. A number of the projects or sub-projects that I'm working on or thinking about are with an eye toward reuse in such an IDE. I've done some work separating the useful, reusable bits of Graphic Adjuster from the rest, which would support loading, saving and manipulating PICT resources. Building a new file format specification and I/O library would make handling operations like opening multiple zones for concurrent editing and rearranging zones far more natural (The BoAEdRemake team did create a library they named Remembrance which would replace the existing one, but it is enormous, depends heavily on Boost, and as far as I can tell is designed only to support the existing format. Add to that the fact that all the people who created it have wandered away, and I'd rather just start over.) There is a good deal of the code in the 3D Editor which is needed, at least as a template for rebuilding the same features, in particular Isaac's 3D drawing algorithms, and we can move in the right direction by sorting out the code that is currently mixed together in the to separate versions of the Editor. Then there's work whose beginning isn't even in sight. For instance, the graphics layer should be separated out into its own module and rewritten based on something like OpenGL. The dialog display layer is already platform abstracted, but the Mac version at least is very finicky, out-dated, and needs to be replaced. Another problem is that it would be hard to build an IDE that both works well on both platforms and shares very much code between them above the layer of things like the file I/O library and so on. I can imagine how I would sketch out much of it using Objective-C and Cocoa for Mac OS, but that would be completely non-portable and I have no notion how to build something equivalent on Windows. There are various cross platform libraries upon which an IDE might be built, but the alternatives are things like Java (it sucks and we wouldn't be able to reuse a single line of existing code) or wxWidgets (the choice of the BoAEdRemake team, but with which I have no experience). My observation has been that for the same program to work well on multiple platforms, it really needs to make the entire GUI layer wholly specialized for each platform, and in the case of an IDE, once we had ready the supporting modules, nearly all of the work would be in the GUI layer (for instance, this is virtually all there is to AScript; the only portable bits of it are the syntax coloring engine and Alint). Basically what it comes down to is that it could be done, but to do it at all could take years for multiple people, and that's to say nothing of doing it well. You could use Qt, which would use Cocoa on OS X, Win32 on Windows, and the proper stuff on Linux even though it would be written totally in C++. Qt is pretty complete, covering pretty much all levels of code. What is AScript? Is it AppleScript, AngelScript, or what?

NTVDM.exe always exists on 32-bit Windows Vista. And, the program wouldn't even launch at all if it were missing. The problem is that NTVDM, with each successive release of Windows, has gotten more and more restricted for stability purposes. It is because of this that some installers don't even work on Windows Vista. 64-bit versions of Windows do not have NTVDM, so none of the Exile series will run on it.

Originally Posted By: Niemand I would suggest that you go ahead with Quicktime. I'm sure Windows has native libraries to load and display PNG images as well, so there doesn't seem to be any reason to do something really low level like building in libpng. I don't think that it would work very well to try to attack the old code to UI elements stored in a nib file. I'm not even sure if you can get the controls stored that way into an antiquated enough form since Jeff used the Control Manager, rather than the more modern HIView library. I looked at that, and decided that nothing short of a full conversion to nibs and custom controls seemed sensible. I've done a little work in that direction, but it won't be useful for some time to come. I agree one the campaign flags, my first thought was to also store them by scenario name. I think that this has a couple of advantages: Firstly, the designer doesn't have to worry about choosing a key. Secondly, scenario names are already essentially unique, so one doesn't need to worry too much about collisions. Having the stored data also be a dictionary would also be nice, although designers could probably deal with having to index their data numerically. I would like to argue that Windows does NOT have a native method of handling PNGs properly. Also, instead of relying on QuickTime or whatever, why not use libpng? By using libpng, you reduce the overall differences in code by using a cross-platform library. Try to use cross-platform methods over platform-specific ones, that would make it easier in the long run to consolidate the sources down to a single tree.

Originally Posted By: Chokboyz Quote: What resources problem? And how are min and max redefined by windows.h? Seems to me that resources format are not the same depending on which platform you are (.rc in windows, .glade if using GTK on linux, ...) I may be wrong though. Min and Max functions are redefined to Windows-brew ones when including "windows.h", overriding the c++ library ones. I had to replace all min/max in the code to either c++ or wxWidget equivalents to get it to compile in wxWidget. Chokboyz wxWidgets is a nightmare in itself. It is well-documented, yes, but it has so much churn and it breaks quite often, even at the source level. There are also weird bugs in wx when it comes to dealing with themed Windows. For example, Code::Blocks has the strange issue of not correctly setting the state of toolbar buttons to be grayed out. This problem is prevalent in all wxWidgets based apps or GUIs. I don't really know if it would be worth working with the Windows sources, since more fixes seem to be going into the Mac OS X sources rather than the Windows ones. I think I stated this before somewhere else, but if I were to work on the sources, I would probably base off of the Carbonized ones, since those sources are being actively developed. However, I don't understand a lick of Carbon, so that point is moot really. We have lots of Windows-based source forks all over the place, mine included. Most do not compile properly. Some that do, don't run. Nikmind is working on a Linux port, basing it off of the Windows one. Perhaps when that one is made public, it would be simpler to port that one to a cross-platform toolkit, but I doubt it. GTK+, no matter which way you slice it, is incredibly platform specific for a cross-platform GUI toolkit. That's really why wxWidgets was so useful to people. It actually made it possible for an app to be cross-platform with "minimal" changes. With Qt 4.5 though, a lot of that changes. Qt 4.5 can use GTK+ engine themes, making it native looking on GNOME. It obviously can use KDE visual styles. It uses the native theming engine on Windows depending on the version (uxtheme on XP, Aero on Vista and higher), and it can use either Cocoa or Carbon on OS X with only a single source code rebuild with zero modifications. One thing that confuses me though, if this is a C project, why the heck does it use *.cpp for the source code extension on Windows sources?

Originally Posted By: Celtic Minstrel Originally Posted By: King InuYasha I didn't assume that the trilogy game data is free. I was assuming that it would be possible to write a converter of the gamedata from the older engine to the open source one. It is true the Exile 1 and 2 do use significantly different engines, after all, they were developed to improve on the previous. With a converter, it should NOT be necessary to fork the BoE engine for each revision of the Exile trilogy. The reason I say a fork would be necessary is because I don't think Exile 1 and 2 would be quite the same if they had the BoE spellset rather than the original spellsets. For example, the Recharge Wand spell in E1. There are likely other details about the engine that I would want to retain if the trilogy were ported to the Blades engine. I wouldn't mind porting the dialogue to the new system, though I wouldn't mind leaving it in the old system either. Oh, and E1 has only humans and no traits, so you'd have to modify the BoE code to eliminate those. And I'd want to modify the BoE code for E2 to retain the Pacifist trait, even if no-one uses it. This may be just my opinion, but making E1-3 as a BoE scenario simply wouldn't be the same. In that case, it WOULD be just easier to branch the engine code and be done with it. If those requirements were put into place, it would make more sense as a build time option rather than forking the whole code. That is assuming that these requirements wouldn't cause the engine to require significant rewrites for each revision of Exile.

Mikmind, do you plan to release the scripts on how you converted the RC files to their GTK+ equivalents?

Originally Posted By: Celtic Minstrel Originally Posted By: King InuYasha Then the Exile gamedata could be forward ported to work with the BoE engine and WHAM! Instant working trilogy and then some. Apart from the obvious fact that the Exile trilogy is not free, that would run into the problem of the engines being different for the Trilogy. E3 uses almost the same engine as BoE, so that one would be fairly simple. But E1 and E2 use significantly different engines. Basically what I mean is it wouldn't be sufficient to make the original trilogy as BoE scenarios. You would have to fork the BoE source and modify it for each one. And all that is assuming Jeff gives permission, which is probably rather unlikely. I didn't assume that the trilogy game data is free. I was assuming that it would be possible to write a converter of the gamedata from the older engine to the open source one. It is true the Exile 1 and 2 do use significantly different engines, after all, they were developed to improve on the previous. With a converter, it should NOT be necessary to fork the BoE engine for each revision of the Exile trilogy.

Originally Posted By: Dark and Starstormy Originally Posted By: Thuryl Or to add OS X compatibility for people who can't use Classic and don't want to use emulators. Because this has worked so well for BoE. Not to bash on the OBoE people -- I think what they're doing is awesome. But it's been two years now and I have yet to see any mostly stable, public OBoE release that people can download-decompress-and-run as could be done with BoE back in the day (and as can still be done with BoE if you have Basilisk ][ set up already). If you have ever looked at the source code and attempted to port something over from an old unsupported platform to one that is, you will realize that it is extremely difficult. The code is an extreme mess, and the Mac people have it somewhat worse, because of the deprecation of the Carbon framework, but it isn't likely to go away for at least one more Mac OS X release. Rewriting BoE to use a modern framework is a pain because the code is cryptic. I tried once to port it to wxWidgets. I just didn't have the time and I still don't. Besides, if I were to do that again, I would not use wxWidgets anyway, since Qt is LGPL and it does follow the one-source/multiple-platform thing far better than wxWidgets did, it would probably be easier to port back the Carbonized code to Qt and make the whole game work on Mac, Windows, and Linux. This would effectively give the Mac version Cocoa support without rewriting it in Objective-C too. Possibly even 64-bit support, who knows? Then the Exile gamedata could be forward ported to work with the BoE engine and WHAM! Instant working trilogy and then some. At the moment, Nikmind is doing a direct port of OBoE to Linux using GTK+ UI. It seems most of the development is focused on the Mac OS X version, which really isn't much of a surprise to me, since this community seems have a higher Mac population than most.

I will gladly test as well

Originally Posted By: Celtic Minstrel Originally Posted By: King InuYasha I'm not sure if GTK+ support for Mac OS X has improved to the point that it no longer requires the installation of Apple's X11.app, but Qt 4.5 allows you use to use Carbon or Cocoa, so it would make it a bit easier to continue using it since Carbon doesn't extend well to 64-bit. I don't think it would be worth porting it to Cocoa. It would be a lot of work, certainly, and would probably require a major rewrite. For now, I think it's best to stick to Carbon. I worded that wrong, Qt 4.5 will use Cocoa or Carbon APIs for its Mac build. Which means, a single recompile of Qt app targeted for Cocoa instead of Carbon will make it use Cocoa without any work at all.

Do you plan to reorganize the code so that the front end code is separated from the back end code? Doing so would definitely make it easier to change out GUIs if it was ever needed. A few months ago, I had used Qt Designer to design from scratch the initial screen when loading up BoE, but I couldn't make it more "functional" because I couldn't figure out heads or tails of the code. I didn't know where the front end code ended and the back end code began. I also had a wx GUI written, but again, the same issue caused problems. I'm not sure if GTK+ support for Mac OS X has improved to the point that it no longer requires the installation of Apple's X11.app, but Qt 4.5 allows you use to use Carbon or Cocoa, so it would make it a bit easier to continue using it since Carbon doesn't extend well to 64-bit. Additionally, wouldn't a GTK+ port still be able to be built for Windows too, even if it uses autotools, especially since Fedora introduced a toolchain for crosscompiling to Windows and testing through Wine?

For the most part, in GTK+ the equivalent of RC files I believe are .glade files. In Qt, the equivalent is .ui file type. GTK+ and Allegro is a good combination, the only issue I can think of is that you are going to wind up rewriting the whole thing from C++ to C, since GTK+ raw uses C as its programming language. Also, GTK+ is well tuned for UNIX style applications, as it was designed with the assistance of people from GNU project, who hold the POSIX model in high regard. In contrast to this, wxWidgets or Qt both abstract away from both the OS2/Win32/VMS model and the POSIX model so that one codebase works with both types of platforms. If I had more time, I would be trying to do this kind of work, but alas, school and life are a higher priority. Also, do you plan to post your changes in a repository so others can see it and try it out soon?

Originally Posted By: Miramor The OBoEcross32 site is gone. I get a strong impression that King InuYasha has quit on us. (Would that I knew my way around C++...) I'm back after about a year. Sorry about being missing, but second semester is always very fast paced. I didn't have any time for it. And the summer was spent in surgery and recovering. (Open heart surgery does take a long time to recover from!) I'm thinking about mixing wxWidgets and Qt, since Phonon is so useful and much easier to write sound output for than SDL or anything else really. Unfortunately, now I don't know what the latest code is now, since I haven't been around for a year.... My site may be gone, but the sources are still there at https://sharesource.org/hg/oboecross32/ Though, they are quite out of date.

Quote: Originally written by Celtic Minstrel: A few questions: Does the zip link at the top download the source? Are you basing all code on the Windows sources? Or are you taking Mac sources into account, too? What platform are you doing this work on? In order Yes Yes, Windows sources. Yes, but in a special way. If the porting goes as outlined in the main page of the website, then automatically the sources will be Mac OS X compatible.

Quote: Originally written by CommonGenius.com: InuYasha, I tried to go to the link in your signature, but it won't open (tries to download a file named "enano"?), and I can't find oboecross32 from the main site. Can you direct me to the appropriate link? I am interested in developing on BoE, on the Windows side. My impression is that most of the current development (what there is of it) is being done on the Mac side; but since presumably all of that work could be ported to Windows, I don't want to duplicate work that has already been done on the Mac. You might have caught the server at a bad moment. The PHP system on that server is being upgraded at times, and messed with quite often, unfortunately out of my control. The site is supposed to show CMS controlled site with basic info... Anyways, here is a direct link to sources... http://hg.sharesource.org/oboecross32/

Yay! I feel somewhat happy! As simple as it is, it still means I managed to actually port some code! Edit: http://hg.sharesource.org/oboecross32/ *Dances a little, then realizes big problem* OH SNAP! There is a Mac codebase file in the Windows codebase... "./ScenEd/townout.cpp" is the Mac Scenario Editor codebase file "townout.c"

Quote: Originally written by Bryce: I agree with King InuYasha with regard to statically linking for closed-source programs on Linux; I've had nothing but trouble with dynamically linked binaries on Linux that weren't from my distribution's own package system. I think a better ultimate solution, of course, would be to open-source the engine so that Jeff can focus on developing (and selling) content rather than hacking on the engine. There is no reason why an open source engine would prevent him from using his demoware model, with some minor adjustments. If you are skeptical, let me explain. The current model relies on the content (scenario) trusting the engine to tell you if it is registered or not. If the engine is open source, you can't trust it to do that, because the user might alter it to always say that it is registered. (You can't trust a closed-source engine either; in theory they can always be compromised, and often in practice they are.) So, don't trust the engine - you don't need to. Instead of sending a registration code when the user pays, send a small (~100k) but vital piece of the full scenario, so that if the unregistered user compromised the shareware protections, it would do him little good. This process could easily be streamlined to the same or similar amount of effort for the user. You could argue that the user can copy the piece of code and give it to his friends. This is true, but he can also copy his copy of Avernum and it's registered preferences file or whatever. You cannot thwart the determined illicit copier, the objective is just to make it easier to register than to copy it illegally for the great majority of people. (People aren't evil, just lazy.) Even in the case where the current system is unchanged, most users can't read C++ and you'd be fairly hard put to find a programmer who is going to steal bread from a colleague's kids by circumventing the system and then advertise and distribute it. I certainly wouldn't. But in case Jeff has any programmer enemies that hate him personally, I still think the alternate scheme above is a better deal. I think that improving Blades of Exile would be a great way to show Jeff that open-source works. If I finish my current project over winter break, I'll try to take a look at how the open-source BoE project is coming along and contribute. (I have done work with SDL before, I agree that it's the right tool for the job.) [edit] On the other hand, Blades of Avernum would be pretty much done for as a salable product with an open-source engine, but there is a partial solution that is pretty simple - sell the normal Avernum editor instead. Theoretically, if the engine and the shareware code were split, with the engine open source, then it would be possible to distribute the shareware component as a separate closed source component. The official Avernum content data could require the shareware component to tell whether it was registered or not. If it isn't registered, then part of the content data would be disabled. If it is registered (according to the shareware component), then the whole data would be accessible. The benefit of that would be that the Avernum core engine could be packaged by people, while Jeff concentrates on the most important part, the content. When the content is ready, then Jeff could offer an installer with the build of engine and content software, as well as offer a content only option, so that those with packages for the engine code already installed can just drop the content in place. Pretty much that is how the Quake engine stuff is handled nowadays (lower than Quake 4), though the Quake data was completely pay for, not shareware. There are still companies that license id Tech 3 for use in commercial games, and all those games are compatible with the opensource engine. In Linux, it is common to combine Quake 3 based games with the ioQuake3 engine because the ioQuake3 engine is very much technically superior to the stock and other modified quake 3 engines. This allows pretty much any Quake 3 based game in Windows to be played in Linux.

Quote: Originally written by scottk: Coding it with cross-platform libraries is one thing, but you're asking Spiderweb Software to also support the Linux distribution(s). If he's going to sell it, he is on the hook for making sure it installs and runs. Unless the libraries are included with the binary (which isn't Linux-like), or built for a narrow specific system configuration (what would be the point?), I think it would be a super headache! I have a lot of experience with how the Battle for Wesnoth is distributed and built for 80 different Linux distributions, and it wouldn't happen without the work of many volunteers familiar with their distributions and able to customize the source so that it builds properly or advise their peers on how to make it themselves. I have a hard time getting my brain around how a commercial Linux venture like that would work. True, it isn't Linux-like to statically link binaries, but by using modular DLLs and including them in the binary tree, that works well for commercial Linux binaries. Many companies do that already. Heck, Exile III for Linux did that. It really isn't necessary to create native packages for all distros either. The Loki installer and the MojoSetup project both are designed with commercial Linux apps in mind. It would be a major problem for Spidweb to support all the different Linux systems if it was in native packaging. However, even without using Loki or Mojo, the Linux Standards Base has a standardization regarding packaging. Debian even adheres to it. All Debian has to do is convert an LSB-RPM to DEB package and it installs perfectly. A generic installer would probably be more suitable though, since there are distros that do not use ANY form of packaging (Linux from Scratch, Gentoo (portage doesnt count)) There is nothing wrong with including shared libraries in the package, or statically linking them. In the unlikely event he would want to spring for a commercial installer packaging system for Linux, there is BitRock. BitRock InstallerBuilder works on all major platforms, but its overkill unless you plan to standardize your installation system across all three platforms. There is a huge difference between Battle of Wesnoth and Spiderweb Software. One, Battle of Wesnoth is open source, and thus it can use dynamic linking and work with the system libs, and two Spiderweb would ALREADY have to include the libraries with the Windows version, and statically linking the Windows and Linux version isn't too big or hard a step. Doing so also would make the games slightly faster than their dynamically linked counterparts. I regularly statically link programs that I compile from sources because I use them for various server stuff (MathTeX for TeX stuff on website, ImageMagick for image thumbnail manipulation on websites, etc.) and the server itself runs an older version of Linux than build environment. Because of this, I make statically linked binaries that include everything in the binary so that its easier to manage and more likely to work. I also have experience packaging in RPMs as well as in BitRock installers, so I know the major differences required to package for each. In RPMs, generally it is recommended you dynamically link so that dependency checking can be used. In BitRock, no such feature exists, so therefore you should either statically link or include the shared object libraries in the program tree included in the installer. Generally statically linking is the better choice because with static linking you have less files to manage, and the program is less likely to be incompatible with future distro versions. In Windows, it is common to dynamically link while including the DLLs in the main program folder, Mac OS X is similar in this I think. Linux varies depending on your range of targets. If your target is a server market, you will want to use native packaging and dynamically link, because that market is slow changing, but when it does, you want to be able to take advantage of new things. For games, things change extremely quickly, so you want to be able to slow down a bit. In this case, static linking or including the libs in the program tree is recommended. Even Wesnoth has a generic installer, though that one does dependency resolution. Personally, I would go with either MojoSetup or BitRock for generic installers. MojoSetup because it is the successor to Loki and is in active development, soon to support all the platforms rather than just Linux. BitRock because it is a commercial alternative that is stable and flexible. BitRock also is very open source friendly for a commercial company, and they evolve with changing demands quite well. I think I repeated myself a few times, but we will just take that as emphasizing