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

safedisc
by Ivan Leo Puoti 04 Jan '06

04 Jan '06

Raphael Junqueira asked on bugzilla what the safedisc status is. Currently it works fine, and I believe what we have is more or less ready for CVS. However Vitaly told me Alexandre didn't like the object manager Vitaly wrote, mostly he didn't like permanent objects, that drivers depend on. I haven't talked to Alexandre about this but hopefully some reasonable solution can be found so we can get Vitaly's OM into wineserver (I mean my original implementation that uses pointers as handles also works, but things look better with a real OM). So let's try and trigger some community discussion, we are talking about the guts of wine after all. Vitaly, what's the OM status currently? Alexandre, what didn't you like about it? Ivan.

4 3

D3DX9 SDK releases, DLL support (CIV4)
by Andrei Barbu 02 Jan '06

02 Jan '06

Hi, I've been playing with getting CIV4 to run on wine. http://appdb.winehq.org/appview.php?versionId=3632&iTestingId=125 I'm left with just one issue. D3DX9_26.DLL is missing. This is a D3D9 SDK release (they put one out every month or so from what I've seen, with a new DLL that has the number incremented). It's mostly like the original with some minor changes. How would I support this in wine? I don't know the wine build system enough to extend it to do this. Is there a nice way to generate these DLLs and to include the d3dx9 dll so I just have to add in/fix missing calls? This may not be an issue now, but as more and more games get released more will depend on these dlls. Thanks, Andrei

5 5

Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)
by L. Lenders 02 Jan '06

02 Jan '06

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

5 6

Re: ADVPACK/tests: exit after 0x8007007e
by James Hawkins 11 Dec '05

11 Dec '05

On 11/17/05, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > I didn't see point in adding HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND) > value into every checks for TranslateInfString(), as all they fails in the > same way later. I guess, this is because of NT3.51 unability to parse > usual INF-files. > > Log message: > Saulius Krasuckas <saulius.krasuckas(a)ieee.org> > Exit test after first TranslateInfString() failure, which seems to > be NT3.51 specific. > I don't think this is correct. I don't have hands on access to this NT3.51 machine, so it's hard to tell, but it sounds like there's a problem creating the file c:\test.inf for whatever reason. I'll send a patch to wine-patches that adds an ok to check that the file was created successfully. -- James Hawkins

3 9

GCC 4.0.1 / WINE bug?
by Evil 10 Dec '05

10 Dec '05

I've been doing some tests with the odd Dreamweaver problem that I originally thought was a regression and discovered the following: 1) If I compile the current CVS on my Mandriva 2005LE machine with gcc v.3.4.3, then install it to my Mandriva 2006 desktop, Dreamweaver works fine. 2) If I compile the current CVS on my Mandriva 2006 desktop with gcc v.4.0.1, then install it to that same machine, Dreamweaver hangs at the splash screen (with the app window in background). Other apps, like Steam and Counter-Strike: Source work fine under this install. This is using the same .wine config directory and everything. I used "make clean" and "wineserver -k" between compiles. When I was originally troubleshooting it as a Dreamweaver problem, I recall checking out a fresh copy of CVS and getting the same hangup symptoms under 4.0.1. So, it appears that this might be caused by either a gcc 4.0.1 bug, or a bug in the WINE source that only becomes evident when compiled under gcc 4.0.1. When I get home from work tonight I can do some traces to try to narrow the scope of investigation. Are there any trace options that would be particularly helpful to you devs? Thanks, Jesse

6 13

Missing WGL function declarations in wingdi.h
by Aric Cyr 06 Dec '05

06 Dec '05

As the subject says, all of the WGL functions that should be declared in wingdi.h are currently only found in dlls/opengl32/wgl.h. I ran across this recently while working on getting wined3d to use wgl instead of glx directly. Currently I work around it by including wgl.h and adding makefile include options to point to dlls/opengl32. It would be much cleaner and correct if I could forgo this and just include wingdi.h. Anyone have problems with me submitting a patch which would move the relevant (i.e. not all) parts of dlls/opengl32/wgl.h into include/wingdi.h? >From MSDN (for wglCreateContext): === Requirements Windows NT/2000: Requires Windows NT 3.5 or later. Windows 95/98: Requires Windows 95 or later. Available as a redistributable for Windows 95. Header: Declared in wingdi.h. Import Library: Use opengl32.lib. === Regards, Aric

3 5

Re: msvcrt incompatibility in Origin 6.0 when saving documents
by Olaf Leidinger 03 Dec '05

03 Dec '05

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

2 2

Steam regression of the day
by Ivan Gyurdiev 02 Dec '05

02 Dec '05

The networking bug has been fixed, but another problem is that I can't see any of the text. Appdb mentions something about installing tahoma.ttf from a Windows installation, which makes no sense to me, since I could see Steam displayed fine earlier, making this a regression. Any suggestions as to what might have caused this (or maybe it was a Steam upgrade?). Also - Steam has a keyboard focus bug, with a documented patch here (from Stefan Dosinger): http://www.winehq.org/hypermail/wine-patches/2005/03/0504.html Previously he reported that the patch might break other apps, but if it fixes Steam, then it must be on the right track - surely it can be changed so it's acceptable for Wine CVS. I don't understand why a known bug with a known patch remains unfixed.

2 4

D3D7 & WineD3D success
by Stefan Dösinger 02 Dec '05

02 Dec '05

Hello! Today I have finally managed to get some useable graphics with D3D7 and WineD3D. The Tomb Raider 3 Demo is running. :) The only visible problem I can see are textures: They only have a solid color, all other things seem to work. I've uploaded a screenshot to http://doesi.gmxhome.de/tomb3-2.png , if anyone wants to have a look. I'll try to fix the textures and get some more games running, then I'll upload a beta patch somewhere for others to try. (Well, if anyone is interested, I can mail the current code too). Greetings, Stefan

6 7

Re: [wined3d] update hw support
by Roderick Colenbrander 01 Dec '05

01 Dec '05

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 +++

4 4