January 2010 - Wine-Devel - list.winehq.org

Re: ntoskrnl: Implement ExSystemTimeToLocalTime and ExLocalTimeToSystemTime
by Alexandre Julliard Jan. 14, 2010

Jan. 14, 2010

Erich Hoover <ehoover(a)mines.edu> writes: > Real Name: > Erich Hoover > Description: > The attached patch implements ExSystemTimeToLocalTime and > ExLocalTimeToSystemTime (Bug #19395), which are necessary to allow the > Sentinel Protection service to load (the Sentinel Protection service > is required by the full version of ZEMAX). Without the patch the > service will crash every time Wine loads, slowing down the launching > of all applications. > Changelog: > ntoskrnl: Implement ExSystemTimeToLocalTime and ExLocalTimeToSystemTime. You most likely want to use RtlSystemTimeToLocalTime etc. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] Implement OleCreatePropertyFrame (try 2)
by Geoffrey Hausheer Jan. 14, 2010

Jan. 14, 2010

On Wed, Jan 13, 2010 at 10:38 PM, Piotr Caban wrote: > Hi, > > There're still some things that needs to be changed. Thank you for the continued feedback. > > In pixels_to_dialog_units: > + *basex = ((float)size.cx/26+1)/2; > > + *x_pixels = MulDiv(*x_pixels, 4, *basex); > I proposed doing the computations on floats so the dialog size is more > accurate. If it was working for you correctly than it's probably better > to keep it the way I proposed. The cast in the patch you've sent doesn't > change anything. > If there are reasons to make the computations on integers it's better to > use GdiGetCharDimensions function. My understanding is that your method is to get the average font width. I have no idea if that is similar to how MapDialogRect works, so I have no idea if it more correct or not. So I haven't any idea if the accuracy of using float is really more accurate with respect to Windows or not. Looking through the dialog code in user32, GetDialogBaseUnits just returns the value of GdiGetCharDimensions (which isn't right here), so I don't see a better way than to use a heuristic. > > I think that pixels_to_dialog_units function should be deleted and it's > code move to OleCreatePropertyFrameIndirect. It was originally meant to implement the inverse of MapDialogRect. Now that it is precomputing the base units, it probably doesn't make sense in its current form. > > + /* This was expected to work but didn't: > + * LONG baseunits = GetDialogBaseUnits(); > + * basex = LOWORD(baseunits); > + * basey = HIWORD(baseunits); > + */ > This comment is not correct. GetDialogBaseUnits is somehow strange and > should be avoided. The comment is correct in that it is how MSDN says it should work, but it obviously doesn't. I think it is valuable to make it clear that there is a reason for the heuristic. > > About PropertyPageSite interface: > You have implemented AddRef and Release functions but you don't really > care about reference counter. The object should be freed when the > counter reaches 0. Well, I didn't implement proper COM objects because I didn't see the need. Memory is allocated and freed in OlePropertyFrameIndirect. But COM objects must present AddRef/Release functions, so I have them. Is the preference here to build the proper COM object and allocate/free individually, or can I implement the AddRef/Release functions as stubs (which is basically what they are now) > > +typedef struct { > + struct { > + DLGTEMPLATE dlg; > + WORD menu; > + WORD class; > + WORD caption; > + WORD font; > + } dialog; > + OLEPropertyPageSite pps; > + IPropertyPage *propPage; > +} OLEPropertyFrame; > You don't need font field. But I do need the WORD to be present, as MSDN clearly states that you must reserve 4 WORDS after the DLGTEMPLATE. Since its general use is for 'font' I figured I'd name it properly. If it is really bothersome, I could call it 'reserved' or something equivalent. I probably won't get to this for several days. My development computer will be out of commission for a while. Thanks again, .Geoff

1 0

Patch: bug 19355, Wine web site, link to the previous version announcement in section "changes since"
by Vincent Cadet Jan. 14, 2010

Jan. 14, 2010

Hi peoople. A couple of months ago, I submitted a patch I wrote to add a backlink to the previous version in WineHQ announcement page. As it has still no been applied I am sending it again here. It actually adds a few (6) lines of PHP code to the web site's template, include/plugins/announce.php . I ahve also submitted this patch into WineHQ bugzilla ( http://bugs.winehq.org/show_bug.cgi?id=19355 ). May I ask for comments about this patch? Thanks a lot in advance, Vince C.

3 4

Re: Wine AppDB xmlexport script
by Austin English Jan. 14, 2010

Jan. 14, 2010

On Tue, Jan 12, 2010 at 8:17 AM, John Brezerk <brezerk(a)gmail.com> wrote: > Hi to All. > > I'd like to present php scripts ( attached xmlexport.tar.gz ) which make > possible for third party applications to query appdb database. > After processing user requests, script generates xml view. > Originally this script was created for q4wine ( > http://q4wine.brezblock.org.ua/ ) project. Neat! There's been talk about doing something like this for a while, but no one's taken the initiative to do it. However, I don't think you'll have much luck getting it in the AppDB's source repository, without having a discussion on wine-devel about it first. > It's licese is GPL v3. Is there any chance of a different license? Wine is currently LGPL 2.1, it'd be nice to have the same license, if possible... -- -Austin

5 4

Re: [PATCH] Implement OleCreatePropertyFrame (try 2)
by Piotr Caban Jan. 14, 2010

Jan. 14, 2010

Hi, There're still some things that needs to be changed. In prop_sheet_proc: + case WM_DESTROY: + { + OLEPropertyFrame *opf = (OLEPropertyFrame *)GetWindowLongPtrW(hwnd, DWLP_USER); + if(opf) { + IPropertyPage_Show(opf->propPage, SW_HIDE); + IPropertyPage_Deactivate(opf->propPage); + SetWindowLongPtrW(hwnd, DWLP_USER, (LONG)NULL); + } + } there's no break/return In pixels_to_dialog_units: + *basex = ((float)size.cx/26+1)/2; + *x_pixels = MulDiv(*x_pixels, 4, *basex); I proposed doing the computations on floats so the dialog size is more accurate. If it was working for you correctly than it's probably better to keep it the way I proposed. The cast in the patch you've sent doesn't change anything. If there are reasons to make the computations on integers it's better to use GdiGetCharDimensions function. I think that pixels_to_dialog_units function should be deleted and it's code move to OleCreatePropertyFrameIndirect. + /* This was expected to work but didn't: + * LONG baseunits = GetDialogBaseUnits(); + * basex = LOWORD(baseunits); + * basey = HIWORD(baseunits); + */ This comment is not correct. GetDialogBaseUnits is somehow strange and should be avoided. About PropertyPageSite interface: You have implemented AddRef and Release functions but you don't really care about reference counter. The object should be freed when the counter reaches 0. +typedef struct { + struct { + DLGTEMPLATE dlg; + WORD menu; + WORD class; + WORD caption; + WORD font; + } dialog; + OLEPropertyPageSite pps; + IPropertyPage *propPage; +} OLEPropertyFrame; You don't need font field. Cheers, Piotr

1 0

Re: gdi32: Use the LOGFONT charset field on OEM font creation
by Ilya Shpigor Jan. 13, 2010

Jan. 13, 2010

Hi, Is this patch incorrect or more tests are needed? Dmitry said that there are needed additional tests, but you wouldn't like to commit these. Please explain my mistakes. -- Best regards, Ilya Shpigor.

1 0

Re: wineoss.drv: Ignore volume settings on primary buffer
by Michael Stefaniuc Jan. 13, 2010

Jan. 13, 2010

Maarten, Maarten Lankhorst wrote: > dsound shouldn't be able to mess with the system-wide volume if this is a deliberate design decision then the FIXME("stub") is wrong. It needs to be replaced by a TRACE (or WARN if you insist) with a message like: "Explicitly ignoring wodSetVolume request; dsound shouldn't mess with the system-wide volume". > Fixes bug 15710 and makes the bsd's happier > --- > --- a/dlls/wineoss.drv/dsrender.c > +++ b/dlls/wineoss.drv/dsrender.c > @@ -533,14 +533,7 @@ static HRESULT WINAPI IDsDriverBufferImpl_SetVolumePan(PIDSDRIVERBUFFER iface, P > { > DWORD vol; > IDsDriverBufferImpl *This = (IDsDriverBufferImpl *)iface; > - TRACE("(%p,%p)\n",This,pVolPan); > - > - vol = pVolPan->dwTotalLeftAmpFactor | (pVolPan->dwTotalRightAmpFactor << 16); > - > - if (wodSetVolume(This->drv->wDevID, vol) != MMSYSERR_NOERROR) { > - WARN("wodSetVolume failed\n"); > - return DSERR_INVALIDPARAM; > - } > + FIXME("(%p,%p) stub\n",This,pVolPan); > > return DS_OK; > } thanks bye michael

1 0

Re: [rsaenh/tests] Don't check result twice (Coccinelle)
by Michael Stefaniuc Jan. 13, 2010

Jan. 13, 2010

Hi Paul, Paul Vriens wrote: > We already check and return FALSE a few lines up. > > Found with the help of Coccinelle and the CocciCheck scripts. > > Changelog > Don't check result twice (Coccinelle) > --- a/dlls/rsaenh/tests/rsaenh.c +++ b/dlls/rsaenh/tests/rsaenh.c @@ -275,7 +275,6 @@ static BOOL derive_key(ALG_ID aiAlgid, HCRYPTKEY *phKey, DWORD len) return FALSE; } ok(result, "%08x\n", GetLastError()); - if (!result) return FALSE; result = CryptHashData(hHash, pbData, sizeof(pbData), 0); ok(result, "%08x\n", GetLastError()); if (!result) return FALSE; that is not the same "result"; it gets a new value after the first "return FALSE". bye michael

3 5

Re: [PATCH 3/4] msxml3/xmldoc: IPersistStreamInit::InitNew() seems to do nothing for IXMLDocument
by Alistair Leslie-Hughes Jan. 12, 2010

Jan. 12, 2010

On 13/01/2010 1:41 AM, Nikolay Sivov wrote: > IPersistStreamInit::InitNew() seems to do nothing for IXMLDocument > > > + hr = IPersistStreamInit_IsDirty(psi); > + todo_wine ok(hr == S_FALSE, "Expected S_OK, got %08x\n", hr); The message doesn't match the condition. Best Regards Alistair Leslie-Hughes

2 1

Re: installation problem with yesterday's git - NEVERMIND
by Susan Cragin Jan. 12, 2010

Jan. 12, 2010

Somehow, the 4th time was a charm. Must be me? -----Original Message----- >I'm having an installation problem with yesterday's git. >err:msi:ITERATE_Actions Execution halted, action L"InstallSpeechAPI" returned 1627 >err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1627 > >Bug? >Regression test? >anyone want to see my whole terminal output?

1 0