- Wine-Devel - list.winehq.org

Re: Janitorial : Use Compiler Warnings ( -Wmissing-declarations ) ( #1 )
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Rémi Assailly <remi.assailly(a)free.fr> writes: > --- include/wine/library.h 2005-01-07 19:41:26.000000000 +0100 > +++ include/wine/library.h 2005-01-07 19:49:41.389057824 +0100 > @@ -42,6 +42,7 @@ > extern void *wine_dlopen( const char *filename, int flag, char *error, int errorsize ); > extern void *wine_dlsym( void *handle, const char *symbol, char *error, int errorsize ); > extern int wine_dlclose( void *handle, char *error, int errorsize ); > +extern void __wine_dll_register( const IMAGE_NT_HEADERS *header, const char *filename ); Functions starting with '__wine' are internal only and must not be declared in the public headers if it can be avoided. -- Alexandre Julliard julliard(a)winehq.org

2 2

Switching to winecfg
by Crestez Leonard Jan. 10, 2005

Jan. 10, 2005

As winecfg gets better and better I think it's time to consider making it actually change the config file. I made a patch for it, but it's a work in progress, and not ready for general use. I don't expect you to commit it, so I sent it here for discussion. I don't think that this needs a complex migration process, all we need to do is save the wine config registry to $WINEPREFIX/config. If people want their config file back, wine can skip saving the configuration if it wasn't modified. This will allow comments to persist in the config file. Anyway, regedit is better than editing a config file. In writing this patch I came across some strange stuff in server/registry.c. What's the point of all the save level stuff? current_level is only set once to 1, on initialization, and save_level depends on whether registry branches should be saved only when modified (can anyone think of a reason to disable that feature?). Can't the KEY_DIRTY bit be used instead of this level stuff? Also update_level seems to be dead code, not called from anywhere. Please tell me what you think about the patch. -- Crestez Leonard <cleonard(a)go.ro>

2 1

Re: WININET: implement InternetTime{From,To}SystemTime{A,W} (#2)
by Alexandre Julliard Jan. 10, 2005

Jan. 10, 2005

Hans Leidekker <hans(a)it.vu.nl> writes: > +/*********************************************************************** > + * InternetTimeFromSystemTimeW (WININET.@) > + * > + * NOTES > + * This is not an illegal W->A crosscall since internet dates are ASCII strings. It would still be much cleaner to have the A function call the W one. -- Alexandre Julliard julliard(a)winehq.org

1 0

typelib2.c problems
by Gerald Pfeifer Jan. 10, 2005

Jan. 10, 2005

The following change to dlls/oleaut32/typelib2.c revision 1.32 date: 2005/01/09 17:32:17; author: julliard; state: Exp; lines: +14 -14 Paul Vriens <Paul.Vriens(a)xs4all.nl> - use Interlocked* functions in AddRef and Release. - store the result of the Interlocked functions and use only this. causes the following warnings on SUSE LINUX 9.2 and FreeBSD: typelib2.c:3012: warning: passing arg 1 of `InterlockedIncrement' from incompatible pointer type typelib2.c:3027: warning: passing arg 1 of `InterlockedDecrement' from incompatible pointer type Would you mind fixing this? Gerald

1 0

dcom95.exe removed from sf.net
by Jeremy Newman Jan. 10, 2005

Jan. 10, 2005

Somebody removed dcom95.exe from sf.net. Was there a reason for that? We really need to keep that file mirrored. It's an essential file for many programs to run under wine. I've re-added the file as a hidden file for the moment. It won't show up in the download list, but we can still link to it.

8 18

Re: German language files
by Mike McCormack Jan. 10, 2005

Jan. 10, 2005

Thanks for the translations, however please read: http://www.winehq.org/site/sending_patches You should send patches, not zip files. Diff against the current WineHQ CVS, not ReactOS. Diff new files against /dev/null. eg. diff /dev/null dlls/shell32/shell32_De.rc Your changes are unlikely to be accepted as they are. There's only one person processing WineHQ patches. If you keep the submissions uniform it reduces his workload. Mike Klemens Friedl wrote:> > Please add the files to the wine directory. Thanks! > > > Klemens Friedl <frik85>

1 0

Re: USER32: result of ScrollBar functions review (4th try)
by Alexandre Julliard Jan. 9, 2005

Jan. 9, 2005

Vitaly Lipatov <lav(a)etersoft.ru> writes: > @@ -1728,12 +1821,15 @@ > SCROLLINFO info; > > TRACE("hwnd=%p nBar=%d min=%d max=%d, bRedraw=%d\n", hwnd, nBar, minVal, maxVal, bRedraw); > - > + > info.cbSize = sizeof(info); > info.fMask = SIF_RANGE; > info.nMin = minVal; > info.nMax = maxVal; > SetScrollInfo( hwnd, nBar, &info, bRedraw ); > + if (nBar == SB_CTL) > + FIXME("needs to send SMB_SETRANGE when SB_CTL\n"); > + //return SendMessageW(hwnd, SBM_SETRANGE, (WPARAM)0, (LPARAM)0); > return TRUE; There's no reason to add a FIXME, calling SetScrollInfo is perfectly fine and it's what Windows does too, we even have a test for it. Also please send separate changes as separate patches, especially when you are renaming functions which causes a lot of changes all over and makes it hard to see what else is changing. -- Alexandre Julliard julliard(a)winehq.org

2 2

Wine(server) priority inversion on CK kernel mailing list
by Andreas Mohr Jan. 9, 2005

Jan. 9, 2005

Hi, I'm following CK kernel development, and the mailing list had the following posting: ---------- Message: 19 Date: Fri, 07 Jan 2005 23:16:14 +1100 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] wine is bloody slow with 2.6.10-ck2 To: Michal ?erav?k <michalz(a)olomouc.com> Cc: CK Kernel <ck(a)vds.kolivas.org> Message-ID: <41DE7D8E.8090102(a)kolivas.org> Content-Type: text/plain; charset="iso-8859-2" Michal ?erav?k wrote: > Hi, > > I have been running photoshop under wine > with 2.6.8.1-ck9 and 2.6.9 and it was good. > Is there any workaround for 2.6.10-ckx and wine > to get normal speed? > It's the same with prelink and without. Nice your wineserver +19. If that's not enough, just run wine at +19. Wineserver gets into a silly priority inversion scenario with the main wine threads. Cheers, Con ---------- Note that Con indicated several times that Wine is a very "special" piece of software, it has wildly differing gaming behaviour (threading behaviour) than native Linux games. For those of you who don't know what priority inversion is (I'll try to explain it, but I'm sure my explanation sucks ;): one (high priority) thread is waiting on a lock, and in order to keep this high priority, another thread owning that lock gets more CPU to get that lock released. Problem is that that thread should have a lower priority, but since the high priority thread always has to wait on the lock, the low priority thread effectively has a much higher priority. These could just be the usual known slow wineserver communication effects at work here, but I wanted to make sure you know about these issues on the CK list. Andreas Mohr

3 3

Re: [winegcc] Include .so files when calling winebuild
by Alexandre Julliard Jan. 9, 2005

Jan. 9, 2005

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > Currently when compiling a program, winegcc calls winebuild > to solve .def references. But winegcc drops .so files, > so any new .def symbols in a .so causes a unresolved symbol at > link time. This patch adds .so files to the files to winebuild. I'm not sure I follow you, if your .so files have been built correctly they shouldn't contain undefined references to Windows APIs. Could you please show an example of the situation that causes a problem? -- Alexandre Julliard julliard(a)winehq.org

2 1

another build problem on current cvs
by Joris Huizer Jan. 9, 2005

Jan. 9, 2005

Hello, For the past week or so, building from cvs on a debian/stable system w/ alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks on alsa-specific code in wine; I attached the log; note that I did a `cvs update -dPA` and `make distclean` so this can't be any problem with the source I have Any ideas? Maybe you can point me to a place where I can read how to fix this properly (I never worked on alsa-specific code before...) or something like that regards, Joris

4 7