- wine-devel - winehq.org

Re: msvcrt: Fix _copysign bugs for NAN/INF
by Piotr Caban 25 Mar '15

25 Mar '15

Hi, On 03/24/15 11:10, Zheng Chen wrote: > --- > dlls/msvcrt/math.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) looks like your email client has destroyed the patch (line wraps). You can solve it by e.g. attaching the patch to email. Thanks, Piotr

2 1

winevdm DOS memory range mmap() shenanigans...
by Andreas Mohr 25 Mar '15

25 Mar '15

Hi all, for fun I just tried to run a Lemmings demo downloaded from http://www.pcgaming.ws/download.php?game=lemmings Picture my not overly amused face when I then got the message " winevdm: Cannot start DOS application C:\lemmings\VGALEMMI.EXE because the DOS memory range is unavailable. You should install DOSBox. ". After some wild fprintf trickery in various winevdm / virtual.c / mmap.c parts and subsequent mmap() Internet research it turned out that this message is annoyingly imprecise: a simple echo 0 > /proc/sys/vm/vmmap_min_addr (original value here: 65536) will allow the corresponding mapping, thereby enabling the game to (partially - then seems to have interesting issues at some VGA register parts) launch. I would therefore strongly suggest adding per-platform hint strings in failure case (either passed directly out of the inner reserve_dos_area() helper, or perhaps near the winevdm message). In the Linux case, this message would obviously be something like: ...range is unavailable (you might need to specially tweak /proc/sys/vm/vmmap_min_addr - note that this is a risky operation...). Since this is an important tweak (otherwise tons of DOS applications will bail out, thus rather negatively affecting Wine implementation debugging/reliability progress since nobody will make it there), it would be useful to add such hinting one way or another (I might find the time to do so, and possibly given some additional counseling I might even be able to come up with a sufficiently perfect patch). Thanks, Andreas Mohr

3 2

Re: comctl32/tests: Listview doesn't subclass its header
by Marvin 25 Mar '15

25 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12399 Your paranoid android. === w7u (32 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Regarding GSOC 2015 : Winetest Graphical User Interface
by Sushant makode 24 Mar '15

24 Mar '15

Hello, I am a graduate student at IIIT Hyderabad India and I am interested in this project idea. ( Winetest Graphical User Interface ) I have been reading the documentation.My understanding is to add a form to existing winetest.exe which will have a table with available tests, results. These results will be read from the data which is read by the web interface possibly on the fly. I think we can run specific tests as follows e.g. cd dlls/advapi32/tests make test make services.ok Then after executing the test cases, an option to rerun the test can also be provided alongside the result of the test case. A consolidated result would be put on the same form in winetest. I am working on my GSOC proposal meanwhile It would be helpful if someone can you give some documentation regarding the winetest.exe and how to make changes to it. Thanks in advance. -- Thanks And Regards, Sushantkumar M. Tech. CSE IIIT Hyderabad

1 0

My ideas for GSoC 2015
by HuddenSin Yuan 24 Mar '15

24 Mar '15

Hello, everyone. I’m Yuan Chen, a college student from China. I will have plenty of time to join GSoC 2015 and I have send two patches about mshtml.dll before and now I study gdi32 module and the Computer Graphics. Here is my idea for GSoC 2015. Improve the basic drawing functions and add GM_ADVANCED mode support ===================================== I found several bugs which show many basic curve and fonts drawing functions don’t support the GM_ADVANCED mode[1][2][3]. And the curve will become odd under this mode. I have written a test case to show these problems[9]. 1.add GM_ADVANCED mode support When I find that wine use polygon to fit the rect in GM_ADVANCED mode(polygon function is not good enough according to [4]). So I think we can use bezier spline or B spline to fit the curve like ellipse or arc in GM_ADVANCED mode[5][6]. There is also a paper about fonts capturing[7]. So the driver functions of curve and fonts like draw_arc, draw_glyph will be improved and added the GM_ADVANCED support. 2.improve the basic drawing functions In order to fix those above, we need to improve and add some basic helper functions in dlls/gdi32/dibdrv/graphics.c. get_arc_points will be improved and some helper functions will be added which help to calculate the coordinate of points of the curves in GM_ADVANCED mode.This part will take about three weeks. The bezier function need to be improved to n points instead of 3n+1 points according to Bresenham’s Algorithm[8]. This function will take less than one week. And I also try to improve the ellipse_first_quadrant functions using the Bresenham’s Algorithm.[10] Perhaps my idea is not mature enough, I will be appreciate it very much if anyone give me some advice! Thanks! [1]https://bugs.winehq.org/show_bug.cgi?id=33190 [2]https://bugs.winehq.org/show_bug.cgi?id=35333 [3]https://bugs.winehq.org/show_bug.cgi?id=35169 [4]https://bugs.winehq.org/show_bug.cgi?id=36891 [5]http://sarahfrisken.com/efficientCurveFitting.pdf [6]http://www.dtic.mil/dtic/tr/fulltext/u2/a350611.pdf [7]http://www.cs.uml.edu/~wanthony/91.427_f2008/cglr1/reference.pdf [8]http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm [9]see the attachment “testforadvanced.txt" [10]see the attachment "0001-gdi32-Improve-the-algorithm-of-ellipse_first_quadrant.txt" ---------------------------------------- Best Regards , Yuan Chen

1 0

Re: Google Summer of Code 2015
by Matteo Bruni 24 Mar '15

24 Mar '15

2015-03-24 11:38 GMT+01:00 Лёша Долгавин <dolgavin.alexey(a)gmail.com>: > Hello Matteo, > Hi Alexey, > I'm the last year student of Moscow institute. > I found you as possible mentors in project ideas. And I want to implement > missing APIs in D3DX (math and/or mesh functions). Cool! > So, I have a question: do I need to do some task or you will choose students > for this project from their proposal? Yes, you will have to write a proposal in Melange (i.e. the GSoC website) and have submitted at least one patch to wine-patches to be considered for acceptance. I suggest you to download Wine's source code, build it and give a look at the D3DX code (both the implementation of the existing functions and the tests, that's in dlls/d3dx9_36/ and the tests/ subdirectory within). Then it might be a good idea to try to run some game using d3dx on Wine, you can e.g. search bugs.winehq.org to find some. You can then try to implement one of the missing functions and see how it's like. Eventually you'll have to choose a set of the missing APIs you want to work on during your GSoC and write a suitable proposal. You'll get feedback on it and you'll be able to update it so don't worry on getting it exactly right on the first try. If you have further questions don't hesitate to ask. It's much better if you also include wine-devel(a)winehq.org in cc the next times, others might be able to reply faster / better than me. There is also the #winehackers IRC channel on freenode available. > I have strong knowledge in math and have experience in commercial software > developing. That's good. Make sure to write that in your proposal :)

1 0

Re: [PATCH] findstr: Added test for findstr.
by Stefan Dösinger 24 Mar '15

24 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for your patch! I have a few comments: Am 2015-03-23 um 04:14 schrieb Kaipeng Zeng: > index 5f5e9d5..f3056c7 100755 > --- a/configure > +++ b/configure You don't have to include the change to configure in your patch, Alexandre will update it himself. > diff --git a/configure.ac b/configure.ac > index d23227a..822affe 100644 > ... > WINE_CONFIG_PROGRAM(findstr,,[install]) > +WINE_CONFIG_TEST(programs/findstr/tests) > WINE_CONFIG_PROGRAM(hh,,[install]) I don't think we have any precedent for having tests without having at least a stub implementation. Personally I don't see anything wrong with having just a test for now. Can you make sure that the test is properly built and included in winetest.exe? Do you intend to implement the program itself? > +static DWORD runcmd(const char* cmd, char *output) > ... > + CloseHandle(hRead); > + return TRUE; > +} I think it would be a good idea to return the return value of findstr here instead of always returning true when CreateProcess succeeds. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVD/UWAAoJEN0/YqbEcdMwh8EP/37ev7ZrJHzmNy5AJfbuzY/s 3wxUIKIo5hwrjJeiwpdFCWAtDQGMo3Hz8weLLyAaCpT4OVrzz/DvbWFLxX3zCl2Z 9EhetkZkyfiPBUF1T+s/WdTse51J9qeP8mFI7NgQdwuwUOXyp2Ba7Kq8DVBM6sNW MtWsKdItE298jTzL21oQ59w9ar6YrFwRTcVcvLQ3JPmLKSfJ5MR2qT1SxIO6nVC9 Omqc89R9Ba3jSFv+5c3l0Zn6zgnf/U5YBPmsOMYb9DWLNvD0ZgiBh5NZkLxYcV16 NLHQWxJy3mO11RNyjSn1Ank26rR1MiM4kVT7tK3WvneM1IZW7Z/RugGaymtTgfBq vIIMKidz2hPrIwmuy4AYSEb9ScJIT+b2DCbwgJEWgmxTPl3mymW5ltXLx8yzcmhV y7GNYGVKuaH6CZeyHLimeLGA845qCzXW15vWxaB6PGw+lVlqpq4mWJnWcB2NOsC+ Auw4vubTf8KTs2UHyQily9AaahthU5IkZA6sPBDpTlZCNlGpRXa+gW88WpKjd5wV 5y9otOU49Fhp704uZAiVcX9ag5cTFaseu0AsTN/TKmYToA50bzAmJr+2/+nJEQIf lcahIWPeyYw1u7rF3cOEZfkN7FIx/ab1gv1hETLvyoKz/nnYb9NPztnnK3HDFNRP XJl+R82YChN/YV946HfO =6sQQ -----END PGP SIGNATURE-----

3 6

Re: msvcrt: fix _copysign(1., -0.) error
by Piotr Caban 24 Mar '15

24 Mar '15

On 03/22/15 14:51, Kevin Chan wrote: > float CDECL MSVCRT__copysignf( float num, float sign ) > { > - /* FIXME: Behaviour for Nan/Inf? */ > - if (sign < 0.0) > - return num < 0.0 ? num : -num; > - return num < 0.0 ? -num : num; > + /* FIXME: Behaviour for signbit(NAN) is different in Linux and > + * Windows, where Windows gives a zero for -NAN > + */ > + if (signbit(sign)) > + return signbit(num) ? num : -num; > + return signbit(num) ? -num : num; It doesn't make sense to add this comment and remove it in next patch. I would also prefer if signbit fallback implementation is changed in this patch. +/* FIXME: Doesnot work with +-NAN and -0. */ There's a typo in this comment. Also it works for NAN with sign bit set to 0. +#define signbit(x) ((x) < 0 ? 1 : 0) This can be simplified to: #define signbit(x) ((x)<0)

2 1

Re: msvcrt: Add errno EDOM setting for atan(NAN)/exp(NAN)/tanh(NAN)
by Piotr Caban 24 Mar '15

24 Mar '15

Hi, On 24/03/15 09:01, Zheng Chen wrote: > --- > dlls/msvcrt/math.c | 3 +++ > 1 file changed, 3 insertions(+) The patch needs to be generated on top of clean wine. This will not apply without applying all your earlier patches. Please send a patch that contains all the changes to atan, exp and tanh functions. Thanks, Piotr

2 1

Re: msvcrt: remove errno EDOM from atan, exp and tanh
by Piotr Caban 24 Mar '15

24 Mar '15

Hi, On 03/22/15 14:50, Kevin Chan wrote: > double CDECL MSVCRT_atan( double x ) > { > - if (!isfinite(x)) *MSVCRT__errno() = MSVCRT_EDOM; > return atan(x); > } I've done a little more testing. The function is not setting errno in INF and -INF case. It does set errno to EDOM when argument is NAN. Thanks, Piotr

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 4)
by Nikolay Sivov 24 Mar '15

24 Mar '15

Looks good, thanks.

1 0

submitting report
by Shubham kumar 24 Mar '15

24 Mar '15

I ran winetest.exe on my pc and it generated a output file resDD89.tmp. How can i view this report? On which website i have to upload this file to generate the log? Thank you

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 3)
by Nikolay Sivov 23 Mar '15

23 Mar '15

On 03/23/2015 10:44 PM, Mark Harmstone wrote: Hey, looks much better, thanks. One minor thing left, and I'm sorry that I missed it last time: > + if (theme) { > + DrawThemeText(theme, hdc, HP_HEADERITEM, state, phdi->pszText, > + lstrlenW(phdi->pszText), DT_LEFT|DT_END_ELLIPSIS|DT_VCENTER|DT_SINGLELINE, > + 0, &r); > + } else { > + Will it work as docs claim if you simply pass -1 as a text length? Otherwise looks good to me.

1 0

Re: [PATCH 1/5] wined3d: Only set TEXTURE_COMPARE_FUNC when ARB_depth_texture is supported.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 23 March 2015 at 18:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - if (desc->compare) > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > - wined3d_gl_compare_func(desc->comparison_func))); > + if (gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + if (desc->compare) > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > + wined3d_gl_compare_func(desc->comparison_func))); > + } Does the driver generate GL errors without this? The way I read the ARB_sampler_objects spec that would a driver bug. (Specifically, it states that TEXTURE_COMPARE_MODE/TEXTURE_COMPARE_FUNC are accepted by SamplerParameter(), without qualifying that with a dependency on ARB_depth_texture. I guess a driver that doesn't support depth textures can essentially just ignore the texture compare mode/function, since it would never encounter a texture it would apply to.)

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Stefan Dösinger 23 Mar '15

23 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/23/15 15:50, Sebastian Lackner wrote: > + format = D3DFMT_DXT5; > + width = 5; height = 5; > ... > + ok(mipmaps == 1, "Returned mipmaps %d, expected %d\n", mipmaps, 1); I'm curious, why does it report 1 mipmap level? Maybe because width / 2 is smaller than the block size, even though the block-size aligned width would allow a second level. What does d3dx9 return when you have width = height = 10 for example? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVEDcbAAoJEN0/YqbEcdMwVyAQAIusV1Z29v1LQQGKJtBdZk9C g+KRkCEcHalFEjwSHL4689U+GtQVigN1OSIJAtsSvrHBpslwtwsA+q7Crgamuk2X zQ+sxYOHE3QIoD2yy/uQElKxfLZWzBQjeUjZGMdYPLv4Bc2NRp4tMexPMKsHVeDx WubraUfiG40uWwcuFTfODuwuybZjWBUk89PIy865PS++/24wO12WB5vP+dK4XEB4 Mrv4Vzv+8f2zVO+tIWtXgr439f4skF4o5peOwe8qN7KxNSkqKduIWf/5dLfgZhgt lqUrziNNcWaVy5poM/cVeo7P4KKMJLjlT9ehItGee1S7gUUiatyGAKyttN5zauiV SRqJSq8sKWSGCDb/779aTonPVkLnHZVWHblJAihrCBuyE3tZVJpgg9xE3rWMyM8d IstQxbGEgDgQmrXxkeox6M3FnkBp3NL8ALzL5NHHoUxPJMg1yz5cGWuiqdBGYPM1 LmqynuRlXERLBMen/Rn69f/KFdGgqitPhzPupZ3nIGAi1Cku4Vjwd92nUS9ruZS9 uTT0t+wAjCvfKMBCfj0nnmQ4y7W9bmCxDVZs/Md83Ed4G49crTo7XTtrZnWDH4GU gFoGbn+BjcU7uankhoC5tq+XatHr6oRkWIrO5jJg2Oyk9Wns5cyanuvfGdwYrQT8 T+IYcghTfBRrDRNKHrqg =YJRY -----END PGP SIGNATURE-----

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 23 March 2015 at 15:50, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > + if (w % fmt->block_width) > + w += fmt->block_width - w % fmt->block_width; > + if (h % fmt->block_height) > + h += fmt->block_height - h % fmt->block_height; Could you please just use the conventional way to align something?

1 0

Counting bits set in a 32 bit value
by Bruno Jesus 23 Mar '15

23 Mar '15

Hi all, after some manual testing I noticed that the joystick structure member dwButtonNumber is not the last button pressed but instead the count of pressed buttons. There is a bit field of buttons set in the structure member dwButton, to fix the number in dwButtonNumber I guess the easiest way is to count the bits set. I think that keeping a counter with ++/-- operations could lead to out of sync situations if the joystick is not polled fast enough. Is there any precedent need for this in wine? Is there an accepted solution for it? Internet searching shows different ways like bit counting with shift, using cpu instructions or internal compiler functions. Best wishes, Bruno

2 1

Re: dsound: Fix angle to sound source calculation.
by Andrew Eikum 23 Mar '15

23 Mar '15

This seems sane to me, but I never had a good grasp on this to begin with. Does it look OK to you, Mark? Andrew On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote: > This patch fixes incorrect sound positioning in dsound. > As of now, angle to sound source is calculated as angle between > vDistance and vOrientFront. > This leads to incorrect results for all sources that are not in the > same plane as speakers. > In extreme case: for sources directly above or below origin, angle is > calculated to -90 degrees, and they are played in the left speaker. > > This patch changes angle calculation: angle to sound source is > calculated as angle between vDistance and plane given by vectors > vOrientFront and vOrientTop. > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001 > From: Stas Cymbalov <dummyunit(a)gmail.com> > Date: Sun, 22 Mar 2015 18:22:49 +0300 > Subject: dsound: Fix angle to sound source calculation. > > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > > diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > index 9a0226a..ffd4d45 100644 > --- a/dlls/dsound/sound3d.c > +++ b/dlls/dsound/sound3d.c > @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT > > cos = product/(la*lb); > angle = acos(cos); > - if (cos < 0.0f) { angle -= M_PI; } > TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x, > b->y, b->z, angle, RadToDeg(angle)); > return angle; > @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb) > else > { > vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop); > - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance); > - > - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle > - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from > - * this whether the sound is to our left or to our right. We have to perform another dot > - * product, with a vector at right angles to the initial one, to get the correct angle. > - * The angle should be between -180 degrees and 180 degrees. */ > - if (flAngle < 0.0f) { flAngle += M_PI; } > - if (flAngle2 > 0.0f) { flAngle = -flAngle; } > + /* To calculate angle to sound source we need to: > + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0. > + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector > + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case). > + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance > + * and vOrientFront. > + */ > + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance); > + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > + if (flAngle2 > M_PI_2) > + flAngle = -flAngle; > + flAngle -= M_PI_2; > + if (flAngle < -M_PI) > + flAngle += 2*M_PI; > } > TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan); > > -- > 2.0.5 > >

1 0

Re: [PATCH 4/4] ddraw/tests: Port test_color_fill to earlier versions.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 12:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (tests[i].caps & DDSCAPS_ZBUFFER) > + { > + surface_desc.dwFlags &= ~DDSD_PIXELFORMAT; > + surface_desc.dwFlags |= DDSD_ZBUFFERBITDEPTH; > + U2(surface_desc).dwZBufferBitDepth = get_device_z_depth(device); > + } > + > + hr = IDirectDraw2_CreateSurface(ddraw, &surface_desc, &surface, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x, surface %s.\n", hr, tests[i].name); > + This crashes for me: ddraw2.c:7654: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw2.c:7654: this is the last test seen before the exception ddraw2: unhandled exception c0000005 at 00437C9D And similarly for ddraw1: ddraw1.c:6636: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw1.c:6636: this is the last test seen before the exception ddraw1: unhandled exception c0000005 at 004167BD

1 0

Re: [PATCH 5/5] wined3d: Don't use the builtin FFP uniforms for texture transformation matrices.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 13:50, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + get_texture_matrix(context, state, tex, &mat); > + GL_EXTCALL(glUniformMatrix4fv(prog->vs.texture_matrix_location[tex], 1, FALSE, (GLfloat *)&mat)); Like 110106. > + for (i = 0; i < MAX_TEXTURES; ++i) > + { > + char name[22]; > + > + sprintf(name, "ffp_texture_matrix[%u]", i); I'd feel slightly happier if this kind of thing used snprintf(), but I also think it's about time we start using something along the lines of shader_addline() for these.

1 0

Re: [PATCH 3/5] wined3d: Don't use the builtin FFP uniform for the projection matrix.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 13:50, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (update_mask & WINED3D_SHADER_CONST_FFP_PROJ) > + { > + struct wined3d_matrix projection; > + > + get_projection_matrix(context, state, &projection); > + GL_EXTCALL(glUniformMatrix4fv(prog->vs.projection_matrix_location, 1, FALSE, (GLfloat *)&projection)); I'd prefer that as "&projection._11", avoiding the cast.

1 0

Re: user32: Fix padding in user_thread_info structure.
by Alexandre Julliard 23 Mar '15

23 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Based on the comment above only TEB->Win32ClientInfo should be used to store the struct user_thread_info. > The padding got out of sync in cb3b7237925a24ba4c5696dd079fdc5d99a48577 where the 64-bit situation was ignored. > The pshpack4 is required because the struct has a size of 31 ULONGs, and gcc will otherwise align the whole > struct up to 8 bytes on 64-bit. I've confirmed manually with C_ASSERTs that the offsets/sizes are right and > that it matches what we expect. I don't see any need to change the packing, there's still enough room. I'd suggest to simply replace the padding with an assert on the structure size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32: Use correct font for themed headers. (try 2)
by Nikolay Sivov 23 Mar '15

23 Mar '15

On 23.03.2015 10:51, Mark Harmstone wrote: Hi, Mark. Thanks for looking into this. > + > + if (theme) { > + LOGFONTW lf; > + HRESULT hr = GetThemeFont(theme, hdc, HP_HEADERITEM, state, TMT_FONT, &lf); > + if (SUCCEEDED(hr)) { > + font = CreateFontIndirectW(&lf); > + if (!font) > + TRACE("Failed to create font\n"); > + else { > + TRACE("font = %s\n", debugstr_w(lf.lfFaceName)); > + oldfont = SelectObject(hdc, font); > + created_font = TRUE; > + } > + } else { > + font = (HFONT)SendMessageW(infoPtr->hwndSelf, WM_GETFONT, 0, 0); > + oldfont = SelectObject(hdc, font); > + } > + } > + > DrawTextW (hdc, phdi->pszText, -1, > &textRect, DT_LEFT|DT_VCENTER|DT_SINGLELINE|DT_CALCRECT); > cw = textRect.right - textRect.left + 2 * infoPtr->iMargin; > + > + if (font) SelectObject(hdc, oldfont); > + if (created_font) DeleteObject(font); This seems to essentially duplicate GetThemeTextExtent(). Any reason why you can't use it instead?

1 0

Adding HID joystick support to FreeBSD
by Bruno Jesus 23 Mar '15

23 Mar '15

Hi, all. In order to add HID joystick support to FreeBSD I need to do some changes I never did before so I could use some help. I tried to understand the changes made by Ken in order to add the winmm OSX driver but I don't get it =) In simple words I need to ensure that usbhid.h and dev/usb/usbhid.h exist and only if they exist compile the winejoystick driver. I believe it's a change in configure.ac but I tried adding these .h files to the long list of other .h files and it didn't work. Also I guess a similar change is needed like Ken did to enable the driver building: -test "$ac_cv_header_linux_joystick_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no} +test "$ac_cv_header_linux_joystick_h" = "yes" -o "$ac_cv_header_IOKit_hid_IOHIDLib_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no} Can anyone help? Best wishes and thanks in advance, Bruno

6 7

Re: comctl32/listview: Update view on style change only if LVS_TYPEMASK styles have changed
by Marvin 23 Mar '15

23 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12359 Your paranoid android. === w7u (32 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

WIP: FreeBSD 10 usbhid joystick support
by Bruno Jesus 23 Mar '15

23 Mar '15

For those wondering (probably a few, lol) this is the WIP patch that is actually working for the standard HID gamepad I have. I also tried testing in a PS2 controller attached in a USB converter but FreeBSD does not recognize it. The configure part is still missing and it required "-lusbhid" to compile and I didn't find the correct place to add that so I'm currently compiling manually. I labeled it as FreeBSD 10 only because it was the only one I tried, probably may require changes to support other BSD systems. This task is proving to be harder than I expected due to my lack of knowledge in the area and any help testing is appreciated specially with different gamepads/joysticks (for example a joystick with a HAT). The problem with configure.ac is that both usbhid.h and dev/usb/usbhid.h must be included and that would require a compound "-o" switch to ensure that both must be present in order to make the driver. The last problem is where to put that -lusbhid is required when compiling the file. And of course testing in the configure script if usbhid lib is present. Best regards, Bruno

1 0

Re: [PATCH 3/3] scrrun: Support BYREF types for integer keys
by Marvin 22 Mar '15

22 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12362 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:542: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:542: Test failed: got hash 0x000001f4

1 0

Re: [PATCH 2/3] scrrun: Added support for VT_DATE keys, and BYREF float key types
by Marvin 22 Mar '15

22 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12361 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:508: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:508: Test failed: got hash 0x000001f4

1 0

Re: msvcrt: Fix bugs in math.c
by Piotr Caban 22 Mar '15

22 Mar '15

Hi, On 03/22/15 12:28, 陈正 wrote: > - Fixed the problem of atan(INF)/tanh(INF)/exp(INF) causing errno EDOM > - Fixed the error of _copysign(1., -0.) returning 1 Please don't send unrelated changes in one patch, please split it into 2 patches. The changes that remove errno setting from atan, tanh and exp looks good for me. > float CDECL MSVCRT__copysignf( float num, float sign ) > { > - /* FIXME: Behaviour for Nan/Inf? */ > - if (sign < 0.0) > - return num < 0.0 ? num : -num; > - return num < 0.0 ? -num : num; > + /* FIXME: Behaviour for signbit(NAN) is different in Linux and > + * Windows, where Windows gives a zero for -NAN > + */ > + if (signbit(sign)) > + return signbit(num) ? num : -num; > + return signbit(num) ? -num : num; > } Why don't you add an isnan() check? Is there any reason for returning "signbit(num) ? -num : num" instead of returning num? It would be nice to also change signbit definition on systems that doesn't support it, so it at least works for normal numbers. Thanks, Piotr

3 6

Re: [PATCH 2/4] ddraw/tests: The testbot applies color keying without a key.
by Marvin 22 Mar '15

22 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12332 Your paranoid android. === w8 (32 bit ddraw1) === ddraw1.c:6302: Test failed: Got unexpected color 0x000000ff. ddraw1.c:6306: Test failed: Got unexpected color 0x00000080.

2 2

Re: [PATCH] wined3d: Don't use the builtin FFP uniform for the normal matrix.
by Matteo Bruni 21 Mar '15

21 Mar '15

2015-03-20 18:56 GMT+01:00 Matteo Bruni <mbruni(a)codeweavers.com>: > + memcpy(out, &temp, sizeof(temp)); Meh. Then there is the missing check for the singular matrix case as Sebastian spotted. I'll do some tests and resend, or send just a patch readding some calls to set GL_MODELVIEW if that takes too long.

1 0

Re: [PATCH] advapi32: succeed for null pointer in ChangeServiceConfig2
by Stefan Dösinger 20 Mar '15

20 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Good work debugging this. My knowledge about advapi32 is limited, but I have a comment about the test: Am 2015-03-19 um 13:06 schrieb Bernhard Übelacker: > + pConfig->lpDescription = NULL; > + ret = pChangeServiceConfig2A(svc_handle, SERVICE_CONFIG_DESCRIPTION,buffer); > + ok(ret, "ChangeServiceConfig2A failed with null pointer\n"); > + if (!ret) { > + goto cleanup; > + } Adding the test like this may work, but I don't think it is the right way. This call may overwrite settings set by the previous ChangeServiceConfig2A call if it succeeds. If it fails (and doesn't crash) the test can continue just fine since the previous call set up the configuration. I think it would be better to move this into its own test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVDAHWAAoJEN0/YqbEcdMwNOgP/irtATTOHllTYLRxVI13UiNi muUvj+pkXYLHzmx6Fzrp90nlu6SCE5yqk4JkE+sHJO3xReQ0r5b7hnAKmgiAEsqk cVLjBXbyrP+gciLPfSJiYUHTwbfFOiEfKhcpcS4llGj2iHpU3XgEkvvTVrxzTfBz lAyp1shmD4zBLq9urW2/zc5YsXtzVOIRSKW2X+S8nyem+pikRi15F7Dm07hftquw Xv/krwZw/36/FKP6gkMk+5594OHmjHiknn+cQFkTZdLXiTdtSqzVWigTfn7IR4rT 0Y0eCeDQI16mcitAVnYgmaaOodIe/J8KmleBJb13VEQxQOIhPyU5ujHys6avoJks JeD/n2NUhzHtNqwxdiGLMnZJXPK3Jt9wSMF6EQu2hY0XURYwwPVEeWegjo/PfdO/ 9fwSRlTfBLVnYIM66fFbntR7M8S/aaYnXdRWNF49GRRgRLb7HMMC27yBnoGif1dC nhaFWS98jM4kByDSf3ib/OPqIdjPc9K/j6X2ilp/Tjx8ybiXxpB/GFojmyaP0j7p fZ4BH4edz85IrzS9Usq53ugpP1lViDeUWcoZrF6wBUrXgiP/EzqV+SNJTesDbFzX DjkhwhuQxsnmKS5hLQkX24uCmY0trs1CFm3eoN+eg2+tXVknLfrQ2M88AblPPxbS Wg5PW20xgEIZ1dbXShSZ =lLfe -----END PGP SIGNATURE-----

1 0

Re: mlang/tests: Use BSTR strings instead of plain WCHARs when API tells so
by Dmitry Timoshkov 20 Mar '15

20 Mar '15

The tests were written this way to ensure that mlang methods do not depend on BSTR layout (and yes, at least IE6 depends on this). -- Dmitry.

2 2

Re: user32/tests: Test return value of EnumDesktopsA (PVS-Studio)
by Marvin 19 Mar '15

19 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12320 Your paranoid android. === w2000pro (32 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed! === wvistau64 (64 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed! === w2008s64 (64 bit winstation) === winstation.c:688: Test failed: EnumDesktopsA failed!

1 0

Compiling with GCC 5.0
by Michael Cronenworth 19 Mar '15

19 Mar '15

Has anyone given GCC 5.0 a shot? It breaks x86_64 for me and other Fedora 22+ users (22 and up use 5.0). Running wine as pure 32-bit does not exhibit issues. We're using 1.7.36 with wine-staging applied. In 64-bit mode it will not create a valid wine-prefix so I cannot run winedbg and nothing eventful happens with gdb attached to wine. Any ideas on how to debug this further? Here is the terminal output when a fresh prefix is attempted to be made: http://fpaste.org/187377/25868142/ Regards, Michael

3 9

Re: mstask: Added IEnumWorkItems stub
by Marvin 19 Mar '15

19 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12318 Your paranoid android. === w2000pro (32 bit task_scheduler) === task_scheduler: unhandled exception c0000005 at 6AC2AEEF

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Sebastian Lackner 19 Mar '15

19 Mar '15

On 19.03.2015 16:22, Andrew Eikum wrote: > --- > dlls/kernel32/kernel32.spec | 4 +- > dlls/kernel32/path.c | 97 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/kernel32/tests/file.c | 88 ++++++++++++++++++++++++++++++++++++++++ > include/winbase.h | 2 + > 4 files changed, 189 insertions(+), 2 deletions(-) > Why do you do the work twice? It would have been much easier if you would have just helped us to review and improve our Staging patchset which is there since about half a year ago, and supports a lot more flags. https://github.com/wine-compholio/wine-staging/blob/master/patches/kernel32… https://github.com/wine-compholio/wine-staging/blob/master/patches/kernel32… Why does noone bother anymore to test those patches, the author Michael Müller asked for feedback there long time ago: https://bugs.winehq.org/show_bug.cgi?id=36073#c4 I'll submit the patches in a few minutes so that you can decide if its better/worse than the current approach. Regards, Sebastian

3 6

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Marvin 19 Mar '15

19 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12304 Your paranoid android. === wvistau64 (32 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4060: Test failed: SetFileValidData failed 87 file.c:4063: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Dmitry Timoshkov 19 Mar '15

19 Mar '15

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > + info->FileName[info->FileNameLength / sizeof(WCHAR)] = 0; > + if (!RtlDosPathNameToNtPathName_U( info->FileName, &nt_name, NULL, NULL )) > + { > + SetLastError( ERROR_PATH_NOT_FOUND ); > + return 0; > + } > + > + name_wchars = nt_name.Length / sizeof(WCHAR); > + if (name_wchars + 1 > len) > + { > + RtlFreeUnicodeString( &nt_name ); > + return name_wchars + 1; > + } > + > + memcpy( outstr, nt_name.Buffer, nt_name.Length ); > + outstr[name_wchars] = 0; Where did you get an idea that you should return an nt path from this API? There is no a single check in the tests for a returned file name, and this whole thing looks over complicated. -- Dmitry.

1 0

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Piotr Caban 19 Mar '15

19 Mar '15

On 03/19/15 16:22, Andrew Eikum wrote: > + char data[MAX_PATH * sizeof(WCHAR) + sizeof(info->FileNameLength)]; Is the path limited to MAX_PATH characters?

2 1

Re: [PATCH] kernel32: Implement GetFinalPathNameByHandle
by Nikolay Sivov 19 Mar '15

19 Mar '15

On 19.03.2015 18:22, Andrew Eikum wrote: > +/************************************************************************* > + * GetFinalPathNameByHandleA (KERNEL32.@) > + */ > +DWORD WINAPI GetFinalPathNameByHandleA(HANDLE handle, char *outstr, DWORD len, > + DWORD flags) > +{ > + WCHAR *wstr; > + DWORD dw; > + > + if (len > 0) > + { > + wstr = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); > + if (!wstr) > + { > + SetLastError( ERROR_OUTOFMEMORY ); > + return 0; > + } > + } > + else > + wstr = NULL; > + > + dw = GetFinalPathNameByHandleW( handle, wstr, len, flags ); > + > + if (dw > 0 && dw < len) > + { > + /* success */ > + > + dw = WideCharToMultiByte( CP_ACP, 0, wstr, -1, NULL, 0, NULL, NULL ); > + if (dw > len) > + { > + /* buffer too small */ > + HeapFree( GetProcessHeap(), 0, wstr ); > + return dw; > + } > + > + dw = WideCharToMultiByte( CP_ACP, 0, wstr, -1, outstr, len, NULL, NULL ); > + if (!dw) > + { > + HeapFree( GetProcessHeap(), 0, wstr ); > + return 0; > + } > + > + /* don't report NUL */ > + dw = dw - 1; > + } > + > + HeapFree( GetProcessHeap(), 0, wstr ); > + > + return dw; > +} > + This doesn't look right. Proper way would be: - call GetFinalPathNameByHandleW() with NULL buffer to get required length; - allocated WCHAR buffer and get a path in it; - call WideCharToMultiByte() with NULL output buffer to get required length for CP_ACP string; - do what you need to do if A buffer length is too small. Right now you're assuming that WCHAR representation has same number of characters as CP_ACP one, I don't think it's always a case.

2 1

Bug that still exists for almost 10 years.
by Joshua Hale 19 Mar '15

19 Mar '15

Hello, I'm helping with the first private server for Phantasy Online Universe that will be made public really soon, but the game can't run correctly with this problem: https://bugs.winehq.org/show_bug.cgi?id=6955 It's been about almost 10 years that this issue has been submitted. We were told in 2009 that there was plans to get this fixed. https://forum.winehq.org/viewtopic.php?f=2&t=6626 but nothing has came from it. This is a bit important that this gets fixed soon or else the Mac wine wrapper at launch will be a dud... Can somebody tell me the progress of this? -- Thanks, Joshua Hale

2 1

Re: [PATCH] advapi32: succeed for null pointer in ChangeServiceConfig2
by Nikolay Sivov 19 Mar '15

19 Mar '15

On 19.03.2015 15:06, Bernhard Übelacker wrote: > @@ -2217,7 +2217,13 @@ BOOL WINAPI ChangeServiceConfig2W( SC_HANDLE hService, DWORD dwInfoLevel, > > info.dwInfoLevel = dwInfoLevel; > info.u.descr = lpInfo; > - err = svcctl_ChangeServiceConfig2W( hService, info ); > + > + if (info.u.descr->lpDescription) > + { > + err = svcctl_ChangeServiceConfig2W( hService, info ); > + } else { > + err = ERROR_SUCCESS; > + } In this case it's better to return earlier, no need to step into try..expect block if you know you won't call anything.

1 0

Re: [2/2] shell32: Fix SHFileOperation(FO_MOVE) for a directory with subdirectories.
by Marvin 19 Mar '15

19 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12288 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

1 0

Re: [1/2] shell32/tests: Add a couple of SHFileOperation(FO_MOVE) tests for a directory.
by Marvin 19 Mar '15

19 Mar '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=12287 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

2 1

Re: ntdll: Use lockfree implementation for get_cached_fd. (resend)
by Alexandre Julliard 19 Mar '15

19 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Contains a couple of small improvements compared with the last > attempt. As a reminder, the #ifdefs are there because we do not have > 64-bit interlocked instructions on PowerPC (and I have also no idea if > its possible at all to implement them properly). I'm not sure we care enough about PowerPC to require this, but in any case it would have to be done without spreading #ifdefs all over the code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/3] ntdll: Expose wine_uninterrupted_[read|write]_memory as exports.
by Alexandre Julliard 19 Mar '15

19 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Since APCs are also implemented outside of ntdll, we need to expose memory management functions. > The alternative solution would be to move ws2_32 code to ntdll. That would be preferable, if you find a way to do it cleanly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] include: Add undocumented theming hook structs to winuser.h.
by Dmitry Timoshkov 19 Mar '15

19 Mar '15

[please keep wine-devel in the cc: list] Mark Harmstone <hellas(a)burntcomma.com> wrote: > >> Adds the undocumented structs to winuser.h which are needed for uxtheme to hook > >> into user32. As researched by ReactOS: see https://www.reactos.org/wiki/Techwiki:RegisterUserApiHook > > > > Referencing reactos as a source of the information makes it unlikely > > to improve the chances of including the patch in Wine. > > What? Why? They've already done the research... To make long story short - ReactOS' understanding of allowed research practices doesn't match the accepted Wine standards. > > Moreover, as > > was already discussed many times, theme interface is completely > > undocumented and different between Windows versions, therefore it's > > very unlikely that there is an application that depends on the > > details of this interface, thus making it unnecessary to duplicate > > it in Wine. > > > > Well, I'm about to submit patches to allow uxtheme to hook into user32, > so it can theme the non-client areas like scrollbars. Clearly some > sort of shared interface is needed for this, would you not agree? Just making this interface Wine specific would work better IMHO. Using that approach you could add the needed pieces one by one. -- Dmitry.

1 0

Re: [PATCH] vbscript: Implemented GetLocale(try 2)
by Piotr Caban 19 Mar '15

19 Mar '15

On 03/17/15 09:29, Shuai Meng wrote: > -#define DISPID_GLOBAL_VBMSGBOXHELPBUTTON 207 > -#define DISPID_GLOBAL_VBMSGBOXSETFOREGROUND 208 > -#define DISPID_GLOBAL_VBMSGBOXRIGHT 209 > -#define DISPID_GLOBAL_VBMSGBOXRTLREADING 210 > +#define DISPID_GLOBAL_VBMSGBOXHELPBUTTON 208 > +#define DISPID_GLOBAL_VBMSGBOXSETFOREGROUND 209 > +#define DISPID_GLOBAL_VBMSGBOXRIGHT 210 > +#define DISPID_GLOBAL_VBMSGBOXRTLREADING 211 > > #define DISPID_GLOBAL_CCUR 100 > #define DISPID_GLOBAL_CINT 101 > @@ -210,6 +210,7 @@ > #define DISPID_GLOBAL_EXECUTE 204 > #define DISPID_GLOBAL_EXECUTEGLOBAL 205 > #define DISPID_GLOBAL_GETREF 206 > +#define DISPID_GLOBAL_GETLOCALE 207 This changes are not matching the typelib in native vbscript.dll. It looks like GetLocale function is not defined there at all.

2 3

uartz.dll and some other newbie questions
by Ali Aminian 19 Mar '15

19 Mar '15

Hello I have 3 newbie questions. 1_I'm interested in quartz.dll but i can't find any resources. can any one help me where can i find information about this dll. 2_plus wine used to crash during playing video files in games when "native quartz.dll" had been installed. I'm interested to know what was the problem. 3_Wine documentation says native dlls should be enabled through winecfg or through command line: "WINEDLLOVERRIDES=quartz=n wine myapp.ex.e" but where does wine look for native dlls.(for instance how quartz.dll should be installed without winetricks)

2 1

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