February 2007 - Wine-devel - list.winehq.org

Re: extract DLL calls from exe file (i.e. from portable executable)
by Stefan Dösinger 12 Feb '07

12 Feb '07

Am Montag 12 Februar 2007 18:56 schrieb Luis C. Busquets Pérez: > Dear all, > > I send this e-mail to you as I have not found a particular section to > put it. I have developped a little program that enables to know the > functions an exe or dll calls. I understand that it may be really > helpful to know if a program will run perfectly on wine or if there is > still a function missing. I think wine-devel is the better list for that. For inclusion in wine please send diffs against the wine code rather than some zipped sources. And I am not sure if pascal is allowed in wine. C or bash scripts are better. > The idea behind this program is the following: > A program compiled to run on MS Windows calls a number of system/program > libraries. > This tool enables to know which functions a program compiled for MS > Windows needs. I think winedump does that, but I could be mistaken > A tool such as WINE provides an implementation of the Windows API. This > implementation has to provide at least the calls that the program calls > in order to run correctly under WINE. Well, not really. That a function is implemented in wine does not necessarily mean that it is free of bugs. In most cases applications do not run because of bugs in the implementation rather than missing functions. > TODO: At this point, you are able to know the calls. In a future time, > extrdll or a script will be able to read the functions that WINE has > implemented and tell a user which dlls or functions on dlls the program > is missing to run correctly. There are some other issues too: I don't speak pascall, but can your program deal with lazy linking, i.e. functions loaded after startup with LoadDLL? And I think you will not be able to read COM interfaces. For example for Direct3D9 you will see only one call, CreateDirect3D9, although d3d9 has numerous interfaces with a few hundred methods.

1 0

Re: extract DLL calls from exe file (i.e. from portable executable)
by Paul Vriens 12 Feb '07

12 Feb '07

Luis C. Busquets Pérez wrote: > Dear all, > > I send this e-mail to you as I have not found a particular section to > put it. I have developped a little program that enables to know the > functions an exe or dll calls. I understand that it may be really > helpful to know if a program will run perfectly on wine or if there is > still a function missing. > > The idea behind this program is the following: > A program compiled to run on MS Windows calls a number of system/program > libraries. > This tool enables to know which functions a program compiled for MS > Windows needs. > > A tool such as WINE provides an implementation of the Windows API. This > implementation has to provide at least the calls that the program calls > in order to run correctly under WINE. > > TODO: At this point, you are able to know the calls. In a future time, > extrdll or a script will be able to read the functions that WINE has > implemented and tell a user which dlls or functions on dlls the program > is missing to run correctly. > > Please let me know if you put it in the winehq. I look forward to have > the opportunity to contribute to the wine project. > > Luis C. Busquets Pérez > T. +32 473 353 128 > > > > ------------------------------------------------------------------------ > > Hi, excuse me if got it wrong, but what's the difference with winedump? Cheers, Paul.

1 0

[7/10] WineD3D: Make the context array dynamic
by Stefan Dösinger 12 Feb '07

12 Feb '07

1 0

DirectX related question
by Tim Schmidt 12 Feb '07

12 Feb '07

Already looking at buying a new computer to play Supreme Commander (http://en.wikipedia.org/wiki/Supreme_commander) is there anything I can do (including, but not limited to purchasing hardware) to help get this game running under Wine? I can't promise miracles, but if I can break down a few obstacles, consider it done. --tim

3 3

Re: user32: WM_NCACTIVATE sent by set_active_window() should never deactivate
by Alexandre Julliard 12 Feb '07

12 Feb '07

Felix Nawothnig <flexo(a)holycrap.org> writes: > This fixes #7198. Problem is that GetForegroundWindow() sometimes > returns NULL (MSDN says: "in certain circumstances, such as when a > window is losing activation"). I didn't bother to check why this > happens for some apps (winemine works fine for me, winecfg doesn't - I > suspect timing issues) here as I saw no point in this check anyway: The point is that the window should not be painted active if it's not the foreground window too. There is one active window per queue, but only one foreground window. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/9] WineD3D: Add a per context structure for context management
by Alexandre Julliard 12 Feb '07

12 Feb '07

Stefan Dösinger <stefan(a)codeweavers.com> writes: > This patch adds a new context management structure which will keep a dirty > state list, state optimization members, a glx context and drawable, ... [2. application/x-zip; 0003-WineD3D-Add-a-per-context-structure-for-context-management.txt.zip]... Please don't send patches in zip format, that's a pain to extract. If you really have to compress please use gzip or bzip2. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Fix compilation on systems that don't support nameless structs.
by Alexandre Julliard 12 Feb '07

12 Feb '07

Francois Gouget <fgouget(a)free.fr> writes: > diff --git a/dlls/ntdll/rtl.c b/dlls/ntdll/rtl.c > index 34a05b7..4d5c41d 100644 > --- a/dlls/ntdll/rtl.c > +++ b/dlls/ntdll/rtl.c > @@ -40,6 +40,12 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(ntdll); > > +#ifdef NONAMELESSSTRUCT > +# define S(x) (x).s > +#else > +# define S(x) (x) > +#endif > + You shouldn't need that sort of macro in the Wine code. Simply define NONAMELESSSTRUCT unconditionally. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comtctl32 : updown : Getter and Setter Tests for Updown control
by James Hawkins 12 Feb '07

12 Feb '07

On 2/10/07, Leslie Choong <septikus(a)gmail.com> wrote: > Hi there, My name is Leslie Choong and I am currently finishing up my > under graduate work at UCLA. This patch is being sent as part of the > coursework for CS 130 : Software Engineering. Please take a look and > let me know if you have any suggestions or comments for change. > Thanks! > -Leslie Choong > + /* Set Range from 0 to 100 */ + r = SendMessage(updown, UDM_SETRANGE, 0 , MAKELONG(100,0) ); + r= SendMessage(updown, UDM_GETRANGE, 0,0); If you're not going to check the first return value, then take out the 'r =', else it seems like you're missing a test. On the other hand, why don't you test the return value? -- James Hawkins

3 4

Re: user32: add test cases for update rects affected by ShowWindow
by Dmitry Timoshkov 12 Feb '07

12 Feb '07

"Clinton Stimpson" <cjstimpson(a)utwire.net> wrote: > This patch adds a test to check the results of GetUpdateRect when a > child window is hidden. > See bug #7360. Wine incorrectly makes an update rect for the > grandparent window which has a todo_wine around it. > > Thanks, > Clinton Stimpson > > ChangeLog: > Add test for GetUpdateRect and ShowWindow interaction. After looking at this test once more, I think we need another test with windows without CS_PARENTDC style set in order to understand better what the proper behaviour is. -- Dmitry.

1 0

Re: wineboot: Start items in StartUp folder on boot, includes security measures.
by James Hawkins 12 Feb '07

12 Feb '07

On 2/11/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Ok, thanks to everybody's responses on the wine-devel list. Here is my > new version of this patch. It starts the items in the StartUp folder > like Windows does (again, if anybody who knows about IShellFolder will > look over my code that would be great :) I tested it and it works for > the Vector NTI installer, but I would really like to have an expert's > opinion on whether it is missing osmething). There were a lot of > comments on wine-devel about malware using this system to start itself > so here is what I added: > > - When wineboot finds a file that it wants to start in the StartUp > folder, it asks the user whether he wants to run the program. His > options are: Always, Yes, No (default), and Never. > - If he selects Yes the program is run, if he select No it is not. > - If he selects Always or Never, I create a registry key in: > HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname > of the program and the value "always" or "never." When wineboot sees > this program in the StartUp folder it checks this key, and if it is > set it performs the appropriate action. > > To me it seems like this would be enough to prevent malware from using > this system because the user could just click no or never. Also, someone > pointed out that wineboot already runs quite a lot of other RUN registry > keys that can be used for malware, and currently there is no system for > these keys like the one I made for startup. Any comments will be > appreciated. Thanks. > These anti-malware changes are unnecessary. We implement Wine to be bug-for-bug compatible with Windows. Windows doesn't ask this question, and Wine shouldn't either. It's not our policy to not implement portions of Windows that make it easier for malware to run. -- James Hawkins

3 2