- Wine-Devel - list.winehq.org

Re: WPP: Fixed 'out of tree' compilation
by Alexandre Julliard Jan. 6, 2005

Jan. 6, 2005

Jacek Caban <jack(a)itma.pwr.wroc.pl> writes: > --- libs/wpp/ppy.y 1 May 2003 03:16:21 -0000 1.1 > +++ libs/wpp/ppy.y 30 Dec 2004 10:11:39 -0000 > @@ -537,7 +537,10 @@ static int boolean(cval_t *v) > static marg_t *new_marg(char *str, def_arg_t type) > { > marg_t *ma = pp_xmalloc(sizeof(marg_t)); > - ma->arg = str; > + if(str) > + ma->arg = pp_xstrdup(str); > + else > + ma->arg = NULL; > ma->type = type; > ma->nnl = 0; > return ma; > @@ -569,7 +572,7 @@ static mtext_t *new_mtext(char *str, int > if(str == NULL) > mt->subst.argidx = idx; > else > - mt->subst.text = str; > + mt->subst.text = pp_xstrdup(str); AFAICS the string is already duplicated everywhere these functions are called, so you are adding a memory leak here. Does this patch really make a difference in the behavior? -- Alexandre Julliard julliard(a)winehq.org

3 4

DCOM roadmap
by Mike Hearn Jan. 6, 2005

Jan. 6, 2005

I thought I'd post an update on where Rob and I are up to, and where we're going. This is the plan that I have in my head, Rob may want to do things in a slightly different order etc so don't be surprised if we change some stuff around as a result of this email. We're currently reworking, extending and in some cases rewriting the code Marcus wrote originally to work more like native DCOM does. This means that new features and major improvements are *not* going to happen for a while, because before we can extend our support for DCOM we have to migrate to the same architecture that Microsoft use internally. This has several benefits: 1) It saves us design work, because MS already did it 2) It's the only way to be wire compatible in the long run 3) It means the documentation (like Essential COM etc) is already written Getting to a more native-style architecture has already been started, but won't be finished for a while. Here are the steps we need to take, the ones marked with a * are already done, - means they are still to do. - Replace the wine_marshal_id structure with [STD]OBJREF. This is necessary because the Microsoft internal interfaces like IOXIDResolver and IRemoteActivation operate in terms of OBJREFs. An OBJREF is a marshalled interface pointer, so by using the same structure we're able to be wire-compatible with MS. * Switch apartments to be identified by OXIDs * Refactor and extend the stub manager, identified by OIDs * Refactor and extend the proxy manager - Make all system interface proxies support aggregation - Identify interface stubs by IPID not IID - Do a search and replace of wine_marshal_id with STDOBJREF - Alexandre has stated that he won't allow any more midl generated code in WineHQ. Enhance widl until it can generate raw RPC marshallers for at least IRemUnknown. - Generate unique names for the pipes we currently use in communication and pull the right name from the OBJREF DUALSTRINGARRAY. In real DCOM this contains the RPC string binding for the OXID Resolver endpoint. This should be the first enhanced feature, as at this point you can run two apps at once that happen to marshal the same interface, and they won't interfere. - Implement IRemUnknown, using custom marshalling for now. Use this to nail distributed refcounting, at the moment we have a bunch of bad hacks for that. - Flip DCOM on top of the RPC transport layer, replacing the current named pipe based IRpcChannelBuffer implementation. Not necessarily using NDR marshalling at this point, though we may find it's necessary (?) - Rework RPC dispatch to be more Windows-like, so call re-entrancy works. - Implement RPC thread affinity. This will fix the InstallShield painting problems ... yes it's a long way off :( - Begin rewriting/moving the typelib marshaller to rpcrt4 and to use NDR (in Windows this is done by generating MOPs at runtime from the type data) .... this point is so far off I don't really care about it .... I probably forgot some items as well. But as you can see we only just begun. Also remember that Rob may want to modify it and also we may change direction at any point to make stuff we want internally work (like native MSIv2 ...) thanks -mike

1 0

[Fwd: Re: video4linux - wine]
by MediaHost (TM) Jan. 6, 2005

Jan. 6, 2005

I'm forwarding this correspondence to wine-devel, in case it interests other developer / users.... -------- Original Message -------- Subject: Re: video4linux - wine Date: Wed, 5 Jan 2005 22:52:33 +0100 From: Jasper van Veghel <vanveghel(a)home.nl> To: MediaHost (TM) <webmaster(a)startcom.org> References: <20050105193015.GA14955(a)Skye.mill1.nb.home.nl> <41DC68AF.2060405(a)startcom.org> Well, sure, a lot of the infrastructure is there already; it seems to me that we'll have to implement several Quartz interfaces / filters and the approriate DLL for VFW to work with DirectX. I'm not quite sure which one to base it on, though; there are quite a lot that deal with VFW, multi-media and stream captur- ing; a lot of abstraction is handled in Quartz (including qcap and amstream), but for the raw video stuff it seems to me that these are the ones where it's really at (and consequently, what we'll have to base the stuff in Quartz on) winmm.dll msvfw32.dll msvideo.dll avicap32.dll As for the devenum stuff, I've had to modify createdevenum.c to include the CLSID for VideoInputDeviceCategory and have it create the corresponding registry entries in CreateSpecialCategories, for which I've extended the stub of avicap32 a bit to actually return a device (a static string, nothing special) - the corresponding filter either references Quartz's VideoRenderer as the DShow or the VfwCapture one .. I've been having more luck with VideoRenderer (MSN 6.2 seemed to respond quite well to that), but native devenum seems to go for the other one. Perhaps they're related in some way (AFAIK there's no implementation of VfwCapture in wine; there is, however, one of VideoRenderer .. perhaps Vfw- Capture captures from the stream and VideoRenderer renders it and provides info about it through IAMStreamConfig (which is a part of VideoRenderer) - anyway, I'm sure this is all well documented and everything on MSDN, but as I said, I've never worked with DirectX before I started looking into this (wouldn't have expected it to be related to it even) Anyway, it would be nice to make some headway with this, and if you have some sample code or even a small application to test this out with (one that indeed uses this DirectX stuff) then I'd be glad to dive back into it :-) Would indeed be nice to return something useful to Wine. Jasper MediaHost (TM) wrote: > Maybe we can start the same procedure with a simpler application. Any > ideas? Of course I would be interested first, what you implemented at > devenum. So I'm not a wine developer (specially not the windows part of > it) I can give it a try and maybe we can return something useful into > wine..... > > Jasper van Veghel wrote: > > >Rob Shearman wrote: > > > > > >>Mike McCormack wrote: > >> > >> > >> > >>>There's currently no support, but you could add it via the Still Image > >>>(STI) API. It's meant for scanners and webcams. There's probably a > >>>way to add VFW (Video For Windows drivers) too. > >>> > >>>I have written an IDL file for IStillImage, which I haven't gotten > >>>round to submitting as yet. I've attached it incase you're > >>>interested... I think it still needs some fixing up. > >>> > >>>Mike > >>> > >>> > >>>MediaHost (TM) wrote: > >>> > >>> > >>> > >>>>Question: Is there support for video4linux devices with wine? Is > >>>>there some support for webcams? What are the settings (config)? I > >>>>couldn't find anything useful on google concerning this issue.... > >>>> > >>>> > >>You're probably much better off implementing a DirectShow -> V4L filter, > >>especially if you want to capture movies or sound. > >> > >>Rob > >> > >> > >> > > > >I've recently been looking into VFW with Wine, and though I certainly am no > >expert at the Windows API concerning this (first time I really looked into > >DX), > >nor Wine for that matter, I was able to get a bit further from where I > >started, > >so allow me to share my experiences with you. > > > >As an application to test this stuff with I went for MSN 6.2, though > >certainly > >not the best application for this, it seemed neat to finally have Webcam > >support > >on MSN - I eventually got some of it working with a load of native DLLs, > >some > >hacking on the SSL stuff (I ended up simply setting useSSL = false, the > >applica- > >tion was sending plain-text over an SSL socket, which wasn't working; this > >fixed > >things, or at least for this application ;-)) and adding some undocumented > >flag > >to InternetSetOption (optionId = 87) - anyway, it seems that MSN is using > >some- > >thing along the lines of the following webcam class I found using Google - > >indeed, using a DirectShow filter: > > > >http://www.jolash.com/projects/other_projects/webcam/WebCam.h > > > >For things to start working under Wine I used the following native DLLs, > >which > >I also registered with regsvr32 (for CLSIDs etc.) > > > >COMCTL32.DLL > >urlmon.dll > >CRYPT32.DLL MSOSS.DLL > >oleaut32.dll ole32.dll rpcrt4.dll > >MSVCRT.DLL > >shlwapi.dll shdocvw.dll > >MLANG.DLL > >qcap.dll amstream.dll > > > >Though I'm not sure if amstream is needed. Don't know what qcap does as I > >only > >managed to get to a point where something in qcap was called which was then > >being forwarded to Quartz (IAMStreamConfig, for which I added a bunch of > >stubs > >and semi-stubs (filled in some bogus information for > >VIDEO_STREAM_CONFIG_CAPS, > >VIDEOINFOHEADER and AM_MEDIA_TYPE) > > > >It turned out that, at least MSN, and this webcam class too, uses devenum > >to > >find the video input devices (CLSID_VideoInputDeviceCategory), for which > >I've > >added the proper code to CreateSpecialCategories and hence > >CreateClassEnumerator > >(it also seems that the windows DLL of devenum always recreates the dynamic > >registery entries whereas Wine only seems to add them once and then never > >again, > >that is, once they're in the registry they stay there (hence if a new > >audio card > >gets added to the system ..)) The Windows DLL seemed to be using avicap32 > >to > >collect information on the available video input devices, so I've simply > >had > >capGetDriverDescription return some string with a fictional video driver > >(this > >also makes it possible to use a native devenum.dll) Next up is Quartz, > >which > >seemed to want IAMStreamConfig (collecting information on the video stream > >(res, > >depth, sps, ..) for starters, but I never got around to implementing > >enough of > >that for the program to accept it and move on, so that's where I got > >stuck. It > >may also have had something to do with MSN wanting an IKsPin which isn't > >imple- > >mented (which is why native quartz may have failed, when trying to > >approach the > >kernel in some way) Here's a small scenario of what I observed working > >with both > >native and hacked up DLLs ;-) > > > >DEVENUM - Read all VideoInputDeviceRenderer's (from CLSID) > >DEVENUM - BindToObject() --> VfwCapture > >QCAP - BindToClass --> Quartz(VideoRenderer) > >QUARTZ - VideoRenderer_create > >QUARTZ - [FAIL] InputPin_QueryInterface (IKsPin) > >QUARTS - VideoRenderer_QueryInterface (IAMStreamConfig) > > > >Anyway, the 'patches' I wrote are probably not worth much as the whole > >under- > >taking was more of a little endeavor trying to see how far I go (MSN > >actually > >managed to sign in, by the way, but kept crashing a few seconds after that > >(the > >webcam stuff can be accessed without signing in though, there's a preview > >option > >in one of the menus), but perhaps this brief explanation of my steps will > >prove > >useful for someone wanting to implement this aspect of VFW :-) Perhaps > >someone > >could build a control from the class I mentioned earlier which can then be > >used > >for testing (through the webpage that refers to it says it's missing some > >code; > >but at least it's a starting point) > > > >Jasper > > > > > > -- > Regards > > Signer: Eddy Nigg > Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> > MediaHost^(TM) at www.mediahost.org > <http://www.mediahost.org/> > Skype: startcom <callto://startcom/> > Phone: +1.213.341.0390 > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390

1 0

bi-arch on an amd64
by Gabriel de Perthuis Jan. 6, 2005

Jan. 6, 2005

Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c With all this, I can get it to build! The problem is, it doesn't run; wine stops with this unhelpful message: wine: could not exec \uffff\uffffmU\uffff\uffffmUp/bin/wine-pthread (special characters inside) So, I am interested in past experiences (versions used and patches): I think wine, as most applications if need be, can be built in 32-bit mode and used by amd64 distros. It would be nice if these fixes were sent back to CVS to save people headaches; I also would like to know where I can go from here, to debug the binaries I finally got.

2 4

Re: Re: [AppDB] Fix to allow creating of new accounts (urgent)
by Chris Morgan Jan. 6, 2005

Jan. 6, 2005

You can CC me on the mail as well to keep the load on Jeremy down. Chris > > From: Mike McCormack <mike(a)codeweavers.com> > Date: 2005/01/06 Thu AM 12:19:45 EST > To: tony_lambregts(a)telusplanet.net > CC: wine-devel(a)winehq.com, burnus(a)gmx.de > Subject: Re: [AppDB] Fix to allow creating of new accounts (urgent) > > > Please send mail about security problems with winehq directly to > jnewman(a)codeweavers.com rather than advertising on public mailing lists > first :) > > Mike > > tony_lambregts(a)telusplanet.net wrote: > > > I admit it I am an idiot for not knowing what to do to fix security flaws. > >

1 0

Re: [AppDB] Fix to allow creating of new accounts (urgent)
by Tobias Burnus Jan. 6, 2005

Jan. 6, 2005

Hello, > $result = mysql_query("INSERT INTO user_list VALUES ( NOW(), 0, ". > "'$username', password('$password'), ". > - "'$realname', '$email', NOW(), 0, 0)"); > + "'$realname', '$email', NOW(), 0, 0, '$CVSrelease')"); Shouldn't one use "'".mysql_escape_string($username)."','" etc.? Or is it ensured elsewhere that no unwanted characters are in the string? ( ' is escaped in PHP, isn't it?) Tobias

4 5

Re: video4linux - wine
by luis lenders Jan. 5, 2005

Jan. 5, 2005

MediaHost (TM) wrote: >> However, is there any development going on concerning v4l and/or USB? >> Actually it's a pity, that I couldn't realize this project....we would >> have been willing to invest in such code.... >I'm not sure what the capabilities of video4linux are, >which devices it >supports or how its API works. I know it supports at >least some USB webcams. Actually video4linux has quite some capabilities, a program like xawtv for example can even grab a movie from your tv-tuner card. >> As we can access /dev/usb/lpt or /dev/dsp, it should >>be possible to access /dev/video....I'm not familiar >>in implementing such stuff at wine, but....? Altough I'm a programming noob i tried a few weeks ago to write some code to accomplish this with (not much) but still a little succes: i used code from a program like vidcat to read a frame from my v4l device (in png format), used code from another program (png2bmp) to turn it into a bitmap, and used CreateWindowEx to display this in a windowsprogram under wine. Although the window with the frame from my webcam showed up , the windowsprogram did not behave further as it should do. There is plenty of code to be found on the internet using the v4l api, but the problem how to get this in wine. Maybe someone has some further hints? Regards luis ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

3 2

Problem with builtin and native regedit
by Christian Costa Jan. 5, 2005

Jan. 5, 2005

Hi, When I try to renamed a key with the builtin regedit, all subkeys are lost. The problem is in regedit because the native one works. The latter however crash just after the renaming. See below for the backtrace. Any idea ? Bye, Christian fixme:font:load_VDMX No suitable ratio found fixme:font:load_VDMX No suitable ratio found fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:graphics:DrawAnimatedRects (0x10022,1,0x406cfe0c,0x406cfdfc): stub fixme:menu:TrackPopupMenuEx not fully implemented First chance exception: page fault on write access to 0x00300039 in 32-bit code (0x401fe6dc). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0007 EIP:401fe6dc ESP:406cf244 EBP:406cf25c EFLAGS:00010202( - 00 - -RI1) EAX:40350038 EBX:402341e4 ECX:406cf24c EDX:0030002d ESI:403cb838 EDI:00000020 Stack dump: 0x406cf244: 00000000 40350000 40350000 4085a094 0x406cf254: 40350000 00000001 406cf27c 40843ad8 0x406cf264: 40350000 00000002 0000001c 4085a094 0x406cf274: 403637fa 00000000 406cf294 40843b8d 0x406cf284: 00000001 000012ee 4085a094 40859f3a 0x406cf294: 406cf2b4 408445be 00000001 00000001 0200: sel=1007 base=40015000 limit=00001f97 32-bit rw- Backtrace: =>1 0x401fe6dc RtlAllocateHeap+0x8c(heap=0x40350000, flags=0x2, size=0x1c) [heap.c:1128] in ntdll (0x 406cf25c) 2 0x40843ad8 REGION_AllocWineRegion+0x28(n=0x1) [/home/titan/winecvs/wine/dlls/gdi/../../include/wi nbase.h:2130] in gdi32 (0x406cf27c) 3 0x40843b8d REGION_CreateRegion+0x3d(n=0x1) [/home/titan/winecvs/wine/dlls/gdi/region.c:521] in gd i32 (0x406cf294) 4 0x408445be ExtCreateRegion+0x4e(lpXform=0x0, dwCount=0x100, rgndata=0x403cd008) [/home/titan/wine cvs/wine/dlls/gdi/region.c:1013] in gdi32 (0x406cf2b4) 5 0x40cd4f33 get_server_visible_region+0x103(hwnd=0x4002e, top=0x10020, flags=0x10012) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:114] in x11drv (0x406cf350) 6 0x40cd53b2 X11DRV_GetDC+0x182(hwnd=0x4002e, hdc=0x7b0, hrgn=0x0, flags=0x10012) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:323] in x11drv (0x406cf3a0) 7 0x40717f15 GetDCEx+0x325(hwnd=0x4002e, hrgnClip=0x0, flags=0x10000) [/home/titan/winecvs/wine/dlls/user/../../windows/dce.c:438] in user32 (0x406cf3d8) 8 0x4073e9e4 CARET_DisplayCaret+0x24(hwnd=0x4002e, r=0x406cf488) [caret.c:58] in user32 (0x406cf400) 9 0x4073f28b HideCaret+0x11b(hwnd=0x4002e) [/home/titan/winecvs/wine/dlls/user/../../include/winbase.h:2125] in user32 (0x406cf4a4) 10 0x40cd67e8 X11DRV_SetWindowPos+0x238(winpos=0x406cf4f4) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:862] in x11drv (0x406cf4e8) 11 0x40736188 SetWindowPos+0xe8(hwnd=0x4002e, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x97) [/home/titan/winecvs/wine/dlls/user/../../windows/winpos.c:1225] in user32 (0x406cf520) 12 0x40cd6dee X11DRV_ShowWindow+0xce(hwnd=0x4002e, cmd=0x0) [/home/titan/winecvs/wine/dlls/x11drv/winpos.c:1139] in x11drv (0x406cf56c) 13 0x40735637 ShowWindow+0x67(hwnd=0x4002e, cmd=0x0) [/home/titan/winecvs/wine/dlls/user/../../windows/winpos.c:864] in user32 (0x406cf588) 14 0x40b08edf TREEVIEW_EndEditLabelNow+0x14f(infoPtr=0x403b42f0, bCancel=0x0) [/home/titan/winecvs/wine/dlls/comctl32/treeview.c:3695] in comctl32 (0x406cfdf4) 15 0x40b0884d TREEVIEW_Edit_SubclassProc+0xad(hwnd=0x4002e, uMsg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/comctl32/treeview.c:3450] in comctl32 (0x406cfe10) 16 0x40736937 WINPROC_wrapper+0x17 in user32 (0x406cfe34) 17 0x40736c71 WINPROC_CallWndProc+0x51(proc=0x40b087a0, hwnd=0x4002e, msg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/user/../../windows/winproc.c:421] in user32 (0x406cfe60) 18 0x4073bf95 WINPROC_CallProc32ATo32W+0x55(func=0x40b087a0, hwnd=0x4002e, msg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/user/../../windows/winproc.c:2930] in user32 (0x406cfe88) 19 0x4073c9c5 CallWindowProcA+0x95(func=0x407d7d30, hwnd=0x4002e, msg=0x100, wParam=0xd, lParam=0x1c0001) [/home/titan/winecvs/wine/dlls/user/../../windows/winproc.c:3221] in user32 (0x406cfebc) 20 0x407256d6 DispatchMessageA+0xd6(msg=0x406cff10) [/home/titan/winecvs/wine/dlls/user/../../windows/message.c:795] in user32 (0x406cfef8) 21 0x0040b87a EntryPoint+0x133 in regedit (0x406cff2c) 22 0x404d76a8 start_process+0xc8(arg=0x0) [/home/titan/winecvs/wine/dlls/kernel/process.c:1046] in kernel32 (0x406cfff4) 23 0x4002adad wine_pthread_abort_thread+0x2d(status=0x0) [port.c:85] in libwine.so.1 (0x00000000) 0x401fe6dc RtlAllocateHeap+0x8c [heap.c:1128] in ntdll: movl %eax,0xc(%edx)

1 0

Trying to get rid of gdi.h
by Rémi Assailly Jan. 5, 2005

Jan. 5, 2005

Hi all ! This mail is a resent because I noticed that it does not appear in wine-devel... I started a work to get rid of GDI_GetObjPtr and GDI_ReleaseObj in x11drv but I am not sure if have chosen a good way. This patch is incomplete : some GDI_* are still staying, those that cannot be removed using my way. Working on it I noticed something which can be interesting : graphics are faster because some times GDI_GetObjPtr were called twice and in my patch only once. I would some comments on this work. Rémi

1 0

Re: video4linux - wine
by Mike McCormack Jan. 5, 2005

Jan. 5, 2005

MediaHost (TM) wrote: > However, is there any development going on concerning v4l and/or USB? > Actually it's a pity, that I couldn't realize this project....we would > have been willing to invest in such code.... I'm not sure what the capabilities of video4linux are, which devices it supports or how its API works. I know it supports at least some USB webcams. > As we can access /dev/usb/lpt or /dev/dsp, it should be possible to > access /dev/video....I'm not familiar in implementing such stuff at > wine, but....? The idea is to use the video4linux interface to implement the VFW API in Wine. The way I usually go about this kind of thing is to write a program or find a simple program (hopefully one with source code) that can grab a picture from a WebCam on Linux. Then run it in Wine, and see which error messages come out... then you'll have a starting point. Looks like there's souce for a simple program like that here: http://www.experts-exchange.com/Programming/Programming_Languages/Cplusplus… and documentation for VFW here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/h… Mike

1 0