General Developer Information

From Wine-Wiki

Jump to: navigation, search

Contents

Introduction

This area is for links to the wine-devel mailing list for Wine Developers. 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

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...

Compiling Wine

Building Wine Even Faster

Copied from WWN269Wine HQ WWN 269 Speeding up Builds
Each time I make a modification (even one line), a 'make' followed by a 'make install' can take a long while...

S.Dossinger: I run these commands in the directory of the dll or program which I changed. That is way faster(especially make install)

The user reported that this was 'way faster'


M.McCormack suggested: Try skipping the 'make install', and instead run wine from the build directory. eg. 

~/src/wine/wine regedit

I make a point of never installing Wine to make sure I don't accidently run an older installed version that didn't get overwritten properly.

I.Leo Poti expanded on this: you can also just have a script called "wine" in your path, that does something like 

#!/bin/bash
/path/to/wine $*


The user then tried runing wine from the build directory: The downside is that make is still slower than if you do it in the directory where you made a modification. The plus side is that it also works when you are modifying the server part of wine. Wine Archive Link


Running Wine from its source tree

M. McCormack: Yes, it can be done [without re installing wine]. In fact, I don't have Wine installed to make sure that I don't get confused as to which version I'm testing. I have the attached script (exists at ~/bin/wine_envsetup) to set up my environment (assumes wine in ~/wine), but running ~/wine/wine will also work.

You can set up a ~/.wine from the source tree using:

./tools/wineprefixcreate --use-wine-tree .

Then add an alias to set up your environment to your ~/.bashrc, something like this:

export OLDPATH=$PATH alias winehq='. $HOME/bin/wine_envsetup'

You can then run 'winehq' to setup your environment. I find this configuration useful to because I have multiple wine environments, so multiple ~/bin/*_envsetup scripts. It points everything to the right place so that running 'wine' on the command line will run the wine binary from the setup I'm interested in, not a shell script.

Again, you don't need to go to all this trouble if you're happy to run the ~/wine/wine script in the source directory.

Mike

  1. !/bin/sh
  2. set up the Wine environment
CVSROOT=:pserver:cvs@cvs.winehq.org:/home/wine
PATH=$OLDPATH:$HOME/wine:$HOME/wine/tools/winegcc
WINESERVER=$HOME/wine/server/wineserver
WINELOADER=$HOME/wine/loader/wineloader
WINEPREFIX=$HOME/.cxoffice/default
LD_LIBRARY_PATH=$HOME/wine/libs/unicode:$HOME/wine/dlls:$HOME/wine/libs/wine
WINEDBG=$HOME/wine/debugger/winedbg
WINEDLLPATH=$HOME/wine/dlls:$HOME/wine/programs
export CVSROOT PATH WINESERVER WINEPREFIX LD_LIBRARY_PATH WINEDBG WINEDLLPATH WINELOADER


D. Kegel [Dec 05] discovered a possible concern when running wine from it's source tree: 

wine: cannot open builtin library for L"C:\\windows\\system32\\regsvr32.exe": 
/home/[nobody]/wine/programs/regsvr32.exe.so: invalid ELF header

V. Margolen: The only time I have seen this message in relation to regsvr32.exe is only when Wine's builtin regsvr32.exe.so was overwritten with native PE executable. That could happen only of you have write access to the the place where you installed wine, or if you running it from the source tree. [It] Looks like a case of overwritten regsvr32.exe with native copy (like what IE6 installation will do).

[After some troubleshooting D. Kegel reported: the problem was caused by having an old copy of wine installed in /usr/local while running a new copy of wine from the build directory. Removing the old copy, and installing wine from the build directory, fixes the problem; I can then run regsvr32 from either the build directory or the installed copy without problems. Nasty little troubleshooting problem. I guess I have to be a lot more careful, and make sure to uninstall all old copies of wine before running new builds without installing. wine archive


Running Wine from the Source Tree

[Bug 1947 Aug 07] Call the wine binary out of your git directory, ie:

$ ~/wine-git/wine /path/to/app.exe

It makes git bisect easy and it's faster with not having to do "make install" first.


Further Reading

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

Wine Archive

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:

  1. define discard_const(ptr) ((void *)((intptr_t)(ptr)))
  2. 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

A. Woods: here are the steps to achieve this for Gentoo 2004.3:

  1. 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)
  2. autoconf
  3. ./configure --x-libraries=<path_to_your_multilib_x_libs>
  4. make depend && make
  5. make install
  6. 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

Compiling with GCC4.0

M. Meissner May 2005: Wine CVS will compile with current CVS and gcc 4.[If you have problems,] Please post error messages [to the wine-devel mailing list].


I. Gyurdiev wrote in April 2005: I Haven't been able to compile cvs wine for the last few weeks with Fedora Rawhide with gcc4. Any suggestions? 

> gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./..   -D_REENTRANT -fPIC -Wall -pipe
 -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith  -g -O2 -o file.o file.c
> In file included from ../../../include/winnt.h:27,
>                  from ../../../include/windef.h:204,
>                  from ../../../include/wine/test.h:25,
>                  from file.c:21:
> ../../../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function 'iswalnum'
> ../../../include/msvcrt/ctype.h:73: warning: conflicting types for built-in function 'iswalpha'
> ../../../include/msvcrt/ctype.h:75: warning: conflicting types for built-in function 'iswcntrl'...

James Hawkins: Edit the respective files containing the errors (iewine/include/msvcrt/process.h) and #if 0 define out all the aliases. Apparently these aren't needed because everything works fine without them. Wine Archive Link

Aliasing and GCC4.0

After a breakage was noticed with GCC4 and aliasing used in Wine, D. O. Paum explained the reason for it's use in Wine

D. O. Paun: aliasing was introduced, [in Wine] because using macros [was] not always acceptable. Some source uses these functions in ways that break if they are defined as macros. Defining them as inline functions work, but we can't do so for varargs, in which case we used aliases.

D. Kegel: http://www.gnu.org/software/gcc/gcc-4.0/changes.html says

--- snip --- Given __attribute__((alias("target"))) it is now an error if target is not a symbol, defined in the same translation unit. This also applies to aliases created by #pragma weak alias=target. This is because it's meaningless to define an alias to an undefined symbol. On Solaris, the native assembler would have caught this error, but GNU as does not. --- snip ---

M. Meissner: The problem is that "aliases" are only useable for renaming functions in the compilation units where they are defined, not for some kind of highlevel "#define" method. [M. Meissner posted patch for compiling Wine with gcc4.0 to the list]Wine Archive Link April 2005

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.

Wine Archive Link

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

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 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 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.

Disassembly

Can someone recommend a good win32 disassembler, preferably one that shows the contents of data segments and shows imports/exports?

  • 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

M. Hearn: SVK can help and I've been using it to manage incremental diffs with the DCOM stuff. Only issue is that it needs to be set up first. Don't try and branch from CVS directly. It supports that but there are some bugs that need to be fixed first. Instead, just maintain a CVS checkout inside SVK with all the CVS control files as well. That's what I do and it works OK. You can do a "cvs diff" to get a patch relative to HEAD and an "svk diff" to get a patch relative to whatever you last committed.

Long term a gateway is needed because it makes merging patches from HQ into your tree without having to commit your own work much simpler. Also parsing the Wine CVS repo takes ages because it's so huge.[3]


Setting up SVK

  1. Install SVK
  2. Do an "svk import" of the clean WineHQ source tree
  3. Build it
  4. Apply your first patch, check it builds, "svk diff >mypatch", submit
  5. svk commit
  6. Apply your second patch, check it builds, "svk diff >mypatch", submit
  7. svk commit .... etc etc
  8. You can now access any patch relative to the previous one with svk diff -r4:5, eg to see the differences between revisions 4 and 5

I always have to use -p0 to apply patches to Wine, that is just the way we generate them.

Obviously this is a very simple usage of the tool, but more advanced work requires me to finish setting up the gateway.

Emacs has some pretty powerful interactive merge abilities that let you select particular chunks to apply, shows you the exact parts that changed and you can edit the document at the same time.


T. Rollo [Jun 05]: I have been experimenting with SVK and Subversion managing a handful of branches to Wine CVS, and it appears to be working well. The system is based on a "central" Subversion repository that mirrors the Wine CVS tree without any modifications (publicly readable at svn://wine-svn.troy.rollo.name/wine/wine/) and is kept up to date within a day or so.

Branches are stored in separate Subversion repositories.

I am finding this very convenient. If you have converted from CVS to Subversion on other projects, you are probably aware of the huge difference it makes. Adding SVK on top of Subversion is another giant leap when you have distributed development. In the case of Wine, however, with the CVS repository being read-only except to Alexandre, the difference between read-only CVS and the combination of Subversion and SVK is even more dramatic (I would compare it to the difference between chiselling documents into stone tablets and using a word processor).

For anybody who is interested in moving their own Wine development to Subversion and SVK, there is a page on the Wiki describing what to do at <http://wiki.winehq.com/SVK>

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?

  1. copy and pasting the code as required.
  2. dynamically loading an elf library at runtime
  3. do configure checks at ./configure and link statically
  4. do the same and link dynamically
  5. 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] 

[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

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

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


Wine Sound Troubleshooting

Wine Archives F. Gouget: Sound depends a lot on the sound card. Some sound cards support only specific sampling rates while others are more accommodating. And that's just one issue. For the Wine operating system, side there are a number of other issues such as mmap support, full duplex support and DSP_GETOSPACE support that vary from one sound card to the next (and to some extent varies even from one Alsa configuration / OSS emulation version to the next), all of which cause problems with sound.

Wine sensitive to these issues, even more so if the application uses DirectSound. Part of this is because the Windows API is painful to emulate, but another part of it is the lack of debugging of basic sound. Unfortunately, debugging supposes one has a sound configuration that does not work which makes it even trickier.

What this means is that each Wine developer who has sound problems can essentially only count on himself to debug them. To help these ones I would recommend the following steps:

  1. Compile the Sound tests 
cd dlls/winmm/tests
make test
  1. Check that winmm works fine: 
WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c
  1. Compile the DirectSound tests: 
cd dlls/dsound/tests
make test
  1. Check that dsound works fine:
Currently (Mar 2003) you manually edit the Wine configuration file for these tests: set HardwareAcceleration = Emulation. 
WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c

Many Wine users are having problems with basic not-low-latency stereo sound and more progress is needed in this area.

Further Reading

Writing a Conformance Test to catch a Bug

MSDN is 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?

A user reported a crash with an EN_MAXTEXT notification and a developer replied "From what I understand, the program crashes when it receives EN_MAXTEXT notification. You should figure out why the textbox is too small to contain the text. Or maybe this notification shouldn't be sent at all, although MSDN says it should be, but maybe there are some exceptions. Probably you'll need to write some test's to figure out what exactly goes wrong."

V. Margolen: You can look at dlls/user/tests/win.c for examples on how to write your own WndProc, attach it to window and test for messages received. Wine Archive Link

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


Links

Wine Links

Retrieved from "http://wiki.jswindle.com/index.php/General_Developer_Information"
Personal tools