more misc fixes

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > Index: wine/include/wine/obj_base.h
> > ===================================================================
> > RCS file: /home/wine/wine/include/wine/obj_base.h,v
> > retrieving revision 1.40
> > diff -u -u -r1.40 obj_base.h
> > --- wine/include/wine/obj_base.h	2001/05/07 18:15:40	1.40
> > +++ wine/include/wine/obj_base.h	2001/07/19 14:50:28
> > @@ -34,6 +34,8 @@
> >  #include "wtypes.h"
> >  #include "guiddef.h"
> >  
> > +#include "wine/windef16.h"
> 
> This is wrong; Win32 header files must not include 16-bit ones.

Ah. You are right, I orginally meant to add it in a
different file (wine/obj_base16.h perhaps) but I didn't
think it would matter since other 16 bit interface like
IStream16 and IStorage16 is in wine/obj_*.h already.
Perhaps they should be move out as well?

If so to where? wine/obj_*16.h or perhaps the DLLs directories if possible?

> Also please avoid adding more 16-bit headers in include/wine, there
> are already too many of them. 

Well that was the idea at first but at least of the new ones are
was needed in more that one directory some I ended up adding all
of them there. But sure I can move the ones that are not use in more
of one directory to that directory, I'm just a little worried that
since the wine/*16.h header are 16-bit "mirrors" of the corresponding
32-bit files that functions from other DLLs happends to end
up there as well. Microsoft seems have mixed headers and DLLs without
much thought especially as far as OLE is concerned.

Sure we can have several .h files with the same name in different
DLL directories as far as functions are concerned since 16-bit functions 
shouldn't call across different DLLs anyway, but duplicating 
types and such are not a very good idea.

But sure I can examine the files more carefully and see if it is possible
and of course we can add it to a DLL directory first and then move
it to include/wine if is because nessary in the future.

> These headers (when they are really
> necessary) belong in their respective dll directory. And BTW your new
> lzexpand16.h is an example of a header file that is *not* necessary.

Nessary for compiling Wine no, clearly not since it already compiles.

However IMO all exported functions whether they are 16-bit or 32-bit
and whether they are actually uses by other files or not should have
declarations in some header file.

For 32-bit it must obviously be so because of Winelib.
The undocumented functions is of course not strictly nessary
but I see not reason not to have them as a Wine extension
that can be ported to Windows eventually in order to have
the same source on both Unix and Windows.

For 16-bit is seems that you disagree. Well, the advantages
that I can think of for doing it for 16-bit as well is the following.
1. It makes it much easier for developer to add calls across files
   between 16-bit functions or move functions between files 
   if the infrastructure is alreay in place.
2. It makes it possible to see related 16-bit functions together in
   a .h file instead of having to search the .c files.
3. It makes it possible go through each 16-bit .h file compare it with
   Windows and add the missing functions in the .h files and when somebody
   in the future runs winapi_check (or whatever) it is possible to present
   a list of what is not yet implemented. Sure the .spec contains that
   information as well in some meaning but it misses which functions that
   are actually listed in the 16-bit header files and thus likely to 
   actually be used by real applications.
4. Since some of the 16-bit exported functions must be declared in some .h
since
   it is used in some of file than it was declared, it is be much easier
   to require all 16-bit export function to be declared since it is
   difficult to tell which that are (or will be) really needed.
5. There is nothing unreasonable to require every non-static function 
   let alone functions that are exported by either Win16 or Win32 to have
   a declaration in some .h files. Indeed tools like lint (at least on
Solaris)
   have flags to check for this.

In short trying to only add the 16-bit functions that are stricly nessary
to .h files is more trouble than it is worth, especially compare to the
advantages that having all of them .h files.

In addition (as I hinted in 5.) requiring all non-static functions
to have a .h file declaration is good policy for any application
including Wine. Hint, if a function isn't static somebody else
should use it otherwise some else is wrong, ie it really should
be static after all.

But OK. You think that there are too many 16-bit files in include/wine.
No problem. I will try to avoid it if at all possible.