Fixed some errors (thanks to F Gouget for reporting them).

Added some bits on thunking and resources for DLLs.
oldstable
Eric Pouech 1999-12-05 02:16:24 +00:00 committed by Alexandre Julliard
parent ba02d1d7d5
commit 31b41cf68e
1 changed files with 61 additions and 2 deletions

View File

@ -189,6 +189,9 @@ into a stub:
IMPLEMENTING A NEW DLL
======================
Generic directions
------------------
Apart from writing the set of needed .c files, you also need to do the
following:
@ -212,6 +215,7 @@ following:
+ ./configure.in (in AC_OUTPUT macro at the end of the file to
trigger the Makefile generation),
+ ./Makefile.in (in LIBSUBDIRS and LIBOBJS macros)
+ ./dlls/Makefile.in (in SUBDIRS macro)
4. You can now regenerate ./configure file (with 'make configure')
and the various Makefiles (with 'configure; make depend') (run
@ -230,7 +234,7 @@ following:
some DLLs it's not the case).
6. You also need to define the loadorder for the created DLL
(./wine.ini and ./module/loadorder.c). Usually, "native,builtin"
(./wine.ini and ./loader/loadorder.c). Usually, "native,builtin"
is ok. If you have written a paired 16/32 bit implementation, don't
forget to define it also in those files.
@ -238,7 +242,19 @@ following:
directory. Refer to 'Implementation of new API calls' earlier in
this document for more information on this part.
8. Don't forget the .cvsignore file.
8. Don't forget the .cvsignore file. The .cvsignore contain (on a per
directory basis) all the files generated by the compilation
process, why cvs shall ignore when processing the dir.
*.o is in there by default, but in Wine case you will find:
- Makefile (generated from Makefile.in)
- *.spec.c: those c files are generated by tools/build from the
.spec file
- when thunking down to 16 bit DLLs, you'll get some others (.glue.c)
- result of .y => .c translation (by yacc or bison)
- result of .rc compilation
- ...
For a simple DLL, listing in .cvsignore Makefile and
<MyDll>.spec.c will do.
9. You can now start adding .c files.
@ -246,12 +262,55 @@ following:
include/. If they are linked to *your* implementation of the DLL,
put them in your newly created directory.
Debug channels
--------------
If you need to create a new debug channel, just add the
DECLARE_DEBUG_CHANNEL to your .c file(s) and rerun
tools/make_debug. When sending out your patch, you don't need to
provide nor ./configure nor the ./include/debugdefs.h diffs. Just
indicate that those files need to be regenerated.
Resources
---------
If you also need to add resources to your DLL, the create the .rc
file. Since, the .rc file will be translated into a .s file, and then
compiled as a .o file, its basename must be different from the
basename of any .c file.
Add to your ./dlls/<MyDll>/Makefile.in, in the RC_SRCS macro, the list
of .rc files to add to the DLL. You may also have to add the following
directives
1/ to tell gnumake to translate .rc into .s files,
$(RC_SRCS:.rc=.s): $(WRC)
2/ to give some parameters to wrc for helping the translation.
WRCEXTRA = -s -p$(MODULE)
See dlls/comctl32/ for an example of this.
Thunking
--------
If you're building a 16 & 32 bit DLLs pair, then from the 32 bit code
you might need to call 16 bit routine. The way to do it to add in the
code, fragments like:
/* ### Start build ### */
extern WORD CALLBACK <PREFIX>_CallTo16_word_wwlll(FARPROC16,WORD,WORD,LONG,LONG,LONG);
/* ### stop build ### */
Where <PREFIX>_ is an internal prefix for your module. The first
parameter is always of type FARPROC16. Then, you can get the regular
list of parameters. The _word_wwlll indicates the type of return (long
or word) and the size of the parameters (here l=>long, w=>word; which
maps to WORD,WORD,LONG,LONG,LONG.
You can put several functions between the Start/Stop build pair.
You can also read tools/build.txt for more details on this.
Then, add to ./dlls/<MyDll>/Makefile.in to the macro GLUE the list of
.c files containing the /* ### Start build ### */ directives.
See dlls/winmm/ for an example of this.
MEMORY AND SEGMENTS
===================