October 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Stefan Dösinger

On Monday 31 October 2011 21:06:09 Henri Verbeet wrote: > Probably in general. The way GetDC is supposed to work is probably by > asking the graphics driver to create a DC on top of the existing > memory or texture, instead of the DIB section hacks we do in wined3d. In the days of the old ddraw code we used to have a Wine-specific export in gdi32 that did that, but I don't think adding that back 1:1 is a good solution. We could allocate surface memory in ddraw and copy between that and the memory wined3d's map() returns for some or all surfaces. This would deal with cases where an app(Some Windows Media Player 9 visualization plugins specifically) use SetSurfaceDesc to set lpSurface and then call GetDC, and we could get rid of SFLAG_USERPTR in wined3d. It would also be more reliable for the backbuffer than hoping the memory returned by glMapBuffer remains valid. Alternatively we could make the dibsection a separate location, but that wouldn't deal with apps that want the backbuffer memory to stay the same. > and since > OWNDC implies the application wants to keep the DC around anyway, we > might as well set it up at surface initialization. This is probably correct, but do you have docs for OWNDC, besides of the name and very short description in msdn/sdk? I don't think IE8 sets OWNDC here, this is most likely our ddrawex.dll. And the main reason I've set it there is because it kinda-sorta sounds like what the ddrawex DDSCAPS_VIDEOMEMORY | DDSCAPS_SYSTEMMEM hack is doing, not because I had any in-depth information what OWNDC does, so I'd be wary about reading too much into it.

Oct. 31, 2011

Re: [4/4] wined3d: YUY2 and UYVY are block based

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=15193 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 31, 2011

Re: [3/4] d3d9/tests: Test partial block locks

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=15192 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 31, 2011

Re: ddraw/tests: Move some surface attachment tests from refcount to dsurface and enhance them.

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=15183 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WXPPROSP3 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WVISTAADM (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K8SE (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PRO (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a

Oct. 31, 2011

Re: [3/4] d3d9/tests: Test partial block locks

by Henri Verbeet

On 31 October 2011 20:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + case D3DPOOL_SCRATCH: > + case D3DPOOL_SYSTEMMEM: > + hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, formats[i].fmt, > + D3DPOOL_SCRATCH, &surface, 0); That doesn't really test D3DPOOL_SYSTEMMEM.

Oct. 31, 2011

Re: [4/4] wined3d: YUY2 and UYVY are block based

by Henri Verbeet

On 31 October 2011 20:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > {WINED3DFMT_ATI2N, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, 0, > GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, > - WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING, > + WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING | WINED3DFMT_FLAG_COMPRESSED, > GL_COMPRESSED_RED_GREEN_RGTC2 is also compressed.

Oct. 31, 2011

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Henri Verbeet

On 31 October 2011 20:38, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > You would get the same effect by calling GetDC and ReleaseDC from ddraw or > ddrawex without another usage flag. Yes, but I don't think that would be an improvement. >> + /* Similar to lockable rendertargets above, creating the DIB section >> + * during surface initialization prevents the sysmem pointer from >> changing + * after a wined3d_surface_getdc() call. */ > Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect > that this applies to sysmem surfaces in general. Probably in general. The way GetDC is supposed to work is probably by asking the graphics driver to create a DC on top of the existing memory or texture, instead of the DIB section hacks we do in wined3d. However, without much more invasive changes to the way wined3d interacts with winex11 that's just not going to happen, and since OWNDC implies the application wants to keep the DC around anyway, we might as well set it up at surface initialization.

Oct. 31, 2011

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Stefan Dösinger

On Monday 31 October 2011 19:48:12 Henri Verbeet wrote: > --- > dlls/ddraw/surface.c | 3 +++ > dlls/wined3d/surface.c | 11 +++++++++++ > include/wine/wined3d.h | 1 + > 3 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index 3860959..567d086 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -5273,6 +5273,9 @@ HRESULT ddraw_surface_init(IDirectDrawSurfaceImpl > *surface, IDirectDrawImpl *ddr if (desc->ddsCaps.dwCaps & DDSCAPS_ZBUFFER) > usage |= WINED3DUSAGE_DEPTHSTENCIL; > > + if (desc->ddsCaps.dwCaps & DDSCAPS_OWNDC) > + usage |= WINED3DUSAGE_OWNDC; You would get the same effect by calling GetDC and ReleaseDC from ddraw or ddrawex without another usage flag. Probably ddrawex should do that since it sets DDSCAPS_OWNDC, assuming that IE 8 still uses ddrawex. > + /* Similar to lockable rendertargets above, creating the DIB section > + * during surface initialization prevents the sysmem pointer from > changing + * after a wined3d_surface_getdc() call. */ Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect that this applies to sysmem surfaces in general. Otoh we don't really want to create a DIB section for every sysmem surface, especially with bug 5535 in mind.

Oct. 31, 2011

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.

by Henri Verbeet

On 31 October 2011 19:56, Josh Juran <josh(a)iswifter.net> wrote: > Looks like you lost an 'inline'. Was that intentional? > Yes.

Oct. 31, 2011

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.

by Josh Juran

On Oct 31, 2011, at 11:48 AM, Henri Verbeet wrote: > --- > dlls/wined3d/buffer.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c > index 45518cc..69c110a 100644 > --- a/dlls/wined3d/buffer.c > +++ b/dlls/wined3d/buffer.c > @@ -76,9 +76,9 @@ static inline void buffer_clear_dirty_areas(struct wined3d_buffer *This) > This->modified_areas = 0; > } > > -static inline BOOL buffer_is_dirty(struct wined3d_buffer *This) > +static BOOL buffer_is_dirty(const struct wined3d_buffer *buffer) > { > - return !!This->modified_areas; > + return !!buffer->modified_areas; > } > > static inline BOOL buffer_is_fully_dirty(struct wined3d_buffer *This) > -- Looks like you lost an 'inline'. Was that intentional? Josh

Oct. 31, 2011

Re: 80199: shdocvw: add a stub for InstallReg_RunDLL

by Austin English

On Thu, Oct 20, 2011 at 15:55, Dan Kegel <dank(a)kegel.com> wrote: > Fails to build here? > > On Thu, Oct 20, 2011 at 3:51 PM, <buildbot(a)kegel.com> wrote: >> This is an experimental automated build and test service. >> Please feel free to ignore this email while we work the kinks out. >> >> For more info about this message, see http://wiki.winehq.org/BuildBot >> >> The Buildbot has detected a failed build on builder runtests-default while building Wine. >> Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/803 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) >> BUILD FAILED: failed shell_2 >> >> Errors: >> shdocvw_main.c: In function 'InstallReg_RunDLL': >> shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] >> shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] >> make[1]: *** [shdocvw_main.o] Error 1 >> make: *** [dlls/shdocvw] Error 2 >> make: *** Waiting for unfinished jobs.... Resent, thanks. -- -Austin

Oct. 31, 2011

Re: [PATCH 2/5] ddraw: Implement copy_mipmap_chain() on top of wined3d_surface_blt().

by Henri Verbeet

On 31 October 2011 15:04, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 30 October 2011 18:06:33 Henri Verbeet wrote: >> + if (FAILED(hr = >> wined3d_surface_blt(dest_level->wined3d_surface, &dst_rect, >> + src_level->wined3d_surface, &src_rect, 0, NULL, >> WINED3DTEXF_POINT))) > Wouldn't wined3d_device_update_surface be a better match? No, the patch actually removes that code.

Oct. 31, 2011

Re: [PATCH 2/5] ddraw: Implement copy_mipmap_chain() on top of wined3d_surface_blt().

by Stefan Dösinger

On Sunday 30 October 2011 18:06:33 Henri Verbeet wrote: > + if (FAILED(hr = > wined3d_surface_blt(dest_level->wined3d_surface, &dst_rect, > + src_level->wined3d_surface, &src_rect, 0, NULL, > WINED3DTEXF_POINT))) Wouldn't wined3d_device_update_surface be a better match? IDirect3DDevice7::Load could probably be handled by wined3d_device_update_texture if it wasn't for color keys/palettes.

Oct. 31, 2011

RFC: Make X11 window rect empty for WS_EX_TRANSPARENT windows

by Octavian Voicu

Hi, Attached patch fixes http://bugs.winehq.org/show_bug.cgi?id=28678. The root problem is that X11 windows cannot be made transparent (allowing other windows to draw over them). My approach I to make the X11 window with WS_EX_TRANSPARENT extended style have an empty region. Obviously, this is very hacky and except for very particular cases (like the bug I'm trying to fix) it won't work at all, so this patch is more like a proof-of-concept than a fix. For example, window decorations aren't drawn and not even the window can paint itself. This becomes kind of a recursive question -- how to draw the contents of the window-less window? Can this approach ever work? Any comments or suggestions are welcome. Octavian

Oct. 30, 2011

d3dx9_36: Simplify the computation of a 2-adic valuation

by David Adam

Hello, please discard this patch. It is logically wrong. David

Oct. 29, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Frédéric Delanoy

2011/10/27 Michael Stefaniuc <mstefani(a)redhat.com>: > On 10/27/2011 02:09 PM, Frédéric Delanoy wrote: >> On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: >>> why do we check for ptr being null or not, when we deref ptr one line above? >> >>>> if (*ptr == '\n') ptr++; >>>> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >>>> strlenW(message), handle); >>>> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >>>> strlenW(message), handle); >>>> if (ptr) { >>>> numChars = 0; >>>> if (++line_count >= max_height - 1) { >> >> It's dereferenced but incremented afterwards, so might be null after that line > Only if ptr wraps around ;) Yeah right. Don't know where I saw a * before the ptr in (ptr)...

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by Bruno Jesus

2011/10/28 André Hentschel <nerv(a)dawncrow.de>: > Am 28.10.2011 19:42, schrieb Bruno Jesus: > ... > btw: if there is no dependencies than you don't need numbered patchsets Agreed. Sorry again. Best wishes, Bruno

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by André Hentschel

Am 28.10.2011 19:42, schrieb Bruno Jesus: > On Fri, Oct 28, 2011 at 15:01, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Bruno Jesus <00cpxxx(a)gmail.com> writes: >> >>> +/* Max ATR size defined by ISO-7816 */ >>> +#define MAX_ATR_SIZE 33 >> >> I don't see that one in my PSDK, where does it come from? > > My bad, apologies. I copied it from Vincent Hardy patch series but in > fact the variable should be name SCARD_ATR_LENGTH and should be in > winsmcrd.h. I'm still not using these defines yet so if possible I > would like the [2/2] to be commited if no mistakes are found in it, btw: if there is no dependencies than you don't need numbered patchsets -- Best Regards, André Hentschel

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by Bruno Jesus

On Fri, Oct 28, 2011 at 15:01, Alexandre Julliard <julliard(a)winehq.org> wrote: > Bruno Jesus <00cpxxx(a)gmail.com> writes: > >> +/* Max ATR size defined by ISO-7816 */ >> +#define MAX_ATR_SIZE 33 > > I don't see that one in my PSDK, where does it come from? My bad, apologies. I copied it from Vincent Hardy patch series but in fact the variable should be name SCARD_ATR_LENGTH and should be in winsmcrd.h. I'm still not using these defines yet so if possible I would like the [2/2] to be commited if no mistakes are found in it, I'll resend this one later. Best wishes, Bruno

Oct. 28, 2011

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > +/* Max ATR size defined by ISO-7816 */ > +#define MAX_ATR_SIZE 33 I don't see that one in my PSDK, where does it come from? -- Alexandre Julliard julliard(a)winehq.org

Oct. 28, 2011

kernel32: Update English resource

by Ken Sharp

I suspect this is the wrong way to update the US English resource for an .mc file. Could anyone comment? Thanks

Oct. 28, 2011

Re: basic_ifstream implementation

by Frédéric Delanoy

On Fri, Oct 28, 2011 at 01:30, Josh Juran <josh(a)iswifter.net> wrote: > I appreciate your (and others') willingness to provide feedback. Unfortunately, my job in this case is to make certain apps work (by hack or by crack) and move on. What you could do is add/update the AppDB entry for this program, and link to your bug (hence patch). Frédéric

Oct. 28, 2011

Re: Antw.: signal_arc.c failing to cross-compile

by Roger Cruz

Thanks Andre, I realize that I'm breaking some new ground here and I don't mind doing the legwork. I just like to first post to make sure someone hasn't already tried this and found a solution before I spend too much time on it. It looks like you have been trying to cross-compile for Android as well. I'm guessing you must have hit this missing header file as well? Regards, Roger R. Cruz On Oct 28, 2011, at 3:05 AM, "André Hentschel" <nerv(a)dawncrow.de> wrote: > Thats not a problem of cross compiling to ARM, but of android. Android is not Linux, not fully. Maybe i can find a solution, but only maybe. BTW all the problems you will find are Android specific. > > Gesendet mit meinem HTC > > ----- Reply message ----- > Von: "Roger Cruz" <roger_r_cruz(a)yahoo.com> > An: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > Betreff: signal_arc.c failing to cross-compile > Datum: Fr., Okt. 28, 2011 06:46 > > > Hi Andre et al, > > Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. > > Thanks in advance, > > Roger R. Cruz > > arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' > make[1]: *** [signal_arm.o] Error 1

Oct. 28, 2011

Re: ntdll: Make the VirtualProtect tests pass under Wine. Resend.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Updated to current git. > --- > dlls/kernel32/tests/virtual.c | 16 ---------------- > dlls/ntdll/virtual.c | 3 +++ > 2 files changed, 3 insertions(+), 16 deletions(-) This completely breaks Wine here. There are several places where we use WRITECOPY for protections, they would have to be fixed first. -- Alexandre Julliard julliard(a)winehq.org

Oct. 28, 2011

Re: signal_arc.c failing to cross-compile

by Paul Chitescu

Hi! Android is hopeless, its C library (bionic) is a very trimmed down and bug ridden version of the BSD library. The Android devel team is not willing to fix any bugs unless they affect native Android applications or Dalvik. In particular the .so loader and related initialization is broken. dlopen() doesn't properly call initializers, dlclose() doesn't work at all. Unless a proper C library is installed on the target systems (and a matching cross-toolchain used for compiling) there are no chances wine will run on Android. Many of the libraries required for Wine will not work properly with bionic even if they may compile. Paul On Friday 28 October 2011 07:46:26 am Roger Cruz wrote: > Hi Andre et al, > > Wondering if any of you know how to get around this? The compiler is > barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. > > Thanks in advance, > > Roger R. Cruz > > > arm-linux-androideabi-gcc -c > -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. > -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include > -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe > -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement > -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings > -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: > expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: > type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: > expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: > expected declaration specifiers or '...' before 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'restore_context': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: > 'sigcontext' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: > (Each undeclared identifier is reported only once > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for > each function it appears in.) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: > type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: > expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: > type defaults to 'int' in declaration of 'ucontext_t' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: > expected ';', ',' or ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: > expected ')' before '*' token > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'segv_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: > 'SIGCONTEXT' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: > 'context' undeclared (first use in this function) > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: > ISO C90 forbids mixed declarations and code > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: > implicit declaration of function 'setup_exception_record' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'trap_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: > implicit declaration of function 'save_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'fpe_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: > implicit declaration of function 'save_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: > implicit declaration of function 'restore_fpu' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'int_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'abrt_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too > many arguments to function 'restore_context' > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function > 'usr1_handler': > /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too > many arguments to function 'restore_context' make[1]: *** [signal_arm.o] > Error 1

Oct. 28, 2011

Antw.: signal_arc.c failing to cross-compile

by André Hentschel

Thats not a problem of cross compiling to ARM, but of android. Android is not Linux, not fully. Maybe i can find a solution, but only maybe. BTW all the problems you will find are Android specific. Gesendet mit meinem HTC ----- Reply message ----- Von: "Roger Cruz" <roger_r_cruz(a)yahoo.com> An: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Betreff: signal_arc.c failing to cross-compile Datum: Fr., Okt. 28, 2011 06:46 Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

Oct. 28, 2011

signal_arc.c failing to cross-compile

by Roger Cruz

Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

Oct. 28, 2011

Re: basic_ifstream implementation

by Josh Juran

On Oct 27, 2011, at 12:35 AM, Piotr Caban wrote: > On 10/27/11 2:01 AM, Josh Juran wrote: >> On Oct 26, 2011, at 11:59 AM, Josh Juran wrote: >> >>> I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. > In order to implement it correctly lots of functions/classes needs to be implemented first. I've started stubbing some of them but there's still lots to be done. >>> Well, it turns out that the game creates an ifstream for its intro movie and then uses a completely different mechanism to read from it. Defining a (nearly) empty constructor and destructor for basic_ifstream<char> was sufficient to make things work. > It may happen because of inlining some functions. I don't understand this explanation. Most games don't have this issue. It looks like the developer was originally using ifstream to read the file and then switched to something else, but forgot to remove the ifstream object definition. > The game may also use created streams later. Possible in theory, but unlikely. > It's not good to add an incomplete structure. We'll end having lots of bugs that will need to be debugged to find where the problem is. Especially adding uninitialized vtable pointer is not a good idea. I agree that this patch should not go into Wine as is. > I think it should be implemented by adding all fstream class dependencies first. Thanks to it it will be possible to create a complete basic_ifstream_char structure. I appreciate your (and others') willingness to provide feedback. Unfortunately, my job in this case is to make certain apps work (by hack or by crack) and move on. Josh

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Michael Stefaniuc

On 10/27/2011 02:09 PM, Frédéric Delanoy wrote: > On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: >> why do we check for ptr being null or not, when we deref ptr one line above? > >>> if (*ptr == '\n') ptr++; >>> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >>> strlenW(message), handle); >>> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >>> strlenW(message), handle); >>> if (ptr) { >>> numChars = 0; >>> if (++line_count >= max_height - 1) { > > It's dereferenced but incremented afterwards, so might be null after that line Only if ptr wraps around ;) bye michael

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Frédéric Delanoy

2011/10/27 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: >> why do we check for ptr being null or not, when we deref ptr one line above? > >>> if (*ptr == '\n') ptr++; >>> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >>> strlenW(message), handle); >>> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >>> strlenW(message), handle); >>> if (ptr) { >>> numChars = 0; >>> if (++line_count >= max_height - 1) { > > It's dereferenced but incremented afterwards, so might be null after that line Of course if (*ptr != '\n') the check is unnecessary. I guess the original author simply wanted to merge both cases. Might need some reorganization, but that's probably outside of the scope of this patch

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Frédéric Delanoy

On Thu, Oct 27, 2011 at 08:38, Eric Pouech <eric.pouech(a)orange.fr> wrote: > why do we check for ptr being null or not, when we deref ptr one line above? >> if (*ptr == '\n') ptr++; >> - WCMD_output_asis_len(message, (ptr) ? ptr - message : >> strlenW(message), handle); >> + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : >> strlenW(message), handle); >> if (ptr) { >> numChars = 0; >> if (++line_count >= max_height - 1) { It's dereferenced but incremented afterwards, so might be null after that line

Oct. 27, 2011

Re: basic_ifstream implementation

by Piotr Caban

On 10/27/11 2:01 AM, Josh Juran wrote: > On Oct 26, 2011, at 11:59 AM, Josh Juran wrote: > >> I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. In order to implement it correctly lots of functions/classes needs to be implemented first. I've started stubbing some of them but there's still lots to be done. >> Well, it turns out that the game creates an ifstream for its intro movie and then uses a completely different mechanism to read from it. Defining a (nearly) empty constructor and destructor for basic_ifstream<char> was sufficient to make things work. It may happen because of inlining some functions. The game may also use created streams later. >> +static const vtable_ptr basic_ifstream_char_vtable; >> + >> +typedef struct _basic_ifstream_char >> +{ >> + const vtable_ptr *vtable; >> + >> + int filler[ 140 / sizeof (int) - sizeof (const vtable_ptr*) ]; >> +} >> +basic_ifstream_char; It's not good to add an incomplete structure. We'll end having lots of bugs that will need to be debugged to find where the problem is. Especially adding uninitialized vtable pointer is not a good idea. I think it should be implemented by adding all fstream class dependencies first. Thanks to it it will be possible to create a complete basic_ifstream_char structure. >> +basic_ifstream_char* __thiscall basic_ifstream_char_ctor(basic_ifstream_char *this, const char *path, int mode, int prot) >> +@ thiscall -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z(ptr long long) basic_ifstream_char_ctor Arguments in spec file are different then in ios.c. Cheers, Piotr

Oct. 27, 2011

Re: cmd: Avoid mixing signed and unsigned type in conditional expression

by Eric Pouech

why do we check for ptr being null or not, when we deref ptr one line above ? something's wrong in the code logic A+ Le 27 octobre 2011 04:53, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > --- > programs/cmd/wcmdmain.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/programs/cmd/wcmdmain.c b/programs/cmd/wcmdmain.c > index 56aa85f..1bcc598 100644 > --- a/programs/cmd/wcmdmain.c > +++ b/programs/cmd/wcmdmain.c > @@ -278,7 +278,7 @@ static void WCMD_output_asis_handle (DWORD std_handle, > const WCHAR *message) { > ptr++; > }; > if (*ptr == '\n') ptr++; > - WCMD_output_asis_len(message, (ptr) ? ptr - message : > strlenW(message), handle); > + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : > strlenW(message), handle); > if (ptr) { > numChars = 0; > if (++line_count >= max_height - 1) { > -- > 1.7.7.1 > > > > -- -- Eric Pouech

Oct. 27, 2011

Re: basic_ifstream implementation

by Octavian Voicu

On Thu, Oct 27, 2011 at 2:01 AM, Josh Juran <josh(a)iswifter.net> wrote: > @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBDHH@Z > @ stub -arch=win64 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAAXXZ You forgot to update the win64 stubs in the spec file. Octavian

Oct. 27, 2011

Re: basic_ifstream implementation

by Josh Juran

On Oct 26, 2011, at 11:59 AM, Josh Juran wrote: > I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. > > http://bugs.winehq.org/show_bug.cgi?id=28612 > > First I'd like to check that Piotr isn't already working on this. If not, I'm open to any advice on how to proceed. My plan is to create fstream.c, and use string.c as a guide. Well, it turns out that the game creates an ifstream for its intro movie and then uses a completely different mechanism to read from it. Defining a (nearly) empty constructor and destructor for basic_ifstream<char> was sufficient to make things work. The good news is that this ticket can be resolved if the patch attached to it and included below (or one like it) is applied. The bad news is that I won't be providing an actual implementation or otherwise working on this any further. Josh diff --git a/dlls/msvcp90/ios.c b/dlls/msvcp90/ios.c index 84dfb17..4290469 100644 --- a/dlls/msvcp90/ios.c +++ b/dlls/msvcp90/ios.c @@ -1727,3 +1727,35 @@ basic_ostream_char* __thiscall basic_ostream_char_write(basic_ostream_char *this FIXME("(%p %s %lu) stub\n", this, debugstr_a(str), count); return NULL; } + +static const vtable_ptr basic_ifstream_char_vtable; + +typedef struct _basic_ifstream_char +{ + const vtable_ptr *vtable; + + int filler[ 140 / sizeof (int) - sizeof (const vtable_ptr*) ]; +} +basic_ifstream_char; + +/* ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z */ +/* ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBDHH@Z */ +DEFINE_THISCALL_WRAPPER(basic_ifstream_char_ctor, 16) +basic_ifstream_char* __thiscall basic_ifstream_char_ctor(basic_ifstream_char *this, const char *path, int mode, int prot) +{ + FIXME("(%p, %s, %d, %d) stub\n", this, path, mode, prot); + + this->vtable = &basic_ifstream_char_vtable; + + return this; +} + +/* ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAEXXZ */ +/* ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAAXXZ */ +DEFINE_THISCALL_WRAPPER(basic_ifstream_char_vbase_dtor, 4) +basic_ifstream_char* __thiscall basic_ifstream_char_vbase_dtor(basic_ifstream_char *this) +{ + FIXME("(%p) stub\n", this); + + return this; +} diff --git a/dlls/msvcp90/msvcp90.spec b/dlls/msvcp90/msvcp90.spec index 33d5619..f43a669 100644 --- a/dlls/msvcp90/msvcp90.spec +++ b/dlls/msvcp90/msvcp90.spec @@ -590,7 +590,7 @@ @ stub -arch=win64 ??0?$basic_fstream(a)_WU?$char_traits(a)_W@std@@@std@@QEAA(a)XZ @ stub -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PAU_iobuf@@@Z @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEAU_iobuf@@@Z -@ stub -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z +@ thiscall -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBDHH@Z(ptr long long) basic_ifstream_char_ctor @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBDHH@Z @ stub -arch=win32 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAE(a)PBGHH@Z @ stub -arch=win64 ??0?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAA(a)PEBGHH@Z @@ -1907,7 +1907,7 @@ @ stub -arch=win64 ??_D?$basic_fstream(a)GU?$char_traits(a)G@std@@@std@@QEAAXXZ @ stub -arch=win32 ??_D?$basic_fstream(a)_WU?$char_traits(a)_W@std@@@std@@QAEXXZ @ stub -arch=win64 ??_D?$basic_fstream(a)_WU?$char_traits(a)_W@std@@@std@@QEAAXXZ -@ stub -arch=win32 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAEXXZ +@ thiscall -arch=win32 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QAEXXZ(ptr) basic_ifstream_char_vbase_dtor @ stub -arch=win64 ??_D?$basic_ifstream(a)DU?$char_traits(a)D@std@@@std@@QEAAXXZ @ stub -arch=win32 ??_D?$basic_ifstream(a)GU?$char_traits(a)G@std@@@std@@QAEXXZ @ stub -arch=win64 ??_D?$basic_ifstream(a)GU?$char_traits(a)G@std@@@std@@QEAAXXZ

Oct. 27, 2011

basic_ifstream implementation

by Josh Juran

I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. http://bugs.winehq.org/show_bug.cgi?id=28612 First I'd like to check that Piotr isn't already working on this. If not, I'm open to any advice on how to proceed. My plan is to create fstream.c, and use string.c as a guide. Josh

Oct. 26, 2011

Re: winscard/tests: Add the tests file

by Bruno Jesus

On Wed, Oct 26, 2011 at 11:38, Marvin <testbot(a)testbot.winehq.org> wrote: > === W2KPROSP4 (32 bit winscard) === > winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 00000006 > winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 00000006 > It looks like Win2000 didn't have the SCARD_E_INVALID_HANDLE and instead return the win error INVALID_HANDLE (error 6). If possible and if no one finds any problem with the patch I would ask for it to be commited as is because I'll fix this in a newer patch using broken. Best wishes, Bruno

Oct. 26, 2011

Re: winscard/tests: Add the tests file

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=15123 Your paranoid android. === W2KPROSP4 (32 bit winscard) === winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 00000006 winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 00000006

Oct. 26, 2011

Re: [PATCH 1/3] widl: teach widl how to automatically create class factories (resend)

by Dan Kegel

On Wed, Oct 26, 2011 at 4:48 AM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > This means tools/widl/Makefile wasn't regenerated. > But the changes to Makefile.in are there, so it's a problem with your system. Hmm. Thanks, I'll have a look. - Dan

Oct. 26, 2011

Re: [PATCH 2/2] d3dx9/test: Fix typo.

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=15120 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 26, 2011

Re: [PATCH 1/3] widl: teach widl how to automatically create class factories (resend)

by Bernhard Loos

On Tue, Oct 25, 2011 at 6:11 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Bernhard, > build fails here: > widl.o: In function `write_dlldata': > /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:423: > undefined reference to `write_dlldata_list' > widl.o: In function `main': > /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:781: > undefined reference to `write_dlldata_list' This means tools/widl/Makefile wasn't regenerated. But the changes to Makefile.in are there, so it's a problem with your system. > http://winehq.org:8010/builders/runtests-default/builds/106 > > Also, patch 2/3 doesn't apply: > > error: patch failed: Make.rules.in:20 > error: Make.rules.in: patch does not apply > > http://winehq.org:8010/builders/runtests-default/builds/107 > Sorry, forgot to rebase yesterday.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Kai Tietz

2011/10/26 Dmitry Timoshkov <dmitry(a)baikal.ru>: > Chris Robinson <chris.kcat(a)gmail.com> wrote: > >> For Wine it doesn't really matter, since we can't use C++. For mingw-w64, >> however, it could be a big problem if it's not properly typed as a long. >> Overloads and template types would silently use 'int' where it should be using >> 'long', and you wouldn't necessarily know until you see odd behavior in the >> app. > > What kind of odd behaviour? Both int and long are 32-bit in win32 and win64. > > -- > Dmitry. See as example for C++: #include <stdio.h> void foo (int i) { printf ("int i == %d\n", i); } void foo (long i) { printf ("long i == %ld\n", i); } int main () { foo (1); foo (1L); return 0; } if you compile this program and execute it, then you will see the following output: $ ./tst.exe int i == 1 long i == 1 C++ has the ability to have for same function name different implementation for different argument types. Means, argument types getting part of function's signature. So you might see the cause what is different about suffixed/non-suffixed values for C++. Regards, Kai

Oct. 26, 2011

Re: [PATCH 1/2] d3dx9: Improve argument check in D3DXFindShaderComment().

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=15119 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Dmitry Timoshkov

Chris Robinson <chris.kcat(a)gmail.com> wrote: > For Wine it doesn't really matter, since we can't use C++. For mingw-w64, > however, it could be a big problem if it's not properly typed as a long. > Overloads and template types would silently use 'int' where it should be using > 'long', and you wouldn't necessarily know until you see odd behavior in the > app. What kind of odd behaviour? Both int and long are 32-bit in win32 and win64. -- Dmitry.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Chris Robinson

On Wednesday, October 26, 2011 12:35:28 PM Michael Stefaniuc wrote: > Chris Robinson wrote: > > imagine some C++ function overrides tripping up with the int/long > > difference. > If you use the Wine headers this should actually fix it as it brings the > numeric constants in line with the types as LONG == int in Wine. For Wine it doesn't really matter, since we can't use C++. For mingw-w64, however, it could be a big problem if it's not properly typed as a long. Overloads and template types would silently use 'int' where it should be using 'long', and you wouldn't necessarily know until you see odd behavior in the app.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Michael Stefaniuc

Chris Robinson wrote: > On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote: >> Hello Jacek! >> >> Jacek Caban wrote: >>> mingw-w64 project imports some of our headers, including most of d3d >>> headers. They would probably prefer to keep them with 'l' modifier since >>> that's the right thing to do. Given that it's mostly harmless for Wine, >>> could we please consider not changing it? >> Well ... the the dinput.h was a real change were Wine was affected. >> But the change should be mostly harmless for mingw-w64 as long == int on >> Win32 and Win64. > > The compiler does still complain about types even if the type is the same > size. Such as when using printf formatting (%x = int, #lx = long; GCC > complains if the type doesn't match, even if it's the same size). Also I could Right, one of the reasons we do this change for Wine. > imagine some C++ function overrides tripping up with the int/long difference. If you use the Wine headers this should actually fix it as it brings the numeric constants in line with the types as LONG == int in Wine. bye michael

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Chris Robinson

On Wednesday, October 26, 2011 12:17:22 PM Michael Stefaniuc wrote: > Hello Jacek! > > Jacek Caban wrote: > > mingw-w64 project imports some of our headers, including most of d3d > > headers. They would probably prefer to keep them with 'l' modifier since > > that's the right thing to do. Given that it's mostly harmless for Wine, > > could we please consider not changing it? > > Well ... the the dinput.h was a real change were Wine was affected. > But the change should be mostly harmless for mingw-w64 as long == int on > Win32 and Win64. The compiler does still complain about types even if the type is the same size. Such as when using printf formatting (%x = int, #lx = long; GCC complains if the type doesn't match, even if it's the same size). Also I could imagine some C++ function overrides tripping up with the int/long difference.

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Kai Tietz

2011/10/26 Michael Stefaniuc <mstefani(a)redhat.com>: > Hello Jacek! > > Jacek Caban wrote: >> On 10/26/11 00:30, Michael Stefaniuc wrote: >>> --- >>> include/d3d9caps.h | 182 >>> ++++++++++++++++++++++++++-------------------------- >>> 1 files changed, 91 insertions(+), 91 deletions(-) >>> >>> diff --git a/include/d3d9caps.h b/include/d3d9caps.h >>> index 8ed6598..64dba21 100644 >>> --- a/include/d3d9caps.h >>> +++ b/include/d3d9caps.h >>> @@ -29,13 +29,13 @@ >>> #define D3DCURSORCAPS_LOWRES 2 >>> >>> >>> -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L >>> -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L >>> -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L >>> -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L >>> -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L >>> -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L >>> -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L >>> +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 >>> +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 >>> +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 >>> +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 >>> +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 >>> +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 >>> +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 >>> >> >> mingw-w64 project imports some of our headers, including most of d3d >> headers. They would probably prefer to keep them with 'l' modifier since >> that's the right thing to do. Given that it's mostly harmless for Wine, >> could we please consider not changing it? > Well ... the the dinput.h was a real change were Wine was affected. > But the change should be mostly harmless for mingw-w64 as long == int on > Win32 and Win64. > > Anyway this is a hit job from Alexandre so you'll have to convince him. > > bye > michael Hi Michael, 2011/10/26 Jacek Caban <jacek(a)codeweavers.com>: > Hi Michael, > > On 10/26/11 00:30, Michael Stefaniuc wrote: >> >> --- >> include/d3d9caps.h | 182 >> ++++++++++++++++++++++++++-------------------------- >> 1 files changed, 91 insertions(+), 91 deletions(-) >> >> diff --git a/include/d3d9caps.h b/include/d3d9caps.h >> index 8ed6598..64dba21 100644 >> --- a/include/d3d9caps.h >> +++ b/include/d3d9caps.h >> @@ -29,13 +29,13 @@ >> #define D3DCURSORCAPS_LOWRES 2 >> >> >> -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L >> -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L >> -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L >> -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L >> -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L >> -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L >> -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L >> +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 >> +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 >> +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 >> +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 >> +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 >> +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 >> +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 >> > > mingw-w64 project imports some of our headers, including most of d3d > headers. They would probably prefer to keep them with 'l' modifier since > that's the right thing to do. Given that it's mostly harmless for Wine, > could we please consider not changing it? > > Thanks, > Jacek As Jacek mentioned already, it would be for our use of Wine direct-x SDK a big flaw to have constants here not proper suffixed with L. Especially in use for C++ this would cause big pain for 32-bit and 64-bit native Windows compilation. I am not sure about this, but I assume that Wine might have an interest to be able to use platform-headers and optional SDKs also with a cross-compiler targeting for Windows native. I would suggest to use here a helper-macro, which does on demand the required L-suffix. Something like in global configure headers: #ifdef __SIZEOF_LONG <= 32 #define MSABI_LONG(VAL) VAL ## L #else #define MSABI_LONG(VAL) VAL #endif And then using in platform/sdk headers ... #define XYZ MSABI_LONG(0x1234) ... instead. Regards, Kai

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Michael Stefaniuc

Hello Jacek! Jacek Caban wrote: > On 10/26/11 00:30, Michael Stefaniuc wrote: >> --- >> include/d3d9caps.h | 182 >> ++++++++++++++++++++++++++-------------------------- >> 1 files changed, 91 insertions(+), 91 deletions(-) >> >> diff --git a/include/d3d9caps.h b/include/d3d9caps.h >> index 8ed6598..64dba21 100644 >> --- a/include/d3d9caps.h >> +++ b/include/d3d9caps.h >> @@ -29,13 +29,13 @@ >> #define D3DCURSORCAPS_LOWRES 2 >> >> >> -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L >> -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L >> -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L >> -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L >> -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L >> -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L >> -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L >> +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 >> +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 >> +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 >> +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 >> +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 >> +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 >> +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 >> > > mingw-w64 project imports some of our headers, including most of d3d > headers. They would probably prefer to keep them with 'l' modifier since > that's the right thing to do. Given that it's mostly harmless for Wine, > could we please consider not changing it? Well ... the the dinput.h was a real change were Wine was affected. But the change should be mostly harmless for mingw-w64 as long == int on Win32 and Win64. Anyway this is a hit job from Alexandre so you'll have to convince him. bye michael

Oct. 26, 2011

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h

by Jacek Caban

Hi Michael, On 10/26/11 00:30, Michael Stefaniuc wrote: > --- > include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- > 1 files changed, 91 insertions(+), 91 deletions(-) > > diff --git a/include/d3d9caps.h b/include/d3d9caps.h > index 8ed6598..64dba21 100644 > --- a/include/d3d9caps.h > +++ b/include/d3d9caps.h > @@ -29,13 +29,13 @@ > #define D3DCURSORCAPS_LOWRES 2 > > > -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L > -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L > -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L > -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L > -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L > -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L > -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L > +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 > +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 > +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 > +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 > +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 > +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 > +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 > mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Thanks, Jacek

Oct. 26, 2011