wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Tracking bug for serious Wine bugs running "must-have" K12 apps
by Dan Kegel 12 Oct '05

12 Oct '05

I've created metabug http://bugs.winehq.org/show_bug.cgi?id=3554 to track problems in Wine that make K12 classroom applications unusable or untestable. So far I only have two bugs listed there, but I have only looked at one of the apps in the list ( http://kegel.com/wine/qa/#app.k12 ) from the K12OSN folks. My hope is that this becomes a list of the highest impact bugs in K-12 bugs, those that are worth fixing for, say, wine-0.9.2. Less serious bugs can wait for future releases, and don't yet need a tracking bug. Coments, anyone?

1 0

How to install mozilla active in wine
by Vijay Kiran Kamuju 12 Oct '05

12 Oct '05

Hi, I would like to install mozilla active in wine, i have downloaded the xpi file. and what should i do make the wine recognize this activex. Thanks, Vijay

5 8

Test If Running Under Wine
by Craig macLeod 12 Oct '05

12 Oct '05

I am a developer of Win32 applications. We have recently found the command ShellExecute when trying to browse folders functions differently between Wine and Windows. This is mainly because there is no implementation of Windows Explorer unider Wine so the command does nothing. How in our code do we differentiate between Wine runs and Windows runs? The documentation discourages such tests saying we should fix Wine. My boss wants to do minimal changes to our code so how do we do a simple test if we are using Wine or not? I have some code to test for the existance of explore.exe and if not present then assume we are under Linux. Is this sufficiently generic? (foreign languages etc)

6 6

Re: COMCTL32: fix separators in check groups in toolbars
by James Hawkins 12 Oct '05

12 Oct '05

On 10/11/05, Krzysztof Foltman <wdev(a)foltman.com> wrote: > ChangeLog: > * Separators with group style set don't separate toolbar radio groups > anymore (which broke tool selection in Front Panel Designer) > > A test case coming soon... > I'm not saying this shouldn't be committed, but it might have a better chance if the test case comes first. -- James Hawkins

1 1

Re: [comctl32] Fix SEGV in file dialogs (bug 3366)
by Alexandre Julliard 11 Oct '05

11 Oct '05

Troy Rollo <wine(a)troy.rollo.name> writes: > The following change seems to prevent the SEGV that frequently occurs when you > double-click on a folder in the file open/save dialogs. This fix uses > IsWindow() to test if the ListView still exists. I have handled all > notifications other than those where it seems entirely implausible that the > callback could destroy the window. I think it would be a lot cleaner to put the IsWindow test in the notify functions and make them return FALSE (or some appropriate code) when the window is destroyed. Then all you have to do in the callers is check the result instead of duplicating the IsWindow calls all over the place. -- Alexandre Julliard julliard(a)winehq.org

2 1

Release plans
by Alexandre Julliard 11 Oct '05

11 Oct '05

Folks, I just released 20050930, this should be considered the pre-0.9 release, so please give it some good testing. In particular, please test the things that new users will encounter first, like the automatic .wine creation and winecfg. Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong. Bugzilla has had a good cleanup lately (thanks guys!) and most of the irrelevant bugs have been closed, so please have a look at the remaining ones to see if there's anything you know how to fix. We also still need many documentation updates, so please consider helping with that. If you have scripts that handle releases, now is the time to ensure they can cope with a version number not in the YYYYMMDD format... If all goes well, and if the documentation is updated by then, the real 0.9 should be released in a couple of weeks. In the meantime we should consider ourselves in a code freeze, so please don't submit new features or large changes, only small bug fixes will be allowed in. Thanks everybody for your help, it has been a long trip but we are getting there... -- Alexandre Julliard julliard(a)winehq.org

15 27

Re: [TRY3] printer dialog fixes part1 + french
by Detlef Riekenberg 11 Oct '05

11 Oct '05

Am Dienstag, den 11.10.2005, 10:36 +0200 schrieb Jonathan Ernst: -- cut -- + + EnumPrintersA(PRINTER_ENUM_LOCAL, NULL, 2, NULL, 0, &needed, &num); + if(num == 0) + { + -- cut -- Sorry that didn't work. You receive in "num" the Number of returned PRINTER_INFO_2 Entries in "buffer" Since "buffer" is NULL, "num" is always 0. Working Example from my Patch: ( http://www.winehq.org/pipermail/wine-patches/2005-October/021268.html ) + /* Verify, that we have a Printer installed */ + /* this will fail in wine, when you deleted your printer */ + + numentries = 0; + size = 0; + result = pEnumPrintersA(PRINTER_ENUM_LOCAL, + NULL, 2, NULL, 0, &size, &numentries); + + if (size == 0) + { + result = pEnumPrintersA(PRINTER_ENUM_CONNECTIONS, + NULL, 2, NULL, 0, &size, &numentries); + } + -- cut -- size == 0: no Printer installed size > 0: one or more Printers installed -- By By ... ... Detlef

1 0

[TRY2] printer dialog fixes part1 + french
by Vijay Kiran Kamuju 11 Oct '05

11 Oct '05

Hi jernst, Please change the return types of the CheckPrinterSetup function to TRUE/FALSE You made changes similar to me, thanks ;) Thanks, Vijay

1 0

wine-faq mailing list
by Dimi Paun 11 Oct '05

11 Oct '05

It's time to put it out of its misery. There's basically no traffic on that list, and the 1 question/quarter I get there is not appropriate for that forum. Can we please kill it? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

5 5

Re: Listview: refcount the infoPtr (Dropped patch)
by Troy Rollo 11 Oct '05

11 Oct '05

On Tue, 27 Sep 2005 08:00, Dimi Paun wrote: > Do we need to do this for other controls too? > > ChangeLog > Add refcounting to the listview to support destroying of > the control from within notification messages. <http://www.winehq.org/pipermail/wine-patches/2005-September/021003.html> This patch does not appear to have gone in, but it fixes a SEGV that occurs quite frequently when you double-click on a folder in the file open dialog. Is there a (good) reason it hasn't gone in?

1 0

Re: [ddraw] Fix bug 3487 take 2
by Christian Costa 11 Oct '05

11 Oct '05

Peter Berg Larsen wrote: > > Walking backwards the bug was introduced in > > http://www.winehq.org/pipermail/wine-patches/2002-November/004161.html > > and altered in > > http://www.winehq.org/pipermail/wine-patches/2004-March/010091.html > > which states > >> Apps should initialize correctly the dwSize member of ddraw structures. >> However some of them do not do this and Windows seems to handle that >> case without crashing. >> Here is a patch that prevents clearing more that the struct size. >> This fixes the bug 2070. > > > So here is better patch that does not open 2070 again. > > > Changelog: > Bug in copying structs if to == from as to was memset first. > > diff -u Wine-20050930/dlls/ddraw/ddraw_private.h > Wine-20050930my/dlls/ddraw/ddraw_private.h > --- Wine-20050930/dlls/ddraw/ddraw_private.h 2005-07-24 > 18:17:29.000000000 +0200 > +++ Wine-20050930my/dlls/ddraw/ddraw_private.h 2005-10-09 > 04:50:59.000000000 +0200 > @@ -41,18 +41,22 @@ > (x)->dwSize = sizeof(*x); \ > } while (0) > > +/* __tosize can be set too large by some programs */ > #define DD_STRUCT_COPY_BYSIZE(to,from) \ > do { \ > - DWORD __size = (to)->dwSize; \ > - DWORD __copysize = __size; \ > - DWORD __resetsize = __size; \ > - if (__resetsize > sizeof(*to)) \ > - __resetsize = sizeof(*to); \ > - memset(to,0,__resetsize); \ > - if ((from)->dwSize < __size) \ > - __copysize = (from)->dwSize; \ > - memcpy(to,from,__copysize); \ > - (to)->dwSize = __size;/*restore size*/ \ > + DWORD __tosize = (to)->dwSize; \ > + DWORD __fromsize = (from)->dwSize; \ > + if ((to) == (from)) \ > + break; \ > + if (__tosize > sizeof(*(to))) \ > + ERR("To struct's size too large"); \ > + if (__fromsize > sizeof(*(from))) \ > + ERR("From struct's size too large");\ > + if (__fromsize > __tosize) \ > + ERR("Copying too large struct"); \ > + memcpy(to,from,__fromsize); \ > + memset(to+__fromsize,0,sizeof(*(to))-__fromsize); \ > + (to)->dwSize = __tosize;/*restore size*/\ > } while (0) > > #define MAKE_FOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << > 24)) > > > > This does not work if the destination size is smaller than the struct size or source size is greater than destination size. Even worst, if source size is greater than struct size, sizeof(*(to))-__fromsize is < 0. Why don't you just add the "if (to = from) break;" statement ? Christian

3 5

Re: WINE Regression due to patch applied Feb 22, 2005 10:50 CDT
by Krzysztof Foltman 10 Oct '05

10 Oct '05

> The patch that changed these files is: > ChangeSet ID: 16245 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/02/22 09:50:14 That patch isn't directly responsible for the bug, it has probably just revealed it. The bugfix will be sent as soon as the previous bugfixes are accepted. It looks more or less like this: Index: editor.c =================================================================== RCS file: /home/wine/wine/dlls/riched20/editor.c,v retrieving revision 1.59 diff -u -r1.59 editor.c --- editor.c 3 Oct 2005 18:45:39 -0000 1.59 +++ editor.c 9 Oct 2005 15:00:34 -0000 @@ -2062,10 +2075,10 @@ if (item->member.run.nFlags & MERF_ENDPARA) { - *buffer++ = '\r'; + *buffer = '\r'; if (bCRLF) { - *buffer = '\n'; + *(++buffer) = '\n'; nWritten++; } assert(nLen == 1); Check it out, it works for me. Krzysztof

3 4

Re: winecfg: Set autodetect windows version to what it realy is - win2k
by Alexandre Julliard 10 Oct '05

10 Oct '05

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > changelog: > winecfg: > Set autodetect windows version to what it really is - win2k The autodetect option should really be removed. -- Alexandre Julliard julliard(a)winehq.org

2 1

COMCTL32 - TreeView control not correctly updated with COMCTL32.OCX (was: Re: comctl32.dll: Running siap and modules under wine, first steps)
by Alex Villacís Lasso 10 Oct '05

10 Oct '05

This SIAP application is revealing more problems with Wine. This time it is the reason for the original complaint: Mr. Maximiliano Curia reported that in the version of Wine he could test, the treeview control in the middle of the screen was not updated correctly. The treeview control should have looked like this: +---------------------------------+ |Persona Física | | | | | +- Datos identificatorios | | | | | | | +- Nombre y otros datos | | | +- Domicilio | | | +- Actividades | | +- Datos comerciales | | | | | | | +- Datos de interés fiscal| | | +- Claves bancarias | | +- Responsable por deuda ajena | +---------------------------------+ Don't mind the actual meaning of the text in the nodes. The problem is that for Mr. Curia, the treeview control actually shows up like this: +---------------------------------+ |Persona Física | | | | | | | | | | | | | | | | | | | | | | | +---------------------------------+ That is, the treeview control only shows the first line of the tree. After some digging in the treeview control, I saw that the code in the control tries to save some drawing by querying the update region of the control window. When the WM_PAINT message indicates a non-null HDC in wParam, the code fetches the update region for the control window. If I understand the intent of the code correctly, the WM_PAINT message can be sent to the control with an wParam of the HDC of an offscreen bitmap, in order to draw the tree into it. When the update region of the control is NULL, the code fetches the BITMAP structure of the target HDC in order to clip the drawing to the dimensions of the target bitmap. The problem is that, in the case of the treeview managed by COMCTL32.OCX, for some as yet undiscovered reason, the control *always* has a null update region, except for the very first rendering (which is overwritten by a second rendering with the problematic null region). No matter how the window is uncovered, the update region remains null. Therefore, the control believes that the target is an offscreen bitmap, even for the rendering to the screen. It then fetches the default bitmap selected, which is an 1x1 dummy bitmap, gets a 1x1 target region, and believes that only 1 pixel should be updated. Only the very first item gets redrawn because of this. The following patch works around this issue. However, this is not a proper fix, because the control window should have been properly invalidated in the first place, and the control should therefore have a proper update region. I am not really sure whether the root cause is in the treeview code or in the region updating code. I am inclined to the former, because the same treeview control seems to work correctly in regedit.exe: --- wine-20050930-cvs/dlls/comctl32/treeview.c 2005-09-12 17:34:07.000000000 -0500 +++ wine-20050930-cvs-patch/dlls/comctl32/treeview.c 2005-10-02 22:08:08.000000000 -0500 @@ -2790,6 +2790,8 @@ RECT rect = *rc; TREEVIEW_ITEM *wineItem; + TRACE("refreshing on (%ld,%ld)-(%ld,%ld)\n", rect.left, rect.top, rect.right, rect.bottom); + if (infoPtr->clientHeight == 0 || infoPtr->clientWidth == 0) { TRACE("empty window\n"); @@ -2859,6 +2861,12 @@ rc.left = 0; rc.top = 0; rc.right = bitmap.bmWidth; rc.bottom = bitmap.bmHeight; + if (bitmap.bmWidth == 1 && + bitmap.bmHeight == 1 && + bitmap.bmWidthBytes == 2) { + ERR("failed to recover a valid update region, using GetClientRect()\n"); + GetClientRect(infoPtr->hwnd, &rc); + } TREEVIEW_EraseBackground(infoPtr, (HDC)wParam); } } The sample (VisualBasic) code and executable have been uploaded as testcases for the following bug report: http://bugs.winehq.org/show_bug.cgi?id=3476 BTW: what happened to the patch that fixes the DBGRID32.OCX control? (Subject: OLEAUT32: add additional condition for creation of interface) On an (hopefully) unrelated note, the user32 tests are failing, at least on my machine: ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so sysparams.c && touch sysparams.ok sysparams.c:1182: Test failed: lfHeight: got -16 instead of 0 sysparams.c:1183: Test failed: lfWidth: got 0 instead of 400 sysparams.c:1185: Test failed: lfWeight: got 400 instead of 7471169 sysparams.c:1186: Test failed: lfItalic: got 0 instead of 105 sysparams.c:1187: Test failed: lfStrikeOut: got 0 instead of 97 sysparams.c:1190: Test failed: lfOutPrecision: got 0 instead of 108 sysparams.c:1193: Test failed: lfQuality: got 0 instead of 32 make: *** [sysparams.ok] Error 7 ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so win.c && touch win.ok fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE win.c:2213: Test failed: message 0200 available win.c:2221: Test failed: message 000f available win.c:2229: Test failed: message 000f available win.c:2240: Test failed: message 000f available win.c:2248: Test failed: message 000f available win.c:2256: Test failed: message 000f available win.c:693: Test failed: window rect does not match: style:exstyle=0x94000000:0x00000000, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x94000000:0x00000000, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x15c00000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x15c00000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c00000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c80000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c80000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c40000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c40000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c20000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c20000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c10000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c10000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14d00000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14d00000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14e00000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14e00000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x94000000:0x00000200, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x94000000:0x00000200, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c40000:0x00000300, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c40000:0x00000300, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x94000000:0x00000080, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x94000000:0x00000080, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c40000:0x00000180, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c40000:0x00000180, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x94000000:0x00000000, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x94000000:0x00000000, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c40000:0x00000100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c40000:0x00000100, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x94000000:0x00040000, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x94000000:0x00040000, menu=1 win.c:693: Test failed: window rect does not match: style:exstyle=0x14c40000:0x00040100, menu=1 win.c:718: Test failed: synthetic rect does not match: style:exstyle=0x14c40000:0x00040100, menu=1 make: *** [win.ok] Error 42 make: Debido a los errores, el objetivo `test' no se reconstruyó.

1 1

Too dumb to 'make' documentation
by Molle Bestefich 10 Oct '05

10 Oct '05

Hi ho. I get this error when doing 'make' in wine docs under 'en': =================================== docbook2txt winedev-guide.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.12/docbook-utils.dsl#html Working on: /root/wine-docs/en/winedev-guide.sgml Unknown option -force_html make: *** [winedev-guide.txt] Error 9 =================================== Eep. Anyone got a solution?

2 3

MS Office 95/97 needs native odbccp32.dll
by Michael Kaufmann 10 Oct '05

10 Oct '05

Hi, The MS Office 95/97 setup program fails when using the built-in odbccp32.dll. A native version of this dll is on the installation media. Since 2005-07-08, Wine doesn't use this file because of this patch: http://cvs.winehq.org/patch.py?id=18748 I think that we have three options: - Change Wine's default configuration and make it use the native odbccp32.dll - Add a remark in the application DB to Office 95/97, Access 95/97, Excel 95/97 (also Word 95/97, Powerpoint 95/97?) that users should use winecfg to change "odbccp32" to "native, builtin" - Implement the needed functions in odbccp32.dll See also bug 3268: http://bugs.winehq.org/show_bug.cgi?id=3268 PS: odbccp32.dll is missing on Wine's status page. Regards Michael

2 2

Re: fix bug 3536
by Kai Blin 10 Oct '05

10 Oct '05

* Vijay Kiran Kamuju <infyquest(a)gmail.com> [10/10/05, 14:48:48]: > 342a343,344 > > {"PHT", > > {'P','h','i','l','i','p','p','i','n','e',' ','T','i','m','e','\0'}, -480, 0}, Please stick to the diff -u format. It doesn't matter much for a patch of this size, but larger patches are much more readable. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Men of peace usually are [brave]. -- Spock, "The Savage Curtain", stardate 5906.5

2 1

Re: [ddraw] Fix bug 3487 take 2
by Lionel Ulmer 10 Oct '05

10 Oct '05

> So here is better patch that does not open 2070 again. > > Changelog: > Bug in copying structs if to == from as to was memset first. Well, while your patch was lying in the moderation queue, I sent what I feel is a better solution to this problem (which fixes also a severe reference counting issue). Could you try it and tell if it fixes the problem ? Lionel PS: and Raphael's patch while not fixing your bug is not technically wrong as Windows checks for the surface description pointer being non-NULL :-) -- Lionel Ulmer - http://www.bbrox.org/

2 1

Fwd: printer dialog fix
by Vijay Kiran Kamuju 10 Oct '05

10 Oct '05

---------- Forwarded message ---------- From: Vijay Kiran Kamuju <infyquest(a)gmail.com> Date: Oct 10, 2005 10:32 AM Subject: Re: printer dialog fix To: Dmitry Timoshkov <dmitry(a)baikal.ru> Well, on futher analysis. i found out that it needs some implementation of printer controlpanel applet, which we dont have at all. This may act as a starting point to add some implementation for it. (atleast support like other control panel applets) Thanks, Vijay On 10/9/05, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > > > This is an initial patch, if this gets accepted i will just add > > another error msgbox that its under development. > > I will be working on that > > If that another error message box won't add the functionality of > adding a printer (which I think is the case) I don't see how it could > improve the things. > > -- > Dmitry. > >

1 0

Re: [DDRAW] fix 2D in D3D device (resent)
by Christian Costa 10 Oct '05

10 Oct '05

Hi, This patch has not been commited yet. Is there any reason for that ? Christian Christian Costa wrote: > Hi, > > This patch fixes 2D in some games (Dino Crisis and Lands of Lore 3) > > Changelog: > Disable depth test when there is no Z buffer attached. > Initialise texture states at creation instead of when tex name is > generated. > > Christian Costa titan.costa(a)wanadoo.fr > >------------------------------------------------------------------------ > >Index: dlls/ddraw/opengl_private.h >=================================================================== >RCS file: /home/wine/wine/dlls/ddraw/opengl_private.h,v >retrieving revision 1.2 >diff -u -r1.2 opengl_private.h >--- dlls/ddraw/opengl_private.h 12 Jun 2005 10:43:11 -0000 1.2 >+++ dlls/ddraw/opengl_private.h 5 Oct 2005 20:51:34 -0000 >@@ -193,21 +193,21 @@ > extern HRESULT d3ddevice_create(IDirect3DDeviceImpl **obj, IDirectDrawImpl *d3d, IDirectDrawSurfaceImpl *surface, int version); > > /* Used for Direct3D to request the device to enumerate itself */ >-extern HRESULT d3ddevice_enumerate(LPD3DENUMDEVICESCALLBACK cb, LPVOID context, DWORD version) ; >-extern HRESULT d3ddevice_enumerate7(LPD3DENUMDEVICESCALLBACK7 cb, LPVOID context) ; >+extern HRESULT d3ddevice_enumerate(LPD3DENUMDEVICESCALLBACK cb, LPVOID context, DWORD version); >+extern HRESULT d3ddevice_enumerate7(LPD3DENUMDEVICESCALLBACK7 cb, LPVOID context); > extern HRESULT d3ddevice_find(IDirectDrawImpl *d3d, LPD3DFINDDEVICESEARCH lpD3DDFS, LPD3DFINDDEVICERESULT lplpD3DDevice); > > /* Used by the DLL init routine to set-up the GL context and stuff properly */ > extern BOOL d3ddevice_init_at_startup(void *gl_handle); > > /* Used to upload the texture */ >-extern HRESULT gltex_upload_texture(IDirectDrawSurfaceImpl *This, IDirect3DDeviceImpl *d3ddev, DWORD stage) ; >+extern HRESULT gltex_upload_texture(IDirectDrawSurfaceImpl *This, IDirect3DDeviceImpl *d3ddev, DWORD stage); > > /* Used to get the texture name */ >-extern GLuint gltex_get_tex_name(IDirectDrawSurfaceImpl *This) ; >+extern GLuint gltex_get_tex_name(IDirectDrawSurfaceImpl *This); > > /* Used to set-up our orthographic projection */ >-extern void d3ddevice_set_ortho(IDirect3DDeviceImpl *This) ; >+extern void d3ddevice_set_ortho(IDirect3DDeviceImpl *This); > > /* Rendering state management functions */ > extern void set_render_state(IDirect3DDeviceImpl* This, D3DRENDERSTATETYPE dwRenderStateType, STATEBLOCK *lpStateBlock); >@@ -222,7 +222,7 @@ > extern HRESULT upload_surface_to_tex_memory_release(void); > > /* Some utilities functions needed to be shared.. */ >-extern GLenum convert_D3D_compare_to_GL(D3DCMPFUNC dwRenderState) ; >+extern GLenum convert_D3D_compare_to_GL(D3DCMPFUNC dwRenderState); > > #endif /* HAVE_OPENGL */ > >Index: dlls/ddraw/device_opengl.c >=================================================================== >RCS file: /home/wine/wine/dlls/ddraw/device_opengl.c,v >retrieving revision 1.9 >diff -u -r1.9 device_opengl.c >--- dlls/ddraw/device_opengl.c 25 Sep 2005 15:18:18 -0000 1.9 >+++ dlls/ddraw/device_opengl.c 5 Oct 2005 20:51:45 -0000 >@@ -1325,6 +1325,7 @@ > IDirect3DDeviceGLImpl* glThis = (IDirect3DDeviceGLImpl*) This; > int num_active_stages = 0; > int num_tex_index = GET_TEXCOUNT_FROM_FVF(d3dvtVertexType); >+ BOOL reenable_depth_test = FALSE; > > /* I put the trace before the various locks... So as to better understand where locks occur :-) */ > if (TRACE_ON(ddraw)) { >@@ -1349,9 +1350,12 @@ > > hr = IDirectDrawSurface7_GetAttachedSurface(ICOM_INTERFACE(This->surface, IDirectDrawSurface7), > (DDSCAPS2 *) &zbuf_caps, &zbuf); >- if (!FAILED(hr)) { >+ if (SUCCEEDED(hr)) { > This->current_zbuffer = ICOM_OBJECT(IDirectDrawSurfaceImpl, IDirectDrawSurface7, zbuf); > IDirectDrawSurface7_Release(zbuf); >+ } else if (glThis->depth_test) { >+ glDisable(GL_DEPTH_TEST); >+ reenable_depth_test = TRUE; > } > } > if (This->current_zbuffer != NULL) { >@@ -1615,6 +1619,9 @@ > /* Whatever the case, disable the color material stuff */ > glDisable(GL_COLOR_MATERIAL); > >+ if (reenable_depth_test) >+ glEnable(GL_DEPTH_TEST); >+ > LEAVE_GL(); > TRACE("End\n"); > >Index: dlls/ddraw/texture.c >=================================================================== >RCS file: /home/wine/wine/dlls/ddraw/texture.c,v >retrieving revision 1.4 >diff -u -r1.4 texture.c >--- dlls/ddraw/texture.c 3 Aug 2005 21:25:11 -0000 1.4 >+++ dlls/ddraw/texture.c 5 Oct 2005 20:51:49 -0000 >@@ -381,7 +381,7 @@ > { > if (src != NULL) { > IDirectDrawSurfaceImpl *src_ptr = ICOM_OBJECT(IDirectDrawSurfaceImpl, IDirectDrawSurface7, src); >- >+ > if ((src_ptr->surface_desc.ddsCaps.dwCaps & DDSCAPS_3DDEVICE) && > ((trans & (DDBLTFAST_SRCCOLORKEY | DDBLTFAST_DESTCOLORKEY)) == 0)) { > /* This is a blt without color keying... We can use the direct copy. */ >@@ -390,7 +390,7 @@ > GLint cur_tex; > IDirect3DTextureGLImpl *gl_surf_ptr = surf_ptr->tex_private; > int y; >- >+ > if (rsrc == NULL) { > WARN("rsrc is NULL\n"); > rsrc = &rsrc2; >@@ -400,10 +400,10 @@ > rsrc->right = src_ptr->surface_desc.dwWidth; > rsrc->bottom = src_ptr->surface_desc.dwHeight; > } >- >+ > width = rsrc->right - rsrc->left; > height = rsrc->bottom - rsrc->top; >- >+ > if (((dstx + width) > surf_ptr->surface_desc.dwWidth) || > ((dsty + height) > surf_ptr->surface_desc.dwHeight)) { > FIXME("Does not handle clipping yet in FB => Texture blits !\n"); >@@ -413,16 +413,16 @@ > if ((width == 0) || (height == 0)) { > return DD_OK; > } >- >+ > TRACE(" direct frame buffer => texture BltFast override.\n"); >- >+ > ENTER_GL(); >- >+ > glGetIntegerv(GL_TEXTURE_BINDING_2D, &cur_tex); > /* This call is to create the actual texture name in GL (as we do 'late' ID creation) */ > gltex_get_tex_name(surf_ptr); > glBindTexture(GL_TEXTURE_2D, gl_surf_ptr->tex_name); >- >+ > if ((gl_surf_ptr->dirty_flag == SURFACE_MEMORY_DIRTY) && > !((dstx == 0) && (dsty == 0) && > (width == surf_ptr->surface_desc.dwWidth) && (height == surf_ptr->surface_desc.dwHeight))) { >@@ -456,7 +456,7 @@ > return DDERR_INVALIDPARAMS; > } > } >- >+ > if ((src_ptr->surface_desc.ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER|DDSCAPS_PRIMARYSURFACE)) != 0) > glReadBuffer(GL_FRONT); > else if ((src_ptr->surface_desc.ddsCaps.dwCaps & (DDSCAPS_BACKBUFFER)) == (DDSCAPS_BACKBUFFER)) >@@ -467,7 +467,7 @@ > LEAVE_GL(); > return DDERR_INVALIDPARAMS; > } >- >+ > for (y = (src_ptr->surface_desc.dwHeight - rsrc->top - 1); > y >= (src_ptr->surface_desc.dwHeight - (rsrc->top + height)); > y--) { >@@ -477,13 +477,13 @@ > width, 1); > dsty++; > } >- >+ > glBindTexture(GL_TEXTURE_2D, cur_tex); > LEAVE_GL(); >- >+ > /* The SURFACE_GL case is not handled by the 'global' dirty flag */ > gl_surf_ptr->dirty_flag = SURFACE_GL; >- >+ > return DD_OK; > } > } >@@ -544,9 +544,9 @@ > > if (glThis->dirty_flag == SURFACE_GL) { > GLint cur_tex; >- >+ > TRACE(" flushing GL texture back to memory.\n"); >- >+ > ENTER_GL(); > glGetIntegerv(GL_TEXTURE_BINDING_2D, &cur_tex); > glBindTexture(GL_TEXTURE_2D, glThis->tex_name); >@@ -554,14 +554,14 @@ > glBindTexture(GL_TEXTURE_2D, cur_tex); > LEAVE_GL(); > } >- >+ > /* First call the previous set_palette function */ > glThis->set_palette(This, pal); >- >+ > /* And set the dirty flag */ > glThis->dirty_flag = SURFACE_MEMORY_DIRTY; > *(glThis->global_dirty_flag) = SURFACE_MEMORY_DIRTY; >- >+ > /* TODO: check palette on mipmapped surfaces... > TODO: do we need to re-upload in case of usage of the paletted texture extension ? */ > } >@@ -603,7 +603,7 @@ > gltex_lock_update(IDirectDrawSurfaceImpl* This, LPCRECT pRect, DWORD dwFlags) > { > IDirect3DTextureGLImpl *glThis = (IDirect3DTextureGLImpl *) This->tex_private; >- >+ > glThis->lock_update(This, pRect, dwFlags); > } > >@@ -613,7 +613,7 @@ > IDirect3DTextureGLImpl *glThis = (IDirect3DTextureGLImpl *) This->tex_private; > > glThis->unlock_update(This, pRect); >- >+ > /* Set the dirty flag according to the lock type */ > if ((This->lastlocktype & DDLOCK_READONLY) == 0) { > glThis->dirty_flag = SURFACE_MEMORY_DIRTY; >@@ -868,7 +868,7 @@ > /* First, initialize the texture vtables... */ > ICOM_INIT_INTERFACE(surf, IDirect3DTexture, VTABLE_IDirect3DTexture); > ICOM_INIT_INTERFACE(surf, IDirect3DTexture2, VTABLE_IDirect3DTexture2); >- >+ > /* Only create all the private stuff if we actually have an OpenGL context.. */ > if (d3d->current_device != NULL) { > IDirect3DTextureGLImpl *private; >@@ -877,12 +877,12 @@ > if (private == NULL) return DDERR_OUTOFMEMORY; > > surf->tex_private = private; >- >+ > private->final_release = surf->final_release; > private->lock_update = surf->lock_update; > private->unlock_update = surf->unlock_update; > private->set_palette = surf->set_palette; >- >+ > /* If at creation, we can optimize stuff and wait the first 'unlock' to upload a valid stuff to OpenGL. > Otherwise, it will be uploaded here (and may be invalid). */ > surf->final_release = gltex_final_release; >@@ -895,7 +895,7 @@ > to save those... */ > surf->aux_blt = gltex_blt; > surf->aux_bltfast = gltex_bltfast; >- >+ > TRACE(" GL texture created for surface %p (private data at %p)\n", surf, private); > > /* Do not create the OpenGL texture id here as some game generate textures from a different thread which >@@ -903,12 +903,14 @@ > private->tex_name = 0; > if (surf->mipmap_level == 0) { > private->main = NULL; >+ private->__global_dirty_flag = SURFACE_MEMORY_DIRTY; > private->global_dirty_flag = &(private->__global_dirty_flag); > } else { > private->main = main; > private->global_dirty_flag = &(((IDirect3DTextureGLImpl *) (private->main->tex_private))->__global_dirty_flag); > } > private->initial_upload_done = FALSE; >+ private->dirty_flag = SURFACE_MEMORY_DIRTY; > } > > return D3D_OK; >@@ -925,15 +927,11 @@ > glGenTextures(1, &(private->tex_name)); > if (private->tex_name == 0) ERR("Error at creation of OpenGL texture ID !\n"); > TRACE(" GL texture id is : %d.\n", private->tex_name); >- private->__global_dirty_flag = SURFACE_MEMORY_DIRTY; > } else { > private->tex_name = gltex_get_tex_name(private->main); > TRACE(" GL texture id reusing id %d from surface %p (private at %p)).\n", private->tex_name, private->main, private->main->tex_private); > } > LEAVE_GL(); >- >- /* And set the dirty flag accordingly */ >- private->dirty_flag = SURFACE_MEMORY_DIRTY; > } > return ((IDirect3DTextureGLImpl *) (surf->tex_private))->tex_name; > } > > >------------------------------------------------------------------------ > > > >

2 1

DosDefineDevice breaking mapping to unix folders
by Christian Costa 09 Oct '05

09 Oct '05

Hi, It seems there is something wrong with DosDefineDevice. If we consider a drive declared as F: -> /mnt/win_e Remapping the drive F: to G: with this function leads to F: -> G: with G: non defined. This makes, in my case, my app to break all my drives assignement. It's seems the code lacks a level of inderection as shown below: Logical drive -> Real drive -> unix dir Any idea? Bye, Christian

2 5

Office97 Install issue
by Steven Edwards 09 Oct '05

09 Oct '05

Hi, As some of you might know I really would like to see Office 97 be able to at least install and parts of it sort of work on Wine 1.0. One of the things I hope to contribute to the 1.0 effort is fixing this. I'm wondering if anyone could give me a pointer or two as to the problem. There are two issues with Winehq that prevent Office 97 from installing and I need help with issue #2 if anyone has ideas. 1. Wine needs to have the "PROCESSOR_ARCHITECTURE"="x86" string in the Key in HKLM\\System\\CurrentControlSet\\Control\\Session Manager\\Environment On CrossOver we are hard setting this (and we install in a Win98 bottle so it does not really matter) but for Winehq we need to properly detect and report the CPU due to Winehq default mode being Win2k. I'll try to make 30mins or so in the next couple of weeks to submit a patch that does this as I think I know where it needs to be implemented. 2. Wine is not properly handling some of the default values in key HKLM\\System\\CurrentControlSet\\Control\\Session Manager\\Environment If you notice from the diff CrossOver uses "%SystemRoot% where the default Wine system.reg had the values hard coded. My wifes Win2k box has these values set with "%SystemRoot% also. Is there a reason that Winehq is setup this way? Should they strings in the wine.inf just be changed for those values? With the default Winehq registry you get a message box error that says something along the lines of "This setup program is not supported under your version of Windows" -[System\\CurrentControlSet\\Control\\Session Manager\\Environment] 1126302066 -"ComSpec"="c:\\windows\\system32\\wcmd.exe" -"PATH"="c:\\windows\\system32;c:\\windows" -"ProgramFiles"="c:\\Program Files" -"SYSTEMROOT"="c:\\windows" -"TEMP"="c:\\windows\\temp" -"TMP"="c:\\windows\\temp" -"USERPROFILE"="c:\\windows\\profiles\\sedwards" -"windir"="c:\\windows" -"winsysdir"="c:\\windows\\system32" +[System\\CurrentControlSet\\Control\\Session Manager\\Environment] 1126301456 +"ComSpec"=str(2):"%SystemRoot%\\System\\wcmd.exe" +"PATH"=str(2):"%SystemRoot%;%SystemRoot%\\System" +"PROCESSOR_ARCHITECTURE"="x86" +"SystemDrive"="C:" +"SystemRoot"="C:\\Windows" +"TEMP"=str(2):"%SystemRoot%\\Temp" +"TMP"=str(2):"%SystemRoot%\\Temp" +"USERPROFILE"="C:\\windows\\profiles\\sedwards" +"windir"=str(2):"%SystemRoot%" +"winsysdir"=str(2):"%SystemRoot%\\System" So if anyone has any ideas I would appreciate feedback. Thanks Steven

2 4

Heap issues
by Randall Walls 09 Oct '05

09 Oct '05

Greetings, I've been (unsuccessfully) attempting to run a children's program through wine for some time. I've been trying successive releases since about may, without luck. The program appears to be extremely simple, just some painting apps for toddlers, but each run fails with what looks like a heap issue. The program is by Creative Wonders called Sesame Street Toddlers Deluxe Art workshop. I'm attaching the output that winedbg gives, but would appreciate any feedback. I'm fairly comfortable with winedbg, so I can provide additional info about the crash if needed. Mostly I'm just curious if this is an issue with Wine's heap implementation, or if it is more likely just a poorly built application that I should give up on. winedbg output: 21:23:34 slight - cdrom>wine: Unhandled exception (thread 0014), starting debugger... WineDbg starting on pid 0xf Unhandled exception: page fault on read access to 0x41ea6f30 in 32-bit code (0x4019fa56). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:0087 EIP:4019fa56 ESP:420254d0 EBP:420254f4 EFLAGS:00210287( - 00 RISP1C) EAX:000090c8 EBX:401d8e28 ECX:41eb0000 EDX:00110000 ESI:41ea6f30 EDI:41dd6f28 Stack dump: 0x420254d0: 00001000 00000004 40075bac 000090c8 0x420254e0: 41dd6f38 4019f9fb 401d8e28 41dc6f20 0x420254f0: 00010000 42025538 4019dcd9 41da0000 0x42025500: 41dd6f28 000d0008 00000000 401bd230 0x42025510: 00000802 00000000 00000000 41dc6f28 0x42025520: 00000000 40370000 41da0000 4052ca5c Backtrace: =>1 0x4019fa56 in ntdll (+0x1fa56) (0x420254f4) 2 0x4019dcd9 RtlAllocateHeap+0x1e9 in ntdll (0x42025538) 3 0x404ccd4d HeapAlloc+0x2d in kernel32 (0x42025550) 4 0x404cabbc GLOBAL_Alloc+0x7c in kernel32 (0x42025588) 5 0x404cad06 GlobalAlloc16+0x46 in kernel32 (0x420255a8) 6 0x4051a387 K32WOWGlobalAlloc16+0x27 in kernel32 (0x420255bc) 7 0x404d0a94 DllMain+0x94 in kernel32 (0x420255d8) 8 0x4051c378 __wine_spec_dll_entry+0x38 in kernel32 (0x420255f8) 9 0x401a1292 call_dll_entry_point+0x12 in ntdll (0x42025610) 10 0x401a396a in ntdll (+0x2396a) (0x42025698) 11 0x401a165e MODULE_DllThreadAttach+0xae in ntdll (0x420256c0) 12 0x4050e202 GetCurrentThreadId+0x136 in kernel32 (0x42025798) 13 0x401c21a2 NtCurrentTeb+0x1be in ntdll (0x42025fec) 14 0x40106b8a __clone+0x5a in libc.so.6 (0x00000000) 0x4019fa56: testb $0x1,0x0(%esi) Modules: Module Address Debug info Name (77 modules) ELF 0x40000000-40017000 Deferred ld-linux.so.2 ELF 0x40032000-4004c000 Deferred libwine.so.1 ELF 0x4004d000-4016a000 Export libc.so.6 ELF 0x4016a000-4016e000 Deferred libdl.so.2 ELF 0x4016e000-401e8000 Export ntdll<elf> \-PE 0x40180000-401e8000 \ ntdll ELF 0x40203000-402f8000 Deferred libwine_unicode.so.1 ELF 0x402f8000-4031b000 Deferred libm.so.6 ELF 0x40336000-4033f000 Deferred libnss_compat.so.2 ELF 0x4033f000-40355000 Deferred libnsl.so.1 ELF 0x40355000-4035f000 Deferred libnss_nis.so.2 ELF 0x4035f000-40369000 Deferred libnss_files.so.2 ELF 0x40482000-4058c000 Export kernel32<elf> \-PE 0x404a0000-4058c000 \ kernel32 ELF 0x405c2000-405d7000 Deferred winevdm<elf> \-PE 0x405d0000-405d7000 \ winevdm ELF 0x406e0000-40815000 Deferred user32<elf> \-PE 0x40700000-40815000 \ user32 ELF 0x40815000-408a5000 Deferred gdi32<elf> \-PE 0x40830000-408a5000 \ gdi32 ELF 0x408a5000-408e3000 Deferred advapi32<elf> \-PE 0x408b0000-408e3000 \ advapi32 ELF 0x408fe000-40968000 Deferred libfreetype.so.6 ELF 0x40968000-40979000 Deferred libz.so.1 ELF 0x40979000-409fd000 Deferred winex11.drv<elf> \-PE 0x40990000-409fd000 \ winex11.drv ELF 0x40a18000-40a20000 Deferred libsm.so.6 ELF 0x40a20000-40a38000 Deferred libice.so.6 ELF 0x40a38000-40a3e000 Deferred libxxf86dga.so.1 ELF 0x40a3e000-40a43000 Deferred libxxf86vm.so.1 ELF 0x40a43000-40a51000 Deferred libxext.so.6 ELF 0x40a51000-40b1b000 Deferred libx11.so.6 ELF 0x40b1b000-40b93000 Deferred libgl.so.1 ELF 0x40b93000-412e4000 Deferred libglcore.so.1 ELF 0x412e4000-412e6000 Deferred libnvidia-tls.so.1 ELF 0x41399000-413a1000 Deferred libxrender.so.1 ELF 0x413a1000-413a4000 Deferred libxrandr.so.2 ELF 0x413a4000-413a7000 Deferred xlcdef.so.2 ELF 0x413a7000-413c5000 Deferred ximcp.so.2 ELF 0x413c5000-413e2000 Deferred imm32<elf> \-PE 0x413d0000-413e2000 \ imm32 ELF 0x413e5000-413e9000 Deferred iso8859-1.so ELF 0x41404000-4140d000 Deferred libxcursor.so.1 ELF 0x41451000-414b4000 Deferred winedos<elf> \-PE 0x41460000-414b4000 \ winedos ELF 0x414b4000-41538000 Deferred winmm<elf> \-PE 0x414c0000-41538000 \ winmm ELF 0x41538000-4157f000 Deferred wineoss.drv<elf> \-PE 0x41550000-4157f000 \ wineoss.drv ELF 0x4157f000-41597000 Deferred msacm.drv<elf> \-PE 0x41590000-41597000 \ msacm.drv ELF 0x41597000-415ba000 Deferred msacm32<elf> \-PE 0x415a0000-415ba000 \ msacm32 ELF 0x416d0000-416e5000 Deferred midimap<elf> \-PE 0x416e0000-416e5000 \ midimap ELF 0x41827000-418be000 Deferred comdlg32<elf> \-PE 0x41830000-418be000 \ comdlg32 ELF 0x418be000-41989000 Deferred shell32<elf> \-PE 0x418d0000-41989000 \ shell32 ELF 0x41989000-419e4000 Deferred shlwapi<elf> \-PE 0x419a0000-419e4000 \ shlwapi ELF 0x419e4000-41a78000 Deferred ole32<elf> \-PE 0x41a00000-41a78000 \ ole32 ELF 0x41a78000-41abe000 Deferred rpcrt4<elf> \-PE 0x41a90000-41abe000 \ rpcrt4 ELF 0x41abe000-41adc000 Deferred iphlpapi<elf> \-PE 0x41ad0000-41adc000 \ iphlpapi ELF 0x41adc000-41bad000 Deferred comctl32<elf> \-PE 0x41af0000-41bad000 \ comctl32 ELF 0x41bad000-41bd8000 Deferred winspool.drv<elf> \-PE 0x41bc0000-41bd8000 \ winspool.drv ELF 0x41c4b000-41c67000 Deferred libcups.so.2 ELF 0x41c67000-41c98000 Deferred libssl.so.0 ELF 0x41c98000-41d97000 Deferred libcrypto.so.0 ELF 0x41eb0000-41ee3000 Deferred uxtheme<elf> \-PE 0x41ec0000-41ee3000 \ uxtheme ELF 0x7bf00000-7bf07000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000000f (D) E:\winevdm.exe 00000014 15 <== 00000011 0 00000010 0 WineDbg terminated on pid 0xf Much obliged, Randall Walls

3 4

font issues
by luis lenders 09 Oct '05

09 Oct '05

Hi, what i find rather confusing in current wine , is that it only tries to use the fonts in ~/.wine/drive_c/windows/fonts. Lets say i'm a new user and i want to try out wine. I create a new directory ~/.wine and i try to install for example Guitar pro demo: http://213.246.36.227/download/GP4DEMO_EN.EXE After install i try the program but it doesn't run (there's a bug) So i want to change settings via winecfg. I end up with the following screen: (see attachment) This is because Guitar Pro places some weird font in ~/.wine/drive_c/windows/fonts. Of course can remove the font again or copy other fonts to ~/.wine/drive_c/windows/fonts but this is beyond the knowledge of new wine users i guess. Is there a simple way to avoid these kinds of issues? ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

3 2

Re: msvcrt: Few failing tests for O_TEXT files
by Richard Cohen 09 Oct '05

09 Oct '05

Vitaliy Margolen wrote: > + _lseek(tempfd, -1, FILE_END); > + ok(_read(tempfd,btext,LLEN) == 1, "_read expected 0 got '\\n'\n"); That doesn't look right. Richard.

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel