November 2005 - Wine-Devel - list.winehq.org

Re: [wined3d] update hw support

by Roderick Colenbrander

The way I would recommend for pci bus scanning is to parse /proc/bus/pci/devices the only problem is that this is linux specific. Something similar can be done on other OSes though. Another way which is more portable is to use libpci but it isn't installed on all systems. Guess something like this would need to be added to some 'kernel' dll... Roderick > > PS: if one of you know a way to implement pci bus scanning on wine i'll be > happy > -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse f�r Mail, Message, More +++

Nov. 30, 2005

riched20: register ListBox & ComboBox classes

by Cihan Altinay

Hi, > This patch partially implements the undocumented REExtendedRegisterClass() > function by registering the two missing classes. That way MS Office 2003 and > probably other programs that rely on these classes display dialogs > completely which were empty before. > > Changelog: > Cihan Altinay <cihan(a)uq.edu.au> > Partially implement REExtendedRegisterClass() to register missing window > classes so that applications relying on them don't get confused. > It seems this patch was ignored and I would appreciate some comments because I haven't done much wine development yet (and probably made a lot of mistakes). Basically, I did some reverse engineering to see what is going on under Windows and implemented the (de)registration of the two classes accordingly. The effect of the patch can be seen in the attached screenshots which is the Options dialog of MS PowerPoint 2003. I agree that a patch that makes the controls actually work would be better :-) Cheers, Cihan

Nov. 30, 2005

Re: Dereferencing a pointer in winedbg

by Vitaliy Margolen

Monday, November 28, 2005, 2:33:35 PM, Eric Pouech wrote: > Vitaliy Margolen wrote: >> Sunday, November 27, 2005, 10:50:39 PM, Marcus Meissner wrote: >> >>>On Sun, Nov 27, 2005 at 06:35:15PM -0700, Vitaliy Margolen wrote: >>> >>>>Is it possible to dereference a pointer in winedbg? Help says that >>>>"*$eax" is a valid expression. But when I'm trying to use it it saying: >>>>Wine-dbg>p *$eax >>>>No type or type mismatch >>>> >>>>Is there are a way to do this? >>> >>>(x aka examine memory) >>> >>>x $eax >>> >>>Ciao, Marcus >> >> >> Well I need to add that to display. Something like: display/x *$eax >> Doing x $eax and then x <result> 100s times kind of hard. > display /x means (in gdb) formatting differently the output, not > dereferencing the (so called) pointer (display is a repeated 'p' > command, not a 'x' one). Yes I know. I meant /x for hex not decimal. > what you'd need is support for type casts and use something like: > display *(int*)$eax Yes correct. That's exactly what I need. > I sent a couple of months ago a patch for winedbg that (partly) > implemented the support for typecasts in wine. You should look for it. Could you please point me to it? I've spent last hour or so trying to find it. Vitaliy.

Nov. 30, 2005

Re: Question about X11DRV_ChoosePixelFormatglXChooseFBConfig returns NULL (glError: 0)

by Aric Cyr

Raphael <fenix <at> club-internet.fr> writes: > > On Tuesday 29 November 2005 22:46, L. Lenders wrote: > > Just for the info: after some digging i found a quick > > hack to get rid of the error: comment line 208 in > > dlls/x11drv/opengl.c: > > > > //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, > > GLX_STEREO); > > No, it's not the good way. > Try my last patch on bug report I think there is still a problem with your patch Raphael. I update the bug report with my observations, but basically it is as follows. glXChooseVisual and glXChooseFBConfig differ in the way they set up attribute lists. glXChooseFBConfig _requires_ all attributes to be followed by a value, even booleans. This implies that TEST_AND_ADD1 should _never_ be used for glXChooseFBConfig and friends. The only place it is being used currently is for GLX_STEREO, which seems to be causing the problems with Doom3. Changing the TEST_AND_ADD1 to a TEST_AND_ADD2 should be enough to correct your patch. Other than that your patch is definitely an improvement. Regards, Aric

Nov. 30, 2005

RE: Problem with serial port.

by gslink

Did you check out that flow control is handled correctly from the Olivetti printer. I have had this happen in the past and in every case I found that either I was using the wrong flow control or not taking it into account.

Nov. 30, 2005

Re: Implement symbolic link object in wineserver.

by Vitaliy Margolen

Tuesday, November 29, 2005, 4:47:47 PM, Robert Shearman wrote: > Hi Vitaliy, > This patch looks pretty good, but needs some finishing touches. Are you > planning to continue the directory work to get objects to start > supporting it? Yes I do. It should be a straight forward for events, sections, mutants, semaphores and timers. But named pipes, mail slots and winstations with desktops will have to wait a bit. I'm not sure yet how to properly separate name spaces (you should not be able to create an event in the named pipe name space. And wise-versa). > Vitaliy Margolen wrote: >>+struct syboliclink *create_syboliclink( struct directory *root, const struct unicode_str *name, >>+ unsigned int attr, const struct unicode_str *target ) >> >> > Spelling mistake again. Also, should match whatever name is decided for > the name of the object. Damn. How in the world did gcc compiled this then? With so many errors?! I don't know why didn't I see this before. Of course I will change it to "symlink". >>+ >>+/* Global initialization */ >>+void init_syboliclinks(void) >>+{ >>+} >>+ >>+void close_syboliclinks(void) >>+{ >>+} >> >> > It would probably be nicer to have all of the namespace initialisation > done in one place, e.g. directory.c > That would mean exporting the create_symlink function, but then > init_symboliclinks and close_symboliclinks would no longer have to be > exported. Yup are you right. Done. >>+ if (req->rootdir && !(root = get_directory_obj( >>current->process, req->rootdir, 0 ))) >>+ return; >> >> > Does NT really allow you to open a directory without having any specific > access rights? Yup. In the tests I'm opening directory with "directory query" rights only. And it works when I'm using it as the RootDirectory. Even when creating new objects in it. Vitaliy

Nov. 30, 2005

Re: Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)

by Raphael

On Tuesday 29 November 2005 22:46, L. Lenders wrote: > Just for the info: after some digging i found a quick > hack to get rid of the error: comment line 208 in > dlls/x11drv/opengl.c: > > //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, > GLX_STEREO); No, it's not the good way. Try my last patch on bug report Regards, Raphael

Nov. 30, 2005

Re: Implement symbolic link object in wineserver.

by Robert Shearman

Hi Vitaliy, This patch looks pretty good, but needs some finishing touches. Are you planning to continue the directory work to get objects to start supporting it? Vitaliy Margolen wrote: >diff --git a/server/object.h b/server/object.h >index 0c2ee1a..1154e0a 100644 >--- a/server/object.h >+++ b/server/object.h >@@ -193,6 +193,11 @@ extern obj_handle_t open_object_dir( str > extern void init_directories(void); > extern void close_directories(void); > >+/* sybmolic link functions */ >+ >+extern void init_syboliclinks(void); >+extern void close_syboliclinks(void); > > Multiple spelling mistakes. >+ > /* global variables */ > > /* command-line options */ > > >diff --git a/server/symlink.c b/server/symlink.c >new file mode 100644 >index 0000000..5a07df3 >--- /dev/null >+++ b/server/symlink.c >@@ -0,0 +1,225 @@ >+/* >+ * Server-side symbolic link object management >+ * >+ * Copyright (C) 2005 Vitaliy Margolen >+ * >+ * This library is free software; you can redistribute it and/or >+ * modify it under the terms of the GNU Lesser General Public >+ * License as published by the Free Software Foundation; either >+ * version 2.1 of the License, or (at your option) any later version. >+ * >+ * This library is distributed in the hope that it will be useful, >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >+ * Lesser General Public License for more details. >+ * >+ * You should have received a copy of the GNU Lesser General Public >+ * License along with this library; if not, write to the Free Software >+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >+ * >+ */ >+ >+#include "config.h" >+#include "wine/port.h" >+ >+#include <assert.h> >+#include <stdarg.h> >+#include <stdlib.h> >+#include <stdio.h> >+#include <sys/types.h> >+ >+#include "ntstatus.h" >+#define WIN32_NO_STATUS >+#include "winternl.h" >+#include "ddk/wdm.h" >+ >+#include "handle.h" >+#include "request.h" >+#include "object.h" >+#include "unicode.h" >+ >+struct syboliclink >+{ >+ struct object obj; /* object header */ >+ struct unicode_str target; /* target of the symlink */ >+}; > > Spelling mistake. In the server the name of the object struct typically mirrors the name of the file. So in this case it would be "struct symlink" >+ >+static void syboliclink_dump( struct object *obj, int verbose ); >+static struct object *symlink_lookup_name( struct object *obj, struct unicode_str *name, >+ unsigned int attr ); >+static void syboliclink_destroy( struct object *obj ); > > Spelling mistakes and lack of consistency with the naming. They should have the name of the object as a prefix: symlink_dump, symlink_lookup_name, symlink_destroy. >+struct syboliclink *create_syboliclink( struct directory *root, const struct unicode_str *name, >+ unsigned int attr, const struct unicode_str *target ) > > Spelling mistake again. Also, should match whatever name is decided for the name of the object. >+ >+/* Global initialization */ >+ >+static struct syboliclink *link_dosdev, *link_global1, *link_global2, *link_local; >+ >+void init_syboliclinks(void) >+{ >+ static const WCHAR dir_globalW[] = {'\\','?','?'}; >+ static const WCHAR dir_basenamedW[] = {'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s'}; >+ static const struct unicode_str dir_global_str = {dir_globalW, sizeof(dir_globalW)}; >+ static const struct unicode_str dir_basenamed_str = {dir_basenamedW, sizeof(dir_basenamedW)}; >+ >+ static const WCHAR link_dosdevW[] = {'\\','D','o','s','D','e','v','i','c','e','s'}; >+ static const WCHAR link_global1W[] = {'\\','?','?','\\','G','l','o','b','a','l'}; >+ static const WCHAR link_global2W[] = {'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s','\\','G','l','o','b','a','l'}; >+ static const WCHAR link_localW[] = {'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s','\\','L','o','c','a','l'}; >+ static const struct unicode_str link_dosdev_str = {link_dosdevW, sizeof(link_dosdevW)}; >+ static const struct unicode_str link_global1_str = {link_global1W, sizeof(link_global1W)}; >+ static const struct unicode_str link_global2_str = {link_global2W, sizeof(link_global2W)}; >+ static const struct unicode_str link_local_str = {link_localW, sizeof(link_localW)}; >+ >+ link_dosdev = create_syboliclink( NULL, &link_dosdev_str, 0, &dir_global_str ); >+ link_global1 = create_syboliclink( NULL, &link_global1_str, 0, &dir_global_str ); >+ link_global2 = create_syboliclink( NULL, &link_global2_str, 0, &dir_basenamed_str ); >+ link_local = create_syboliclink( NULL, &link_local_str, 0, &dir_basenamed_str ); >+} >+ >+void close_syboliclinks(void) >+{ >+ release_object( link_dosdev ); >+ release_object( link_global1 ); >+ release_object( link_global2 ); >+ release_object( link_local ); >+} > > It would probably be nicer to have all of the namespace initialisation done in one place, e.g. directory.c That would mean exporting the create_symlink function, but then init_symboliclinks and close_symboliclinks would no longer have to be exported. >+ >+ >+/* create a symbolic link object */ >+DECL_HANDLER(create_symlink) >+{ >+ struct syboliclink *symlink; >+ struct unicode_str name, target; >+ struct directory *root = NULL; >+ >+ get_req_unicode_str( &name ); >+ target.str = name.str + req->symlink_name_len / sizeof(WCHAR); >+ target.len = name.len - req->symlink_name_len; >+ name.len = req->symlink_name_len; >+ >+ if (req->rootdir && !(root = get_directory_obj( current->process, req->rootdir, 0 ))) >+ return; > > Does NT really allow you to open a directory without having any specific access rights? -- Rob Shearman

Nov. 29, 2005

Re: msvcrt incompatibility in Origin 6.0 when saving documents

by Olaf Leidinger

Hello again! Running Origin6.0 with WINEDEBUG="+snoop,+relay" with and without native msvcrt, tailing, cutting and wc-ing and finally diffing the output I found the following: First of all using the native version I get some msvcrt._EH_prolog calls I can't find in the builtin version. all window-procs have such calls: native: ret kernel32.94() retval=00000009 ret=7f6c5a5c call window proc 0x6c231b81 (hwnd=0x1003a,msg=wm_settext,wp=00000000,lp=7fadedd4) call msvcrt._eh_prolog(7f6cf147,0001003a,0000000c,00000000,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db10190 ret=6c231b8b call msvcrt._eh_prolog(6c231b9c,6c23b419,6c231b81,6c231b81,7fadf8ec,6c2c2cfe,ffffffff0009 ret ntdll.rtlentercriticalsection() retval=00000000 ret=7e6563d2 call ntdll.rtlleavecriticalsection(7e69a888) ret=7e656412 ret ntdll.rtlleavecriticalsection() retval=00000000 ret=7e656412 \\mnt\\privat\\origin6\\untitled",7f6ee620,0001003a,0000000c, ...) ret=6c2310b5 ret msvcrt._eh_prolog() retval=7db10190 ret=6c2310b5 call kernel32.tlsgetvalue(00000003) ret=6c231018 ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018 call msvcrt._eh_prolog(6c23138a,00000000,6c231be9,0001003a,7fadeba8,6c231bba,0001003a,0000000c,00000000,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db10190 ret=6c23112a call kernel32.tlsgetvalue(00000003) ret=6c231018 ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018 call kernel32.tlsgetvalue(00000003) ret=6c231018 ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018 call msvcrt._eh_prolog(6c231bfb,7d9366c0,0001003a,0000000c,00000000,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db10190 ret=6c231c09 call kernel32.tlsgetvalue(00000003) ret=6c231018 builtin: call window proc 0x6c231b81 (hwnd=0x1003a,msg=wm_settext,wp=00000000,lp=7fadedd4) call kernel32.tlsgetvalue(00000003) ret=6c231018 This is another example not concerting window procs: native: call kernel32.lstrlena(7fadecc0 "microcal origin") ret=6c2338d7 ret kernel32.lstrlena() retval=0000000f ret=6c2338d7 call msvcrt._eh_prolog(6c2319c6,0000000f,7fadedd0,7fd299fc,6c23393c,0000000f,0000000f,7fadedd0,6c2338f9,0000000f,7fadecc0 "microcal origin",7fadedd0,6c2338e0,0000000f,7fadecc0 "microcal origin",0000000f, ...) ret=6c231aeb ret msvcrt._eh_prolog() retval=7db101a9 ret=6c231aeb call ntdll.rtlentercriticalsection(6c300088) ret=6c231b03 same as builtin: call kernel32.lstrlena(7fadecc0 "microcal origin") ret=6c2338d7 ret kernel32.lstrlena() retval=0000000f ret=6c2338d7 call ntdll.rtlentercriticalsection(6c300088) ret=6c231b03 >From mfc there is also such a call: native: call mfc42.6374(0000000c,00000000,7fadedd4 "microcal origin - i call mfc42.5163(0000000c,00000000,7fadedd4 "microcal origin - i call msvcrt._eh_prolog(7db101db,0000000c,00000000,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db101f4 ret=6c231d16 call ntdll.rtlentercriticalsection(6c300220) ret=6c23178e builtin: call mfc42.6374(0000000c,00000000,7fadedd4 "microcal origin - i call mfc42.5163(0000000c,00000000,7fadedd4 "microcal origin - i call ntdll.rtlentercriticalsection(6c300220) ret=6c23178e Then there is also a difference when calling ftime(): native: (line 16240) call msvcrt.memcpy(7d945558 "untitled",7fe5e27a "untitled",00000008) ret=6c233905 ret msvcrt.memcpy() retval=7d945558 ret=6c233905 ret mfc42.860() retval=7d943dc0 ret=7f81a080 call outl60.labutil_str2date(00000000,00000003,00000000) ret=7f81a0fe call msvcrt._ftime() ret=7f74100d call kernel32.getsystemtimeasfiletime(7fadedf0) ret=78026aad call ntdll.ntquerysystemtime(7fadec80) ret=7fd08e30 ret kernel32.getsystemtimeasfiletime() retval=01c5f531 ret=78026aad ret msvcrt._ftime() retval=438cd1d8 ret=7f74100d call msvcrt.localtime() ret=7f74103e call kernel32.getlasterror() ret=78002699 ret kernel32.getlasterror() retval=00000000 ret=78002699 call kernel32.tlsgetvalue(00000002) ret=780026a7 ret kernel32.tlsgetvalue() retval=7d930088 ret=780026a7 call kernel32.setlasterror(00000000) ret=780026b8 ret kernel32.setlasterror() retval=00000000 ret=780026b8 ret msvcrt.localtime() retval=7d9306f8 ret=7f74103e builtin: (line 16632) call msvcrt.memcpy(7fe7dff8,7fe637e2,00000008) ret=6c233905 ret msvcrt.memcpy() retval=7fe7dff8 ret=6c233905 ret mfc42.860() retval=7fe7aac0 ret=7f81a080 call outl60.labutil_str2date(00000000,00000003,00000000) ret=7f81a0fe call msvcrt._ftime(7f75b778) ret=7f74100d call kernel32.gettimezoneinformation(7fadec9c) ret=7e886be4 call ntdll.rtlquerytimezoneinformation(7fadec9c) ret=7fd09bce ret ntdll.rtlquerytimezoneinformation() retval=00000000 ret=7fd09bce call ntdll.ntquerysystemtime(7fadebc0) ret=7fd08e30 ret kernel32.gettimezoneinformation() retval=00000000 ret=7e886be4 call kernel32.getsystemtimeasfiletime(7faded48) ret=7e886bf3 call ntdll.ntquerysystemtime(7fadebe0) ret=7fd08e30 ret ntdll.ntquerysystemtime() retval=00000000 ret=7fd08e30 ret kernel32.getsystemtimeasfiletime() retval=01c5f530 ret=7e886bf3 ret msvcrt._ftime() retval=00000000 ret=7f74100d call msvcrt.localtime(7f75b748) ret=7f74103e call kernel32.filetimetolocalfiletime(7faded48,7faded40) ret=7e886e9a call ntdll.rtlsystemtimetolocaltime(7fadeba4,7fadebac) ret=7fd09f03 ret ntdll.rtlsystemtimetolocaltime() retval=00000000 ret=7fd09f03 ret kernel32.filetimetolocalfiletime() retval=00000001 ret=7e886e9a call kernel32.filetimetosystemtime(7faded40,7faded30) ret=7e886ea4 call ntdll.rtltimetotimefields(7fadebb0,7fadeba0) ret=7fd09572 ret ntdll.rtltimetotimefields() retval=0000016f ret=7fd09572 ret kernel32.filetimetosystemtime() retval=00000001 ret=7e886ea4 call kernel32.gettimezoneinformation(7fadec84) ret=7e886fd1 call ntdll.rtlquerytimezoneinformation(7fadec84) ret=7fd09bce ret ntdll.rtlquerytimezoneinformation() retval=00000000 ret=7fd09bce call ntdll.ntquerysystemtime(7fadeb98) ret=7fd08e30 ret ntdll.ntquerysystemtime() retval=00000000 ret=7fd08e30 ret kernel32.gettimezoneinformation() retval=00000000 ret=7e886fd1 ret msvcrt.localtime() retval=7e8ae660 ret=7f74103e And the native msvcrt seems to use an internal _ftol native: call msvcrt._cipow() ret=7f82aaf9 ret msvcrt._cipow() retval=40f00020 ret=7f82aaf9 call msvcrt._ftol() ret=7f82a67a ret msvcrt._ftol() retval=00000001 ret=7f82a67a builtin: call msvcrt._cipow() ret=7f82aaf9 ret msvcrt._cipow() retval=00000001 ret=7f82aaf9 call ntdll._ftol() ret=7f82a67a ret ntdll._ftol() retval=0000000000000001 ret=7f82a67a By the way... what is the difference between "retval" and "ret"? It sounds the same. There are still some megs in front of me... Perhaps you could comment my discoveries so far. Personally I think they aren't very important, but I really don't know much about the win32 api, so I can't tell... Ciao, Olaf Leidinger

Nov. 29, 2005

Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)

by L. Lenders

Just for the info: after some digging i found a quick hack to get rid of the error: comment line 208 in dlls/x11drv/opengl.c: //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, GLX_STEREO); Somehow setting the PFD_STEREO flag makes doom3 crash and triggers the error mentioned in the subject. After commenting line 208 doom3 starts up just fine. Digging further..... :) (any help appreciated) Louis ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Nov. 29, 2005