wine-devel June 2006

wine-devel@winehq.org

174 participants
352 discussions

Re: [AppDb] Comments handling cleanup
by Tony Lambregts 25 Jun '06

25 Jun '06

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 25 Jun '06

25 Jun '06

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 25 Jun '06

25 Jun '06

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 25 Jun '06

25 Jun '06

> 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 25 Jun '06

25 Jun '06

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 25 Jun '06

25 Jun '06

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

How do I get the unix filename for a wine handle?
by Christoph Probst 24 Jun '06

24 Jun '06

Hi, I'm one of the Google Summer of Code students and I'm working on the ClamAV integration in wine. Today I was discussing an issue with my mentor and he suggested to post it here. Currently I'm working on a scan-after-write functionality: Whenever a file was changed the virusscanner checks the file. My plan is to hook in NtWriteFile() (dlls/ntdll/file.c), because whenever a windows program writes to a file this function is called. Within this function the file is accessed using its unix_handle. The problem is that I need to know the unix filename for clamAV to access the file, but I see no proper way or function to get it as long as I just know the unix_handle or fd. Possible solutions so far: 1. searching /proc/self/fd/%d for the name. This would be an easy but very ugly solution. 2. maintaining a table mapping unix_handles to filenames from within NtCreateFile(). Hence I don't have the feeling that this is a good solution. 3. storing the unix filename in the wineserver handle object when it's created. This is probably the right place to keep this information but it would require some changes to the wineserver. If I understand it right it is already planned to implement something like this ("lookup_name" in server/object.c) But maybe I just missed an even better approach. What would you recommend to do? Any comment is appreciated. Cheers, Chris -- Kontakt-Details: http://www.christoph-probst.com/kontakt/ PGP-FP: B171 7EA4 988C DD90 1601 D21C 5279 2FAF 9978 AF86

5 8

Re: setupapi: Fix SetupCloseInfFile when a NULL handle is given, with tests
by Joris Huizer 24 Jun '06

24 Jun '06

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 24 Jun '06

24 Jun '06

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 24 Jun '06

24 Jun '06

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

← Newer
1
...
7
8
9
10
11
12
13
...
36
Older →

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