January 2004 - Wine-devel - list.winehq.org

Re: Fix dashed/solid line in Postscript output
by Alexandre Julliard 21 Jan '04

21 Jan '04

Blake Leverett <bleverett(a)att.net> writes: > Index: dlls/wineps/ps.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/ps.c,v > retrieving revision 1.23 > diff -u -r1.23 ps.c > --- dlls/wineps/ps.c 8 Dec 2003 21:40:27 -0000 1.23 > +++ dlls/wineps/ps.c 16 Jan 2004 05:26:55 -0000 > @@ -508,6 +508,7 @@ > BOOL PSDRV_WriteSetPen(PSDRV_PDEVICE *physDev) > { > char buf[256]; > + static char *last_dash = NULL; You can't use a static variable here, this would need to be stored in the device structure. But it's probably easier to always set the dash style unconditionally. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine cvs notes and proposed keyboard detection fix.
by Dmitry Timoshkov 20 Jan '04

20 Jan '04

"Shane Shields" <locutusenterprises(a)softhome.net> wrote: > > There are two problems with current x11drv keyboard code: > > 1. Very likely that Turkish keyboard layout there is incorrect. > > AFAICT The Turkish keyboard layout is correct. X11 team tends to remove more than 2 characters per keysym. See /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more than 2 for some of them. Just do 'setxkbmap tr' and run Wine with +key,keyboard,+x11drv and look for mismatches. > The original code doesnt get as > far as looking at the turkish definition. From what I could determine it > stopped searching when it got a wrong keysymb and if that combination > satisfied the selection that keyboard was chosen. That shouldn't happen. Keyboard detection code always does a full round of comparisons with every keyboard table in x11drv. > It didnt matter if it was > the right keyboard or not. This was not completely verified through testing > as I only have one keyboard :) > > 2. As stated before the keyboard code should be fixed to take into account > > the real keyboard layout while building the keyc2vkey map, not the > > hardcoded one. > > That would be a more elegant and portable fix. How do the other programs do it > (read window managers)? Other programs have no constrains implied by implementing Win32 APIs on the top of X11. -- Dmitry.

3 3

shell32 patch 10
by Martin Fuchs 20 Jan '04

20 Jan '04

Changelog: - implemented SHGetRealIDL() Index: pidl.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/pidl.c,v retrieving revision 1.96 diff -u -p -d -r1.96 pidl.c --- pidl.c 18 Jan 2004 22:08:46 -0000 1.96 +++ pidl.c 20 Jan 2004 21:32:24 -0000 @@ -688,6 +688,7 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL /* TRACE(pidl,"--new pidl=%p\n",pidlNew);*/ return pidlNew; } + /************************************************************************* * SHGetRealIDL [SHELL32.98] * @@ -695,10 +696,37 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL */ HRESULT WINAPI SHGetRealIDL(LPSHELLFOLDER lpsf, LPCITEMIDLIST pidlSimple, LPITEMIDLIST *pidlReal) { - FIXME("sf=%p pidlSimple=%p pidlReal=%p\n", lpsf, pidlSimple, pidlReal); + UINT cfShellIDList = RegisterClipboardFormatA(CFSTR_SHELLIDLIST); - pdump (pidlSimple); - return 0; + STGMEDIUM medium = {0, {0}, 0}; + FORMATETC fmt = {cfShellIDList, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL}; + + IDataObject* pDataObj; + HRESULT hr = IShellFolder_GetUIObjectOf(lpsf, 0, 1, &pidlSimple, &IID_IDataObject, 0, (LPVOID*)&pDataObj); + + if (SUCCEEDED(hr)) { + hr = IDataObject_GetData(pDataObj, &fmt, &medium); + + IDataObject_Release(pDataObj); + + if (SUCCEEDED(hr)) { + /*assert(pida->cidl==1);*/ + LPIDA pida = (LPIDA)GlobalLock(medium.hGlobal); + + LPCITEMIDLIST pidl_folder = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[0]); + LPCITEMIDLIST pidl_child = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[1]); + + *pidlReal = ILCombine(pidl_folder, pidl_child); + + if (!*pidlReal) + hr = E_OUTOFMEMORY; + + GlobalUnlock(medium.hGlobal); + GlobalFree(medium.hGlobal); + } + } + + return hr; } /*************************************************************************

1 0

Re: DPA_Create/Search may be missing
by Alexandre Julliard 20 Jan '04

20 Jan '04

Francois Gouget <fgouget(a)free.fr> writes: > On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry > points for DPA_Create and DPA_Search. So we need to link them > dynamically if we want the rest of the tests to run. What version of comctl32 is that? -- Alexandre Julliard julliard(a)winehq.com

7 18

Re: Oleaut32 tests fail
by Jon Griffiths 20 Jan '04

20 Jan '04

Hi, >Running the oleaut32 tests shows that vartype and vartest are >failing. >Has someone an idea about these ? Your (presumably early) version of oleaut32.dll doesn't support the VT_DECIMAL type. I'll update the tests shortly. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

2 2

Unicode and CP_SYMBOL question.
by Rein Klazes 20 Jan '04

20 Jan '04

Hi, Trying to fix a problem with Win2K's charmap.exe, I have a question for the unicode experts. If I convert character code's 32 to 255 using codepage SYMBOL on a Win2K system, like in this snippet: char c;WCHAR w; for( c = 32; c; c++) MultiByteToWideChar(CP_SYMBOL,0,&c,1,&w,1); I get that w == c + 0xf000 ( codes 0-31 are unchanged, any flag setting makes the function fail). Wine's implementation of MultiByteToWideChar() does something quite complicated based on standard unicode tables and returns Unicode characters in all kind of ranges. The loop above is basically what Win2K's charmap.exe does. Of course it does not properly display symbol fonts like "Symbol". Is there any reason why in this case MultiByteToWideChar should not do w = c + 0xf000 ? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 5

Re: Need help debugging ... Ddraw issue
by Jason Edmeades 19 Jan '04

19 Jan '04

Andreas Rosenberg: >If somebody could provide me the problematic exe of DK and the address >where the crash occurs I will put it through IDA pro. This might help lifting the >mystery. If IDA pro detects which compiler suite has been used to link the EXE, >it should be "easy" to detect where the string came from http://ftp.sunet.se/pub/pc/games/pcgameworld/demos/dkdemo.zip Unzip it, run KDDATA -d, and keeper95 is the executable From my notes (I dont have Linux to hand just now): Trap occurs ar 0x43d4e2 At this point in time the path/exe is in 0x552150 On windows: This was copied from 0x12fe20 (Was already filled in at a breakpoint at 0x43d4ba) which in turn came from 0x141ee0 when the pgm is very first loaded (windbg or msdev prior to executing any code). Jason

3 2

Re: Typo fix in type names
by Peter Hunnisett 19 Jan '04

19 Jan '04

They are correct as is and yes MS makes spelling mistakes. Francois Gouget wrote: >In dlls/dplayx/lobbysp.h I found types and a field with a typo: > SPDATA_BUILDPARENTALHEIRARCHY > LPSPDATA_BUILDPARENTALHEIRARCHY > LPSP_BUILDPARENTALHEIRARCHY > BuildParentalHeirarchy > >I checked in the latest Microsoft SDK and in the DirectX 9.0a SDK and >couldn't find any type with a spelling of 'HEIRARCHY'. I also searched >on Google and could not find them here either. However I did not find >these types with the correct spelling either. > >That may be because these are internal types (they are defined in an >internal header after all), or because they are badly documented. > > This is the case. They're from a not really often distributed SDK. Ciao, Peter

3 2

Re: Fix dplayx initialisation
by Alexandre Julliard 19 Jan '04

19 Jan '04

Sylvain Petreolle <spetreolle(a)yahoo.fr> writes: > Trying to load dplayx returns error 487 (ERROR_INVALID_ADDRESS) for > now. > > The following change lets wine determine a memory space by itself. This won't work, the code needs the address to be the same in all processes. This has to be fixed first. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: readme 2
by Alexandre Julliard 19 Jan '04

19 Jan '04

"Ivan Leo Murray-Smith" <puoti(a)inwind.it> writes: > OK, it uses winehq.org this time, and hopefully doesn't mess up the readme.fr There's no reason to change these URLs at all, the existing ones work just fine. -- Alexandre Julliard julliard(a)winehq.com

1 0