September 2004 - Wine-Devel

Re: ez-cdda sleep

by Mike Hearn

On Thu, 2004-09-30 at 16:33, James Hawkins wrote: > I added the ERR output to GetThreadContext and the results are: > > err:thread:GetThreadContext Eip: 0 > err:thread:GetThreadContext Eip: 0 > err:thread:GetThreadContext Eip: 0 > err:thread:GetThreadContext Eip: 0 > > and this continues until I break out of the program with ctrl-c. Huh, well that can't be right, Eip is supposed to be a pointer! Are you sure you did this *after* the server RPC, and not before? If you did it after the RPC returns from the server then maybe we've got a clue as to the problem.

Sept. 30, 2004

Re: ez-cdda sleep

by James Hawkins

I added the ERR output to GetThreadContext and the results are: err:thread:GetThreadContext Eip: 0 err:thread:GetThreadContext Eip: 0 err:thread:GetThreadContext Eip: 0 err:thread:GetThreadContext Eip: 0 and this continues until I break out of the program with ctrl-c. On Thu, 30 Sep 2004 15:27:20 +0100, Mike Hearn <mike(a)navi.cx> wrote: > > I modified Sleep to do an ERR("USING MODIFIED SLEEP!\n") and then > > added the check for timeout==64, set it to 3000, but it still calls > > sleep over and over again without any progress. I even took out the > > check for timeout==64 and just timeout to 3000 for the second test, > > but I get the same results. > > OK. Now stick an ERR into GetThreadContext and dump the output of Eip, so > you can see if the remote process is being scheduled at all. If it is > (remember logs only show Wine interactions, there can be lots of code > which never shows up there), we have some other problem. If Eip never > changes then I suspect we've hit a scheduling difference between the Linux > and NT kernels which could prove fun :) > > -- James Hawkins

Sept. 30, 2004

Re: WINEDLLOVERRIDES for all dlls?

by Mike Hearn

> If we don't want any user using a native advapi32.dll no matter what > the circumstances, shouldn't the default override for advapi32 be > *advapi32=b (no matter whether it's in a config file or the registry > or whatever)? If the user is not using a config file, where are the > default overrides stored btw? Correct. There is a hardcoded list somewhere in the source. I forget where, I discovered it once. See if you can find it, and when you do, patch it to force advapi32 to be builtin. thanks -mike

Sept. 30, 2004

Re: ez-cdda sleep

by Mike Hearn

> I modified Sleep to do an ERR("USING MODIFIED SLEEP!\n") and then > added the check for timeout==64, set it to 3000, but it still calls > sleep over and over again without any progress. I even took out the > check for timeout==64 and just timeout to 3000 for the second test, > but I get the same results. OK. Now stick an ERR into GetThreadContext and dump the output of Eip, so you can see if the remote process is being scheduled at all. If it is (remember logs only show Wine interactions, there can be lots of code which never shows up there), we have some other problem. If Eip never changes then I suspect we've hit a scheduling difference between the Linux and NT kernels which could prove fun :)

Sept. 30, 2004

Re: MSCMS: implement OpenColorProfile{A,W} and CloseColorProfile

by Hans Leidekker

On Saturday 25 September 2004 20:29, Hans Leidekker wrote: > Changelog: > Implement color profile handles. > Implement OpenColorProfile{A,W} and CloseColorProfile. Is there anything wrong with this patch? -Hans

Sept. 30, 2004

How to deal with C++ APIs in wine spec file

by Dan Kegel

Jia L Wu (jwu(a)cc.helsinki.fi) wrote: > I have to write a spec file so that a winelib application can use a third > party dll. The problem is that APIs in third party dll are written in C++. > As c++ names and parameters are mangled, how can i call them in spec file? > For example, how can I call a class constructor (which is built form > another class) in spec file? Can anyone provide me an example? Thanks. Did you know that MSVC and g++ have completely incompatible C++ name mangling? In other words, you can only call third party C++ dlls if you're compiling with MSVC, as far as I know. And you can't compile winelib apps with MSVC, since MSCV only generates Windows apps, not Linux apps. So you may be out of luck. Can you write a windows app rather than a winelib app? If so, then you are in business; you can even build it on Linux (by running msvc under wine, which I do fairly often). - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

Sept. 30, 2004

Problems with SpamAssassin

by Mike McCormack

Raphael is having some trouble sending mail to the lists winehq.org. Can we get him whitelisted? Mike

Sept. 30, 2004

Strictify make_authors

by Francois Gouget

I'm not very familiar with this tool so all I can say is that it does not have compilation errors at startup and seems to behave rationally. Changelog: * tools/make_authors Switch to 'perl -w' and add 'use strict;'. Add prototypes to all functions. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Sept. 29, 2004

main menu bar problem

by Attila Csosz

Hi, We developed an application under windows with borland cbuilder 5 and now we want run under linux with wine (not using an windows partition). We have tried with the latest version ( compiled and installed from CVS ) under "debian testing" linux distribution. This is mainly an opengl application and almost everything works fine but the menu bar dont works, clicking to the menu bar but nothing happened. It seems there is a problem with opengl and the main window. We have tested an other application that uses opengl but with an MDI child window (this works, opengl area in MDI window, main menu in the main window). The original application doesn't have an MDI window. So I think the problem: the main menu is it in the opengl area. Is it possible? We've tested a third application : it has the same problem ( main menu cant be clicked, and this not an MDI application ) We have tried wine in debian-stable, debian-testing, CVS. Thanks for any help (no solution from wine-users) Attila

Sept. 29, 2004

audio driver autodetection

by James Hawkins

>From Mike Hearn's winecfg post: > > - Obviously, once audio autodetection has been moved into the drivers we > > need to kill the audio tab. > > Still needs to be done. Not all that hard. I remember working on this a couple months ago. I put the driver detection in winmm.c, but that was wrong. I can't remember exactly what I was supposed to do to fix it...something like put the driver detection in each driver. I'm not really sure what that means or how it would work if it does what I think it does. Does it mean that we load one driver, and if it doesn't detect its *nix counterpart then it loads the next driver? I would like to get to work on this task, so if anyone has any pointers or ideas on this one, please let me know. -- James Hawkins

Sept. 29, 2004