wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Stupid thing to try ...
by Lars Segerlund 14 Oct '04

14 Oct '04

I was thinking of a silly thing to try, namely replacing windows dll's with wines, does anybody have any thoughts about it ? I just thought about it as a debugging trick I wanted to try, but I don't know enough to evaluate if it's even worth trying. So what about it, is it worth giving a shot ? Regards, Lars Segerlund.

3 2

Rename Wine User Guide to Wine User's Guide?
by Scott Ritchie 14 Oct '04

14 Oct '04

The Winelib documentation is called the Winelib User's Guide, but the Wine documentation is called the Wine User Guide. I think for consistency's sake we should rename the Wine User Guide to Wine User's Guide - afterall, it's a guide for the user, not about the user. Thoughts?

10 12

Rename Wine User Guide to Wine User's Guide?
by Scott Ritchie 14 Oct '04

14 Oct '04

2 1

Re: Rename Wine User Guide to Wine User's Guide?
by Ivan Leo Puoti 14 Oct '04

14 Oct '04

Let's do it like Microsoft, and call it "Wine 1.0 starts here" ;-) Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

[PATCH] DrawDibDraw flag handling
by Peter Riocreux 14 Oct '04

14 Oct '04

I got a lot of messages from this function about a particular flag (DDF_BACKGROUNDPAL) not being handled, so I tried to handle it. The MSDN docs are at <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/h…> I am coming to this completely cold, so I may be completely off target here, so if anyone can comment on whether I have done this right. I suspect that there needs to be explicit support for DDF_SAME_HDC, but I didn't really understand what it was wanting .... (Patch is against CVS from this AM (GMT) Index: dlls/msvideo/drawdib.c =================================================================== RCS file: /home/wine/wine/dlls/msvideo/drawdib.c,v retrieving revision 1.21 diff -u -r1.21 drawdib.c --- dlls/msvideo/drawdib.c 3 Jun 2004 23:19:51 -0000 1.21 +++ dlls/msvideo/drawdib.c 14 Oct 2004 14:46:47 -0000 @@ -311,7 +311,7 @@ whdd = MSVIDEO_GetHddPtr(hdd); if (!whdd) return FALSE; - if (wFlags & ~(DDF_SAME_HDC | DDF_SAME_DRAW | DDF_NOTKEYFRAME | DDF_UPDATE | DDF_DONTDRAW)) + if (wFlags & ~(DDF_SAME_HDC | DDF_SAME_DRAW | DDF_NOTKEYFRAME | DDF_UPDATE | DDF_DONTDRAW | DDF_BACKGROUNDPAL)) FIXME("wFlags == 0x%08lx not handled\n", (DWORD)wFlags); if (!lpBits) @@ -362,7 +362,10 @@ } } if (!(wFlags & DDF_DONTDRAW) && whdd->hpal) - SelectPalette(hdc, whdd->hpal, FALSE); + if ((wFlags & DDF_BACKGROUNDPAL) && ! (wFlags & DDF_SAME_HDC)) + SelectPalette(hdc, whdd->hpal, TRUE); + else + SelectPalette(hdc, whdd->hpal, FALSE); if (!(StretchBlt(whdd->hdc, xDst, yDst, dxDst, dyDst, whdd->hMemDC, xSrc, ySrc, dxSrc, dySrc, SRCCOPY))) ret = FALSE;

3 4

Re: MM doc update
by Mike Hearn 14 Oct '04

14 Oct '04

The problem with ASCII art is that the website uses a proportional font so it looks all messed up. I think a good janitorial task would be for somebody to install Inkscape and convert the ASCII art diagrams we have in the docs to SVG, so they could be rendered to PNGs or something and become a part of the developer guide. What do people think of this? If anybody is reading this and wants to help the Wine projcet but doesn't want to/can't write patches, this would be a great little job to do. BTW you can install Inkscape via autopackage (plug plug), using the nightly builds from here: http://navi.cx/~mike/inkscape thanks -mike

4 5

Re: alsa 0.9 + audio.c (Joris Huizer)
by Dietrich Teickner 14 Oct '04

14 Oct '04

Message: 2 Date: Wed, 13 Oct 2004 20:19:21 +0200 From: Joris Huizer <......> Subject: Re: alsa 0.9 + audio.c To: .... Dietrich Teickner wrote: >> Hi, >> >> Have anyone a solution for this problem ? >> >> Dietrich >> What *is* your problem?? Joris I and some others can not compile wine/dlls/winmm/winealsa. Wine audio.c can not compile with alsa 0.9 (SuSE 8.1) Dietrich audio.c:3224: warning: passing arg 3 of `snd_pcm_hw_params_set_buffer_time_near' makes integer from pointer without a cast audio.c:3226: warning: passing arg 3 of `snd_pcm_hw_params_set_period_time_near' makes integer from pointer without a cast audio.c:3231: warning: passing arg 2 of `snd_pcm_hw_params_get_period_size' from incompatible pointer type audio.c:3231: too many arguments to function `snd_pcm_hw_params_get_period_size' audio.c:3232: too many arguments to function `snd_pcm_hw_params_get_buffer_size' make[2]: *** [audio.o] Fehler 1 make[2]: Verlassen des Verzeichnisses ?/home/sao2l02/Wine/wine/dlls/winmm/winealsa½ make[1]: *** [winmm/winealsa] Fehler 2 make[1]: Verlassen des Verzeichnisses ?/home/sao2l02/Wine/wine/dlls½ make: *** [dlls] Fehler 2 sao2l02@x2l:~/Wine/wine>

1 0

nonclient.c and sysmetrics.c
by William Poetra Yoga Hadisoesen 14 Oct '04

14 Oct '04

This is my first post here. I noticed that the caption buttons wine draws are different with those drawn by windows. I found the functions in nonclient.c and this led me to modify sysmetrics.c. I haven't succeeded yet... Should I post those two files here (the diffs)? Or does anyone have a comment? __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

2 5

alsa 0.9 + audio.c
by Dietrich Teickner 13 Oct '04

13 Oct '04

Hi, Have anyone a solution for this problem ? Dietrich

2 1

RE: .so dependancies in winegcc
by Pierre d'Herbemont 13 Oct '04

13 Oct '04

Warren, On Mac OS X/Darwin .so and .dylib extensions are both used. In fact .dylib extension is used for dynamic libraries (libwine*.dylib) whereas dll.so and exe.so extensions are used for the dlls and the exe. So your patch would break winegcc on Mac OS X. Pierre.

3 2

Re: Revised Wine User Guide Introduction
by Dimitrie O. Paun 13 Oct '04

13 Oct '04

On Sat, Oct 09, 2004 at 06:30:19PM -0700, Scott Ritchie wrote: > The version 0.9 todo list (bug 85) specifies the need for a rewritten > intro to the Wine User Guide. > > This patch is that rewritten intro. It rewords things to make Wine > easier to understand for the new user, gives it a more professional > look, and removes some outdated information. Cool. Can you please also reformat the long lines in the spirit of the original format? It makes it much more pleasant to work with... -- Dimi.

3 2

window caption buttons
by William Poetra Yoga Hadisoesen 13 Oct '04

13 Oct '04

This is related to my last post. The buttons wine draw actually have wrong borders, like for example a normal window has this close button: ::::::::::::::::::::::::::::::00 :: 3300 :: 3300 :: #### #### 3300 :: #### #### 3300 :: ######## 3300 :: #### 3300 :: ######## 3300 :: #### #### 3300 :: #### #### 3300 :: 3300 :: 3300 ::333333333333333333333333333300 00000000000000000000000000000000 where: '::' is color ffffff '33' is color 808080 '00' is color 000000 (404040 in win2k & winxp, not sure about winme) ' ' is the background (default is c0c0c0, but d4d0c8 in win2k...) '##' is black but wine draws it as: ================================00 ==::::::::::::::::::::::::::::3300 ==:: 3300 ==:: #### #### 3300 ==:: #### #### 3300 ==:: #### #### 3300 ==:: ######## 3300 ==:: #### 3300 ==:: ######## 3300 ==:: #### #### 3300 ==:: #### #### 3300 ==:: #### #### 3300 ==:: 3300 ==33333333333333333333333333333300 0000000000000000000000000000000000 where '==' is some other color between '::' and ' ' There are two mistakes: 1. The borders aren't correct. For an active unpushed button, there should only be one "top-left edge". For a pushed button, there should be only one "bottom-right edge" (and inner/outer "top-left edge"s) 2. The 'X' should be drawn a bit more to the right and higher, and smaller. Smaller, because with the correct edges, we need to have (for an unpushed button) a spacing of 3, 2, 2, 2 pixels for the left, top, right, bottom sides respectively, between the 'X' and the edges (look at the correct example above). Higher and more to the right, because after making the 'X' smaller, it should have the correct spacing. Comments please... :) _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

3 4

Re: PATCH: dlls/comctl32/tests/imagelist.c
by Vincent Béron 13 Oct '04

13 Oct '04

Le mer 13/10/2004 à 04:39, Gerald Pfeifer a écrit : > Notice by my nightly builds. This function is not used at all, so > an alternative approach might be to completely yank it. It's used (in a #if 0'd) block to dump differences detected in a test, if the comparison fails. Yes it's not used currently, but I guess it is (or has been) useful in understanding why some tests failed. Maybe we can make the dumping not a compile-time choice but a runtime choice (and default on not doing it)... Vincent

1 0

Wine on Debian on sun4m
by Saulius Krasuckas 13 Oct '04

13 Oct '04

I've decided to try compiling Wine on the Sun SPARC station 4. This machine is running Debian Woody 3.0r2. I am first time Debian installer. Is it completely wrong idea? If no, then going next: I've chose "C and C++ development" task and finished it (by tasksel), so all the related packages were installed. Now, after the run of "./configure" I run "make depend" and get into trouble: s2@austechia:/usr/src/wine-20040914$ make depend cd ./tools && make `basename tools/makedep` make[1]: Entering directory `/usr/src/wine-20040914/tools' gcc -c -I. -I. -I../include -I../include -DLEX_OUTPUT_ROOT="\"lex.yy\"" -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o makedep.o makedep.c In file included from makedep.c:23: ../include/wine/port.h:53: conflicting types for `mode_t' /usr/include/sys/types.h:71: previous declaration of `mode_t' ../include/wine/port.h:56: conflicting types for `off_t' /usr/include/sys/types.h:89: previous declaration of `off_t' ../include/wine/port.h:59: warning: redefinition of `pid_t' /usr/include/sys/types.h:99: warning: `pid_t' previously declared here ../include/wine/port.h:71: conflicting types for `fsblkcnt_t' /usr/include/sys/types.h:247: previous declaration of `fsblkcnt_t' ../include/wine/port.h:74: conflicting types for `fsfilcnt_t' /usr/include/sys/types.h:251: previous declaration of `fsfilcnt_t' make[1]: *** [makedep.o] Error 1 make[1]: Leaving directory `/usr/src/wine-20040914/tools' make: *** [tools/makedep] Error 2 I would like to find the primary reason of this, but am not sure about all the possible combinations of header files. Should I post the output of running ./configure?

3 5

Re: [WineHQ] s/Forums/Mailing Lists/
by Jeremy Newman 13 Oct '04

13 Oct '04

I committed this, but when you go to the page it calls itself Forums still. My instinct was to s/Forums/Mailing Lists/g on forums.template. But I held off to see if anyone had a better idea on how to layout this page. As it stands right now, it does not make sense. On Mon, 2004-10-11 at 10:51, Dimitrie O. Paun wrote: > The latest cleanup patch seems to have reverted this change > that was discussed and implemented long ago. > > ChangeLog > s/Forums/Mailing Lists/ -- _ _ WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman@codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1711553 Yahoo: laxdragon

3 2

Re: winmm/time.c change
by Dmitry Timoshkov 13 Oct '04

13 Oct '04

"Jeremy White" <jwhite(a)codeweavers.com> wrote: > static void TIME_TriggerCallBack(LPWINE_TIMERENTRY lpTimer) > { > - TRACE("before CallBack => lpFunc=%p wTimerID=%04X dwUser=%08lX !\n", > - lpTimer->lpFunc, lpTimer->wTimerID, lpTimer->dwUser); > + TRACE("%04lx:CallBack => lpFunc=%p wTimerID=%04X dwUser=%08lX dwTriggerTime %ld(delta %ld)\n", > + GetCurrentThreadId(), lpTimer->lpFunc, lpTimer->wTimerID, lpTimer->dwUser, > + lpTimer->dwTriggerTime, GetTickCount() - lpTimer->dwTriggerTime); That "%04lx:"/GetCurrentThreadId() shouldn't be there, that's the job of +tid debug channel. -- Dmitry.

2 1

'make check' hangs after crash in msvcrt/tests?
by Dan Kegel 12 Oct '04

12 Oct '04

With this morning's cvs, 'make check' hangs after this point ... make[3]: Entering directory `/home/dank/winebuild/dlls/msvcrt/tests' ../../../../wine/tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p msvcrt_test.exe.so ../../../../wine/dlls/msvcrt/tests/cpp.c && touch cpp.ok fixme:msvcrt:__unDNameEx ((nil),.?AVtest1@@,0,0x40809010,0x40808fcc,(nil),2800) stub! wine: Unhandled exception (thread 005e), starting debugger... Usage: winedbg [--auto] [--gdb] cmdline Sounds like it's invoking winedbg wrong? Also, is there a way to say "I'm running these tests unattended, please don't wait for input"? - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

2 1

cvs update mystery
by Dan Kegel 12 Oct '04

12 Oct '04

Last night I did a cvs update and built, and got a build failure dlls/amstream/amstream.c:40: parse error before "AM_Vtbl" Evidently cvs update failed to update the files in dlls/amstream, as it failed to pick up that part of this change: 2004-08-12 Alexandre Julliard <julliard(a)winehq.com> * dlls/amstream/amstream.c, dlls/amstream/main.c, dlls/avifil32/acmstream.c, dlls/avifil32/avifile.c, ... dlls/winmm/wineaudioio/audio.c, dlls/winmm/wineoss/audio.c, include/objbase.h, include/rpcproxy.h: Get rid of the non-standard ICOM_VTABLE macro. Repeated 'cvs update's didn't fix it. cd'ing into dlls/amstream and doing a cvs update directly in that directory worked, though, and got me new versions of the files in that directory. How strange. Maybe I'll stop using this newfangled cvs system and fall back on the old reliable ... uh, wait, cvs *is* the old reliable one... grr... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 2

Re: Added DWebBrowserEvents and WebBrowser declaration
by Robert Shearman 12 Oct '04

12 Oct '04

Jacek Caban wrote: > Changelog: > - Added dispinterfaces: DWebBrowserEvents and DWebBrowserEvents2 > - Added coclass: WebBrowser > - Added exdispid.h > You forgot the patch. Rob

1 0

COM inheritence
by Ann and Jason Edmeades 12 Oct '04

12 Oct '04

Hiya, If you havent noticed, I'm trying to port the d3d8 code into wined3d and make it common for use from d3d9, and this is all COM objects. I have come across something which in theory would enable me to tidy my code simply, but I cant see how to make it work in C. Now I have a class, for example FRED who implements some common functions, and all the code for it would be in fred.c. I also have a subclass, defined called JIM, which needs to have entrypoints as per fred, plus some more, and its code resides in jim.c. Still with me...? Now previously, inside jim, I have duplicated all the common functions, but I want to avoid this and just call the one definition. My plan was to change the Vtbl to look like: IJimVtbl Jim_Vtbl = { IJimImpl_QueryInterface, IJimImpl_AddRef, IJimImpl_Release, IFredImpl_CommonFunc1, IFredImpl_CommonFunc2, : IJimImpl_UniqueFunc1 etc } I was also ensuring the variable definitions in the IJimImpl structure map precisely over the IFredImpl structure, before any unique variables are defined (I think this is a necessity for emulating subclassing in C?). Now, obviously if the common funcs need changing I can copy in the code, and change the vtbl to have a local override but at the moment I dont need to (they are mostly stubs even in the d3d8 code today). However, doing this fails to compile - It wont allow me to have a vtbl in jim.c which includes pointers to functions which are in fred.c, even if I have extern prototypes defined. Basically this is because array initialization requires constant values. However, this would seem something which is so common - ie inheritence is used all over the place. How do people handle this? I've looked through a few places in the code and cant see how this can be done. I could 'pretend' by initializing the Vtbl as I create the com object and do some LoadLibrary type dynamic addressing but I really want link time resolution not load time resolution. One solution would be to put the common routines in a header file, and #include it, but code in headers or #including modules is uaually frowned upon! I cant see any sensible way of doing this and I'd rather not do lots of code duplication if avoidable as this common class is used in about 7 other classes! Jason

2 3

Re: Fix for bug 824 - proper handling of REG_MULTI_SZ
by Dimitrie O. Paun 12 Oct '04

12 Oct '04

> * - the modification time optionally follows the key name > - * - REG_EXPAND_SZ and REG_MULTI_SZ are saved as strings instead of hex > + * - REG_EXPAND_SZ are saved as strings instead of hex > + * - REG_MULTI_SZ are saved hex (as of 10/10/04 -- see Bug 824) > */ Well, I don't know if the fix is correct, but if it is, just remove the comment instead of saying it's fixed, otherwise we risk cluttering the real issues to the point where they are useless. -- Dimi.

1 0

Re: Fix for bug 824 - proper handling of REG_MULTI_SZ
by Chris Morgan 12 Oct '04

12 Oct '04

It would be useful to roll this test into the integrated winetests so we can check this behavior on all windows platforms and prevent it from breaking in the future. Chris > > From: Randy Galbraith <randy.galbraith(a)cox.net> > Date: 2004/10/11 Mon PM 09:19:42 EDT > To: wine-patches(a)winehq.org > Subject: Fix for bug 824 - proper handling of REG_MULTI_SZ > > This proposed patch addresses the concern raised by bug 824. This patch > changes the handling of REG_MULTI_SZ from REG_SZ to REG_BINARY. For > more details follow this URL: > > http://bugs.winehq.org/show_bug.cgi?id=824 > > To see a test program follow this URL: > > http://members.cox.net/~rgalbraith10/wine/bug824/demo824.c > http://members.cox.net/~rgalbraith10/wine/bug824/Makefile > > ===begin diff -u output of wine/server/registry.c 1.60=== > --- registry.c- 2004-10-10 10:46:15.000000000 -0700 > +++ registry.c 2004-10-10 12:26:35.000000000 -0700 > @@ -157,7 +157,8 @@ > * - strings and key names can contain \x escapes for Unicode > * - key names use escapes too in order to support Unicode > * - the modification time optionally follows the key name > - * - REG_EXPAND_SZ and REG_MULTI_SZ are saved as strings instead of hex > + * - REG_EXPAND_SZ are saved as strings instead of hex > + * - REG_MULTI_SZ are saved hex (as of 10/10/04 -- see Bug 824) > */ > > > static inline char to_hex( char ch ) > @@ -195,7 +196,6 @@ > { > case REG_SZ: > case REG_EXPAND_SZ: > - case REG_MULTI_SZ: > if (value->type != REG_SZ) fprintf( f, "str(%d):", value->type ); > fputc( '\"', f ); > if (value->data) dump_strW( (WCHAR *)value->data, value->len / > sizeof(WCHAR), f, "\"\"" ); > @@ -1123,7 +1123,7 @@ > { "\"", 1, REG_SZ, REG_SZ }, > { "str:\"", 5, REG_SZ, REG_SZ }, > { "str(2):\"", 8, REG_EXPAND_SZ, REG_SZ }, > - { "str(7):\"", 8, REG_MULTI_SZ, REG_SZ }, > + { "hex(7):", 8, REG_MULTI_SZ, REG_BINARY }, > { "hex:", 4, REG_BINARY, REG_BINARY }, > { "dword:", 6, REG_DWORD, REG_DWORD }, > { "hex(", 4, -1, REG_BINARY }, > ===end diff -u output=== > This is my first attempt at creating a patch for wine. Any feedback is > greatly appreciated. > > Kind regards, > -Randy Galbraith > > >

1 0

winetest fails enumerating test files
by Saulius Krasuckas 12 Oct '04

12 Oct '04

It shows some message-box telling: "Can't enumerate test files: 1813" Greping programs/winetest/main.c gives: | report (R_STATUS, "Counting tests"); | if (!EnumResourceNames (NULL, MAKEINTRESOURCE(TESTRES), | EnumTestFileProc, (LPARAM)&nr_of_files)) | report (R_FATAL, "Can't enumerate test files: %d", | GetLastError ()); | wine_tests = xmalloc (nr_of_files * sizeof wine_tests[0]); I guess this may be some regression (have been running winetest a whole month ago last time). Am I alone with this?

2 3

Re: wineserver contexts for Alpha
by Steven Edwards 12 Oct '04

12 Oct '04

Hi, --- Vincent B�ron <vberon(a)mecano.gme.usherb.ca> wrote: > There are two definitions of _CONTEXT for Alpha in winnt.h: one > protected by __ALPHA__ (added by Steven 2 years ago), and one > protected > by _ALPHA_, which is the same kind of protection as MSVC. Should we > dump > the __ALPHA__ one and change configure to define _ALPHA_ instead? Yes sorry dump the one I added. I totally missed it and did not have MSVC+PSDK installed then. Thanks Steven _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

1 0

tchar.h
by Martin Fuchs 11 Oct '04

11 Oct '04

Hello, can anyone explain to me, what's the exact reason for the following error message in wine/include/tchar.h: #if defined(_UNICODE) || defined(_MBCS) #error You must use msvcrt when building in Unicode/MBCS mode #endif It disallows inclusion of this <tchar.h> header file when using the _UNICODE define. Just a few lines later in this file there are the following definitions: /***************************************************************************** * tchar mappings */ #ifndef _UNICODE # ifndef _MBCS # include <string.h> # define WINE_tchar_routine(std,mbcs,unicode) std # else # include <mbstring.h> # define WINE_tchar_routine(std,mbcs,unicode) mbcs # endif #else /* _UNICODE */ # include <wchar.h> # define WINE_tchar_routine(std,mbcs,unicode) unicode #endif Again asking for "_UNICODE" ! So something can't be right with this. The <tchar.h> header should really define constants like _tcschr dependend on the _UNICODE define. But currently this doesn't work because of the error message described above. Either there should be a overriding "wine/include/msvcrt/tchar.h" file with different defintions. Or the error message "You must use msvcrt when building in Unicode/MBCS mode" is simply superfluous. Regards, Martin

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel