In the past, submitting code to wine had a reputation for being difficult. We're trying several changes to make it easier for people to contribute code, but one thing we don't want to let go of are high standards for patches. Although we can't list all of the issues that might come up, here are a few that drew a lot of attention in the past.
Many of these could theoretically be checked automatically, and there are already basic scripts floating around for some of them. It hasn't been discussed yet, but having our testbot check for these down the road could be a worthwhile project.
Wine supports old 16-bit executables, but since many users might not be interested in this feature, we have a build option to disable it: --disable-win16. However, especially in its early versions, wine had a significant amount of overlap between its 16 and 32-bit functions.
This shouldn't be nearly as much of a problem now (it might be resolved entirely), but any changes should respect the separation so be sure that your submission:
- Places code for 16-bit support in its own file in the appropriate 16-bit dll
- Don't call 16-bit DLLs from a 32-bit one (with LoadLibrary16 or GetModuleHandle16)
- Don't use a 16-bit include file for any 32-bit code
- Don't implement a 16-bit function in a file for 32-bit code
If you come across a situation where you believe making an exception to these rules is necessary, you can definitely discuss it on the wine developer's mailing list.
Set Read-Only Data to const
This task actually isn't too difficult. After compiling whatever files you're working on, you can use the objdump -x tool on the resulting object files, then cross-reference the .data and .rodata segments.
Any variables in .data that shouldn't be written to can be set as const in your source, which should place them in .rodata once you rebuild them. Of course, be sure to fix any new compile warnings your changes generate too.
After you've made your changes, rebuild and actually run your modified version of wine to test. It's important you do some real-world testing because a variable incorrectly set as const can often cause segfaults.
- For an introduction to COM, Jeff Glatt's "COM in Plain C" articles are very good