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

SecuRom investigation
by Martin Owen June 25, 2006

June 25, 2006

Hello all, I have been investigating getting rid of a terminal anoyancy for wine game users, SecuRom security. I don't believe it is good enough to crack the games as this makes us out to look like criminals rather than trying to get legitimate games to work. I have sent a query to sony, asking if they will help with providing information, but I'm not hopeful of a positive response. I found an interesting tool here: http://www.gameburnworld.com/securompatches.htm which if we could get our hands on the source code would at least give us more information about how this security works and may even allow us to work around it perminently with in wine. Best Regards, Martin Owens

4 4

Re: [AppDb] Comments handling cleanup
by Tony Lambregts June 25, 2006

June 25, 2006

Jonathan Ernst wrote: > Hi, > > I followed your discussions about sql/html injection and had a look at > what you are doing in order to fix the situation and I don't want to > offense anybody but I feel that what you are trying to do is a bit hacky > ;-). > > Here is a cleaned up version of the comments handling that better fixes > (imho) all problems related to sql and html injection. > > The code I made is not dependent on magic_quote value and should'nt > allow anybody to mess with the values read or written from/to the > database. Also it doesn't require to make copies of every single string the user > passes to us. > > It is based on php manual's best practices for avoiding injection. > > I'd be very glad if we'll use such mechanism for the rest of the > queries and get rid of compile_whatever, makeSafe & co. > > This patch follows the Coding Standards we set up a little bit more as > well. > > Awaiting your comments. I am more in favor of this approach than using makeSafe() and do the same thing as Chris's query_parameters() patch. However I am hard pressed to say whether this method is really better or safer than query_parameters(). I have had real issues with makeSafe() the primary one is that IMO the place to make sure that we are safe from sql injection is where we create the SQL. The makeSafe() did not do that. The changes to that are only cosmetic and make it harder to see the actual changes. Formating changes should be in a separate patch. Also I would really appreciate a "Files Changed:" section that lists the files changed/added/removed by this patch. I find that it really helps in reviewing patches. Please resubmit with the formating changes in a separate patch. -- Tony Lambregts

2 1

An RPM of wine with safedisc support
by ivanleo＠gmail.com June 25, 2006

June 25, 2006

Safedisc has now been working on wine for almost a year, but it'll still take some time before we get the code into winehq, so I've decided to build an RPM of wine with safedisc 1 support so users can play around with it, you can download it from http://www003.portalis.it/115/wine-safedisc-0.9.16-mdk.i586.rpm Safedisc 2 and above are not supported. This is based on wine 0.9.16, however it isn't an official winehq release, and is provided on an as is basis. To run a safedisc protected game, you must run winecfg and set the drive type of your cdrom drive to "cdrom" in the drives tab. Yes, this sounds dumb, but it has to be done. Then run the game normally, and as long as you have an original CD (Ok, copies can work too but that's Macrovision's fault) in the drive, the game will start. Ivan.

3 4

Ole-BSTR-Concat broken?
by Olaf Schmidt June 25, 2006

June 25, 2006

Hi *.*, seems, that the Ole-BSTR-Concat doesn't work anymore: (Debian Sid, from wine 0.9.12 upwards - wine configured, to use the builtin Ole-Stuff) In VB-Applications (wich are using (wide) Ole-BSTRs under the hood), I can reduce the problem to the following: If I define two Strings with the Content: S1, containing a Zero WChar (BSTR-LenDescriptor=2, ByteSequence 0 0) and S2, containing "A|Zero|B" (BSTR-LenDescriptor=6, ByteSequence 65 0 | 0 0 | 66 0) and then do the concat: SResult = S1 + S2 the resulting string contains only an "A" (BSTR-LenDescriptor=2, ByteSequence 65 0) instead of the correct ByteSequence: 0 0 | 65 0 | 0 0 | 66 0 That means, that the current implementation does not use the BSTR-Len-Descriptor anymore (it has worked in 0.9.10 or 0.9.11 - not very sure, but think it was 0.9.11 in my last tests) Instead it now behaves like routines, wich have to concat Zero-Terminated Strings. Nothing changed in my wine-configuration - only apt-getted to 0.9.12 first -> then to the latest 0.9.16 (ubuntu-deb) -> same problem. Do you handle the OLE-BSTR-stuff directly in wine, or do you give that jobs to other Libs in the system (the 0.9.12er winelib- update has also changed some dependencies (Gtk, libc* and others)? Olaf Schmidt

4 3

Re: Recording with "Lexia" (mci "open new")
by Damjan Jovanovic June 25, 2006

June 25, 2006

> 3) Most importantly: Why is it necessary to add > CAPTURE to system.ini? > Perhaps the "alias" argument isn't correctly > handled? Yes wine's MCI is broken: the parsing of some formats of MCI commands is incorrect, one of the examples I clearly remember being: "open G: type cdaudio alias cd" and wine complains that it could not load driver for type G: (whereas the driver type is cdaudio, no?) and you have to add "G:=mcicda.dll" in system.ini __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

Re: riched20: WM_SETFONT support
by Matt Finnicum June 25, 2006

June 25, 2006

I was just about to send in the same patch when you did. I'll have to keep you updated on what I'm working on in the future. (You can see what I'm planning to do for my SoC project at http://wiki.winehq.org/MatthewFinnicum) I've attached the patch I was going to send - I suggest we use some parts of each (either I can merge them into a patch or you can, your call). Our code is actually quite similar - though your "ME_CharFormatFromLogFont" is definitely superior to mine (I just did it all in function / was slightly less awesome). Aside from my conformance tests (Which your patch passed just fine), my patch covers some extra things: 1) You need to rewrap the paragraphs, since line lengths change. 2) Your code ignores lParam (which is supposed to specify if it repaints immediately) 3) You need to invalidate the entire control - otherwise just the are the text takes up will be redrawn - if the text shrinks, then the area outside it's new size won't be blanked / you'll see fragments of the old text. 4) Your code (I believe) will reset the scroll position - I store it ahead of time and then restore it. Thanks, --Matt On 6/24/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > ChangeLog: > * WM_SETFONT implementation - sets the default font and the font for > the whole pre-existing text > > Seems to fix bug 4563 and half of the bug 3917. > > Krzysztof > > > diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c > old mode 100644 > new mode 100755 > index 50527ca..61ecc72 > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -92,7 +92,7 @@ > - EM_SELECTIONTYPE > - EM_SETBIDIOPTIONS 3.0 > + EM_SETBKGNDCOLOR > - - EM_SETCHARFORMAT (partly done, no ANSI) > + + EM_SETCHARFORMAT (partly done, no ANSI) > - EM_SETEDITSTYLE > + EM_SETEVENTMASK (few notifications supported) > - EM_SETFONTSIZE > @@ -135,7 +135,7 @@ > + WM_GETTEXT (ANSI&Unicode) > + WM_GETTEXTLENGTH (ANSI version sucks) > + WM_PASTE > - - WM_SETFONT > + + WM_SETFONT > + WM_SETTEXT (resets undo stack !) (proper style?) ANSI&Unicode > - WM_STYLECHANGING > - WM_STYLECHANGED (things like read-only flag) > @@ -1442,7 +1442,6 @@ LRESULT WINAPI RichEditANSIWndProc(HWND > UNSUPPORTED_MSG(EM_SETTYPOGRAPHYOPTIONS) > UNSUPPORTED_MSG(EM_SETWORDBREAKPROCEX) > UNSUPPORTED_MSG(EM_SHOWSCROLLBAR) > - UNSUPPORTED_MSG(WM_SETFONT) > UNSUPPORTED_MSG(WM_STYLECHANGING) > UNSUPPORTED_MSG(WM_STYLECHANGED) > /* UNSUPPORTED_MSG(WM_UNICHAR) FIXME missing in Wine headers */ > @@ -1844,6 +1843,27 @@ LRESULT WINAPI RichEditANSIWndProc(HWND > > return 0; > } > + case WM_SETFONT: > + { > + LOGFONTW lf; > + CHARFORMAT2W fmt; > + HDC hDC; > + BOOL bRepaint = LOWORD(lParam); > + > + if (!wParam) > + wParam = (WPARAM)GetStockObject(DEFAULT_GUI_FONT); > + GetObjectW((HGDIOBJ)wParam, sizeof(LOGFONTW), &lf); > + hDC = GetDC(hWnd); > + ME_CharFormatFromLogFont(hDC, &lf, &fmt); > + ReleaseDC(hWnd, hDC); > + ME_SetCharFormat(editor, 0, ME_GetTextLength(editor), &fmt); > + ME_SetDefaultCharFormat(editor, &fmt); > + > + ME_CommitUndo(editor); > + if (bRepaint) > + ME_UpdateRepaint(editor); > + return 0; > + } > case WM_SETTEXT: > { > ME_InternalDeleteText(editor, 0, ME_GetTextLength(editor)); > diff --git a/dlls/riched20/editor.h b/dlls/riched20/editor.h > old mode 100644 > new mode 100755 > index 33b7626..a4d4980 > --- a/dlls/riched20/editor.h > +++ b/dlls/riched20/editor.h > @@ -55,6 +55,7 @@ void ME_CopyToCF2W(CHARFORMAT2W *to, CHA > CHARFORMAT2W *ME_ToCFAny(CHARFORMAT2W *to, CHARFORMAT2W *from); > void ME_CopyToCFAny(CHARFORMAT2W *to, CHARFORMAT2W *from); > void ME_CopyCharFormat(CHARFORMAT2W *pDest, CHARFORMAT2W *pSrc); /* only works with 2W structs */ > +void ME_CharFormatFromLogFont(HDC hDC, LOGFONTW *lf, CHARFORMAT2W *fmt); /* ditto */ > > /* list.c */ > void ME_InsertBefore(ME_DisplayItem *diWhere, ME_DisplayItem *diWhat); > diff --git a/dlls/riched20/style.c b/dlls/riched20/style.c > old mode 100644 > new mode 100755 > index f420f09..6104a0c > --- a/dlls/riched20/style.c > +++ b/dlls/riched20/style.c > @@ -286,6 +286,25 @@ ME_LogFontFromStyle(HDC hDC, LOGFONTW *l > lf->lfCharSet = s->fmt.bCharSet; > } > > +void ME_CharFormatFromLogFont(HDC hDC, LOGFONTW *lf, CHARFORMAT2W *fmt) > +{ > + int rx, ry; > + > + ME_InitCharFormat2W(fmt); > + rx = GetDeviceCaps(hDC, LOGPIXELSX); > + ry = GetDeviceCaps(hDC, LOGPIXELSY); > + lstrcpyW(fmt->szFaceName, lf->lfFaceName); > + fmt->dwEffects = 0; > + fmt->dwMask = CFM_WEIGHT|CFM_BOLD|CFM_ITALIC|CFM_UNDERLINE|CFM_STRIKEOUT|CFM_SIZE|CFM_FACE|CFM_CHARSET; > + fmt->wWeight = lf->lfWeight; > + fmt->yHeight = -lf->lfHeight*1440/ry; > + if (lf->lfWeight>400) fmt->dwEffects |= CFM_BOLD; > + if (lf->lfItalic) fmt->dwEffects |= CFM_ITALIC; > + if (lf->lfUnderline) fmt->dwEffects |= CFM_UNDERLINE; > + if (lf->lfStrikeOut) fmt->dwEffects |= CFM_STRIKEOUT; > + fmt->bPitchAndFamily = lf->lfPitchAndFamily; > + fmt->bCharSet = lf->lfCharSet; > +} > > BOOL ME_IsFontEqual(LOGFONTW *p1, LOGFONTW *p2) > { > > > > > >

2 2

Re: wined3d: declaration/FVF conversion test
by Jason Green June 25, 2006

June 25, 2006

On 6/19/06, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > Does the windows box support shader model 3.0 ? The reason I keep asking > about this is that MSDN talks about a ' pre-3.0' driver and a 3.0 driver, > and I wanted to see if behavior was different. Just tested on my primary machine which has an NVidia 6600GT (Shader Model 3.0) in Windows XP, and got this: vertexdeclaration: 441 tests executed, 0 marked as todo, 0 failures. So, looks like we are good to go.

1 0

Re: setupapi: Fix SetupCloseInfFile when a NULL handle is given, with tests
by Joris Huizer June 24, 2006

June 24, 2006

James Hawkins wrote: > Hi, > > This fixes bug 5511. > > Changelog: > * Fix SetupCloseInfFile when a NULL handle is given, with tests. > > dlls/setupapi/parser.c | 2 ++ > dlls/setupapi/tests/parser.c | 9 +++++++++ > 2 files changed, 11 insertions(+), 0 deletions(-) > > -- > James Hawkins > > > ------------------------------------------------------------------------ > > This attachment seems to be empty; regards, Joris

1 0

Variable sized server replies
by Thomas Kho June 24, 2006

June 24, 2006

In protocol.def, the get_startup_info request declares two VARARGS as replies. Unless I've mistaken, replies are limited to one VARARG that the server call writes into preallocated data, right? That leads me to my next question: I'm currently working on moving menus into the server (see <http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/> for a series of patches that moves most menu data into the server. Most logic is still on the client, but it's still surprisingly snappy.) If you look at <http://silenceisdefeat.org/~tkho/seas/wine/patches/menu-0622-3/10-server-mii>, my problem is that I don't know the size of the data that the server is going to return and my current hack is to set a hard upper limit. I can think of two ways to tackle this: 1. Do a server call before hand to request the size of the data to be returned. This has the overhead of the additional call, but doesn't increase the complexity of the server itself. 2. Instead of preallocating memory for the variable reply, have the request mechanism allocate it (like it does on the server end for variable sized data in the request). This also adds complexity as the reply would be callee-allocated, caller-freed (or perhaps we could take advantage of SERVER_END_REQ?). However, it seems kind of natural to have the request process parallel the reply process. Is there another alterative? Any comments on which approach is better? Thomas Kho

2 1

Re: [AppDB] - protect sql insert statements from injection attacks
by Tony Lambregts June 24, 2006

June 24, 2006

Chris Morgan wrote: > Here is the new version. I've switched to the fully expanded method of > writing out the sql. This is the same format used by several db wrapper > libraries, in prepared sql statements and is the recommended style under > c#/.net for queries. > > I've tested creating new users and distributions and submitting an > application. > I have tested the patch thoroughly and it looks good to me. -- Tony Lambregts

1 0