1 This document should help new developers get started. Like all of Wine, it
8 The Wine source tree is loosely based on the original Windows modules.
9 Most of the source is concerned with implementing the Wine API, although
10 there are also various tools, documentation, sample Winelib code, and
11 code specific to the binary loader. Note that several of the libraries
12 listed here are "stubbed out", meaning they still need to be implemented.
16 dlls/ - All the DLLs implemented by Wine
18 advapi32/ - Crypto, systeminfo, security, eventlogging
19 avicap32/ - AVI capture window class
20 avifil32/ - COM object to play AVI files
21 cabinet/ - Cabinet file interface
22 capi2032/ - Wrapper library for CAPI4Linux access
23 cfgmgr32/ - Config manager
24 comcat/ - Component category manager
25 comctl32/ - Common controls
26 commdlg/ - Common dialog boxes (both 16 & 32 bit)
27 crtdll/ - Old C runtime library
28 crypt32/ - Cryptography
29 ctl3d/ - 3D Effects for Common GUI Components
30 d3d8/ - Direct3D (3D graphics)
31 d3d9/ - Direct3D (3D graphics)
32 d3dim/ - Direct3D Immediate Mode
33 d3dx8/ - Direct3D (3D graphics)
34 dciman32/ - DCI Manager (graphics)
35 ddraw/ - DirectDraw (graphics)
36 devenum/ - Device enumeration (part of DirectShow)
37 dinput/ - DirectInput (device input)
38 dinput8/ - DirectInput (device input)
40 dmcompos/ - DirectMusic
42 dmloader/ - DirectMusic
43 dmscript/ - DirectMusic
44 dmstyle/ - DirectMusic
45 dmsynth/ - DirectMusic
47 dmusic32/ - DirectMusic
48 dplay/ - DirectPlay (networking)
49 dplayx/ - DirectPlay (networking)
50 dpnhpast/ - DirectPlay NAT Helper
51 dsound/ - DirectSound (audio)
53 gdi/enhmfdrv/ - Enhanced metafile driver
54 gdi/mfdrv/ - Metafile driver
55 glu32/ - OpenGL Utility library (graphics)
56 icmp/ - ICMP protocol (networking)
57 imagehlp/ - PE (Portable Executable) Image Helper lib
58 imm32/ - Input Method Manager
59 iphlpapi/ - IP Helper API
60 kernel/ - The Windows kernel
61 lzexpand/ - Lempel-Ziv compression/decompression
62 mapi32/ - Mail interface
63 mpr/ - Multi-Protocol Router (networking)
64 msacm/ - Audio Compression Manager (multimedia)
65 msdmo/ - DirectX Media Objects
66 msimg32/ - Gradient and transparency (graphics)
67 msisys/ - System information
68 msi/ - Microsoft Installer
69 msnet32/ - Network interface
70 msvcrt/ - C runtime library
71 msvcrt20/ - C runtime library version 2.0
72 msvcrtd/ - C runtime library debugging
73 msvideo/ - 16 bit video manager
74 msvideo/msrle32/- Video codecs
75 mswsock/ - Misc networking
76 netapi32/ - Network interface
77 ntdll/ - NT implementation of kernel calls
78 odbc32/ - Open DataBase Connectivity driver manager
79 ole32/ - 32 bit OLE 2.0 libraries
80 oleaut32/ - 32 bit OLE 2.0 automation
81 olecli/ - 16 bit OLE client
82 oledlg/ - OLE 2.0 user interface support
83 olepro32/ - 32 bit OLE 2.0 automation
84 olesvr/ - 16 bit OLE server
85 opengl32/ - OpenGL implementation (graphics)
86 psapi/ - Process Status interface
87 qcap/ - DirectShow runtime
88 quartz/ - DirectShow runtime
89 rasapi32/ - Remote Access Server interface
90 richedit/ - Rich text editing control
91 rpcrt4/ - Remote Procedure Call runtime
92 serialui/ - Serial port property pages
93 setupapi/ - Setup interface
94 shdocvw/ - Shell document object and control
95 shfolder/ - Shell folder service
96 shell32/ - COM object implementing shell views
97 shlwapi/ - Shell Light-Weight interface
98 snmpapi/ - SNMP protocol interface (networking)
99 sti/ - Still Image service
100 tapi32/ - Telephone interface
101 ttydrv/ - TTY display driver (Wine specific)
102 twain/ - TWAIN Imaging device communications
103 url/ - Internet shortcut shell extension
104 urlmon/ - URL Moniker allows binding to a URL (like KIO/gnome-vfs)
105 user/ - Window management, standard controls, etc.
106 uxtheme/ - Theme library
107 version/ - File installation library
108 win32s/ - 32-bit function access for 16-bit systems
109 winaspi/ - 16 bit Advanced SCSI Peripheral Interface
110 winedos/ - DOS features and BIOS calls (interrupts) (wine specific)
111 wineps/ - Postscript driver (Wine specific)
112 wininet/ - Internet extensions
113 winmm/ - Multimedia (16 & 32 bit)
114 winmm/joystick/ - Joystick driver
115 winmm/mcianim/ - MCI animation driver
116 winmm/mciavi/ - MCI video driver
117 winmm/mcicda/ - MCI audio CD driver
118 winmm/mciseq/ - MCI MIDI driver
119 winmm/mciwave/ - MCI wave driver
120 winmm/midimap/ - MIDI mapper
121 winmm/wavemap/ - Audio mapper
122 winmm/winealsa/ - ALSA audio driver
123 winmm/winearts/ - aRts audio driver
124 winmm/wineaudioio/ - audioio audio driver
125 winmm/winejack/ - JACK audio server driver
126 winmm/winenas/ - NAS audio driver
127 winmm/wineoss/ - OSS audio driver
128 winnls/ - National Language Support
129 winsock/ - Sockets 2.0 (networking)
130 wsock32/ - Sockets 1.1 (networking)
131 wintab32/ - Tablet device interface
132 winspool/ - Printing & Print Spooler
133 wintrust/ - Trust verification interface
134 wow32/ - WOW subsystem
135 x11drv/ - X11 display driver (Wine specific)
140 programs/ - All the Winelib programs
142 avitools/ - AVI information viewer and player
143 clock/ - Graphical clock
144 cmdlgtst/ - Common dialog tests
145 control/ - Control panel
146 expand/ - Decompress Lempel-Ziv compressed archive
147 notepad/ - Notepad with RichEdit functionality
148 osversioncheck/ - Check version of Windows being indicated
149 progman/ - Program manager
150 regapi/ - Command line Registry implementation
151 regedit/ - Registry editor
152 regsvr32/ - Register COM server
153 regtest/ - Registry testing program
154 rpcss/ - RPC services
155 rundll32/ - Execute DLL functions directly
156 uninstaller/ - Remove installed programs
157 view/ - Metafile viewer
158 wcmd/ - Command line interface
159 wineconsole/ - Console
161 winefile/ - File manager
162 winemine/ - Mine game
163 winepath/ - Translate between Wine and Unix paths
164 winhelp/ - Help viewer
165 winver/ - Windows Version Program
168 Support programs, libraries, etc:
169 ---------------------------------
171 documentation/ - some documentation
172 include/ - Windows standard includes
173 libs/ - the Wine libraries
174 libs/port/ - portability library
175 libs/unicode/ - Unicode support shared
176 libs/uuid/ - Windows-compatible UUID numbers
177 libs/wine/ - Wine bootstrap library
178 libs/wpp/ - C preprocessor
179 loader/ - the main Wine loader
180 server/ - the Wine server
181 tools/ - relay code builder, resource compiler, etc.
187 Note: these directories will ultimately get moved into their
190 files/ - KERNEL file I/O
191 misc/ - KERNEL shell, registry, winsock, etc.
193 graphics/ - GDI graphics drivers
194 objects/ - GDI logical objects
196 controls/ - USER built-in widgets
197 windows/ - USER window management
201 IMPLEMENTING NEW API CALLS
202 ==========================
204 This is the simple version, and covers only Win32. Win16 is slightly
205 uglier, because of the Pascal heritage and the segmented memory model.
207 All of the Win32 APIs known to Wine are listed in the .spec file of
208 their corresponding dll. An unimplemented call will look like (from
210 269 stub PolyBezierTo
211 To implement this call, you need to do the following four things.
213 1. Find the appropriate parameters for the call, and add a prototype to
214 the correct header file. In this case, that means [include/wingdi.h],
215 and it might look like
216 BOOL WINAPI PolyBezierTo(HDC, LPCVOID, DWORD);
217 If the function has both an ASCII and a Unicode version, you need to
218 define both and add a #define WINELIB_NAME_AW declaration. See below
219 for discussion of function naming conventions.
221 2. Modify the .spec file to tell Wine that the function has an
222 implementation, what the parameters look like and what Wine function
223 to use for the implementation. In Win32, things are simple--everything
224 is 32-bits. However, the relay code handles pointers and pointers to
225 strings slightly differently, so you should use 'str' and 'wstr' for
226 strings, 'ptr' for other pointer types, and 'long' for everything else.
227 269 stdcall PolyBezierTo(long ptr long) PolyBezierTo
228 The 'PolyBezierTo' at the end of the line is which Wine function to use
229 for the implementation.
231 3. Implement the function as a stub. Once you add the function to the .spec
232 file, you must add the function to the Wine source before it will link.
233 Add a function called 'PolyBezierTo' somewhere. Good things to put
235 o a correct prototype, including the WINAPI
236 o header comments, including full documentation for the function and
237 arguments (see documentation/README.documentation)
238 o A FIXME message and an appropriate return value are good things to
241 /************************************************************
242 * PolyBezierTo (GDI32.269)
244 * Draw many Bezier curves.
248 * Failure: FALSE. Use GetLastError() to find the error cause.
253 BOOL WINAPI PolyBezierTo(HDC hdc, /* [In] Device context to draw to */
254 LPCVOID p, /* [In] Array of POINT structs */
255 DWORD count /* [In] Number of points in p */
258 /* tell the user they've got a substandard implementation */
259 FIXME(gdi, ":(%x,%p,%d): stub\n", hdc, p, count);
261 /* some programs may be able to compensate,
262 * if they know what happened
264 SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
265 return FALSE; /* error value */
268 4. Implement and test the rest of the function.
271 IMPLEMENTING A NEW DLL
272 ======================
277 Apart from writing the set of needed .c files, you also need to do the
280 1. Create a directory <MyDll> where to store the implementation of
281 the DLL. This directory has to be put under the dlls/ directory.
282 If the DLL exists under Windows as both 16 and 32 bit DLL, you
283 should have a single directory with both implementations.
285 2. Create the Makefile.in in the ./dlls/<MyDll>/ directory. You can
286 copy an existing Makefile.in from another ./dlls/ subdirectory.
287 You need at least to change the MODULE and C_SRCS macros.
289 3. Add the directory in ./configure.ac (in AC_OUTPUT macro at the end
290 of the file to trigger the Makefile generation)
292 4. Run ./make_dlls in the dlls directory to update Makefile.in in
295 5. You can now regenerate ./configure file (with 'make configure')
296 and the various Makefiles (with 'configure; make depend') (run
297 from the top of Wine's tree).
298 You should now have a Makefile file in ./dlls/<MyDll>/
300 6. Create the .spec file for the DLL exported functions in your
301 directory. Refer to 'Implementation of new API calls' earlier in
302 this document for more information on this part.
304 7. You can now start adding .c files. For the .h files, if they are
305 standard Windows one, put them in include/. If they are linked to
306 *your* implementation of the dll, put them in your newly created
312 If you need to create a new debug channel, just add the
313 WINE_DEFAULT_DEBUG_CHANNEL to your .c file(s), and use them.
314 All the housekeeping will happen automatically.
319 If you also need to add resources to your DLL, then create the .rc
320 file. Add to your ./dlls/<MyDll>/Makefile.in, in the RC_SRCS macro,
321 the list of .rc files to add to the DLL. See dlls/comctl32/ for an
327 If you're building a 16 & 32 bit DLLs pair, then from the 32 bit code
328 you might need to call 16 bit routine. The way to do it to add in the
329 code, fragments like:
330 /* ### Start build ### */
331 extern WORD CALLBACK <PREFIX>_CallTo16_word_wwlll(FARPROC16,WORD,WORD,LONG,LONG,LONG);
332 /* ### stop build ### */
333 Where <PREFIX>_ is an internal prefix for your module. The first
334 parameter is always of type FARPROC16. Then, you can get the regular
335 list of parameters. The _word_wwlll indicates the type of return (long
336 or word) and the size of the parameters (here l=>long, w=>word; which
337 maps to WORD,WORD,LONG,LONG,LONG.
338 You can put several functions between the Start/Stop build pair.
340 You can also read the winebuild manpage for more details on this.
342 Then, add to ./dlls/<MyDll>/Makefile.in a line like:
344 EXTRA_OBJS = $(MODULE).glue.o
346 See dlls/winmm/ for an example of this.
351 NE (Win16) executables consist of multiple segments. The Wine loader
352 loads each segment into a unique location in the Wine processes memory
353 and assigns a selector to that segment. Because of this, it's not
354 possible to exchange addresses freely between 16-bit and 32-bit code.
355 Addresses used by 16-bit code are segmented addresses (16:16), formed
356 by a 16-bit selector and a 16-bit offset. Those used by the Wine code
357 are regular 32-bit linear addresses.
359 There are four ways to obtain a segmented pointer:
360 - Using the MapLS function (recommended).
361 - Allocate a block of memory from the global heap and use
362 WIN16_GlobalLock to get its segmented address.
363 - Declare the argument as 'segptr' instead of 'ptr' in the spec file
364 for a given API function.
366 Once you have a segmented pointer, it must be converted to a linear
367 pointer before you can use it from 32-bit code. This can be done with
368 the MapSL function. The linear pointer can then be used freely with
369 standard Unix functions like memcpy() etc. without worrying about 64k
370 boundaries. Note: there's no easy way to convert back from a linear
371 to a segmented address.
373 In most cases, you don't need to worry about segmented address, as the
374 conversion is made automatically by the callback code and the API
375 functions only see linear addresses. However, in some cases it is
376 necessary to manipulate segmented addresses; the most frequent cases
378 - API functions that return a pointer
379 - lParam of Windows messages that point to a structure
380 - Pointers contained inside structures accessed by 16-bit code.
382 It is usually a good practice to used the type 'SEGPTR' for segmented
383 pointers, instead of something like 'LPSTR' or 'char *'. As SEGPTR is
384 defined as a DWORD, you'll get a compilation warning if you mistakenly
385 use it as a regular 32-bit pointer.
391 Under Windows, data structures are tightly packed, i.e. there is no
392 padding between structure members. On the other hand, by default gcc
393 aligns structure members (e.g. WORDs are on a WORD boundary, etc.).
394 This means that a structure like
396 struct { BYTE x; WORD y; };
398 will take 3 bytes under Windows, but 4 with gcc, because gcc will add a
399 dummy byte between x and y. To have the correct layout for structures
400 used by Windows code, you need to embed the struct within two special
401 #include's which will take care of the packing for you:
403 #include "pshpack1.h"
404 struct { BYTE x; WORD y; };
405 #include "poppack1.h"
407 For alignment on a 2-byte boundary, there is a "pshpack2.h", etc.
409 The use of the WINE_PACKED attribute is obsolete. Please remove these
410 in favour of the above solution.
411 Using WINE_PACKED, you would declare the above structure like this:
413 struct { BYTE x; WORD y WINE_PACKED; };
415 You had to do this every time a structure member is not aligned
416 correctly under Windows (i.e. a WORD not on an even address, or a
417 DWORD on a address that was not a multiple of 4).
420 NAMING CONVENTIONS FOR API FUNCTIONS AND TYPES
421 ==============================================
423 In order to support both Win16 and Win32 APIs within the same source
424 code, the following convention must be used in naming all API
425 functions and types. If the Windows API uses the name 'xxx', the Wine
428 - 'xxx16' for the Win16 version,
429 - 'xxx' for the Win32 version when no ASCII/Unicode strings are
431 - 'xxxA' for the Win32 version with ASCII strings,
432 - 'xxxW' for the Win32 version with Unicode strings.
434 If the function has both ASCII and Unicode version, you should then
435 use the macros WINELIB_NAME_AW(xxx) or DECL_WINELIB_TYPE_AW(xxx)
436 (defined in include/windef.h) to define the correct 'xxx' function
437 or type for Winelib. When compiling Wine itself, 'xxx' is _not_
438 defined, meaning that code inside of Wine must always specify
439 explicitly the ASCII or Unicode version.
441 If 'xxx' is the same in Win16 and Win32, you can simply use the same
442 name as Windows, i.e. just 'xxx'. If 'xxx' is Win16 only, you could
443 use the name as is, but it's preferable to use 'xxx16' to make it
444 clear it is a Win16 function.
448 typedef struct { /* Win32 ASCII data structure */ } WNDCLASSA;
449 typedef struct { /* Win32 Unicode data structure */ } WNDCLASSW;
450 typedef struct { /* Win16 data structure */ } WNDCLASS16;
451 DECL_WINELIB_TYPE_AW(WNDCLASS);
453 ATOM RegisterClass16( WNDCLASS16 * );
454 ATOM RegisterClassA( WNDCLASSA * );
455 ATOM RegisterClassW( WNDCLASSW * );
456 #define RegisterClass WINELIB_NAME_AW(RegisterClass)
458 The Winelib user can then say:
460 WNDCLASS wc = { ... };
461 RegisterClass( &wc );
463 and this will use the correct declaration depending on the definition
464 of the UNICODE symbol.
467 NAMING CONVENTIONS FOR NON-API FUNCTIONS AND TYPES
468 ==================================================
470 Functions and data which are internal to your code (or at least shouldn't be
471 visible to any Winelib or Windows program) should be preceded by
472 an identifier to the module:
476 ENUMPRINTERS_GetDWORDFromRegistryA() (in dlls/winspool/info.c)
477 IAVIFile_fnRelease() (in dlls/avifil32/avifile.c)
478 X11DRV_CreateDC() (in graphics/x11drv/init.c)
480 if you need prototypes for these, there are a few possibilities:
481 - within same source file only:
482 put the prototypes at the top of your file and mark them as prototypes.
483 - within the same module:
484 create a header file within the subdirectory where that module resides,
485 e.g. graphics/ddraw_private.h
486 - from a totally different module, or for use in winelib:
487 you should never do that. Only exported APIs can be called across
494 To display a message only during debugging, you normally write something
502 depending on the seriousness of the problem. (documentation/debugging.sgml
503 explains when it is appropriate to use each of them). You need to declare
504 the debug channel name at the top of the file (after the includes) using
505 the WINE_DEFAULT_DEBUG_CHANNEL macro, like so:
507 WINE_DEFAULT_DEBUG_CHANNEL(win);
509 If your debugging code is more complex than just printf, you can use
512 TRACE_ON(xxx), WARN_ON(xxx), ERR_ON(xxx) and FIXME_ON(xxx)
514 to test if the given channel is enabled. Thus, you can write:
516 if (TRACE_ON(win)) DumpSomeStructure(&str);
518 Don't worry about the inefficiency of the test. If it is permanently
519 disabled (that is TRACE_ON(win) is 0 at compile time), the compiler will
520 eliminate the dead code.
522 For more info about debugging messages, read:
524 http://www.winehq.org/site/docs/wine-devel/debugging
530 1. There is a FREE online version of the MSDN library (including
531 documentation for the Win32 API) on http://msdn.microsoft.com/
532 or http://www.msdn.com/
534 2. Windows apilist: http://www.mentalis.org/apilist/apilist.php
536 3. http://www.sonic.net/~undoc/bookstore.html
538 4. In 1993 Dr. Dobbs Journal published a column called "Undocumented Corner".
540 5. www.geocities.com/SiliconValley/4942/
projects / wine / blob