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

MSVCRT printf functions
by Aneurin Price 07 Jan '05

07 Jan '05

I've gone over this patch again, fixed any bugs I could find, and tried to address the points made regarding readability. Hopefully the coding style should now be much improved, so could anyone who knows about such things give it a look over? If there's not too much of a problem there I'll fix up any points made and submit to wine-patches with the appropriate notes. I am still a little unsure about a couple of points; ones I can remember off the top of my head: probably insufficient attribution for code derived from file.c, since I have no idea who wrote the functions I used (these are specified in the copyright notice for printf.c, BTW). It's also pretty big; I presume it's okay to have this much in one file, but maybe not. Either way it can't be broken down into smaller patches since it's one big change. Thanks, Aneurin Price

2 1

Re: MSVCRT printf functions
by Juan Lang 06 Jan '05

06 Jan '05

Hi Aneurin, some style comments on your patch: +<<<<<<< file.c +======= This shouldn't be in your patch. +typedef struct +{ + int flags; + unsigned int width; + __int64 precision; + const MSVCRT_wchar_t *input; + MSVCRT_wchar_t *output; + int HeapAlloced; + union + { + int intIn; + double doubleIn; + }; +} PRINTF_SPECIFIER; The HeapAlloced flag shouldn't be upper-cased. A BOOL may make more sense too. +PRINTF_SPECIFIER integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER specifier) This calling convention is a little strange. It's more typical in C not to return "large" things on the stack, but to use pointers instead. Since you use the specifier in the following way: + specifier = charprocessw(va_arg(*args, int),specifier); you may want to make the specifier an in/out parameter passed by pointer instead, e.g. void integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER *specifier) The calls would then look like: + charprocessw(va_arg(*args, int),&specifier); Finally, your internal functions should be made static. --Juan __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

RC file translation via winehq?
by Mike McCormack 06 Jan '05

06 Jan '05

Hey All you web programmers out there! How hard to you think it would be to rig up a web page for people to do translations for wine on? Have a web page (translate.winehq.org?) into which we feed in all the .rc files and maybe even parts of WineHQ, and show the translations for each language and bits that are missing ... then accumulate all the bits of translation somehow so they can be sumbitted back to wine-patches. I think there's plenty of people who'd do translation work for us if they didn't have to bother learning about how to submit patches or understand how .rc files work. Mike

7 8

questions for safedisc implementation (AJ pleas read)
by Ivan Leo Puoti 06 Jan '05

06 Jan '05

Chances are I'll be quite busy during the next week, but Laurent Pinchart, the guy who originally reverse engineered safedisc, asked a few questions on IRC about implementing support for the native safedisc driver, feedback, particularly from AJ, would be very appreciated, here is the IRC log. peter_pan is Laurent. < peter_pan> I'm trying to figure out how to implement "kernel services" in wine. a kernel service is a device driver which is loaded by StartService and runs in kernel space. the driver has a DriverEntry entry point, which, unlike regular services, seem to return immediately after registering callbacks. this might not always be the case though 23:41 < peter_pan> after DriverEntry returns, the process started by StartService currently exits. how should I handle calls to the callbacks registered by IoCreateDevice inside DriverEntry ? should they run in the calling process space, the wine server space or the service process space ? 23:41 < peter_pan> in the first case, I have to map the kernel service in all wine processes space, as the service can make use of global data (in windows the kernel service only exists once inside the kernel) 23:41 < peter_pan> in the third case, I will have to find a way to keep the service process alive (in a stopped state) after DriverEntry returns, and use wineserver and ptrace to call the callbacks from the user processes. this will imply inter process communication and inter process synchronization. or maybe I could just use IPC and keep the kernel space process waiting on a pipe or something. this wouldn't work for a kernel service which doesn't return from DriverEntry immediately, but I don't know if those exist. 23:41 < peter_pan> does anyone have any thought to share ? 23:47 <@Thunderbird> hi 23:47 <@Thunderbird> guess it needs to happen in wineserver 23:47 <@Thunderbird> better ask julliard about it 23:47 <@Thunderbird> if he is still awake 23:48 < peter_pan> he's been idling for 1 hour and 45 minutes 23:49 < peter_pan> are you there alexandre ? 23:50 <@Thunderbird> td might be online too .. 23:51 * TD is gone to a film, like NOW 23:51 <@TD> bye .... 23:51 < peter_pan> no luck either 23:51 < peter_pan> lol 23:52 <@Thunderbird> isn't there some function in wineserver that runs all the time? 23:53 < peter_pan> my opinion is that DriverEntry should be called in a separate process like it is now, as it can block, and that IoCreateDevice should map the image in the wineserver process space and update the callback table. the problem is that the changes to data sections made in DriverEntry must be somehow shared with wineserver. 23:55 < peter_pan> StartService will have to be modified to handle kernel services. it uses CreateProcess now, which calls DriverEntry (the entry point) with wrong parameters. we would need a way to mark a process as being a kernel process or a user process 23:57 <@Thunderbird> I guess that is good but I'm not qualified enough to say something about that 23:58 < peter_pan> using wineserver to host the driver callbacks would serialize the calls, which might not be a good thing to do. in windows, syscalls are executed in kernel space, but in the context of the calling process. it might be a good idea to do that here too. is the windows kernel interruptible ? can a process call a driver function while another process sleeps in the same functions, or while another process executes inside that function on another CPU ? 23:59 <@Thunderbird> how is this stuff handled in reactos? 23:59 < peter_pan> I have no idea 23:59 < peter_pan> maybe I should ask them

2 1

Re: WPP: Fixed 'out of tree' compilation
by Alexandre Julliard 06 Jan '05

06 Jan '05

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 06 Jan '05

06 Jan '05

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) 06 Jan '05

06 Jan '05

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 06 Jan '05

06 Jan '05

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 06 Jan '05

06 Jan '05

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 06 Jan '05

06 Jan '05

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