General Developer Information
From Wine-Wiki
Introduction
This area is for links to the wine-devel mailing list for Wine Developers. Because wine moves so fast, this will quickly become out of date, as opinions, and decisions do change over time. When information is based on discussions in the Wine mailing lists, please give the authors their due recognition by including a link to the archives [1]. Readers are then able to find and examine the original posts or articles.
Official Documentation is Here
- The Wine FAQ at http://winehq.org/site/docs/wine-faq/index
- [May 05] B. Vincent: The FAQ [has] recently changed.Wine Archive Link
- According to WWN: Wine Documentation the most up to date document.
- The Wine User Guide at http://winehq.org/site/docs/wine-user/index
- WWN: Wine Documentation This will need updating as the Config File is now removed.
- The Wine Developers Guide at http://winehq.org/site/docs/wine-devel/index
- [May 05] WWN: Wine Documentation :Recently updated. 'In great shape'.
- WineLib User Guide needs some work
- and according to one developer [Jun 06]: "DEVELOPERS-HINTS" is your friend :-) wine archive
- How to help get applications working in Wine at http://winehq.org/site/helping-applications
- Getting Started with Wine Development at http://winehq.org/site/developer-cheatsheet
- Official WineHQ wiki (note: this one is more developer-oriented)
Interesting details that have yet to be assigned a permanent page in the wiki can also be listed here.
Wine
Wine is not an interpreter or a JIT compiler. It is a binary loader, so it loads a Windows program into memory, and jumps to the start address. The program itself will run exactly the same way as on a Windows machine, expect for the times when it calls an API function in a "builtin" or Wine implemented DLL.
Anon [jun 05] questioned what the effort would be to port Wine run on a Power Series RISC cpu:
M.McCormack: If you want to run general Windows (eg. existing Windows binaries) then you're better off running Wine inside a real emulator such as QEMU. If you're only planning to run Winelib binaries (eg. compiled by you from source code), it can be done without using a CPU emulator. Either way, it's a significant amount of work.Wine Archive
Wine Tips and Tricks
Counting the Lines of code in Wine
T. Wicklinke [Aug 05]: calculating it from a clean CVS download from about 10 minutes ago.
$wc -l `find . -name "*" -exec file {} \; | grep "ASCII C" | awk -F\: '{print $1}'` <snip> 1,526,983 total
A. Julliard: I've been using something like this:
wc -l `find . -name "*.[chS]" -print -o -name "*.spec" -print | grep -v unicode/c_ | grep -v wineps/data/` | tail -1
It should probably be updated to count idl files too.
T. Wickline: With the current method I get a line count of 1,440,439 Wine Archive
The WineServer
The wineserver is an integral part of wine...
Configure
tools/wineinstall does not generate configure, since configure is kept in tree, e.g., AJ runs autoconf whenever configure.ac changes.
If you're changing the wine source in some way, you can add that change to wineinstall, nothing's stopping you...
$ rm configure && autoconf && ./configure
works[..] Winehq Bugzilla entry 18322
Further read
Enabling GCC Warnings
Apparently not all warnings need to be fixed.
A patch was suggested: This patch adds prototypes for the functions in opengl_norm.c which are prefixed with 'wine_'. As this file is generated from the make_opengl script this was also modified to emit this additional lines as it already did for opengl_ext.c. This patch fixes 374 missing-declarations warnings.
However A. Julliard noted: At the cost of adding 374 useless prototypes... We really don't want to do that, it's perfectly legitimate in that case that the functions don't have a declaration, that's why the warning is not turned on by default. Wine Archive
Compiling Wine with -Wstrict-prototypes
Work has been on going toward enabling wine to compile cleanly with the option -Wstrict-prototypes, with regular patches being accepted.
According to the gcc Manual http://www.psc.edu/general/software/packages/gcc/manual/gcc_11.html#SEC14:
- -Wstrict-prototypes:
- Warn if a function is declared or defined without specifying the argument types. (An old-style function definition is permitted without a warning if preceded by a declaration which specifies the argument types.)
Dimi Paun asked [Jun 05]: Will we be able to ever turn this on by default? If so, how far away are we?
S. Huehner: Good question. Counting unique occurences of "warning: function declaration isn't a prototype' i get 431 lines at present. From these there are several header files which are included often and cause a lot of ocurrences of a single unique warning i.e.:
1324 ../../include/windef.h:260: warning: function declaration isn't a prototype
I don't check these ones at the moment but [I am trying] to decrease the 431 lines at present. I dont know [yet] whether these warnings coming from some header files can be removed or silenced. Wine Archive
Compiling Wine with -W-Wall=
While wine doesnt use this by default - as Erik de Castro Lopo pointed out, it can be handy.
Gcc-4.0 catches this:
cat test.c int main (void)
{
if (0) ;
return 0 ;
}
gcc-4.0 -W -Wall test.c -o /dev/null
test.c: In function 'main':
test.c:3: warning: empty body in an if-statement
Compiling Wine with -Wcast-qual
S. Huehner: In include/wine/unicode.h there are 4 functions:
static inline int strncmpW( const WCHAR *str1, const WCHAR *str2, int n) static inline WCHAR *strchrW( const WCHAR *str, WCHAR ch ) static inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch ) static inline WCHAR *strpbrkW( const WCHAR *str, const WCHAR *accept )
whose signatures forces us to discard the const of an parameter while returning it as the function value. Compiling with -Wcast-qual gives (correctly) this warning:
- ../../include/wine/unicode.h:218: warning: cast discards qualifiers from pointer target type
Together these four functions account for a total of 1400 (!) warnings.
In samba_4 sourcecode i discovered the following macros, which are apparently a hack but silences these warnings:
- define discard_const(ptr) ((void *)((intptr_t)(ptr)))
- define discard_const_p(type, ptr) ((type *)discard_const(ptr))
[He then attached a 'proof of concept' patch and wondered..] how portable this solution is.
J. Caben: To make it portable you can use ULONG_PTR instead of intptr_t.
J. Vernooij: It should be fairly portable as it works on all of the platforms Samba runs on, which includes odd ones such as AIX, Cray, various BSDs, solaris.
D. Laight mentioned a possible alternative:
- static inline void *deconst(const void *p)
- {
- return ((const char *)p - (const char *)0) + (char *)0;
- }
Compiling a Working Multilib Wine on AMD64
[this is very old. Perhaps should be removed] A. Woods: here are the steps to achieve this for Gentoo 2004.3:
- Move your /usr/include out of the way and replace with one from an ix86 box (might not be necessary if your distro has multilib includes)
- autoconf
- ./configure --x-libraries=<path_to_your_multilib_x_libs>
- make depend && make
- make install
- Don't forget to put your /usr/include back ;)
Currently (Feb2004) there is a problem with the 2.6.10 kernel, but with 2.6.9 wine runs perfectly.
At this point in time multilib is in varying states on different distributions. You may need to create symbolics to some libraries if the compile complains about them not being found (eg libXext, libX11, libasound). You will also need a version of wine >= 20050211, which is the first version with the required patch in it for building a multilib wine.
Compiling a working multilib wine is an advanced task. However the benefits can be worth it, in that that a multilib wine optimised for AMD64 processors works very well.
Wine-Devel Archive Links: Ptrace problems on AMD64
Unicode
Generating a Code Page File
A programmer said: I want to generate a new code page file for code page 20261, the T.61 (Teletex) code page. The comments in the c_*.c files in libs/unicode say the files are generated, so I was wondering.. by what?
D. Timoshkov: They are generated by libs/unicode/cpmap.pl
The programmer noted: There's no file for 20261 on the unicode.org web site, but I wrote a Windows program that spits out the encoding of each unicode character in 20261. I'll happily mangle it to produce the format desired by whatever converter program.. unless there isn't one.
D. Timoshkov: I'd recommend to find independent source of cp20261 and do not use Windows data. Then you can generate Wine compatible c_20261.c file and submit it for inclusion. Wine Archive
Editors
A. Talbot highlighted a possible bug in Kate [Jun 06]: in Vim, a sample array looks like this, containing some accented characters:
- /*** Icelandic keyboard layout (setxkbmap is) */ static const char
- main_key_IS[MAIN_LEN][4] = {
- "","1!","2\"","3#","4$","5%","6&","7/","8(","9)","0=","","-_",
- "qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","","'?",
- "aA","sS","dD","fF","gG","hH","jJ","kK","lL","","","+*",
- "zZ","xX","cC","vV","bB","nN","mM",",;",".:","", "<>"
- };
I have the text editor I use - Kate - set to use utf8 encoding, which renders the same text thus:
- /*** Icelandic keyboard layout (setxkbmap is) */ static const char
- main_key_IS[MAIN_LEN][4] = {
- "","1!","2\"","3#","4$","5%","6&","7/","8(","9)","0=","?","-_",
- "qQ","wW","eE","rR","tT","yY","uU","iI","oO","pP","?","'?",
- "aA","sS","dD","fF","gG","hH","jJ","kK","lL","?","?,"+*",
- ^
- missing double quote
- "zZ","xX","cC","vV","bB","nN","mM",",;",".:","?, "<>"
- };
If I save this file in my editor, I inadvertently corrupt it into this second form. wine archive
Icon Artwork
You don't need to be a programmer to help out with Wine. You could assist by working with Icons.
M. Hern: Typically icons have to be totally redrawn in the Gimp for 16x16 and other small sizes according to Jimmac. Here are some tips:
- Avoid perspective, at the sizes Wine works at (32x32 and 16x16) perspective just doesn't work. Draw them front on.
- We don't need SVG or large sizes, because Windows doesn't use them. 48x48 is the max necessary and I'm not sure we actually use them in Wine (they are an XP thing)
- icons with a very clear solid outline. At small sizes the lines can be anti-aliased into grey which we don't want.
Running Multiple Versions of Wine
Sometimes it can be handy when debugging or developing to use more than one version of Wine.
M. Knecht: We're back into debugging problems with the Jack driver for wine. I'd really like to run multiple versions of Wine for a few days.[..] What's the most effective way to handle this and not make mistakes?
D. Gmbel: Wine Archive Link You might want to use a tool I've written for exactly that purpose, called winestart and available online http://www.david-guembel.de/index.php?id=13. Feel free to ask if any questions on the usage arise. [To install winestart] for your personal user[...], put it e.g. in ~/bin/winestart.pl, make it executable, and maybe define an alias like:
alias winestart='/home/YOU/bin/winestart.pl '
Undocumented
API
Ivan Leo Pouti: made a general appeal: to not write wine code based on the docs at undocumented.ntinternals.net, because they're often misleading, incomplete or simply wrong, and do more harm than good. Please refer to "windows nt/2000 native api reference" by Gray Nebbett, to the reactos team, or to me (I've got the book) instead, and always write tests for undocumented functions. Wine Archive
[Do not submitt reactos code to Wine. For more information see Coding Hints:Patches
Further Reading
Shared User Data
V. Margolen [Oct 05]: 0x7ffe0000 is SharedUserData that is present on all NT+ systems. It's format only documented in DDK for kernel address space and only for some first several values. This structure keeps growing as I understand and no one except MS knows what's all in it. We do need this structure for some programs that use it.
U. Bonnes: It's also related to transfering arguments to the winehelp() API call. I I remember, no solution was agreed upon that problem.
I. Leo Pouti: You can see the start of what's there in include/ddk/wdm.h, it's the KSHARED_USER_DATA struct. It's meant to be read only memory for user mode. Wine Archive
How to add a placeholder for a dll
Winehq Bugzilla entry 18308 how would you suggest I go about making a placeholder dll for gdiplus? Without it, the program fails to run properly.
D. Timoshkov: Add it to tools/wine.inf.in,[FakeDllsSection].
How to compile a new wine dll
A programmer [oct 05]: tried creating [his] own DLL inside Wine. I've been following the steps in the DEVELOPER'S HINTS file. I already have my Makefile.in and placed my directory in configure.ac
it looks like this:
- tools/wrc/Makefile])
- AC_OUTPUT dlls/w2lvpd/
- if test "$have_x" = "no"
however, I'm having problems with regenerating the ./configure file. it says here that i should use autoconf. but it shows this error: autoconf autoconf: configure.in <http://configure.in/>: No such file or directory
V. Beron: You need autoconf-2.53b or later. A more specific version check has been added to configure.ac after 20050725 (somtime in September IIRC). Wine Archive
How to add version to a wine dll
P. Vriens: have a look at http://www.winehq.org/pipermail/wine-patches/2005-September/020423.html this shows you how to add version stuff to a dll.
How to Change a Windows Version
A developer [Jan 09] posted a patch to: Change the XP SP version to 3.0, as required by some recent apps. A. Julliard noted: You also need to fix wine.inf and winecfg.
How to scan a DLL
Sometimes you want to know what functions it exports, their arg types and return types. From the mailing list:
A. Mohr [Feb 05]:You really want DependencyWalker, but probably PE Explorer is very useful, too... Or maybe even winedump.[2]
B. Medland: Surely the only way to throw the arguments and return types out, is disassembly - to see what is referenced off the stack and returned.
A. Mohr added: In the case of C, that has to be done, yes. In the case of C++, you've got function name mangling to include the function's parameters as well (as you most likely know ).
[July 05] Is there any way to get these mangled function names to be displayed un-mangled please?
A. Mohr: Yes, use the Winedump program. Wine Archive
C. Reversi: Another option is to use Spy Studio intercepting processes API calls dynamically, you can compare application behaviour in Windows vs Wine, if they has a difference you know where to look before trying a disassembler.
Be careful with dissasembly. Even running a trace on Wine can run into trouble as one developer wrote [Dec 08]: I have been looking to reduce the number of places where window handles are used, so I did a relay trace to see if native richedit controls gave a non-null handle when calling OpenClipboard. The relay trace showed that NULL was being used, even for normal windowed richedit controls.
He was warned: Please don't do that. The calls that native makes are part of the internal workings that you are not supposed to peek into. You should treat native as a black box and only replicate behavior that can be observed through test cases.
Disassembly
Be Carefull in this area, as a mistake could mean you cant work on wine. A. Julliard jan 08 wine devel: You are not allowed to look at what calls the native [Windows] dll makes, that's an implementation detail. The only thing you can do with native is to write test cases to determine the externally visible behaviour. One person was excluded for disassembly and a developer suggested [Dec 08]: If you would like to send me that high level overview then I can see if it works into wine. That way you can continue to contribute and we do not compromise the source code. But A. Julliard instructed: No, please don't do that. We don't want to have people disassemble Windows code at all, even to write high level descriptions. There's simply no need for it, just write test cases.
One programmer who was prevented from contributing asked if his test cases could go in to help developers implement what was needed: Is there anything wrong with these two patches? I'd really like to see these tests go in, so hopefully someone will decide to tackle this olepicture stuff. At the very least, putting the stubs in for OleLoadPictureFile (patch 1/2) keeps my app from crashing...
A. Julliard: Sorry but I'm not going to accept your patches in this area since you looked at the disassembled code. Probably your best bet is to file a bug about the missing function and hope that someone else picks it up.
Someone asked: Can someone recommend a good win32 disassembler, preferably one that shows the contents of data segments and shows imports/exports?
- OllyDbg
- is a good free binary disassembler/debugger
- http://www.ollydbg.de/
- Ida Pro
- is a very nice disassembler/debugger -- (its commerical but it there is a free windows version)
- IDA (Interactive DisAssembler). About $600 or so [...], there are also free versions available. - A. Mohr
- http://www.datarescue.com/
- W32Dasm is a decent (kinda old) disassembler/debugger -- is it still commerical??
- (look for a demo via google)
- REC is an impressive free deCompiler (better than a simple disassembler) its based off boomarang
- recstudio
- HT Editor is far less featureful than IDA Pro, but it has a built-in analyzer and suports many win32 executable formats. I use it in conjunction with winedbg to find wine bugs. - A. Lizardo
F. Nowothnig: REC uses compiler dependant pattern matching which often fails miserably for modern code, it doesn't recognize a huge amount of >i386 opcodes (even some i386 opcodes) and I've seen way too many segfaults when dealing with large programs. I'm not sure if the situation has changed with REC 2.0 but as the author admits that the backend hasn't really changed I doubt it. REC is also (debian) non-free (instead of boomerang, which is open-source and much more advanced from a architectural point of view but isn't really usable for larger binaries either).
You're much better off with some assembly knowledge and a good disassembler. Wine Archive
Tools for Managing Patches for Wine
Update: the Wine project now uses GIT
Wine Environment Variables
D Reikenberg [May 2005]: While reading the source to learn how wine works internal, i found some things not found in the documentation (wine-user.pdf, wine-devel.pdf or winelib-user.pdf):
environment: WINEPATH WINEHOME WINETEMP WINETMP
"WINEPREFIX" is not new for me (working with wineprefixcreate), but the documentation is "rare". [...]
A. Julliard explained: These are internal variables used to pass DOS environment strings through the Unix environment, they are not really meant to be used by end users.
Dimi Paun: Probably wine.man [is where this should be documented], there is already a section there for environment variables.
After further investigation D. Riekenberg commented: While working with wine, I found the way how wine handles the environment.
example for "TMP": 1. HCU\Environment\TMP 2. HKLM\System\CurrentControlSet\Control\Session Manager\Environment\TMP 3. $WINETMP 4. $WINEPREFIX/config (TEMP) 5. Buildin Default (c:\windows\temp)
During "wineprefixcreate", "TMP" and "TEMP" are created for entry 2 (HKLM\..) from entry 4 ($WINEPREFIX/config : TEMP) with a fallback to entry 5 (c:\windows\temp), but entry 3 ($WINETMP) is ignored.
When I delete the entry 2 (HKLM\..), then entry 3 is used ($WINETMP).Wine Archives
Using External Libraries
A programmer asked [July 05]: I'd like to use an LGPL licensed LZX compressor for the compression part of cabinet.dll. What's the best way to accomplish this?
- copy and pasting the code as required.
- dynamically loading an elf library at runtime
- do configure checks at ./configure and link statically
- do the same and link dynamically
- checking a windows-version of this LZX compressor to wine cvs and use that at runtime.
Web site:http://www.speakeasy.org/~russotto/chm/
S. Edwards: "checking a windows-version of this LZX compressor to wine cvs and use that at runtime" If its not too big I would rather go this route to make it less trouble to share the dll with Reactos.
D. Kegel: I had a look at the source for this compressor. It's pretty small. I recommend unpacking lzxcomp.tar.gz right into dlls/cabinet and simply using the source files completely unchanged if possible. Wine Archive
Wine File System
Considerable discussion has arisen about exposing the Unix file system and this also led to examining integrating this with Gnome.
Further Reading
Wine Troubleshooting
Troubleshooting VXD fixme Error Messages
fixme:vxd:VXD...
VxDs are a type of virtual driver that only exist in Windows 3.x and 9x. A VXD must run in ring 0 with all priviledges. So a bad Windows VXD might bring down the whole Linux machine. Supporting VXDs is a lot of work and currently VxD support is minimal
There are a few VXD drivers in wine. In Jan 2001 A grep for vxd in wine gave:
/spare/bon/wine/msdos/vxd.c /spare/bon/wine/win32/device.c /spare/bon/wine/msdos/int2f.c
If the software can run on an NT variation, changing Wine to run as NT/Win2k/WinXP may enable it to run. R.Shearman explains: NT doesn't support VXDs, just like we don't (although we fake a few).Wine Archive Link
fixme:vxd:VXD_Open Unknown/unsupported VxD L"driverx.vxd". Try setting Windows version to 'nt40' or 'win31' ...
fixme:setupapi:SetupDiClassGuidsFromNameExA trace:vxd:DeviceIoControl (0xffffffff,222074,0x7e8e00b4,4,(nil),0,0x72c9f57c,(nil))
T.Barnaby: I understand, from reading mailing lists and looking at the program, that the program is using a DLL which has the capability of loading an embedded VXD driver to access the LPT1 port.
A.Mohr:DriverX appears to be a commercial driver for I/O and parallel port access etc. You might want to implement a DriverX replacement driver in Wine, [You may be able to get this program to communicate with the LPT1 port] If you can trick it into doing direct port access (changing windows version!)or using the parallel port access methods available on Windows, otherwise you WILL have to create a DriverX replacement driver in Wine. Wine Archive Link
sice.vxd, ntice.vxd copy protection
fixme:vxd:VXD_Open Unknown/unsupported VxD L"sice.vxd". Try setting Windows
version to 'nt40' or 'win31'.
T. Lambregts: This is copy protection. If you see attempts to load SICE.VXD or NTICE.VXD then you're seeing a check for the popular SoftIce debugger. You might be able to get arround this by setting the windows version to some varient of NT.
Alter the [Version] section of your ~/.wine/config to instruct Wine to imitate a different version. [After June 2005 apparently you can use winecfg to set the version] [ed update. the config file is now out of date. this would be achieved using winecfg
[Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win2k3,win20,win30,win31) "Windows" = "win2k" ; DOS version to imitate ;"DOS" = "6.22"
fixme:file:DeviceIoControl Unimplemented control 256 for VxD device NWLINK
nwlink.vxd is a virtual device driver the 256 is the screen depth the driver needs.
Further Reading
- Win32 VXD Drivers
- Drivers - Wiki Link
Stubs Partially Explained
What does this stub message: "fixme:actctx:CreateActCtxW stub" mean?
"fixme:actctx:CreateActCtxW stub" means that while Wine has the function CreateActCtxW, the "stub" message means that there is nothing in the function that does anything. The function will get called but (typically) won't do anything other than print a debugging message.
Should I submit a patch that is only a stub? If it doesn't actually do anything is this ok?
M.Hearn please do. Better stubs are definitely improvements, even if they aren't implementing the functionality.
Further Reading
- Introduction to Implementing Stubs
- Wine HQ - WWN 127 'How to make a stub'
- Wine-Devel Archive Link - How to make a stub?
- Developer Hints - IMPLEMENTING NEW API CALLS
When software fails with a beep..
The only response I can get is when it has focus. Then any mouse click or key press gets a beep from the pc speaker
This can turn out to be helpful when debugging - you have a head start on where to start looking. Try finding a MessageBeep() call in the relay log (the speaker beep). This location in the log is where you can find what it is complaining about... Wine-Devel Archive Link
Sound
Sound_Troubleshooting#Wine_Sound_Troubleshooting_using_the_WineTests
Writing a Conformance Test to catch a Bug
MSDN is how shall we put it? 'sometimes' incorrect. Often you need to write a short test to figure out what is happening, or discover whether there are exceptions to a rule. Wine is tested against Windows with the WineTests infrastructure. Developers can test and investigate their hunches across the different versions of Windows with Winetest.
Where is the current testing infrastructre located?
Dimi Timoshkov: a confirmation with a test case is mandatory for not obvious fixes or for fixes which could have side effects. I'd consider all window management/ message handling related patches to be in that category.Wine Archive Link
Further Reading

