I've been toying with some gcc warnings lately, and this could generate some new ideas for janitorial tasks. For example:

• -Wmissing-declarations should point lots of missing APIs declarations (I've done it in some cases, and I'm in the process of submitting some fixes). We cannot turn this warning always on because there are lots of cases where we have global functions without prototypes (more than 2/3 of them are made out of the 16bit entry points)
• -Wcast-qual should point out all the (const bla*) => (foo*) casts. We use quite a bit this, and in some cases it would prevent some errors. These are the main cases pointed out by this warning:
  1. const void* ptr; and then reading a value from ptr (word...) like *(WORD*)ptr which should be written *(const WORD*). The warning in this case is harmless.
  2. const void* ptr; and then setting it to another const pointer: const WORD* pw = (WORD*)ptr; which should be written pw = (const WORD*)ptr;. This warning is harmless if pw is really defined as const, in some cases it isn't and this should be fixed.
  3. const void* ptr; and then setting it to a pointer to a pointer (used a lot for qsort/bsearch... callbacks), when dealing with arrays of pointers. Here again, what's const is the first pointer, so const foo* f = *(const foo**)ptr is wrong, it should be const foo* f = (const foo* const*)ptr; This could be harmfull if not declared properly. Unfortunately, we cannot turn this warning on all the time because some C functions implementation would always trigger it (strstr for example), unless we use intergral values (not pointer) to cast from the const char* to the returned char*), and this is uglier IMO than the warning we try to avoid.

Some others warnings could be used as well. Trying also the Intel compiler gave lots of interesting warnings (and a tons of not so usefull too).

Here are a couple extra suggestions:

Add -Wwrite-strings

There has already been quite some work on this but I believe it's not finished yet. I'm not 100% sure of the status though.

Patch our min/max macros to catch signed/unsigned comparisons.

This generates a lot of warnings. Ideally they should be fixed without using casts but it may not always be possible.

(the modified min/max macros where borrowed from a Linux kernel patch)

On Fedora Core 2, the kernel is compiled with the 4G/4G VM split option enabled, which can prevent us from performing a correct emulation.

Win32 apps are apparently built with the assumption that they will not be allocated addresses beyond the 3G boundary. The solution therefore is to perform a similar trick to the preloader and reserve the address space before the emulation starts so mmap will never use addresses in that area.

This probably won't be combined with the preloader itself though, as Alexandre says it can be done after Wine gets control (what about DSOs mapped >3gig?) and so it can be done more portably. Up until now this issue has only affected Solaris and therefore nobody fixed it.

There is currently no known workaround for this problem short of recompiling your kernel. The error looks like this:

wine: unable to create process heap

Alexandre diagnosed this problem so I'm sure he'll correct me if this email contains any mistakes.

setarch i386 wine ....

I'm glad to announce that now (with this little patch) Unreal2 is working and playable (it's only slow and i havent seen graphics problems for now).

Now play :)

Changelog:

• better handling of User IDirectMusicTools

This dll is needed by a game, bug report number 1202. With this empty dll, the game crashes at the same point where it crashes when used with the native copy, mainly because it crashes before any function in the dll is called. But at least it doesn't crash with a dll not found error. You'll have to run the autofoo stuff after applying this patch.

Well, my point was the same made about stubs in normal DLLs: why add a completely useless DLL which may break more things than actually help.

Or, when adding it, have it at least disabled by default.

As for its simplicity, from what I remember there are tricky stuff like Mesh builders, interpolations, ... Which are 'easy' in the sense it's pure geometrical stuff and not at all linked to Win32, but still something that needs at least a good knowledge in 3D geometry processing.

Well, D3DRM is so rarely used (in all my game demos I ever tested, only one actually used it) that it's something very difficult to do for no real gain to Wine.

But well, I do not object to someone working on it, I just object to the 'let's add an empty DLL to Wine' approach... If adding an empty DLL, it should at least have FIXME printed on each call (to know which calls are used) and, even better, to have the COM hierarchy implemented with stubs to see which calls are used in which interfaces.

Otherwise, it's no help to anyone.

sorry, just saw the note on WWN. I did hope that there would be someone to point to the gcc visibility stuff already - but it seems that people are more concerned to exchange their beliefs and politics rather showing off some engineering stuff.

preface

it's not in the file format - it's in the tools.

The name ELF stands for Extensible Linker Format, it allows to invent all kind of new sections, and expand the symbol table with many interesting attributes that can be checked up by a toolchain. Well, "IF" the tools check for them.

gcc -fvisibility

The gcc -fvisibility exists since 3.1 and is supported by binutils. If you read up some web reports, it seems to have been invented for hiding stuff not quite unlike what the original poster wanted. The icc supports all -fvisibility options as well afair.

the real problem

traditionally, one can kill local systems which are usable within one file only, i.e. "static". Pretty 20year old unix stuff. The other symbols are referencable outside (in .o) and the standard shard linker will put all of them into the shared library symbol export table. - But now we want two different symbol flavours, one exported to the same library, the others for the rest of the world. Perhaps use a linker script to decide later about symbol visibility.

example solution

gcc supports the universal attribute syntax, and it does now know about more symbol flavours as to their visibility. Probably you want to have "hidden". Attached are two simple test*.c files and a makefile. The final sharedlib symbol table contains only test3 after stripping. - using a linker script instead of in-source __attribute__ is left as an excercise to the reader.

more hints

search freshmeat - there are ELF tools to staticlink, to obfuscate, and more. It's all in the tools. There is only one problem with opensource: many programmers do not need to hide symbols to the extreme, so they did not write such tools so far. Not yet. There are some real ELF-educated people out there - hire one, and let him write the tool you need. The ELF format is well-defined and simple enough to allow everything and quite easily.