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

Exception in DefWindowProcA
by Paul Vriens 26 Apr '05

26 Apr '05

Hi, when running proces explorer (V9.0.3) and some hacks, I get an exception in DefWindowProcA: trace:message:SPY_EnterMessage (0x20022) DefWindowProc32: WM_GETTEXT [000d] wp=00000100 lp=00000000 Call kernel32.WideCharToMultiByte(00000000,00000000,6b2592e0 L"Process Explorer - Sysinternals: www.sysinternals.com",ffffffff,00000000,00000100,00000000,00000000) ret=61b8be5 Ret kernel32.WideCharToMultiByte() retval=00000000 ret=61b8be52 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x61b8be5c It somewhat boils down to this piece of code in defwnd.c: line:754 if (wndPtr->text) { if (!WideCharToMultiByte( CP_ACP, 0, wndPtr->text, -1, dest, wParam, NULL, NULL )) dest[wParam-1] = 0; result = strlen( dest ); } else dest[0] = '\0'; WIN_ReleasePtr( wndPtr ); dest = NULL in my case so I added some tests for this: if (wndPtr->text) { if (!WideCharToMultiByte( CP_ACP, 0, wndPtr->text, -1, dest, wParam, NULL, NULL )) { if (dest) dest[wParam-1] = 0; } if (dest) result = strlen( dest ); else result = 0; } This makes the GUI appear but I want to find out if the call is valid or that we indeed should check for dest being NULL. Any ideas? Cheers, Paul.

1 0

Re: OLEAUT32: (resend) Floating point locale, no negative zero
by Alexandre Julliard 26 Apr '05

26 Apr '05

Alex Villacis Lasso <a_villacis(a)palosanto.com> writes: > Changelog: > * Force Single|Double conversion to BSTR to use the decimal separator > defined by the current locale, because that is what native oleaut32 > does, and to be consistent with later parsing of floating-point > numbers, which uses current locale. Failure to apply this patch causes > vartype test to fail in non-US locales with a decimal separator other > than a period. > * The number form "-0" is *not* allowed to be returned in a > Single|Double conversion to BSTR in case of numeric undeflow, use > unsigned zero instead. Some applications depend on this. Test included. That's ugly, I think we really want to do our own formatting instead of using the system printf and hacking the string afterwards. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PATCH: gcc4 alias fixes
by Dan Kegel 26 Apr '05

26 Apr '05

Dimitrie O. Paun wrote: >> This is the patch I use for gcc4.0 here. >> >> I am not really sure why this aliasing was introduced, >> but it will not work this way anymore. > > I still don't understand why it doesn't work. > > It was introduced because using macros it not always acceptable. > Some source uses these functions in ways that break if they are > defined as macros. > > Defining them as inline functions work, but we can't do so for > varargs, in which case we used aliases. > > What was the reason to break them, and why they don't work? > They are aliasing to things that _are_ defined, so I'm not > sure what is going on there. http://www.gnu.org/software/gcc/gcc-4.0/changes.html says (not that I really understand it totally): --- snip --- Given __attribute__((alias("target"))) it is now an error if target is not a symbol, defined in the same translation unit. This also applies to aliases created by #pragma weak alias=target. This is because it's meaningless to define an alias to an undefined symbol. On Solaris, the native assembler would have caught this error, but GNU as does not. --- snip --- - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

How to deal with different struct sizes per OS
by Paul Vriens 26 Apr '05

26 Apr '05

Hi, while dealing with the SYSTEM_PROCESS_INFORMATION struct in winternl.h I found that the struct has different sizes for NT/W2K/W2K3. How do we deal with this? Have a struct per OS and deal with it in the handling part (ntdll/nt.c in this case) for what *version* returns? Should the default one be the most extensive one? We obviously need a run-time check. While I'm at it, this struct contains another struct (VM_COUNTERS). Do we want the seperate items in SYSTEM_PROCESS_INFORMATION or a reference to VM_COUNTERS? (VM_COUNTERS looks cleaner). Cheers, Paul Vriens.

1 0

Bug 2904
by Dustin Navea 25 Apr '05

25 Apr '05

Hey guys, can one of you have a look at bug 2904? The reporter left a slightly barebones report, but I was able to find the patch that caused the problem, and posted all the relevant info I could find in my comments. Hopefully someone can write up a quick fix.. Thanks Dustin P.S. It's great to be back maintaining the database.. Now for all those bugs Ive missed over the last couple of years! ;-)

1 0

Re: avicap32 patch
by Juan Lang 25 Apr '05

25 Apr '05

Hi Maarten, > +#ifdef HAVE_LINUX_VIDEODEV_H > +#include <stdio.h> > +#include <sys/ioctl.h> > +#include <sys/stat.h> > +#include <errno.h> > +#include <asm/types.h> > +#include <linux/videodev.h> > +#include <fcntl.h> > +#include <unistd.h> > +#include "winnls.h" > +#endif You need to include "winnls.h" unconditionally, capGetDriverDescriptionW is always compiled with calls to MultiByteToWideChar. > + sprintf(device, "/dev/video%i", devnum); Why not use snprintf(device, sizeof(device) ...) instead? > + strcpy(name, caps.card); Ug. Please don't use strcpy. Even though caps.card and name happen to be declared of the same size, and caps.card is very likely null-terminated, it takes a bit of searching around to make sure that's the case. It's easier to verify it's correct if you use lstrncpyA or memcpy instead. Since you NULL-terminate in the next line, I'd suggest memcpy. > + sprintf(version, "%s v%u.%u.%u", It's also not obvious how large version is. I'd recommend passing in the length of the buffer and using snprintf instead. You might as well pass in the length of name, too. > + strncpy(lpszName, devname, cbName); You won't be able to use strncpy anymore, see Alexandre's commit: http://www.winehq.org/hypermail/wine-cvs/2005/04/0275.html --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

WoW, er Wine on Windows--Re: Still more fun?
by Augustus Saunders 25 Apr '05

25 Apr '05

I've been avidly following WWN for some time now, and now that other people have brought up this topic (using WINE dlls on Windows), I wanted to jump in. (I'm not subscribed, so please CC me on any response) My employer is vaguely considering pursuing a product idea, depending on 1) how difficult this is to do, 2) how complete WINE is in the areas we're interested in, and 3) presuming the licensing works out. But that's neither here nor there, so let me describe what we want to do. We are interested in creating an "application launcher" application, where-in you run our application, choose any other application installed on your system, and it is executed, but links against any WINE dlls that we provide instead of system dlls. So we want to put all of the WINE dlls (that we care to use) in say, "C:\Program Files\LauncherApp\WINE" or some such, and injecting that ahead of WINDOWS and SYSTEM32 directories, but only for apps run from our launcher. Anything we don't provide should just fall back on the system dlls. As for what we hope to accomplish, well, it might seem like massive overkill to try using WINE, but it's the only plausible way I've come up with. Basically, we want to substitute all the graphics/windowing/GDI etc so that we can record all the painting/rendering into some kind of WMF type thingy. The idea is to get screen captures as metafiles that are perfectly screen-accurate. There are numerous ways to grab a bitmap rendering of a window/screen, but that's useless. Also, you can (sometimes) get an application to print to your metafile, but that is for printing documents and does not show the application as it appears on screen. The end result? Essentially vector graphic screen shots. I can imagine some weird interactions caused by using wine dlls and system dlls at the same time. I can also imagine that things might go berzerk when a WINE-linked app's window's overlapped a regular app--it would probably be necessary to forward some stuff to the WIN32 system so that windows would interact and messages get sent properly. In fact, for us, it would be ok to forward everything to WIN32 versions, and have WINE maintain a "shadow" copy of all the windows in memory that we capture from, but aren't on-screen. But that could be a huge performance drain. It seems like this could be a ton of work, or practically trivial, and I can't tell which. Finally, how much is DirectDraw/D3D used outside of games? We're only interested in desktop/office type apps, and I presume we can safely ignore trapping anything sent through DirectX. I appreciate any feedback anybody has. Thanks- Augustus PS I'm not subscribed (I just read WWN), so please CC me on any responses. Thanks.

4 4

TrashCan - Day 4
by Steven Edwards 25 Apr '05

25 Apr '05

Hi, This one is much better but still far from perfect. Trashing files to ~/.Trash now works and its cleanly put in to a new function. Alexandre wants to have the default behavior to be to use C:\Recycled so I am going to add a registry entry and a option to winecfg so that the user can enable FreeDesktop trash if they wish. Any suggestions on Key/Value name and location? Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: Some fixes for filtergraph.c (#2)
by Christian Costa 25 Apr '05

25 Apr '05

> > >>> >> This is not correct, you must connect all pins, not just the first >> that succeeds. > > > Asleep? ;) You can't connect an input pin more then once > (VFW_E_ALREADY_CONNECTED), anyway this function always returned S_OK, > I fixed that too now... If you still think multiple connects should > happen > http://msdn.microsoft.com/library/en-us/directshow/htm/ipinconnect.asp ;) No, no. It's not necessary. I'm convinced. :-) > > static HRESULT WINAPI Mediacontrol_Pause(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ TRACE("(%p/%p)->()\n", This, iface); > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ if (This->state == State_Paused) return S_OK; >+ >+ SendTheFilterAMessage(iface, SendPause); >+ This->state = State_Paused; > > return S_OK; > } > > Shouldn't S_FALSE be returned in the last statement? > > static HRESULT WINAPI Mediacontrol_Stop(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ TRACE("(%p/%p)->()\n", This, iface); > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ if (This->state == State_Stopped) return S_OK; >+ if (This->state == State_Running) SendTheFilterAMessage(iface, SendPause); >+ SendTheFilterAMessage(iface, SendStop); >+ This->state = State_Stopped; > > return S_OK; > } > > I think you should move the critical section out of SendTheFilterAMessage and put it in Run, Pause and Stop methods. Bye, Christian PS: SendTheFilterAMessage and FoundFilter are really odd names, no?

2 1

Re: Privilege Checks For RegLoadKey, RegUnloadKey & RegSaveKey
by Alexandre Julliard 25 Apr '05

25 Apr '05

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > - Fix access rights for RegOpenKeyEx and RegCreateKeyEx calls. > - Add privilege checks for RegLoadKey, RegUnloadKey & RegSaveKey calls. This breaks the crypt tests: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so crypt.c && touch crypt.ok crypt.c:224: Test failed: 8009000f -- Alexandre Julliard julliard(a)winehq.org

1 0