February 2006 - Wine-devel - list.winehq.org

Copy / Paste with complex Objects
by Roland Kaser 14 Feb '06

14 Feb '06

Hello Sorry, this is the second post for this reason, but it's important for me to sort this problem out. Can somebody try to get a answer? I noticed a strange behavior of the copy/paste functionality of Corel Draw on diffrent SuSE 10 Systems. On one system copy/paste works fine (without any failure) on a other system there is no function at all. (itss storage error). Can somebody tell me which system libraries used for the copy/paste functions? So that I can compare the two systems to find out where the copy/paste error cames from. Many thanks Roland Kaeser

1 0

Re: WINMM: prevent division by zero in mciwave
by Eric Pouech 14 Feb '06

14 Feb '06

Alex Villacís Lasso wrote: > This was found while digging for the source of the mp3 jittering > problem. Both native L3CODECA.ACM and winemp3 trigger this > division-by-zero exception with ACMAPP.EXE demonstration program from > MSDN when using the Player! menu item with a MP3-encoded .WAV file > unless this patch is applied. > > Changelog: > > * Prevent division-by-zero exception on codecs that do not report > bits-per-sample. > > Alex Villacís Lasso > > > ------------------------------------------------------------------------ > > diff -ur wine-0.9.7-cvs/dlls/winmm/mciwave/mciwave.c wine-0.9.7-cvs-patch/dlls/winmm/mciwave/mciwave.c > --- wine-0.9.7-cvs/dlls/winmm/mciwave/mciwave.c 2005-12-06 16:28:17.000000000 -0500 > +++ wine-0.9.7-cvs-patch/dlls/winmm/mciwave/mciwave.c 2006-02-12 11:52:25.000000000 -0500 > @@ -205,7 +205,7 @@ > ret = val; > break; > case MCI_FORMAT_SAMPLES: /* FIXME: is this correct ? */ > - ret = (val * 8) / wmw->lpWaveFormat->wBitsPerSample; > + ret = (val * 8) / (wmw->lpWaveFormat->wBitsPerSample ? wmw->lpWaveFormat->wBitsPerSample : 1); > break; I think the overall fix is wrong. The computation is correct for PCM files, not for MP3 (and any other non linear compression format). You should check how native mciavi32 behaves here. A+ -- Eric Pouech

1 0

msvcrt: portable printf integer conversions
by Jesse Allen 14 Feb '06

14 Feb '06

I've been trying to get some functionality to the %I64 printf size specifier. My last patch was rejected because it was non-portible. Therefore, I've written an internal function, pf_integer_conv, to handle the conversion of integers only -- not floats. The patch tries to not impact the current printf infrastructure as much as possible, therefore it only forwards %I64 sizes. However, it could be possible to foward all integer types as I wrote it to handle them all, and this is probably the way to go. There are a couple of problems I have discovered in our printf. One is that if flags->Precision is zero, then it is unused. But according to man 3 printf, precision can be explicitly defined as zero. Therefore, we do not handle "zero" precision. The next problem is when we rebuild our format string to handle the integer and floats, and call printf from libc to handle it. It happens to print to a fixed buffer of 40 without checking. If we ever get called to print a number with a field length greater than 40 or whatever large combination, libc will happily print beyond the end of the buffer. These are problems in the current infrastructure and will need to be addressed. Any comments? I'd like to have a better idea on restructuring the printf to handle number conversions before we move forward. I still need to work on floating point too, as of yet. Jesse

1 1

Re: usp10: [RESEND] Add ScriptItemize, ScriptShape and ScriptPlace functionality
by James Hawkins 13 Feb '06

13 Feb '06

On 2/13/06, Jeff L <lats(a)yless4u.com.au> wrote: > This patch is a resend that contains the correct file that combines the > code and the tests, sent previously as two patches, into one patch. It > also has the .cvsignore for dlls/usp10/tests and fixes some issues with > comments and dead code. > You'll have more luck getting this accepted if you send each function implementation in separate patches. Some comments about the patch: if (psc) *psc = NULL; return 0; + HeapFree ( GetProcessHeap(), 0, *psc); + *psc = NULL; You should keep the if (psc), because the user can send in a NULL psc. - FIXME("%p,%p\n",ppSp,piNumScripts); + FIXME("%p,%p,%p\n",ppSp, *ppSp, piNumScripts); If this function is now implemented, it should be a TRACE and not a FIXME. If ppSp is NULL, this call to FIXME will cause a crash (see next comment.) - if (piNumScripts) *piNumScripts = 0; +/* Set up a sensible default and intialise pointers */ + *piNumScripts = MAX_SCRIPTS; + *ppSp = (SCRIPT_PROPERTIES *)Global_Script; Same as above, need to keep the if (ptr) checks. + TRACE("ppSp:%p, *ppSp:%p, **ppSp:%p, %d\n", ppSp, *ppSp, **ppSp, + *piNumScripts); If you *really* need to see all the values of these pointers, then you have to check that each pointer above it is not NULL. + FIXME("(%p,%p,%p,%s,%d,%d, %p, %d, %p, %d): stub\n", hdc, psc, pwcChars, I dont know what this function is supposed to do, but it looks like you've added quite a bit of functionality to this function. If it's not completely implemented, I would change it to semi-stub, so we know it at least does something. Same thing for the rest of the functions. A good first step is to send the tests in the first patch, adding todo_wine's where appropriate. Next send each function implementation in separate patches afterwards, removing todo_wine's from tests that now pass. -- James Hawkins

1 0

Re: user: Fix return type of GetDlgItemText{A,W}
by Troy Rollo 13 Feb '06

13 Feb '06

On Tuesday 14 February 2006 11:59, Troy Rollo wrote: > ChangeLog: > user: Fix return type of GetDlgItemText{A,W} Please disregard this one - the argument types are wrong too. I will follow up with a consolidated patch fixing both -- Troy Rollo - wine(a)troy.rollo.name

1 0

Re: StretchDIBits function problem.
by Cyril Margorin 13 Feb '06

13 Feb '06

Hello, According the patches, I've send before: I've got two small questions: 1) Shouldn't the Shared Memory XImage created in X11DRV_DIB_SetImageBits/X11DRV_DIB_GetImageBits functions? Or creating shared memory image takes too long? 2) Shouldn't XImage be passed to X11DRV_DIB_SetImageBits, and useShm field correctly in X11DRV_SetDIBits? Why it was NULL in X11DRV_GetDIBits and is NULL in X11DRV_SetDIBits, with useShm hardcoded to FALSE? -- Cyril Margorin

1 0

Re: When possible, use tgkill instead of tkill syscall on Linux.
by Robert Shearman 13 Feb '06

13 Feb '06

Eric Pouech wrote: >diff --git a/server/context_x86_64.c b/server/context_x86_64.c >index c102510..e5d8fc2 100644 >--- a/server/context_x86_64.c >+++ b/server/context_x86_64.c >@@ -271,12 +271,12 @@ int get_thread_single_step( struct threa > } > > /* send a signal to a specific thread */ >-int tkill( int pid, int sig ) >+int tkill( int tgid, int pid, int sig ) > { > #ifdef __linux__ > int ret; > __asm__( "syscall" : "=a" (ret) >- : "0" (200) /*SYS_tkill*/, "D" (pid), "S" (sig) ); >+ : "0" (200) /*SYS_tkill*/, "D" (tid), "S" (sig) ); > > Shouldn't this line change "pid" to "tgid" instead of "tid"? -- Rob Shearman

1 0

[winecfg] Localize app specific title
by Paul Vriens 13 Feb '06

13 Feb '06

Hi, the title shown in winecfg is always in English when configuring stuff for an specific application. Any remarks on the patch? Would this work for every language? (I mean will the name of the app always be after the IDS_WINECFG_TITLE_APP) Cheers, Paul. diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc index 22bdeb0..6d5594d 100644 --- a/programs/winecfg/En.rc +++ b/programs/winecfg/En.rc @@ -199,6 +199,7 @@ BEGIN IDS_TAB_AUDIO "Audio" IDS_TAB_ABOUT "About" IDS_WINECFG_TITLE "Wine configuration" + IDS_WINECFG_TITLE_APP "Wine configuration for" IDS_THEMEFILE "Theme files" IDS_THEMEFILE_SELECT "Select a theme file" IDS_AUDIO_MISSING "There is no audio driver currently specified in the registry.\n\nA recommended driver has been selected for you.\nYou can use this driver or select another driver if available.\n\nYou must click Apply for the selection to take effect." diff --git a/programs/winecfg/resource.h b/programs/winecfg/resource.h index 4fac41f..85bf11c 100644 --- a/programs/winecfg/resource.h +++ b/programs/winecfg/resource.h @@ -39,6 +39,7 @@ #define IDS_WINECFG_TITLE 13 #define IDS_THEMEFILE 14 #define IDS_THEMEFILE_SELECT 15 +#define IDS_WINECFG_TITLE_APP 16 /* App specific title */ #define IDD_MAINDLG 101 #define IDB_WINE 104 #define IDD_ABOUTCFG 107 diff --git a/programs/winecfg/winecfg.c b/programs/winecfg/winecfg.c index df2b05f..f87ccf0 100644 --- a/programs/winecfg/winecfg.c +++ b/programs/winecfg/winecfg.c @@ -53,23 +53,22 @@ HMENU hPopupMenus = 0; */ void set_window_title(HWND dialog) { - char *newtitle; + char newtitle[1024]; /* update the window title */ if (current_app) { - const char *template = "Wine Configuration for %s"; - newtitle = HeapAlloc(GetProcessHeap(), 0, strlen(template) + strlen(current_app) + 1); - sprintf(newtitle, template, current_app); + char prefix[1024]; + LoadString(GetModuleHandle(NULL), IDS_WINECFG_TITLE_APP, prefix, 1024); + sprintf(newtitle, "%s %s", prefix, current_app); } else { - newtitle = strdupA("Wine Configuration"); + LoadString(GetModuleHandle(NULL), IDS_WINECFG_TITLE, newtitle, 1024); } WINE_TRACE("setting title to %s\n", newtitle); SendMessage(GetParent(dialog), PSM_SETTITLE, 0, (LPARAM) newtitle); - HeapFree(GetProcessHeap(), 0, newtitle); }

2 1

todo_wine help
by Phil Lodwick 13 Feb '06

13 Feb '06

I have a test in msvcrt/file.c that requires there be no TMP environment variable. I thought I would just do a _putenv("TMP="), but this seems to interfere with todo_wine. Basically, static void test_todo( void ) { todo_wine { ok((1 == 1), "This shows up correctly\n"); } _putenv("TMP="); todo_wine { ok((1 == 1), "This does not show\n"); } } My quick search has not turned up anything obvious. Can somebody help me understand what is going on here? Assuming TMP is actually required by somebody else, how do I correctly do my test and check with no TMP environment variable? Thanks, Phil

1 0

Re: Startup time of OOo2, Firefox 1.5. Some surprises.
by Dan Kegel 13 Feb '06

13 Feb '06

On 2/13/06, Dan Kegel <dank(a)kegel.com> wrote: > It's 4 or 6 seconds for me, too, if I run with 96 MB ram. gaah, I meant "it's fast for me too if I use 400MB of ram". -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0