wine-devel January 2006

wine-devel@winehq.org

161 participants
302 discussions

Wine on SuSE 10 and German Umlauts
by Roland Kaeser 19 Jan '06

19 Jan '06

Hello I'm new in this list. I'm the Application Maintainer of Corel Draw 9 and Railroad Tycoo3 so I hope I'm ready to discuss with the developers on a equal level. I have a very strange behaviour when using wine (the original suse rpm, the compiled source code (release or cve)) on SuSE 10 on a Intel ia32 machine. All Windows Programs (running on wine) don't accept german umlauts (äöü) keys. The rest of system (console, X-Window System) accepts it (as Yours can see in the mail). Does somebody has a idea about the reason behind this behaviour? Many Thanks Roland Kaeser ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

3 4

CVS build error on RH9
by Robert Reif 19 Jan '06

19 Jan '06

This patch: http://www.winehq.org/pipermail/wine-cvs/2006-January/020350.html doesn't compile on RH9. make[2]: Entering directory `/home/wine/wine/dlls/d3d8' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o device.o device.c device.c: In function `IDirect3DDevice8Impl_SetRenderState': device.c:3087: `GL_ARB_point_sprite' undeclared (first use in this function) device.c:3087: (Each undeclared identifier is reported only once device.c:3087: for each function it appears in.) device.c:3088: `GL_POINT_SPRITE_ARB' undeclared (first use in this function) make[2]: *** [device.o] Error 1 make[2]: Leaving directory `/home/wine/wine/dlls/d3d8'

3 4

Internet Explorer 6.0 SP1 fails on CVS
by Henry Kroll 19 Jan '06

19 Jan '06

For the past 2 weeks, IE6 has been failing to load under CVS. It works fine on wine <= .9.5, however. And other apps work no problem. The error I get is: fixme:toolbar:TOOLBAR_CheckStyle [0x10032] TBSTYLE_REGISTERDROP not implemented fixme:toolbar:TOOLBAR_CheckStyle [0x10032] TBSTYLE_REGISTERDROP not implemented fixme:shell:NTSHChangeNotifyRegister (0x10032,0x00008003,0x00008000,0x0000c070,0x00000001,0x55c3ddc8):semi stub. fixme:toolbar:TOOLBAR_Unkwn45D hwnd=0x10032, wParam=0x00000000, size.cx=1280, size.cy=32000 stub! fixme:toolbar:TOOLBAR_CheckStyle [0x10032] TBSTYLE_REGISTERDROP not implemented fixme:toolbar:TOOLBAR_CheckStyle [0x10032] TBSTYLE_REGISTERDROP not implemented fixme:toolbar:TOOLBAR_Unkwn464 hwnd=0x10036 wParam 00000001 lParam 00000000 err:rebar:REBAR_Layout no redraw and client is zero, skip layout wine: Call from 0x55861bf0 to unimplemented function kernel32.dll.BaseCheckAppcompatCache, aborting fixme:imm:ImmDisableIME (-1): stub I think it wants a stub for BaseCheckAppcompatCache. Henry

1 0

Re: winspool/tests: dump filename and version of the tested file
by James Hawkins 19 Jan '06

19 Jan '06

On 1/17/06, Detlef Riekenberg <wine.dev(a)web.de> wrote: > > Changelog: > - winspool/tests: dump filename and version of the tested file > - use <name> for all includes > We generally have a policy of silence for the test suite unless a failure occurrs. Why do you need to output the version tested? -- James Hawkins

3 5

Re: [bug 4004] MenuItemInfo vs GetMenuString
by Dmitry Timoshkov 18 Jan '06

18 Jan '06

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> wrote: > Copy and store the dwTypeData of a menu item even for a ownerdraw item, and > ensure the memory allocations/freeing occurs correctly > + /* Just change ftype to string and see what text is stored */ > + memset(&info, 0x00, sizeof(info)); > + info.cbSize= sizeof(MENUITEMINFO); > + info.fMask= MIIM_FTYPE; /* Set string type */ > + info.fType= MFT_STRING; > + info.dwTypeData= (char *)0xdeadbeef; > + SetMenuItemInfo( hmenu, 0, TRUE, &info ); > + > + /* Did we keep the old dwTypeData? */ > + ok (GetMenuString( hmenu, 0, strback, 99, MF_BYPOSITION), "GetMenuString on ownerdraw entry failed\n"); > + ok (!strcmp( strback, "Dummy string" ), "Menu text from Ansi version incorrect\n"); > + > + /* Just change ftype to bitmap and back to ensure data isnt freed */ > + memset(&info, 0x00, sizeof(info)); > + info.cbSize= sizeof(MENUITEMINFO); > + info.fMask= MIIM_FTYPE; /* Set as bitmap type */ > + info.fType= MFT_BITMAP; > + info.dwTypeData= (char *)0xdeadbee2; > + SetMenuItemInfo( hmenu, 0, TRUE, &info ); > + info.fType= MFT_OWNERDRAW; /* Set as ownerdraw type */ > + info.dwTypeData= (char *)0xdeadbee3; > + SetMenuItemInfo( hmenu, 0, TRUE, &info ); You don't check SetMenuItemInfo return code after the above calls and I very much suspect that they fail leading to the observed results. -- Dmitry.

5 15

FWD: Wine on SuSE 10 and German Umlauts
by Roland Kaeser 18 Jan '06

18 Jan '06

1 0

Re: GIT rebase changes
by Eric POUECH 18 Jan '06

18 Jan '06

why don't you guys use stg (stacked git) it allows you to manage a set of patches, with features like : - re-edit an existing one (basically, you push/pull a set of patches from a stack, and decide which one to use) - you get the upside of git, without the down side (ie a commit is done only once) (but you can still commit a patch - in git sense ; but you'll get back Mike's first point about pull/fetch discussion) - you don't need to rebase (it does it for you) - you don't need to coalesce patches (as you can reedit an existing one) - it's compatible with some other tools (like qgit) basically, I switched to stg - on top of git - when I got my tree messed up twice by updates... If you go for stg, I also recommend the bash completion extension which is very helpful (for patch name's management) my 2 cents > Message du 18/01/06 17:39 > De : "Robert Shearman" > A : "Mike McCormack" > Copie à : "Wine Devel" > Objet : Re: GIT rebase changes > > Mike McCormack wrote: > > > > > Hi GIT users, > > > > The GIT guys have made rebase and pull incompatible, and to use rebase > > (which is likely what we want to do for Wine), you must use "fetch" > > then "rebase", not "pull" (which does a merge). > > > And on a slightly related note, I wrote a script which works kinda like > rebase (and is based on the old version of rebase) that allows you to > coalesce two patches in your tree. This is useful in two situations: > 1. You commit a new feature and then realise after some extensive > testing that there is a bug, so you commit a fix, don't want to send the > two separate patches to wine-patches (maybe to save face :-), or maybe > to reduce noise). > 2. You revert a patch in your tree but don't want both the revert and > the old patch in your patch queue as shown by git-format-patch or by > Mike's mm-send-patch. > > Note that the first commit chronologically must be the first commit on > the command line. > > -- > Rob Shearman > > > > [ rob-git-coalesce-patches (2.5 Ko) ] > [ (pas de nom de fichier) (0.0 Ko) ]

1 0

GIT rebase changes
by Mike McCormack 18 Jan '06

18 Jan '06

Hi GIT users, The GIT guys have made rebase and pull incompatible, and to use rebase (which is likely what we want to do for Wine), you must use "fetch" then "rebase", not "pull" (which does a merge). See: http://article.gmane.org/gmane.linux.kernel/365410 The error message that you get if you use "pull" then try to "rebase" with newer version of GIT is pretty useless: bash-3.00$ git-rebase origin Current branch refs/heads/master is up to date. So use "git-fetch" to update origin, then "git-rebase origin" after that to get the new changes. I've update the Wiki with that information - don't shoot the messenger :/ Mike

3 3

Re: [D3D8] fix compile error for missing GL define
by H. Verbeet 18 Jan '06

18 Jan '06

On 18/01/06, Robert Reif <reif(a)earthlink.net> wrote: > I don't know the best way to handle this but this patch does get it to > compile again. Fixing it that way makes it a compile time check instead of a runtime check. I think the idea was for d3d to check extension support during runtime. include/wine/wined3d_gl.h has defines for GL_ARB_point_sprite etc, but as far as I know it doesn get included by d3d8. For d3d8, it should probably be defined in dlls/d3d8/d3dcore_gl.h (it isn't right now).

1 0

Re: PATCH/RFC: defer OLE apartment window creation
by Marcus Meissner 18 Jan '06

18 Jan '06

On Wed, Dec 21, 2005 at 02:55:14AM +0000, Robert Shearman wrote: > Marcus Meissner wrote: > > >@@ -257,6 +254,15 @@ > > return apt; > >} > > > >+void make_apartment_window(APARTMENT *apt) { > >+ if (apt->win) return; > >+ if (!(apt->model & COINIT_APARTMENTTHREADED)) > >+ return; > >+ apt->win = CreateWindowW(wszAptWinClass, NULL, 0, > >+ 0, 0, 0, 0, > >+ 0, 0, OLE32_hInstance, NULL); > >+} > >+ > > > > This isn't thread-safe. It would also be better to make this an accessor > function for the win field of struct apartment and fix up all callers to > use this. I still have to verify on Windows whether this is what it does > or whether it does something funny with message loops. I lack the time and testing abilities to do this right now (and now on xmas break). Its just a quick hack to get Google Earth running. It is now up to showing the famous GL "black screen". :( (WINEDLLOVERRIDES=*usp10=n) Ciao, Marcus

2 2

← Newer
1
...
12
13
14
15
16
17
18
...
31
Older →

Jump to page:

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 January 2006