- Wine-Devel - list.winehq.org

notes under wine under qemu with the help of pth
by Rafael Ávila de Espíndola Aug. 26, 2004

Aug. 26, 2004

I was trying to run lotus notes under wine under qemu. Unfortunately qemu appears to have some trouble with linuxthreads. For example, consider the following program test.c: #include <pthread.h> #include <stdio.h> void * f(void *oie) { printf("tata\n"); pthread_exit(oie); return NULL; } int main() { pthread_t t; int i; pthread_create(&t,NULL,f,&i); printf("blit\n"); pthread_join(t, NULL); return 0; } I can compile and run it natively: $ gcc -Wall -o test -lpthread test.c $ ./test tata blit but qemu (i386 -> i386) fails: $ qemu-i386 ./teste qemu: Unsupported syscall: 258 Segmentation fault My next attempt was to use pth (www.gnu.org/software/pth) export LD_LIBRARY_PATH=/home/rafael/inst/pth/lib gcc -Wall -o teste -I/home/rafael/inst/pth/include/ -L/home/rafael/inst/pth/lib/-lpthread test.c $ ./test blit tata $ qemu-i386 ./teste blit tata Success with the test program. Wine is able to run putty and notes6 when compiled with linuxthreads. To compile wine with pth I had to create empty pthreadtypes.h and sigthread.h files in the pth include dir and apply the attached patch in wine. When compiled with pth wine is able to run putty (even inside qemu!). Unfortunately it fails to run notes6: wine "c:\lotus\notes\nlnotes.exe" fixme:console:SetConsoleCtrlHandler ((nil),0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x601aa540,1) - no error checking or testing yet fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 wine client error:d: version mismatch 0/147. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running? wine client error:d: read: Bad file descriptor wine client error:d: read: Bad file descriptor There was no wineserver running when I started the program and only one was in the path. The log of a successful execution when linked with linuxthreads is: fixme:console:SetConsoleCtrlHandler ((nil),0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x601aa540,1) - no error checking or testing yet fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 fixme:hook:NotifyWinEvent (32782,0x10036,-4,2)-stub! fixme:console:SetConsoleCtrlHandler ((nil),0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x601aa540,1) - no error checking or testing yet fixme:ole:CoRegisterMessageFilter stub fixme:console:SetConsoleCtrlHandler (0x601aa540,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yet I have followed the instructions present in http://vowe.net/archives/004104.html to install notes. Thanks for any help Rafael

1 0

runtime change to WINEDEBUG output
by James Hawkins Aug. 26, 2004

Aug. 26, 2004

Hi, Is there a way to change the trace options of WINEDEBUG during runtime? For example, let's say I'm running an installer that encounters a fatal error during one part of the install. I'm not exactly sure where in the wine code base this error is occurring and it would take forever if I set WINEDEBUG=trace+all and had to wait till I get to the right section to find the error. If this is not a feature we have, would it be possible to write a simple program that will send a message to the wineserver telling it to change it's WINEDEBUG value during runtime? I have no idea how this would be implemented or if anyone else would actually want this feature, but if you have any ideas let me know. Thanks. -- James Hawkins

5 11

Re: Don't compile winetest as part of the main build
by Mike Hearn Aug. 26, 2004

Aug. 26, 2004

Hi Alexandre, Was this dropped? On my laptop (a 600mhz Pentium with 128mb of ram, so not too pokey) attempting to build the winetest binary actually kills the build dead. It ends up attempting to feed ~20mb of data to gas which doesn't make it very happy. I guess I misphrased it - it's not for slower machines, it's for machines with less memory. There's not much reason to run the entire winetest binary on Wine itself, so why do we always build it ? thanks -mike > Mike Hearn <mike_at_navi.cx> > Don't compile winetest as part of the main build to avoid > problems on low memory machines. > > --- programs/winetest/Makefile.in.~1.30.~ 2004-07-22 20:43:42.000000000 +0100 > +++ programs/winetest/Makefile.in 2004-08-01 23:44:24.334453984 +0100 > @@ -1,3 +1,7 @@ > +# MKPROG_SKIP > + > +# This program must be built explicitly to make compiles on slower machines easier > + > TOPSRCDIR = @top_srcdir@ > TOPOBJDIR = ../.. > SRCDIR = @srcdir@

4 4

Re: Don't compile winetest as part of the main build
by Ivan Leo Puoti Aug. 26, 2004

Aug. 26, 2004

> On my laptop (a 600mhz Pentium with 128mb of ram, so > not too pokey) attempting to build the winetest binary actually kills > the build dead. I have a 500 mhz laptop with 128 mv of ram, and winetest builds quite successfully, so maybe it's something wrong with your build toolchain, or your configuration, or something else like that? Ivan.

2 1

Re: Don't fall back to OSS when Drivers=""
by Mike Hearn Aug. 26, 2004

Aug. 26, 2004

Ditto, was there something wrong with this one? > Mike Hearn <mike_at_navi.cx> > Don't fall back to OSS when Drivers="" > > --- dlls/winmm/lolvldrv.c.~1.58.~ 2004-06-01 20:40:48.000000000 +0100 > +++ dlls/winmm/lolvldrv.c 2004-08-03 22:01:16.795976000 +0100 > @@ -731,6 +731,9 @@ > size = sizeof(buffer); > if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) { > p1 = buffer; > + > + if (!*p1) return TRUE; /* if Drivers="" don't load sound */ > + > while (p1) { > p2 = strchr(p1, ';'); > if (p2) *p2++ = '\0';

2 2

Re: Simple bugzilla question
by Ivan Leo Puoti Aug. 26, 2004

Aug. 26, 2004

> Do I put the bug in fixed state and submit the patch or leave that > change to the raised? I suppose you can submit the patch, and change the bug status to fixed once the patch is committed. Ivan.

1 0

Re: GetSecurityInfo stub replacement
by Steven Edwards Aug. 25, 2004

Aug. 25, 2004

Hi, --- Evan Deaubl <wine(a)warpedview.com> wrote: > Well, this has been a humbling experience. :-S Let's see if these > patches finally come out right. > + FIXME("stub!\n"); > + return ERROR_BAD_PROVIDER; In the FIXME message you should print the values of the params being passed to the function. Look at how other stubs are implemented. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

1 0

Get rid of W->A calls : help me help ?
by Joris Huizer Aug. 25, 2004

Aug. 25, 2004

Hello, I'm thinking of trying to do some helpfull work on wine; I have the following problem, - I don't know where to start (I have never done stuff in wine or another open source project) ; but I hope you have patience to guide me into that (but I'm a informatica student, I like learning stuff like htis ;) ) - I don't know the details about Unicode functions; I think the W->A thing of the janitorial might be a great way to start working in wine code; as it doesn't require too much overview about the way wine does its work I think.. (and I don't yet have much of that overview..) About a month ago, I saw a thread, including an interesting patch, about the W->A calls; Could someone find that link? Are there tutorials/manuals/guides/... about Unicode funcitons you recommend ? Now, on to the work: if you can hand me that thread, how do I start? Are there unit tests? Where should I put tests ..? How do I run the tests? Thanks for any help -- I hope it's not too much trouble to answer these questions! Oh.. and if the W->A thing is already covered.. is there some other area where a starter like me could start? regards, Joris

4 5

Re: poll vs. epoll
by Dan Kegel Aug. 25, 2004

Aug. 25, 2004

Shachar wrote: > I noticed that in server/fd.c, the wineserver is using "poll" to select > between file descriptors. The application is going through this code > over 2000 times a second, with over 380 file descriptors each time. I am > wondering whether this can be the cause of the slowdown. > > One of the possible solutions to this would be to use epoll instead. > This, of course, would have to be backed by a configure check, as not > all systems for which wine is intended support epoll. Another, arguably > better, solution would be to use libevent for this purpose. Libevent has > the distinct advantage that it automatically chooses the best tool for > the job (epoll, poll, /dev/poll, or if all else fails, select). By all means, let's try epoll. FWIW, I wrote a wrapper layer that illustrates how to detect whether epoll etc. are available. I'm convinced that *runtime* detection is the only way to go. Compile time detection is insufficient. My code is at http://kegel.com/rn If you actually try to use it, let me know. I expect it might be useful mostly as a guide. It's edge-trigger oriented, but you can trivially add the flag (or remove the flag) needed to get level-triggered behavior again if you really need it. I highly recommend using edge-triggered behavior, though. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 10

USB?
by Alex Zeiger Aug. 25, 2004

Aug. 25, 2004

I'm interested in possibly working on USB support for Wine. I'm not particularly familiar with USB programming, but I'm fluent in C and C++. Where do I start?

6 7