May 2006 - Wine-Devel - list.winehq.org

Missing wine documentation
by mark cox May 17, 2006

May 17, 2006

The documentation directory in cvs and in the tarball contains no documentation, i got cvs and did a find for '*.sgml'. Nothing to be found. Am i missing something? mark

4 3

Re: widl: Added an option to set importlib search path.
by Alexandre Julliard May 17, 2006

May 17, 2006

Jacek Caban <jacek(a)codeweavers.com> writes: > We can't really do it the way midl does. midl can import files from > system directories and from resource of dlls. In UNIX we don't have such > dirs. We can add support for tlb libs in PE files, but I don't think we > want to do it for Wine's builtin dlls. I thought that we could add an > other, more UNIX like, option that will be a nice workaround. Of course > -I also does the trick although IMO it's better to have -L option. I'll > send a patch that uses include search patch so you can decide which one > to use. Thanks; my idea is that since we don't want to make widl load a tlb from a builtin dll, we'll need to ship the raw tlb, and it would make sense to ship it in the include dir since the lib dir already contains the builtin dll. And when building Wine itself, we'll need the raw tlb in order to build the includes, since we can't build the builtins before the includes, so in both cases we'll want to load the tlb from the include dir. Does that make sense? -- Alexandre Julliard julliard(a)winehq.org

2 1

AW: thanks for wine
by Roland Kaeser May 17, 2006

May 17, 2006

!-- DIV {margin:0px;}-->Hello I tried to copy a formated text object into the clipboard. (Click on the Text Tool and on the page and write some letters. Resize it (make it a little bit bigger) and than CTRL+C, move the original and try to paste the previous copied text back in to Corel.) so its just a test if copy/paste works. I use such actions often to copy some design elements to a other page. > and to which application were you pasting? The is a kind of misunderstanding. I just want to copy/paste from/into the same application instance of Corel Draw 9. And sometimes this works (on some Linux distributions (SuSE/Fedora etc.). But currently I don't have one who the copy/paste works. The most strange about this is that I observed that it works on a SuSE 10 on a office computer but not on a SuSE 10 system at home. Currently I'm updating the systems to SuSE 10.1 and saw on my notebook that it also not works with SuSE 10.1, Xorg 6.9, KDE 3.5.1, Wine 0.9.13. So I can't find a pattern by which I get a idea form which part the bug comes. You might test it on diffrent systems to get a overview what happens. The debug output was created on a system with SuSE 10.0 / xorg 6.8.2 / kde 3.5.1 / wine 0.9.13 and the most recent updates from suse. --- Xorg Packages --- xorg-x11-fonts-75dpi-6.8.2-100 xorg-x11-server-6.8.2-100.2 xorg-x11-devel-6.8.2-100 xorg-x11-libs-6.8.2-100.2 xorg-x11-Xvnc-6.8.2-100 xorg-x11-server-glx-6.8.2-100 xorg-x11-man-6.8.2-100 xorg-x11-Mesa-devel-6.8.2-100 xorg-x11-Mesa-6.8.2-100 xorg-x11-Xnest-6.8.2-100 xorg-x11-fonts-scalable-6.8.2-100 xorg-x11-6.8.2-100.2 ---- Many thanks Roland >----- Ursprüngliche Mail ---- >Von: Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> >An: Roland Kaeser <roli8200(a)yahoo.de> >Gesendet: Dienstag, den 16. Mai 2006, 02:14:07 Uhr >Betreff: Re: thanks for wine >What exactly did you do to generate the log? What did you copy and to which >application were you pasting? Was this two instances of Corel Draw? >I might be able to get my hands on a copy of Corel Draw 9 sometime next >week. If I can I'll see if I can reproduce the bug. >Thanks, >/Ulrich On Fri, May 12, 2006 at 09:12:30PM +0000, Roland Kaeser wrote: > Hello > > I started CorelDraw with the given WINEDEBUG options but there is no chance to get success with this options. It took me more than 2 hours just to start Corel and generated about 1.5GB of log output. Even moving the mouse generated more than 5000 lines of debug output. So I removed the +relay option. And here is the generated debug output which is already a lot of text. (See the attachement). I hope this is enough information to find where there bug exactly comes. Many thanks for the efforts. > > Roland Kaeser > > > >----- Ursprüngliche Mail ---- > >Von: Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> > >An: Roland Kaeser <roli8200(a)yahoo.de> > >CC: wine-devel(a)winehq.org > >Gesendet: Freitag, den 12. Mai 2006, 14:18:00 Uhr > >Betreff: Re: thanks for wine > > >On Fri, May 12, 2006 at 06:20:13AM +0000, Roland Kaeser wrote: > >> >The only major issues that I'm aware of are coping and pasting OLE embedded > >> >objects. That should be taken care of when Rob is finished his COM work. > >> > >> >IMO 633, 2382 and 5061 are not really copy and paste bugs. They are caused > >> >by problems translating from windows data formats to linux data formats and > >> >vice versa. > >> > >> As far as I know, all "complex" objects in the windows clipboard, such as formatted text, images etc. is stored as rtf-object. > >> BTW: There is also a bug #3611 which was marked as dublicate of #633 but its not the exact reason. > >> > >> I recognized that the copy and paste bug #3611 works on some systems. I may have to do with some X11 library/KDE Lib versions. etc. Is there a kind of WINEDEBUG option to track what happens when copy/paste in application? > >> On the other side I saw a lot of applications by which the copy/paste does not work. It seems to be a much bigger issue than assumed. > >> > > >I agree, they are different bugs. I don't have Corel Draw 9 so if you can > >send me a +relay,+clipboard,+tid trace I can take a look. > > >/Ulrich > > > >

2 1

Re: rpcrt4: Store the authentication level and service information in the connection as well, so we don't need to reach inside the binding for these.
by Robert Shearman May 17, 2006

May 17, 2006

Robert Shearman wrote: > --- > > dlls/rpcrt4/rpc_binding.h | 2 ++ > dlls/rpcrt4/rpc_message.c | 11 +++++------ > dlls/rpcrt4/rpc_transport.c | 2 ++ > 3 files changed, 9 insertions(+), 6 deletions(-) Alexandre, please don't apply this patch. It causes some regressions because the binding handle can be NULL. -- Rob Shearman

1 0

Re: advapi32: Stub for FileEncryptionStatus
by Hans Leidekker May 17, 2006

May 17, 2006

Hi Paul, +BOOL WINAPI FileEncryptionStatusW(LPCWSTR lpFileName, LPDWORD lpStatus) +{ + FIXME("%s %p\n", debugstr_w(lpFileName), lpStatus); + return TRUE; If you need to return TRUE here it would be better to set lpStatus to a meaningful value, for example FILE_SYSTEM_NOT_SUPPORT, otherwise the caller could end up using random data. -Hans

1 0

WineGL, take two
by Tomas Carnecky May 17, 2006

May 17, 2006

After submitting the patches last night, I got some feedback on IRC. It seems that adding new exports to gdi32.dll is bad (it apparently tends to break applications, those using safedisc2 seem to be good candidates), so I had to look for another solution. Everything that follows here is under the assumption that we want to move all access to the native opengl library to x11drv. But that's the impression I got from Alexandre in the other mail regarding new escape codes (http://www.winehq.org/pipermail/wine-devel/2006-May/047539.html) If the above assumption is true then opengl32.dll needs access to the low-level driver (eg. x11drv) where all the WGL functions are implemented. And if adding new gdi32.dll exports is not an option then ExtEscape() or some other Escape function is the only way to go. Someone told me that even in Windows Vista opengl uses an escape function to talk to the low-level driver. So my new approach is this: - one new gdi driver function: WineGL_getDispatchTable => returns the dispatch table for the basic WGL functions. - two new ExtEscape() codes: => WINEGL_GET_DISPATCH: returns dispatch table as returned by the new driver function => WINEGL_GET_PRIVATE: returns physDev for the given HDC. - opengl32.dll gets the dispatch table using the new escape code when it is loaded. - in x11drv, opengl.c is replaced by various winegl_??? files. Why is WINEGL_GET_PRIVATE needed? The question really is: where do we want to have the WGL extension entry points? I'd recommend to have them in x11drv, why? If they were in opengl32.dll, we'd have to update the dispatch table whenever we would add a new extension. And because the application calls the functions which are entirely implemented in x11drv and not called through wrappers (which don't really exist in my patchset anyway) and the functions still need access to the physDev structure... well, hence the second escape code. I've removed all opengl related #ifdefs, I'd like to have configure set WINEGLFILES to either 'winegl_noop.c', which implements noop functions when opengl isn't supported, or a list with all the required winegl files when all required headers are present. And there is no need to check for linGL.so, too, (at least not for opengl32 and x11drv) because all functions are loaded using wine_dlsym() or glXGetProcAddress(). What is needed at compilation time are the three opengl header files gl.h, glx.h and glu.h. I'm not a configure expert and this big script scares me. That's why the configure patch is king of a hack, but should work when someone uses --without-opengl. The WGL related code is mostly copied over from opengl32/wgl.c and opengl32/wgl_ext.c, I've formatted it a bit to look nicer and changed what was needed to embed it into x11drv. For example 'get_dispay()' is gone as we now have direct access to the display through 'gdi_display'. The only thing that I've disabled is the WGL_ARB_render_texture extension (nvidia drivers don't support it and there is a good chance that no application relies explicitly on this extension, however, the extension can be enabled by uncommenting one line in x11drv/winegl_extensions.c). I've put all the patches, eleven to be precise, on my server: http://dbservice.com/ftpdir/tom/wine/ up until patch number 10, it should not introduce any regression as it only makes the necessary changes to gdi to support the new GDI driver function (but doesn't use it yet) and adds the winegl files to x11drv. Patch number 10 is a bit large, it changes configure to compile the winegl files, removes x11drv/opengl.c and updates gdi32.DescribePixelFormat and friends to use the functions from the dispatch table. Patch number 11 seems big but it basically only replaces functions with wrapper functions that call the function pointer from the dispatch table. It also removes the now unnecessary wgl_ext.[c|h] functions and updates the Makefile. tom

2 2

Re: user32: Make all the recently added ShowWindow tests pass in Wine
by Vitaliy Margolen May 17, 2006

May 17, 2006

Tuesday, May 16, 2006, 11:39:42 PM, Dmitry Timoshkov wrote: > Hello, > this patch makes all the recently added ShowWindow tests pass in Wine, > and is aimed to fix the bug #4960. > GetWindowRect(hwnd, &rc); > +todo_wine { > ok( rc.right-rc.left == GetSystemMetrics(SM_CXSCREEN) && > rc.bottom-rc.top == GetSystemMetrics(SM_CYSCREEN), > "Invalid maximized size after ShowWindow (%ld,%ld)-(%ld,%ld)\n", > rc.left, rc.top, rc.right, rc.bottom); > +} > DestroyWindow(hwnd); > flush_sequence(); Please don't do this. I fixed this problem and added tests exactly for the reason to keep it from braking again. This change will brake most of Delphi apps that have their main windows as a maximized popup. Vitaliy Margolen

1 0

Programatically minimising window gets incorrect results.
by Troy Rollo May 17, 2006

May 17, 2006

The attached C sample demonstrates two problems with using ShowWindow(hwnd,SW_SHOWMINIMIZED) to minimise a top level window. The tests were done in KDE, but the second problem has been confirmed in Gnome and I suspect the first also occurs there. 1. If you start this program without arguments and click on the resulting window it will correctly minimise, but when restored it will appear with size 32x32 in the lower left hand corner of the screen (that is, as if it were still minimised as an icon). 2. If you start this program with any argument, the window will not appear at all. It should appear minimised. The first problem can be fixed by the attached hack (presumably this is not the correct fix or even anything approximating a correct fix). The second seems hairier and my best guess is that it happens that way because the window manager has not mapped the window yet. -- Troy Rollo - wine(a)troy.rollo.name

2 3

Re: kernel[2/2]: fix path test to pass on 95 and 98
by Alexandre Julliard May 16, 2006

May 16, 2006

Andrew Ziem <ahziem1(a)mailbolt.com> writes: > --- dlls/kernel/tests/path1.c 2006-05-14 23:32:47.000000000 -0600 > +++ dlls/kernel/tests/path.c 2006-05-15 08:08:52.000000000 -0600 > @@ -339,14 +339,22 @@ > newdir,tmpstr,tmpstr1,id); > ok(DeleteFileA(newdir),"Couldn't delete the temporary file we just created\n"); > > - ok((id=GetTempFileNameA(tmppath,NULL,0,newdir)),"GetTempFileNameA failed\n"); > - sprintf(tmpstr,"%.4x.tmp",id & 0xffff); > - sprintf(tmpstr1,"%x.tmp",id & 0xffff); > - ok(lstrcmpiA(newdir+lstrlenA(tmppath),tmpstr)==0 || > - lstrcmpiA(newdir+lstrlenA(tmppath),tmpstr1)==0, > - "GetTempFileNameA returned '%s' which doesn't match '%s' or '%s'. id=%x\n", > - newdir,tmpstr,tmpstr1,id); > - ok(DeleteFileA(newdir),"Couldn't delete the temporary file we just created\n"); > + if (GetVersion() & 0x80000000) { You should never add version checks in tests, simply check for both behaviors. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: user32: Remove Wine specific hacks from PrivateExtractIconsW
by Alexandre Julliard May 16, 2006

May 16, 2006

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > ChangeLog: > Remove Wine specific hack from PrivateExtractIconsW. > > It's not necessary anymore, due to the new fake dlls. I don't think we want to require creation of fake dlls for all builtins that contain icons. Fake dlls should only be created when real apps need them, not for internal Wine purposes. -- Alexandre Julliard julliard(a)winehq.org

1 0