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

Re: [MinGW-dvlpr] Mingw Wine port bug

by Earnie Boyd

Steven Edwards wrote: > > I'm getting multiple definintion errors when building > certain parts of wine under mingw. Anyone have a idea > for the solution? > -nostdlib? Just a WAG, you're mixing the import libs for Windows with Wine's export. Earnie.

June 14, 2002

Mingw Wine port bug

by Steven Edwards

I'm getting multiple definintion errors when building certain parts of wine under mingw. Anyone have a idea for the solution? Building Comdlg32.dll - ../../ole/libwine_uuid.a(uuid.o)(.text+0x9c0):uuid.c: multiple definition of `CL SID_ShellDesktop' D:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-7/../../../libshell32.a(shell32.o)(.t ext+0x0)://d/src/mingw/w32api/lib/shell32.c: first defined here ../../ole/libwine_uuid.a(uuid.o)(.text+0x9d0):uuid.c: multiple definition of `CL SID_ShellLink' D:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-7/../../../libshell32.a(shell32.o)(.t ext+0x10)://d/src/mingw/w32api/lib/shell32.c: first defined here ../../ole/libwine_uuid.a(uuid.o)(.text+0xa30):uuid.c: multiple definition of `FM TID_Intshcut' D:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-7/../../../libshell32.a(shell32.o)(.t ext+0x20)://d/src/mingw/w32api/lib/shell32.c: first defined here ../../ole/libwine_uuid.a(uuid.o)(.text+0xa40):uuid.c: multiple definition of `FM TID_InternetSite' D:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-7/../../../libshell32.a(shell32.o)(.t ext+0x30)://d/src/mingw/w32api/lib/shell32.c: first defined here ../../ole/libwine_uuid.a(uuid.o)(.text+0xa50):uuid.c: multiple definition of `CG ID_Explorer' D:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-7/../../../libshell32.a(shell32.o)(.t ext+0x40)://d/src/mingw/w32api/lib/shell32.c: first defined here ../../ole/libwine_uuid.a(uuid.o)(.text+0xa60):uuid.c: multiple definition of `CG ID_ShellDocView' D:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-7/../../../libshell32.a(shell32.o)(.t ext+0x50)://d/src/mingw/w32api/lib/shell32.c: first defined here ../../ole/libwine_uuid.a(uuid.o)(.text+0xa90):uuid.c: multiple definition of `II D_INewShortcutHookA' __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 14, 2002

Re: Merge rpcrt/ole32 from Rewind

by Jürgen Schmied

> > I started to merge this files in. This patches are done to a loder wine version so it does not merge in a clean way. Some code is allready implemented twice. > > So I do: > > - merge as far as I can > > - if a function is implemented twice I comment one implementation out but leave the code in (mainly the standard marshaler parts). I can't decide how to merge it. > > That's not a merge, that's just copying code around. If you don't know > how to merge that stuff properly, please leave it for someone else like > Marcus. No, the most things I can merge properly but I don't like to decide what implementation of the standard marshaler is better. I can copy Ove's one in a extra file and send it together with the patch so someone else (MM) can merge this part. > > - the final cleanup should be done by the ones who are familiar with that code (Marcus?) > > - any objections against the rpcrt4 stuff? Ove himself says its not very clean but we dont have any better code yet. > > I don't know, I haven't seen the patch, it seems the sourceforge > archives don't store large mails. Could you please forward it to me? I can send you the patch against the current tree (I've already merged it) a bit later. juergen --- juergen.schmied(a)debitel.net

June 14, 2002

Old unicode standard

by Shachar Shemesh

Hi all, I am trying to find any references to the old unicode standard. In particular, I need the Bidirectional algorythm used with ~unicode 1.0. If anyone can help, it would be greatly apretiated. If you don't have the 1.0 standard, but do have a later standard (but not 3.0, which is what is available on the unicode web site), that would probably be a great help too. Shachar

June 14, 2002

Re: WM_GETTEXTLENGTH returns double size

by Shachar Shemesh

Andriy Palamarchuk wrote: >Can you submit a bug for this? You can give better >information than I and add dependencies on othe bugs >about MBCS, BiDi, etc. (I guess this bug will be >assigned to you as the component owner ;-) >Can you also make it depend on bug 791? > > Submitted http://bugs.winehq.com/show_bug.cgi?id=794 Marked that this bug depends on 791 (which was already resolved at the time of submitting my bug, but I figured that we better transfer our knowledge into the system). What say you about placing a FIXME inside that case, so we tell the user we are merely guessing here? Shachar

June 14, 2002

Re: ole help please! invoke fn issue

by us＠the-edmeades.demon.co.uk

marcus(a)jet.franken.de wrote: > Actually I think just the DATE part should be out there, which is 8 byte > long. I'm not convinced. The following tracepoint: trace:ole:ITypeInfo_fnInvoke set 0 to disparg type 7 vs 12 This shows that the arg 0 was supplied by the application as a VT_DATE but the function itself wants a VT_VARIANT. I have found whatever is the first word on the stack is later passed into another variant function as the vt type field. Putting the whole variant onto the stack is the only way I have got beyond that function. If the function took a VT_DATE, you may well be correct. I think we need to change that code to memcpy onto the args storage the variant size (or sizeof DWORD, I guess as that is minimum size for an arg by the way we currently have it coded). If you agree, I'll have a go at doing a patch, although if you understand it better than me please (really - please!) feel free to code it for me. My 'hack' definitiely got me further through to the next point which is a bug in the oleaut32 vardate handling routines which I am currently hacking. My last change cause the app to crash the whole of Linux (no mouse, keyboard etc!). Rebooting now to try again... Oh I love having a few days off with nothing to do except fiddling with wine internals! Regards, Jason

June 14, 2002

Re: dlls/ddraw build problem

by Steven Edwards

> The structures we currently use are from the Win9x > DDK. But changing it to > use NT-compatible structures instead may not be that > hard, I don't know. We are just now working on Windowing for ReactOS so DirectX is not currently high my TODO list. I'm going to create a bug in bugzilla to make sure all HAL Structures are NT-compatable for DirectX and leave it at that. If someone wants to address it now thats cool, if not when we get to that point (yeah right) mabey the reactos project will submit patches for it. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 14, 2002

Re: Problems running IE with latest release

by Con Hennessy

Hi Won, Thank you very much for your detailed help. Here are some problems/comments I have on some of the stages : On Wednesday 12 June 2002 17:30, Won Kyu Park wrote: [snip] > I could IE 5.01 installation successfully with a fake_windows. > > step: > 1. make a fake_windows in the $HOME/.wine > http://chem.skku.ac.kr/~wkpark/kle/wine/dotwine/make_dotwine OK. > 2. install some ttf fonts($ wine NEWFNT32.exe;wine corfnt32.exe) > wget ftp://ftp.microsoft.com/developr/drg/TrueType/NEWFNT32.EXE I had many problems tryingto down load this file from the ftp servers but was eventually successful. > wget ftp://ftp.microsoft.com/developr/drg/TrueType/corfnt32.exe > 3. install dcom98.exe($ wine dcom98.exe) > wget http://download.microsoft.com/msdownload/dcom/98/x86/en/dcom98.exe > 4. install ie5setup.exe ($wine ie5setup.exe) > wget > http://download.microsoft.com/download/ie501sp2/Install/5.01_SP2/WIN98/EN-U >S/ie5setup.exe To access this you must go to http://download.microsoft.com/download and follow the various steps to get "IE5 service pack 2". Also while running this exe I got the following problem after successfully downloading all of the relevant ( 19MB !) files : err:win:WIN_FindWndPtr window 10021 belongs to other process err:win:WIN_FindWndPtr window 10021 belongs to other process The installation window briefly appeared ( did not contain anything ) and then disappeared! The 2 error messages seem to appear at the same time. The installation dialog boxes then indicates that nothing has been installed ( or more acurately it shows a long list of items which have not been installed ). What can I do now ? Thanks CP Hennessy > 5. delete .wine/fake_windows/Windows/WinInit.ini(?) > see Wininit.ini and you can find some instructions... > 6. run explorer.exe with following config; > (explorer.exe!! not iexplore.exe, you may copy it from some windows boxs) > i think.. when explorer.exe executed.. some registry entries are created > which iexplore.exe need. > > [AppDefaults\\explorer.exe\\x11drv] > "Managed"="N" > "Desktop"="800x600" > > [AppDefaults\\explorer.exe\\DllOverrides] > ;; > "gdi32" = "builtin" > "kernel32" = "builtin" > ;;"shell" = "native" > ;;"shell32" = "native" > ;;"commctl" = "native" > ;;"comctl32" = "native" > "shell" = "builtin" > "shell32" = "builtin" > "commctl" = "builtin" > "comctl32" = "builtin" > ; > "imm" = "builtin" > ;"ntdll" = "native" > "shdocvw" = "native" > "shlwapi" = "native" > "wininet" = "native" > "*" = "native, builtin" > > 7. run iexplore.exe !! > > [AppDefaults\\iexplore.exe\\DllOverrides] > ;; > "gdi32" = "builtin" > "kernel32" = "builtin" > ;;"shell" = "native" > ;;"shell32" = "native" > ;;"commctl" = "native" > ;;"comctl32" = "native" > "shell" = "builtin" > "shell32" = "builtin" > "commctl" = "builtin" > "comctl32" = "builtin" > "imm" = "builtin" > ;"ntdll" = "native" > "shdocvw" = "native" > "shlwapi" = "native" > "wininet" = "native" > "*" = "native, builtin" > > this is my screenshot. > http://chem.skku.ac.kr/~wkpark/screenshot/2002_06_12_215103_shot.png > (with "Windows"="win95") > http://chem.skku.ac.kr/~wkpark/screenshot/2002_06_12_230527_shot.png > (with "Windows"="win98")

June 13, 2002

Re: ole help please! invoke fn issue

by Marcus Meissner

On Thu, Jun 13, 2002 at 08:39:05PM +0100, Ann and Jason Edmeades wrote: > Hi all, > > Playing further with my VB program and native oleaut32 I've hit an > 'interesting issue' with the Microsoft Date/Time picker. > > typelib.c in dlls\oleaut32 assumes all parms are dwords and picks the lval > of a variant (which for most of the types of variant is the dword containing > the important information). However as shown by the following trace: > > trace:ole:ITypeInfo_fnInvoke > (0x404560ac)(0x40418fac,id=20,flags=0x00000004,0x405c5d84,(nil),0x405c5d64,0 > x405c5d94) partial stub! > trace:ole:dump_DispParms args=1 named args=1 > trace:ole:dump_Variant (0x405c5dec) > trace:ole:dump_Variant VARTYPE: VT_DATE > This shows that the function takes one parm and that parm is a variant. We > pass the value contained in the parm and it fails. We need to ensure the > whole variant is put on the stack for the called function. Since we > currently only call with dword parms this wont work. Actually I think just the DATE part should be out there, which is 8 byte long. > This hack takes the parm and puts the variant into that arg and subsequent > ones, meaning the stack to the called function should look as it would be. > Unfortunately as it stands this would only work with one parm, so my > question is how it is supposed to be fixed. I could potentially change > args[i+1] to args[numArgWords+1] but it still feels very hacky. No, just reuse _argsize() from tmarshal.c, calculate the number of stack positions using this function, allocate enough space, memcpy() out of the VARIANTS into the stack space and invoke. (I have submitted a patch to tmarshal.c). Looking at the code in there ... I think I have to have another, closer look at it :/ Ciao, Marcus

June 13, 2002

Re: Repeated: Breakage in -relay and -snoop

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Did I miss some announcement :-) There was a patch on wine-cvs ;-) > B.t.w. what is the reason about all those commandline options vanishing into > the config file? It makes changes inflexible at least... The basic reason is modularity; centralized option handling is incompatible with dll separation. Also command-line parsing is policy that belongs in the higher layers, we must not have kernel dictate applications what their command-line looks like. For instance today you cannot pass options to a Winelib app without using '--' first to isolate the Wine options and this is wrong. It would be perfectly possible to write a high-level wrapper to Wine to handle all sorts of options; all we need is someone to implement it... -- Alexandre Julliard julliard(a)winehq.com

June 13, 2002

Re: dlls/ddraw build problem

by Ove Kaaven

On Thu, 13 Jun 2002, Steven Edwards wrote: > > But never fear, I'm actually currently working on > > making more proper use > > of the DirectDraw HAL. This would let the x11drv HAL > > itself create the > > special DIB sections it needs, rather than having > > the ddraw.dll call this > > nonstandard entry point. I was planning to submit it > > to rewind when I was > > done (will take another week or so depending on my > > workload). > > Are you going to be CC'ing wine-patches on your rewind > merges or is it going to be each maintainer job to > check ReWind to keep both trees in sync? Since such patches would probably not apply unmodified to Wine anyway, it would probably be the job of someone inclined to merge this stuff to subscribe to rewind-patches (and/or rewind-cvs). > > Unfortunately, it's still going to be kinda unlikely > > to work on real > > Windoze (the NT/2000 HAL is different from the win95 > > HAL, and we use the > > win95 HAL structures with the 16-bit parts treated > > like 32-bit parts, so > > it isn't compatible with anything) > > Gav said something at Wineconf about WineX using the > HAL interfaces you guys could port to ReactOS. We > assumed he meant NT/2K HAL. The structures we currently use are from the Win9x DDK. But changing it to use NT-compatible structures instead may not be that hard, I don't know. > Is this only true for certain parts of WineX/ReWind or whats the deal? I'm not sure I understand the question. Each DirectX component has its own completely independent HAL. (At least they used to... I haven't checked if this is still the case in WDM, but each component has obviously radically different requirements, so I'd guess so.) > I dont even remeber now what parts of DirectX he was discussing at the > time so it might not be releated to this discussion. He was mostly talking about Direct3D, I think.

June 13, 2002

Re: Repeated: Breakage in -relay and -snoop

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> since last week, e.g a commandline like "wine <xxx> --debugmsg >> -relay=RtlEnterCriticalSection" inhibits _any_ relay message to be >> logged. Alexandre> Specifying relay functions on the command-line is no longer Alexandre> supported. You have to put them in the config file. Did I miss some announcement :-) B.t.w. what is the reason about all those commandline options vanishing into the config file? It makes changes inflexible at least... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 13, 2002

Re: Repeated: Breakage in -relay and -snoop

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > since last week, e.g a commandline like "wine <xxx> --debugmsg > -relay=RtlEnterCriticalSection" inhibits _any_ relay message to be logged. Specifying relay functions on the command-line is no longer supported. You have to put them in the config file. -- Alexandre Julliard julliard(a)winehq.com

June 13, 2002

Re: Repeated: Breakage in -relay and -snoop

by Andriy Palamarchuk

--- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > since last week, e.g a commandline like "wine <xxx> > --debugmsg > -relay=RtlEnterCriticalSection" inhibits _any_ relay > message to be logged. Great! It would be convenient to have this option on by default. So we do not have to tell ppl to use this option before they send logs to us. For precation we can show status of the debugging options in the beginning of the debugging output. What do you think? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 13, 2002

Re: dlls/ddraw build problem

by Steven Edwards

> But never fear, I'm actually currently working on > making more proper use > of the DirectDraw HAL. This would let the x11drv HAL > itself create the > special DIB sections it needs, rather than having > the ddraw.dll call this > nonstandard entry point. I was planning to submit it > to rewind when I was > done (will take another week or so depending on my > workload). Are you going to be CC'ing wine-patches on your rewind merges or is it going to be each maintainer job to check ReWind to keep both trees in sync? > Unfortunately, it's still going to be kinda unlikely > to work on real > Windoze (the NT/2000 HAL is different from the win95 > HAL, and we use the > win95 HAL structures with the 16-bit parts treated > like 32-bit parts, so > it isn't compatible with anything) Gav said something at Wineconf about WineX using the HAL interfaces you guys could port to ReactOS. We assumed he meant NT/2K HAL. Is this only true for certain parts of WineX/ReWind or whats the deal? I dont even remeber now what parts of DirectX he was discussing at the time so it might not be releated to this discussion. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 13, 2002

Re: WM_GETTEXTLENGTH returns double size

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > Just refreshed Wine and tested. Still see the bug. > You > > can check it yourself using the test case in the > bug: > > http://bugs.winehq.com/show_bug.cgi?id=791 > > Seems to work just fine here. Are you sure you > updated your tree > properly? Yes, it works now for me. I fixed screwed time on my machine after the CVS update and did not bother to update CVS one more time. Thanks! Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 13, 2002

Repeated: Breakage in -relay and -snoop

by Uwe Bonnes

Hallo, since last week, e.g a commandline like "wine <xxx> --debugmsg -relay=RtlEnterCriticalSection" inhibits _any_ relay message to be logged. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 13, 2002

Re: WM_GETTEXTLENGTH returns double size

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Your patches fix the controls logic but not the > problem of mapping return values of WM_GETTEXTLENGTH > message from Unicode to ASCII. That's not a problem, that's the way it's supposed to work. > Just refreshed Wine and tested. Still see the bug. You > can check it yourself using the test case in the bug: > http://bugs.winehq.com/show_bug.cgi?id=791 Seems to work just fine here. Are you sure you updated your tree properly? -- Alexandre Julliard julliard(a)winehq.com

June 13, 2002

Re: Merge rpcrt/ole32 from Rewind

by Alexandre Julliard

juergen.schmied(a)debitel.net writes: > I started to merge this files in. This patches are done to a loder wine version so it does not merge in a clean way. Some code is allready implemented twice. > So I do: > - merge as far as I can > - if a function is implemented twice I comment one implementation out but leave the code in (mainly the standard marshaler parts). I can't decide how to merge it. That's not a merge, that's just copying code around. If you don't know how to merge that stuff properly, please leave it for someone else like Marcus. > - the final cleanup should be done by the ones who are familiar with that code (Marcus?) > - any objections against the rpcrt4 stuff? Ove himself says its not very clean but we dont have any better code yet. I don't know, I haven't seen the patch, it seems the sourceforge archives don't store large mails. Could you please forward it to me? -- Alexandre Julliard julliard(a)winehq.com

June 13, 2002

Re: WM_GETTEXTLENGTH returns double size

by Andriy Palamarchuk

Alexandre, --- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > The best approach I could think of is to send an > > internal message from this location which returns > > lengths of Unicode and ASCII strings. This message > > will be processed only by our controls. > > If lengths of the Unicode strings are the same > this > > means that both are generated by our code for the > same > > text and I return the A length. If the lengths are > > different this means length was generated not in > our > > code and I keep existing behavior (return double > > original Unicode length). > > Actually our code should never have that problem > because we have both > ASCII and Unicode winprocs for all controls. But > there were a few > ASCII/Unicode mismatches in the combobox, I believe > it should be fixed > now. Your patches fix the controls logic but not the problem of mapping return values of WM_GETTEXTLENGTH message from Unicode to ASCII. Just refreshed Wine and tested. Still see the bug. You can check it yourself using the test case in the bug: http://bugs.winehq.com/show_bug.cgi?id=791 Comment out the mentioned code snippet and it works. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 13, 2002

winedbg debugging

by Ann and Jason Edmeades

I am using winedbg and find it really annoying the 'display' option. I put a break point in a routine and use display varName to ensure I can see the variable everytime we hit the breakpoint. This works nicely until the program happens upon a RaiseException, and this variable is no longer in scope. This traps and goes into gdb. I quit gbd, wine traps again and invokes gdb until I end up using killall wine to proceed. Is there any way to avoid this or at leat put and exception handler around the display handling? Jason PS Why dont the up/down arrows work to recall commands? PgUp/PgDn do!

June 13, 2002

ole help please! invoke fn issue

by Ann and Jason Edmeades

Hi all, Playing further with my VB program and native oleaut32 I've hit an 'interesting issue' with the Microsoft Date/Time picker. typelib.c in dlls\oleaut32 assumes all parms are dwords and picks the lval of a variant (which for most of the types of variant is the dword containing the important information). However as shown by the following trace: trace:ole:ITypeInfo_fnInvoke (0x404560ac)(0x40418fac,id=20,flags=0x00000004,0x405c5d84,(nil),0x405c5d64,0 x405c5d94) partial stub! trace:ole:dump_DispParms args=1 named args=1 trace:ole:dump_Variant (0x405c5dec) trace:ole:dump_Variant VARTYPE: VT_DATE trace:ole:dump_Variant (?)-882854389 L"Value"(1) parm0: L"\00e5MSComCtl2WWW" memid is 00000014 Param 0: tdesc.vartype 12 (VT_VARIANT) u.parmadesc.flags 1 u.parmadesc.lpex (nil) funckind: 1 (pure virtual) invkind: 4 (property put) callconv: 4 (stdcall) oVft: 224 cParamsOpt: 0 wFlags: 3c helpstring: L"Returns/sets the current date." entry: (null) 08072560:Call ntdll.RtlAllocateHeap(40370000,00000000,00000008) ret=408bfcc3 08072560:Ret ntdll.RtlAllocateHeap() retval=4041a160 ret=408bfcc3 08072560:Call ntdll.RtlAllocateHeap(40370000,00000008,00000004) ret=408bfce4 08072560:Ret ntdll.RtlAllocateHeap() retval=4041a180 ret=408bfce4 trace:ole:ITypeInfo_fnInvoke set 0 to disparg type 7 vs 12 This shows that the function takes one parm and that parm is a variant. We pass the value contained in the parm and it fails. We need to ensure the whole variant is put on the stack for the called function. Since we currently only call with dword parms this wont work. I have managed to get further by a dirty hack: DWORD numArgWords = 0; args[0] = (DWORD)pIUnk; for (i=0;i<pFDesc->funcdesc.cParams;i++) { if (i<pDispParams->cArgs) { TRACE("set %d to disparg type %d vs %d\n",i, V_VT(&pDispParams->rgvarg[pDispParams->cArgs-i-1]), pFDesc->funcdesc.lprgelemdescParam[i].tdesc.vt ); if (pFDesc->funcdesc.lprgelemdescParam[i].tdesc.vt != VT_VARIANT) { args[i+1] = V_UNION(&pDispParams->rgvarg[pDispParams->cArgs-i-1],lVal); numArgWords = numArgWords+1; } else { TRACE("Faking variant on stack as more args \n"); memcpy(&args[i+1], &pDispParams->rgvarg[pDispParams->cArgs-i-1], sizeof(VARIANT)); numArgWords = numArgWords + sizeof(VARIANT)/4; } } else { TYPEDESC *tdesc = &(pFDesc->funcdesc.lprgelemdescParam[i].tdesc); TRACE("set %d to pointer for get (type is %d)\n",i,tdesc->vt); /*FIXME: give pointers for the rest, so propertyget works*/ args[i+1] = (DWORD)&args2[i]; numArgWords = numArgWords+1; /* If pointer to variant, pass reference to variant * in result variant array. */ if ((tdesc->vt == VT_PTR) && (tdesc->u.lptdesc->vt == VT_VARIANT) && pVarResult ) args[i+1] = (DWORD)(pVarResult+(i-pDispParams->cArgs)); } } TRACE("_invoke with %ld args\n", numArgWords+1); res = _invoke((*(DWORD***)pIUnk)[pFDesc->funcdesc.oVft/4], pFDesc->funcdesc.callconv, numArgWords+1, args ); This hack takes the parm and puts the variant into that arg and subsequent ones, meaning the stack to the called function should look as it would be. Unfortunately as it stands this would only work with one parm, so my question is how it is supposed to be fixed. I could potentially change args[i+1] to args[numArgWords+1] but it still feels very hacky. If I have been ignorant of something please bear with me - I've never touched com programming before! Regards, Jason

June 13, 2002

Re: WM_GETTEXTLENGTH returns double size

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > The best approach I could think of is to send an > internal message from this location which returns > lengths of Unicode and ASCII strings. This message > will be processed only by our controls. > If lengths of the Unicode strings are the same this > means that both are generated by our code for the same > text and I return the A length. If the lengths are > different this means length was generated not in our > code and I keep existing behavior (return double > original Unicode length). Actually our code should never have that problem because we have both ASCII and Unicode winprocs for all controls. But there were a few ASCII/Unicode mismatches in the combobox, I believe it should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

June 13, 2002

Re: dlls/ddraw build problem

by Ove Kaaven

On Wed, 12 Jun 2002, Steven Edwards wrote: > Hola, > While everyone is looking at the new directx stuff can > someone check and see if there is a easy way to fix > this? > > dsurface/dib.o(.text+0x38a):dib.c: undefined reference > to `DIB_CreateDIBSection' No, I think this is actually the reason ddraw hasn't been properly DLL-separated in Wine proper yet - there's no easy fix (except for "major breakage is OK"-style fixes). But never fear, I'm actually currently working on making more proper use of the DirectDraw HAL. This would let the x11drv HAL itself create the special DIB sections it needs, rather than having the ddraw.dll call this nonstandard entry point. I was planning to submit it to rewind when I was done (will take another week or so depending on my workload). Unfortunately, it's still going to be kinda unlikely to work on real Windoze (the NT/2000 HAL is different from the win95 HAL, and we use the win95 HAL structures with the 16-bit parts treated like 32-bit parts, so it isn't compatible with anything) > >From the changelog on 2000-04-29 Ove implemented this > in graphics/x11drv/dib.c, include/bitmap.h, > include/gdi.h, include/x11drv.h, objects/dib.c. > I havent had time to look at the new DIB engine > patches from transgamming to see if they could fix > this, so if they do then please send this email to > /dev/null. No, this has nothing to do with the DIB engine.

June 13, 2002

Re: WM_GETTEXTLENGTH returns double size

by Andriy Palamarchuk

--- Shachar Shemesh <wine-devel(a)sun.consumer.org.il> wrote: [skipped] > I don't mind receiving ownership over all > non-western languages, as I > speak a BiDi language, and have experience in > programming for an MBCS > language (and between the two you are almost cover > the entire range of > problematic languages), but that does not mean that > the two are, in any > way, related. Hidenori Takeshima did a lot of work with MBCS (this is why I'm CCing him the thread), Dimitry Timoshkov has big experience with internationalization issues. To clear my position - having a bug assigned to you does not mean you are required to work on it. I already assigned this issue to myself. > BTW, bringing us to the "ownership" issue. Is wine > going to have a > "Credits" file, sorted by lines of code submitted or > similar criteria? I do not like idea of having such "official" list, like we have list of authors now. Contribution is a gift. One appreciates gifts not basing on their price tag. However, I do not see anything wrong against creating such a list to satisfy curiosity. > It would be nice to have my name there in case I am > ever fired for > answering WINE emails while at work ;-). Do not worry, after you are fired you'll have some time to create a script to parse archive of wine-cvs mailing list and generate this information ;-) Changelog, wine-devel can also tell a lot about your work. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 13, 2002