- Wine-Devel - list.winehq.org

Re: avicap32 patch
by Juan Lang April 25, 2005

April 25, 2005

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 April 25, 2005

April 25, 2005

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 April 25, 2005

April 25, 2005

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 April 25, 2005

April 25, 2005

> > >>> >> 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 April 25, 2005

April 25, 2005

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

Re: tools/widl
by Alexandre Julliard April 25, 2005

April 25, 2005

Ge van Geldorp <gvg(a)reactos.com> writes: > + switch(var->type->type) > + { > + case RPC_FC_BYTE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_BYTE */\n", RPC_FC_BYTE); > + break; > + case RPC_FC_CHAR: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_CHAR */\n", RPC_FC_CHAR); > + break; > + case RPC_FC_WCHAR: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_WCHAR */\n", RPC_FC_WCHAR); > + break; > + case RPC_FC_USHORT: > + case RPC_FC_SHORT: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_USHORT */\n", RPC_FC_SHORT); > + break; > + case RPC_FC_ULONG: > + case RPC_FC_LONG: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_LONG */\n", RPC_FC_LONG); > + break; > + case RPC_FC_HYPER: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_HYPER */\n", RPC_FC_HYPER); > + break; > + case RPC_FC_IGNORE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_IGNORE */\n", RPC_FC_IGNORE); > + break; > + case RPC_FC_SMALL: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_SMALL */\n", RPC_FC_SMALL); > + break; > + case RPC_FC_FLOAT: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_FLOAT */\n", RPC_FC_FLOAT); > + break; > + case RPC_FC_DOUBLE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_DOUBLE */\n", RPC_FC_DOUBLE); > + break; You should add some sort of get_fc_name() function instead of duplicating a big switch like that every time you want to print a name. > static void write_function_stubs(type_t *iface) > { > - func_t *cur = iface->funcs; > - char *handle_name = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); > + char *implicit_handle = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); > + int explitit_handle = is_attr(iface->attrs, ATTR_IMPLICIT_HANDLE); > + func_t *func = iface->funcs; > + var_t* var; Your patch would be a lot easier to review if you avoided renaming existing local variables. If you really think the names need to be changed please do it in a separate patch. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: Installing Mozilla
by Juan Lang April 25, 2005

April 25, 2005

--- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Is the Mozilla Installer Installshield or MSI based? Otherwise is it > open source? Perhaps an easier way to backtrace the problem? I believe it's open source. The crash was due to Mozilla attempting to write to a value that's exported by msvcrt.dll. It was declared in msvcrt's spec file, but never defined. Thus Mozilla was writing to a garbage pointer. It's been fixed in Wine. There's a separate issue that Mozilla probably isn't doing the right thing. It's overwriting a buffer it doesn't own and whose size is not documented, and it should be writing only four characters but is writing more. Now that Wine is fixed this is unlikely to cause anyone any trouble, but it's still not right. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

writejump purpose
by Robert Lunnon April 25, 2005

April 25, 2005

In kthread.c there is this code that is only defined for I386 glibc, but the solaris port uses Solaris libc so the function does nothing. What is the purpose of this function and exactly what should the semantics be ? BOb static inline void writejump( const char *symbol, void *dest ) { #if defined(__GLIBC__) && defined(__i386__) unsigned char *addr = wine_dlsym( RTLD_NEXT, symbol, NULL, 0 ); if (!addr) return; /* write a relative jump at the function address */ mprotect((void*)((unsigned int)addr & ~(getpagesize()-1)), 5, PROT_READ| PROT_EXEC|PROT_WRITE); addr[0] = 0xe9; *(int *)(addr+1) = (unsigned char *)dest - (addr + 5); mprotect((void*)((unsigned int)addr & ~(getpagesize()-1)), 5, PROT_READ| PROT_EXEC); # ifdef HAVE_VALGRIND_MEMCHECK_H VALGRIND_DISCARD_TRANSLATIONS( addr, 5 ); # endif #endif /* __GLIBC__ && __i386__ */ }

2 1

Wine no longer compiles
by Ivan Gyurdiev April 25, 2005

April 25, 2005

Haven't been able to compile cvs wine for the last few weeks. This is Fedora Rawhide with gcc4. Any suggestions? gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.o file.c In file included from ../../../include/winnt.h:27, from ../../../include/windef.h:204, from ../../../include/wine/test.h:25, from file.c:21: ../../../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function ‘iswalnum’ ../../../include/msvcrt/ctype.h:73: warning: conflicting types for built-in function ‘iswalpha’ ../../../include/msvcrt/ctype.h:75: warning: conflicting types for built-in function ‘iswcntrl’ ../../../include/msvcrt/ctype.h:77: warning: conflicting types for built-in function ‘iswdigit’ ../../../include/msvcrt/ctype.h:78: warning: conflicting types for built-in function ‘iswgraph’ ../../../include/msvcrt/ctype.h:79: warning: conflicting types for built-in function ‘iswlower’ ../../../include/msvcrt/ctype.h:80: warning: conflicting types for built-in function ‘iswprint’ ../../../include/msvcrt/ctype.h:81: warning: conflicting types for built-in function ‘iswpunct’ ../../../include/msvcrt/ctype.h:82: warning: conflicting types for built-in function ‘iswspace’ ../../../include/msvcrt/ctype.h:83: warning: conflicting types for built-in function ‘iswupper’ ../../../include/msvcrt/ctype.h:84: warning: conflicting types for built-in function ‘iswxdigit’ ../../../include/msvcrt/ctype.h:85: warning: conflicting types for built-in function ‘towlower’ ../../../include/msvcrt/ctype.h:86: warning: conflicting types for built-in function ‘towupper’ ../../../include/msvcrt/io.h:179: error: ‘open’ aliased to external symbol ‘_open’ ../../../include/msvcrt/io.h:180: error: ‘sopen’ aliased to undefined symbol ‘_sopen’ ../../../include/msvcrt/process.h:129: error: ‘execl’ aliased to undefined symbol ‘_execl’ ../../../include/msvcrt/process.h:130: error: ‘execle’ aliased to undefined symbol ‘_execle’ ../../../include/msvcrt/process.h:131: error: ‘execlp’ aliased to undefined symbol ‘_execlp’ ../../../include/msvcrt/process.h:132: error: ‘execlpe’ aliased to undefined symbol ‘_execlpe’ ../../../include/msvcrt/process.h:133: error: ‘spawnl’ aliased to undefined symbol ‘_spawnl’ ../../../include/msvcrt/process.h:134: error: ‘spawnle’ aliased to undefined symbol ‘_spawnle’ ../../../include/msvcrt/process.h:135: error: ‘spawnlp’ aliased to undefined symbol ‘_spawnlp’ ../../../include/msvcrt/process.h:136: error: ‘spawnlpe’ aliased to undefined symbol ‘_spawnlpe’ -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

2 1

PATCH: gcc4 alias fixes
by Marcus Meissner April 24, 2005

April 24, 2005

Hi, 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. Ciao, Marcus diff -ruN -x CVS wine-20050419/include/msvcrt/conio.h marcus-wine-20050419/include/msvcrt/conio.h --- wine-20050419/include/msvcrt/conio.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/conio.h 2005-04-13 13:03:23.000000000 +0200 @@ -53,7 +53,7 @@ static inline unsigned short outpw(unsigned short i, unsigned short j) { return _outpw(i, j); } #endif -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int cprintf(const char*,...) __attribute__((alias("_cprintf"),format(printf,1,2))); extern int cscanf(const char*,...) __attribute__((alias("_cscanf"),format(scanf,1,2))); #else diff -ruN -x CVS wine-20050419/include/msvcrt/io.h marcus-wine-20050419/include/msvcrt/io.h --- wine-20050419/include/msvcrt/io.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/io.h 2005-04-13 13:03:23.000000000 +0200 @@ -175,7 +175,7 @@ #endif static inline int write(int fd, const void* buf, unsigned int size) { return _write(fd, buf, size); } -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int open(const char*,int,...) __attribute__((alias("_open"))); extern int sopen(const char*,int,int,...) __attribute__((alias("_sopen"))); #else diff -ruN -x CVS wine-20050419/include/msvcrt/process.h marcus-wine-20050419/include/msvcrt/process.h --- wine-20050419/include/msvcrt/process.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/process.h 2005-04-13 13:03:23.000000000 +0200 @@ -125,7 +125,7 @@ static inline int spawnvp(int flags, const char* name, const char* const* argv) { return _spawnvp(flags, name, argv); } static inline int spawnvpe(int flags, const char* name, const char* const* argv, const char* const* envv) { return _spawnvpe(flags, name, argv, envv); } -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int execl(const char*,const char*,...) __attribute__((alias("_execl"))); extern int execle(const char*,const char*,...) __attribute__((alias("_execle"))); extern int execlp(const char*,const char*,...) __attribute__((alias("_execlp")));

2 1