wine-devel

wine-devel@winehq.org

84471 discussions

Wine and Font-Rendering, copy/paste (partial solution)
by Roland Kaser 15 Feb '06

15 Feb '06

Hello As seen on My previous post about copy/paste and font rendering, both functions does work on some systems but not on other. I made some test installations with SuSE 10 and wine 0.9.7 (the rpm version form Marcus) and found a partial solution: It seems that the font-rendering and copy/paste works on SuSE 10 (original installed system, without and SuSE online update). As soon the first SuSE Online Update was made, the font-rendering and copy/paste refuses to work. I'm currently not sure whats the exact reason for this behaviour. Does eventually somebody has close contacts to the SuSE developers and can discuss it with them? The Error is definitively reproducable on diffrent hardware types. Kind regards Roland Kaeser

1 0

Re: [RESENT] Don't duplicate handles for _get_osfhandle
by Alexandre Julliard 15 Feb '06

15 Feb '06

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > wine/dlls/msvcrt/file.c: _get_osfhandle > Don't duplicate handles, otherwise they leak > > This time with test case that fails without the patch (but succeed with > native msvcrt). It would be nice to also add a test for the case that the DuplicateHandle was supposed to fix, so that we can avoid reintroducing that bug. -- Alexandre Julliard julliard(a)winehq.org

2 1

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

15 Feb '06

To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 under Wine routinely, I benchmarked their startup time on a Fedora Core 5 test 2 system under four conditions: native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM (by booting with mem=96M; this was to simulate running on one of those cheapo 128MB boxes that uses shared video RAM). This was on a zippy Compaq Presario 3000 Athlon 64 3000+. All apps were downloaded from openoffice.org and mozilla.com. Results for first run of app after booting (1st column is startup time): 5 Firefox run1 native 416MB 12 Firefox run1 wine 416MB 11 Firefox run1 native 96MB 15 Firefox run1 wine 96MB 11 ooo run1 native 416MB 15 ooo run1 wine 416MB 60 ooo run1 native 96MB 37 ooo run1 wine 96MB So wine is 1.4 to 2.5 times slower at app startup generally, but when ram is really short, win32 openoffice starts up with wine 1.5 times *faster* than the native linux version! (Maybe because the Microsoft tools are better at avoiding I/O or relocations during loading?) I then measured how long it took to start up the app the second time, when the cache was nice and hot: 3 Firefox run2 native 416MB 4 Firefox run2 wine 416MB 4 ooo run2 native 416MB 6 ooo run2 wine 416MB 4 Firefox run2 native 96MB 6 Firefox run2 wine 96MB 36 ooo run2 native 96MB 28 ooo run2 wine 96MB The times are uniformly faster on the second run, but the patter holds, i.e. wine is 1.4-1.5 times slower than native generally, but win32 openoffice under wine is 1.5 times *faster* than the native version when starved for RAM. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 12

[d3d8] question about "bogus" code
by Christoph Frick 15 Feb '06

15 Feb '06

hiho as with newer versions more and more games i try no longer work (which worked with wine around 0.9.0) i try to find the reasons. i stumbled over this code in dlls/d3d8/surface.c: date: 2006-02-14 17:05:35 +0000; author: julliard; state: Exp; lines: +202 -319 Roderick Colenbrander <thunderbird2k(a)gmx.net> d3d8: Move d3d8 surface over to wined3d (based on the work of Oliver Stieber). 149 1.48 (julliard 14-Feb-06): if (This == D3D8_SURFACE_GET_DEVICE(This)->backBuffer || This == D3D8_SURFACE_GET_DEVICE(This)->renderTarget || This == D3D8_SURFACE_GET_DEVICE(This)->frontBuffer || D3D8_SURFACE_GET_DEVICE(This)->depthStencilBuffer) { 150 1.48 (julliard 14-Feb-06): if (This == D3D8_SURFACE_GET_DEVICE(This)->backBuffer) { 151 1.48 (julliard 14-Feb-06): TRACE("(%p, backBuffer) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 152 1.48 (julliard 14-Feb-06): } else if (This == D3D8_SURFACE_GET_DEVICE(This)->frontBuffer) { 153 1.48 (julliard 14-Feb-06): TRACE("(%p, frontBuffer) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 154 1.48 (julliard 14-Feb-06): } else if (This == D3D8_SURFACE_GET_DEVICE(This)->renderTarget) { 155 1.48 (julliard 14-Feb-06): TRACE("(%p, renderTarget) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 156 1.48 (julliard 14-Feb-06): } else if (This == D3D8_SURFACE_GET_DEVICE(This)->depthStencilBuffer) { 157 1.48 (julliard 14-Feb-06): TRACE("(%p, stencilBuffer) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 158 1.9 (julliard 17-May-03): } 159 1.9 (julliard 17-May-03): } else { 160 1.48 (julliard 14-Feb-06): TRACE("(%p) : rect@%p flags(%08lx), output lockedRect@%p, memory@%p\n", This, pRect, Flags, pLockedRect, D3D8_SURFACE(This)->resource.allocatedMemory); 161 1.9 (julliard 17-May-03): } why is in line 149 for the depthStencilBuffer check not comparing against This like in three checks before? if there is a reason, if would be good to have a comment there - otherwise it looks like an error. -- cu

4 3

DSOUND bugs
by Tomas Carnecky 15 Feb '06

15 Feb '06

I'm really wondering why nobody has fixed the DSOUND buffer underrun bugs.. I get lots of these message when I run World of Warcraft: err:wave:wodPlayer_ProcessMessages pcm_pause failed: Input/output error err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fda2038 I can fix these buffer underruns partially by playing with the buffer size in asoundrc, but it never disappears completely. It gets worse if I also start TeamSpeak (which btw. uses 50% of the CPU)), but I can play videos using totem or mplayer or listen to music without any xruns. is it really unknown where the bug is? because I'm willing to test patches and helm looking where the bug might be.. tom

3 5

crosstool-0.40 status 2
by Dan Kegel 15 Feb '06

15 Feb '06

Since I'm developing on ubuntu, where the default compiler is gcc-4.0.x, I'm running into a lot of little problems (glibc-2.3.2 unhappy about gcc-4.0 during initial header installation, binutils-2.15 incomplete array type errors). Fortunately, having waited forever to do this update, googling for the errors is turning up proposed fixes. I've also included a few of the cygwin and mac doc fixes and one or two other little fixes people have contributed. I should have something for people to play with in a day or so. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 1

Wine Font Rendering
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 Font/Vector objects functionality of Corel Draw on diffrent SuSE 10 Systems. On one system Rotated Text works fine (without any failure) on a other system, rotated fonts became invisible on the screen. At pdf export, the fonts are normally visible. So it seems to be a graphics subsystem error. No winedebug output at all. Can somebody tell me which system libraries used for the font rendering functions? So that I can compare the two systems to find out where the font-rendering error cames from. Many thanks Roland Kaeser

4 3

Re: Appdb thoughts
by Chris Morgan 14 Feb '06

14 Feb '06

> Unfortunately, I'm not volunteering since I know nothing about the codebase > for either project, but it is really just a matter of creating a new table > and adding a field or two to the existing tables (and updating the > interface, of course). Its written in php and the source is available through cvs if you are interested in taking a look. We can always use help. Chris

1 0

Refcounting fun
by H. Verbeet 14 Feb '06

14 Feb '06

I've run into a somewhat annoying problem with d3d9/wined3d recently. It appears that on d3d9 on Windows a surface either forwards its AddRef / Release calls to its container if it has one, or just shares the refcount directly. Either way, it comes down to the same thing. Calling AddRef on the surface increases the texture's refcount and calling AddRef on the texture increases the surface's refcount. Same thing for Release. As a consequence, on Windows, it's perfectly legal to do something like this: /* Create a texture */ IDirect3DDevice9_CreateTexture() /* Get a surface. Adds a reference to the surface/texture combination */ IDirect3DTexture9_GetSurfaceLevel() /* Release the texture. Note that the texture isn't freed yet, because we still hold a reference to the surface */ IDirect3DTexture9_Release() <Do some stuff with the surface, perhaps call GetContainer, etc> /* Release the surface. The texture and all of it's surfaces will now be released. */ IDirect3DSurface9_Release() In wine, the call to IDirect3DTexture9_Release() frees the texture. (It also calls Release on it's surfaces, but since the surface had an extra reference from the call to GetSurfaceLevel the surface is still ok). Calling any function on the surface that needs access to the container will now have undefines results, most likely a crash. Naively, I tried to fix this by having the surface keep a reference to it's container. That keeps the code above from crashing, but only because it creates a circular reference between the surface and the container. Oops. Fixing the problem for wined3d is probably not even that hard. Just separate the Release code from the Cleanup code, then have WineD3DSurface forward its AddRef / Release calls to the container, if it has one. The container can then call the Cleanup code for its surfaces when it gets deleted. However, there is another problem, related to the way d3d9 (and ddraw/d3d7/d3d8, when their respective rewrites are finished) wraps wined3d. After fixing the problem for wined3d as above, the relation between IDirect3DSurface9 and IDirect3DTexture9 in wine would look roughly like this: |-------------------| |-------------------| | IDirect3DSurface9 | | IDirect3DTexture9 | |-------------------| |-------------------| ^ ^ | | |----------------| |----------------| | WineD3DSurface |<--------->| WineD3DTexture | |----------------| |----------------| WineD3DSurface and WineD3DTexture "share" reference counts, IDirect3DSurface9 keeps a reference to WineD3DSurface, and IDirect3DTexture keeps a reference to WineD3DTexture. WineD3DSurface and WineD3DTexture don't keep references to their parents (and can't, without creating circular references). So releasing the texture before the surface would still not work, since the d3d9 texture still has only 1 reference, the one it got when it was created. That means that in the call to IDirect3DTexture9_Release the d3d9 texture gets freed, while the wined3d texture doesn't. When we do something with the d3d9 surface that needs the container, the wined3d surface correctly returns its container, but when d3d9 then tries to get the parent of that container it still dies. One way to solve this would be to have wined3d handle the reference counting for d3d7/8/9 as well, so that their AddRef/Release calls just call AddRef/Release on the wined3d object they wrap. That would also mean we need to pass a pointer to the d3d7/8/9 object's cleanup function. (Releasing a d3d9 surface to 0 should cause a d3d9 texture to be freed). Note that for creating a texture, currently a similair construction is used, in that IWineD3DDeviceImpl_CreateTexture gets passed a pointer to a d3d9 surface create function, in order to create the texture's surfaces. Obviously doing all that would be quite a change in the way d3d is setup in wine, and would also have some implications for the d3d7 and d3d8 rewrites. I'm wondering if this solution would be acceptable, and whether perhaps there are other, better solutions. Anyone care to comment?

2 14

WINEMP3: increase factor from 4 to 12 in MPEG3_StreamSize
by Alex Villacís Lasso 14 Feb '06

14 Feb '06

This is a summary of what I have been doing with winemp3 over the weekend. First, the idea of a GStreamer wrapper for wine is a no-go because 1) would not solve the jittering problem (more on this later), 2) I have not found yet a streaming source for raw memory buffers (as opposed to file/network streaming), 3) although GStreamer is LGPL, some of the codecs might be proprietary, and this might cause legal problems later on. I fired the ACMAPP.EXE demo program from MSDN (the one I used to improve the msacm implementation), and noticed that MP3-encoded WAV files play almost normally with this app. This means that the codec itself is not the problem - the most likely source is the (odd?) use of msacm by dsound, which is in turn invoked by native quartz.dll. Before reaching this conclusion, I found that ACMAPP.EXE played the files without jittering, but it stopped playing a few moments before the end of the song. How much before depends on the actual length of the song but this was annoying enough to be worth investigating. For example, one sample song stopped playing 30 seconds before the actual end. However, according to the app, playback was already at the end of the song. It turns out that mpglib has a queue of undecoded data in its decoding structure. On every call to the decodeMP3() function of mpglib, the caller specifies either a buffer of new data, or NULL to use the remaining data from a previous invocation. The buffer grows and shrinks dynamically with the amount of unencoded data passed by the caller. What was going on was the following: - Caller (winmm) computes required output buffer for encoded input buffer. This uses acmStreamSize, which in turn invokes MPEG3_StreamSize. - MPEG3_StreamSize return a factor 4X for the size of the output buffer (in my tests, a 2333-byte encoded buffer expands into (at most) 9332 bytes of output, or so reports winemp3). - winmm happily calls acmStreamConvert() with a 2333 source buffer and a 9332 destination buffer. - mpglib decodes as much as it can into the 9332-byte buffer. However, in almost all cases, 9332 bytes is not enough to decode 2333 bytes of MP3 data. This is important to note, because it means a non-trivial amount of the MP3 data remains in the mpglib queue. - acmStreamConvert() is called over and over, with a 2333 source buffer and a 9332 destination buffer. The output buffer is always too small, so the undecoded data in the mpglib buffers accumulates. - winmm sends the last encoded buffer. Supposedly this means that decoding is complete, but it isn't, because mpglib has a backlog of undecoded data which has not been played. However, winmm stops there, and the user notices the cut in the middle of the song. In the same situation, L3CODECA.ACM reports a non-integer factor for the output buffer, a little under 12X. Therefore L3CODECA.ACM always has enough space to consume the full source buffer and therefore does not cut the song in the middle. The ideal solution would be to dynamically compute the expansion factor based on the input and output bitrates. The attached patch raises the expansion factor instead to 12X to ensure that mpglib can always decode all the input data without running out of output space. Changelog: * Increase size factor from 4 to 12 in MPEG_StreamSize, otherwise mpglib buffer queue grows * Add TRACE of mpglib buffer queue for conversion. Alex Villacís Lasso

2 1

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 14 Feb '06

14 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 14 Feb '06

14 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

Re: [TWAIN] Reconcile sane's long names to TWAIN's 32 byte limit
by Robert Shearman 13 Feb '06

13 Feb '06

Jeremy White wrote: >libsane can return arbitrarily long names, but TWAIN supports only a maximum of 32. >Further, the name is a unique identifier, and so must be returned to libsane for processing. > >This algorithm tries to convert a long libsane name into a more reasonable short name, >but adds a crude signature process in an attempt to ensure a unique short identifier. > > > >------------------------------------------------------------------------ > > > dlls/twain/dsm_ctrl.c | 85 ++++++++++++++++++++++++++++++++++++++++++------- > 1 files changed, 73 insertions(+), 12 deletions(-) > >eabadf1c3584adda1a36b199f82bc6bbb17b71da >diff --git a/dlls/twain/dsm_ctrl.c b/dlls/twain/dsm_ctrl.c >index f744939..6d1318d 100644 >--- a/dlls/twain/dsm_ctrl.c >+++ b/dlls/twain/dsm_ctrl.c >@@ -22,6 +22,7 @@ > > #include <stdlib.h> > #include <stdarg.h> >+#include <stdio.h> > > #define NONAMELESSUNION > #define NONAMELESSSTRUCT >@@ -33,6 +34,14 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(twain); > >+inline static LPSTR TWAIN_strdup( LPCSTR str ) >+{ >+ LPSTR ret = HeapAlloc( GetProcessHeap(), 0, strlen(str) + 1 ); >+ if (ret) strcpy( ret, str ); >+ return ret; >+} >+ >+ > /* DG_CONTROL/DAT_IDENTITY/MSG_CLOSEDS */ > TW_UINT16 TWAIN_CloseDS (pTW_IDENTITY pOrigin, TW_MEMREF pData) > { >@@ -83,6 +92,38 @@ TW_UINT16 TWAIN_CloseDS (pTW_IDENTITY pO > #endif > } > >+/* Sane returns device names that are longer than the 32 bytes allowed >+ by TWAIN. However, it colon separates them, and the last bit is >+ the most interesting. So we use the last bit, and add a signature >+ to ensure uniqueness */ >+static char * get_sane_short_name(const char *in) >+{ >+ char *p; >+ LPSTR ret; >+ int signature = 0; >+ >+ if (strlen(in) <= 32) >+ return TWAIN_strdup((char *) in); >+ >+ for (p = (char *) in; *p; p++) >+ signature += *p; > > These casts from const char * to char * shouldn't be necessary. -- Rob Shearman

1 1

Direct3D Z order question
by Stefan Dösinger 13 Feb '06

13 Feb '06

Hello, I have written a small Direct3D7 test application which draws two overlapping triangles, a red one and a blue one. The red triangle has the z value 0.0 (closest to the viewer), the blue one 1.0(far away). Strangely, the blue triangle overlaps the red one on Windows. The same happens on the current ddraw implementation, but in WineD3D the red triangle overlaps the blue one, which is mathematically correct. I've studied the ddraw and wined3d drawing code over and over, but I couldn't find any difference. It seems that on Windows, the triangle that is drawn last overlaps the other one in the output, and the z value seems to be ignored completely. Can someone explain me what's going on here???? The reason for this is the Direct3D mode of Half-Life 1. I've got it working with WineD3D after a long struggle with IDirect3DVertexBuffer::ProcessVertices, except of the HUD, which is hidden. If I force the z value in the [0.0, 1.0] range, it is shown, but the rest is broken obviously. How to run my test program: I've attached a source file and a Makefile which builds a .exe with mingw, and a precompiled exe file. When you run it, it shows a black screen, and if you click anywhere, it draws the triangles. I've some bug in the flipping code, so you have to click two times actually. Pressing esc exits. Thanks, Stefan PS: If anyone needs the d3d7->wined3d code to look at, I can send patches. But it's quite messy now ;)

3 10

Re: GDI: Don't crash when copying to an EMF from a NULL bitmap.
by Alexandre Julliard 13 Feb '06

13 Feb '06

Mike McCormack <mike(a)codeweavers.com> writes: > @@ -84,9 +84,14 @@ static BOOL EMFDRV_BitBlockTransfer( > BITMAP BM; > WORD nBPP; > LPBITMAPINFOHEADER lpBmiH; > - EMFDRV_PDEVICE* physDevSrc = (EMFDRV_PDEVICE*)devSrc; > - HBITMAP hBitmap = GetCurrentObject(physDevSrc->hdc, OBJ_BITMAP); > + EMFDRV_PDEVICE* physDevSrc; > + HBITMAP hBitmap; > > + physDevSrc = (EMFDRV_PDEVICE*)devSrc; > + if (!devSrc) > + return TRUE; You still need to generate the EMF record, you can't just ignore it and return TRUE. -- Alexandre Julliard julliard(a)winehq.org

1 0

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

13 Feb '06

lats wrote: >Index: dlls/usp10/usp10.c >=================================================================== >RCS file: /home/wine/wine/dlls/usp10/usp10.c,v >retrieving revision 1.7 >diff -u -r1.7 usp10.c >--- dlls/usp10/usp10.c 9 Jan 2006 19:55:03 -0000 1.7 >+++ dlls/usp10/usp10.c 12 Feb 2006 05:25:09 -0000 >@@ -39,6 +39,42 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(uniscribe); > >+#define MAX_SCRIPTS 8 >+ >+/* Set up a default for ScriptGetProperties */ >+const SCRIPT_PROPERTIES Default_Script_0 = {0, 0, 0, 0, 0, 0, 0, 0, >+ 0, 0, 0, 0, 0, 0, 0}; > > This can be "static const" instead of just "const". >@@ -69,9 +108,13 @@ > */ > HRESULT WINAPI ScriptGetProperties(const SCRIPT_PROPERTIES ***ppSp, int *piNumScripts) > { >- FIXME("%p,%p\n",ppSp,piNumScripts); >+ FIXME("%p,%p,%p\n",ppSp, *ppSp, piNumScripts); > >- if (piNumScripts) *piNumScripts = 0; >+/* Set up a sensible default and intialise pointers */ >+ *piNumScripts = MAX_SCRIPTS; >+ *ppSp = (SCRIPT_PROPERTIES *)Global_Script; >+ TRACE("ppSp:%p, *ppSp:%p, **ppSp:%p, %d\n", ppSp, *ppSp, **ppSp, >+ *piNumScripts); > return 0; > } > > > The identation of the comment is unusual. >@@ -129,7 +172,60 @@ > if (!pwcInChars || !cInChars || !pItems || cMaxItems < 2) > return E_INVALIDARG; > >- *pcItems = 0; >+/* Set a sensible default */ >+/* Set SCRIPT_ITEM */ >+ pItems[0].iCharPos = 0; >+/* Set the SCRIPT_ANALYSIS */ >+// pItems[0].a.eScript = SCRIPT_UNDEFINED; >+ pItems[0].a.eScript = 2; > > Which is it, SCRIPT_UNDEFINED or 2? Decide this and remove the dead code. -- Rob Shearman

2 1

Czech language resources encoding fix
by Petr Tesarik 13 Feb '06

13 Feb '06

Hi everyone, On 8 Feb I sent a patch to fix the encoding of Czech resources in Wine (see wine-patches), but nothing seems to have happened. Is something wrong with the patch? Of course, I double-checked the "Sending patches" page: # Include a ChangeLog entry with your name, email address and a description of what your patch does. There is a ChangeLog entry and a (IMO concise) description of what the patch does. # Keep the patch small and the point of the change clear. # Submit one fix or group of related changes per patch. Well, OK, I could possibly break the patch into numerous smaller ones, each fixing only one of the resource files. Is that what you expect? # Generate your patch against the latest version of Wine from the WineHQ CVS (see below). It applies cleanly against latest CVS. # Test your patch, and if possible write a test case demonstrating it is correct. Umgh. Does changing a resource string need writing a test case? # Be careful to not corrupt the patch through line-wrapping. Not the case. # Avoid unnecessarily changing the formatting of the code. No. # Use standard C, avoid C++ comments and inline variable declarations. They'r resource files. No C/C++ comments at all. # Read the diff and make sure it contains only what you want in it. Done. Thanks for any clue, Petr Tesarik

2 2

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