December 2004 - Wine-Devel - list.winehq.org

is WIDL a sutable replacement for microsoft MIDL?
by Jonathan Wilson Dec. 24, 2004

Dec. 24, 2004

Could WIDL be used alongside MingW to generate IDL files on windows? What changes, if any, would be needed to WIDL to get it working on win32 and compiling IDL files in a way that MingW can use? Does MingW have enough of the OLE header files for WIDL to work? Having an IDL compiler for MingW would be a very usefull thing for those doing COM development IMO.

2 1

Wine Bug Busters @ 7pm GMT
by Brian Vincent Dec. 24, 2004

Dec. 24, 2004

The first ever Wine Bug Busters hacking session is coming up in an hour - 7pm GMT or 2pm EST for you North American folks. A few people are already sitting in irc. If you want to join, fire up your favorite IRC and log into irc.freenode.net, channel #winehackers. -Brian

5 5

Re: [QUARTZ] Some fixes
by Robert Shearman Dec. 24, 2004

Dec. 24, 2004

Christian Costa wrote: > Hi, > > With this patch, the indeo codec feels a little better. > > Changelog: > Initialize the COM libraries for the newly created worker thread in > the AVI splitter. > Fixed some returned error codes. > Show refcount in the AddRef/Release traces in filter. > Added 24 bits source in the video renderer. > > Christian Costa titan.costa(a)wanadoo.fr > >------------------------------------------------------------------------ > >Index: avidec.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avidec.c,v >retrieving revision 1.11 >diff -u -r1.11 avidec.c >--- avidec.c 20 Dec 2004 17:07:17 -0000 1.11 >+++ avidec.c 24 Dec 2004 13:31:39 -0000 > > Why make things difficult for Alexandre? It is Christmas after all. Provide a diff relative to the root of the wine tree. ... >Index: pin.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/pin.c,v >retrieving revision 1.9 >diff -u -r1.9 pin.c >--- pin.c 16 Dec 2004 14:25:15 -0000 1.9 >+++ pin.c 24 Dec 2004 13:31:52 -0000 >@@ -1134,6 +1134,8 @@ > REFERENCE_TIME rtCurrent; > ALLOCATOR_PROPERTIES allocProps; > >+ CoInitialize(NULL); >+ > SetEvent(This->hEventStateChanged); > > hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps); > > Good catch, but it would probably be better to use CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what Microsoft uses for the pull thread. Rob

3 5

Re: [MSVCRT] Fix get/set pos (fixes Supreme Snowboarding demo).
by Dmitry Timoshkov Dec. 24, 2004

Dec. 24, 2004

"Lionel Ulmer" <lionel.ulmer(a)free.fr> wrote: > Basically, there was two issues: the first is that the 'fpos_t' is 64 bits > in Windows (Mike M. checked on VC++ and I checked on MinGW and both > confirmed this). The situation with fpos_t is even worse. Both VC++ (Win32) and Platform SDK (Win64 part) define it as follows (stdio.h): #ifndef _FPOS_T_DEFINED #undef _FPOSOFF #if defined (_POSIX_) typedef long fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else /* _POSIX_ */ #if !__STDC__ && _INTEGRAL_MAX_BITS >= 64 typedef __int64 fpos_t; #define _FPOSOFF(fp) ((long)(fp)) #else typedef struct fpos_t { unsigned int lopart; int hipart; } fpos_t; #define _FPOSOFF(fp) ((long)(fp).lopart) #endif #endif /* _POSIX_ */ #define _FPOS_T_DEFINED #endif -- Dmitry.

2 1

Re: [MSVCRT] Fix get/set pos (fixes Supreme Snowboarding demo).
by Mike Hearn Dec. 24, 2004

Dec. 24, 2004

On Fri, 24 Dec 2004 15:42:30 +0100, Lionel Ulmer wrote: > With the help of Mike (M.) on IRC to point me to the right direction, I > finally managed to nail down the problem that was plaguing TD's snowboarding > game demo (oh well, it's better doing it in real life but well, if you are > blocked in England it's better than nothing :-) ). YAY! Great work guys, wonderful Christmas present :) Now I suppose I should fix the launcher creation problem. Then the only one left is the black sky bug but like you said, it's likely to be a driver issue. thanks -mike

1 0

Re: wine/dlls shell32/shlfileop.c shell32/shlexec. ...
by Christian Costa Dec. 24, 2004

Dec. 24, 2004

Hi Michael, This is typically the kind of patches that breaks everything. The code you find useless, is often use in lazy allocation or error handling. I doubt the current wine code is so bad designed even if there is some cases where the test is useless. For example in memallocator.c, this is wrong because you can release the allocator even before allocating the memory with the SetProperties method. Looking at your other patches, there is some changes that seems suspect to me (in winmm and directx). I think, this kind of cleanup should be done very carefully by understanding what the code really does. Morever, sending large patches that involves several dll makes it appears as obvious cleanups which they are not. Bye, Christian PS: Alexandre, please, could you remove all theses patches ? Alexandre Julliard wrote: >ChangeSet ID: 15010 >CVSROOT: /opt/cvs-commit >Module name: wine >Changes by: julliard(a)wine.codeweavers.com 2004/12/23 11:12:07 > >Modified files: > dlls/shell32 : shlfileop.c shlexec.c shelllink.c > shell32_main.c pidl.c brsfolder.c > autocomplete.c > dlls/setupapi : setupx_main.c parser.c > dlls/serialui : confdlg.c > dlls/rsaenh : rsaenh.c handle.c > dlls/rpcrt4 : rpc_server.c rpc_message.c rpc_binding.c > dlls/richedit : reader.c > dlls/quartz : memallocator.c > >Log message: > Michael Stefaniuc <mstefani(a)redhat.de> > Do not check for non NULL pointer before HeapFree'ing it. It's > redundant. > >Patch: http://cvs.winehq.org/patch.py?id=15010 > >Old revision New revision Changes Path > 1.49 1.50 +1 -2 wine/dlls/shell32/shlfileop.c > 1.58 1.59 +1 -1 wine/dlls/shell32/shlexec.c > 1.79 1.80 +17 -40 wine/dlls/shell32/shelllink.c > 1.141 1.142 +2 -2 wine/dlls/shell32/shell32_main.c > 1.123 1.124 +1 -1 wine/dlls/shell32/pidl.c > 1.53 1.54 +1 -4 wine/dlls/shell32/brsfolder.c > 1.11 1.12 +2 -4 wine/dlls/shell32/autocomplete.c > 1.29 1.30 +3 -3 wine/dlls/setupapi/setupx_main.c > 1.14 1.15 +1 -2 wine/dlls/setupapi/parser.c > 1.19 1.20 +1 -2 wine/dlls/serialui/confdlg.c > 1.7 1.8 +4 -4 wine/dlls/rsaenh/rsaenh.c > 1.2 1.3 +1 -2 wine/dlls/rsaenh/handle.c > 1.33 1.34 +1 -1 wine/dlls/rpcrt4/rpc_server.c > 1.11 1.12 +2 -5 wine/dlls/rpcrt4/rpc_message.c > 1.29 1.30 +1 -1 wine/dlls/rpcrt4/rpc_binding.c > 1.18 1.19 +1 -2 wine/dlls/richedit/reader.c > 1.5 1.6 +1 -2 wine/dlls/quartz/memallocator.c > > > > > >

2 2

gmail invitation
by Ivan Leo Puoti Dec. 24, 2004

Dec. 24, 2004

I have 6 gmail invitations, I'm giving them out to Wine developers only. If you want one drop me a line, first come first served. Ivan.

4 3

Re: Systray patch but explorified
by Mike Hearn Dec. 24, 2004

Dec. 24, 2004

On Mon, 13 Dec 2004 21:58:07 +0000, Mike Hearn wrote: > - Use freedesktop.org system tray protocol, remove legacy KDE support > - Introduce new Explorer process > - Rewrite system tray handling to be out of process Hi Alexandre, What needs doing next for this patch? thanks -mike

2 5

Interface for working directories/launchers
by Mike Hearn Dec. 24, 2004

Dec. 24, 2004

Hi, Wine currently creates launchers (.desktop files) with an Exec line like this: Exec=wine 'c:\games\supreme\supreme.exe' But, some games expects to be run from its working directory. As working directory typically doesn't matter to UNIX apps, some desktop environments like GNOME don't let you set it. Really, this is a Wine specific issue. So I'm wondering how we should fix this. The most obvious is a way to tell Wine to change the working directory to the path of the EXE file before running it, but we can't introduce command line switches any more and an environment variable for this doesn't make much sense. My proposal is to have a new winelib app "winemenulauncher" which simply takes the working directory, program and arguments, and runs the program but switching current directory first, ie the menu entry would look like: Exec=wine winemenulauncher c:\games\supreme supreme.exe Hopefully this should let us fix the case of games like Dungeon Keeper which actually crash when run from their install directory. Does this sound sensible? thanks -mike

3 3

Re: [AppDB] CODING_STANDARD
by Paul van Schayck Dec. 24, 2004

Dec. 24, 2004

Jonathan, On Fri, 24 Dec 2004 10:43:45 +0100, Jonathan Ernst <Jonathan(a)ernstfamily.ch> wrote: > This patch sets variable naming convention that should be used in the > appDB code. Why would we change it. I think it just clutters up the source without adding value. PHP is a variable-type decleration less language. We often just change string in booleans without thinking about it. And I think I'm just lazy. I don't like typing more characters. What are your argument for it? Paul

2 1