"Marcus Meissner" <marcus(a)jet.franken.de> wrote:
> - MultiByteToWideChar(CP_ACP,0,lpszPath,-1,szPath,MAX_PATH);
> + INT ret;
> +
> + ret = MultiByteToWideChar(CP_ACP,0,lpszPath,-1,NULL,0);
> + if (ret > MAX_PATH) {
> + FIXME("Too long path!\n");
> + return FALSE;
> + }
> + ret = MultiByteToWideChar(CP_ACP,0,lpszPath,-1,szPath,sizeof(szPath)/sizeof(WCHAR));
It should be sufficient to check return value of MultiByteToWideChar
to detect an overflow, there is no need to call MultiByteToWideChar
twice for that.
--
Dmitry.
Hi,
I find discussion about XEMBED implementation in this mailing list and
that was 3 years ago. Is there now any usable implementation or examples
for wine XEMBED plug?
What I am doing is to embed IE into a GtkSocket. I wrote a standalone
program compiled using winelib that can CreateWindow and embed IE. Can I
CreateWindow using the XEMBED Id if there is already XEMBED
implementation or can I just CreateWindow as a child of a GtkPlug which
is a gtk-embeddee?
Any advices or suggestions would be highly appreciated. Thank you!
Regards,
cloudor
Hi,
I've done some more work on my state management, and I uploaded an updated
patch to http://stud4.tuwien.ac.at/~e0526822/wined3d-statemgmt-2.tar.bz2 .
Ok, so what's updated:
* Pixel shaders: Should work now
* GLSL shaders: Working too. Henris shader backend stuff is integrated in a
messy way.
* Offscreen rendering: Works with back buffer and pbuffer rendering, fbos not
yet.
* Stateblocks: Brute force integration by just scheduling all modified states
for a reset. No display list yet
* Blitting, render target unlocking: Enabled again, sets new gl states and
schedules a reapplication of the modified states. Not a nice solution yet
What is still missing:
* Nv register combiners. I haven't found a way yet to build a texture stage ->
texture unit mapping which I like. All the ways I could think of could
potentially cause lots of unneccessary state changes.
One nice thing I have noticed is that this changes give a huge performance
gain in Half-Life 2(dxlevel 80, and 90). Dxlevel 80 is accelerated to
approximately 150-200% of the former performance, and especially slow parts
are faster now. This makes a really huge playability difference :-)
There are some regressions too, especially related to texture
loading(3Dmark2000), and some glsl crashes. The good part about this change
is that I can send it in in very small patches, making regression testing
much easier, contrary to the huge ddraw rewrite.
Where to go from here? As long as nobody screams I'd start sending patches
now. Its easier to catch regressions while sending small patches instead of
hunting them on the blob I have here(and my messy patch history in my git
tree). I'm also afraid that I get too far away from the main wined3d code(See
the shader backend integration). We can discuss the code based on the small
changes I'll send.
Stefan
James Hawkins wrote:
> Changelog:
> * Remove redundant NULL checks before x_Release.
obj->Release() will read the vtable pointer from the object, and that
will crash if obj is NULL, so these checks are needed. The following
code will crash:
IUnknown *obj = NULL;
IUnknown_Release(obj);
You can see this looking at the definition of the IUnknown_Release macro:
include/unknwn.h:#define IUnknown_Release(p) (p)->lpVtbl->Release(p)
Mike
There is currently a bug in FC6 that affects Wine. If, with any Nvidia
driver from any source, a program attempts to use accelerated video and
the attached monitor uses digital feed the program will often crash the
user session. This has been reported and is not a problem in Wine but a
good many games that used to run under Wine now crash. Other cards were
not tested but may be affected. It is hoped RH will fix this rather
quickly.
On Friday 01 December 2006 07:23, Vitaliy Margolen wrote:
> Sorry ignore my previous patches. I didn't send them in the proper order.
>
> ---
> dlls/dinput/device.c | 28 ++++++++++++++++++++++++++++
> dlls/dinput/device_private.h | 3 +++
> dlls/dinput/joystick_linux.c | 23 ++++++++---------------
> dlls/dinput/keyboard.c | 36 ++++++++++++++++--------------------
> dlls/dinput/mouse.c | 23 ++++++++---------------
> 5 files changed, 63 insertions(+), 50 deletions(-)
>
Hi,
some questions/notices about this patch:
Previously when the device was not acquired inside JoystickAImpl_Unacquire DIERR_NOTACQUIRED was returned.
now you call IDirectInputDevice2AImpl_Unacquire, which returns DI_NOEFFECT when not acquired.
but DI_NOEFFECT does not have high bit set so it won't trigger the FAILED macro.
Do you know if the Acquire/Unacquire functions return value the same for all device types?
In JoystickAImpl_Acquire you don't use your new IDirectInputDevice2AImpl_Acquire function but set This->base.acquired = 1;
Is there a reason for this?
In SysKeyboardAImpl_Unacquire you seem to call IDirectInputDevice2AImpl_Acquire?
Greetings Peter
"Pierre d'Herbemont" <pdherbemont(a)free.fr> wrote:
> At the same time ShowWindow gets factorized because WindowCreate and
> ShowWindow share both the use of WINPOS_MinMaximize, so it is easier to
> factorize both functions in a single patch. In fact ShowWindow is
> removed entirely from the drivers as it is driver independant.
>
> To properly factorize WindowCreate we have to export 3 new functions
> from the graphics driver which are SetIconicState, SyncWindowStyle,
> SystrayDockWindow.
I'd suggest to leave ShowWindow in the driver's interface. You already
have created 3 new entry points to replace its partial functionality,
but still miss ShowWindow functionality for at least SW_RESTORE and
SW_MAXIMIZE. Also did you run 'make test' after this patch?
--
Dmitry.
"Charles Blacklock" <charles(a)diagnos.co.uk> wrote:
> + if (lcid == 0)
> + {
> + ret = memcmp(pbstrLeft, pbstrRight, min(SysStringByteLen(pbstrLeft), SysStringByteLen(pbstrRight)));
> + if (ret < 0)
> + return VARCMP_LT;
> + if (ret > 0)
> + return VARCMP_GT;
> + if (SysStringByteLen(pbstrLeft) < SysStringByteLen(pbstrRight))
> + return VARCMP_LT;
> + if (SysStringByteLen(pbstrLeft) > SysStringByteLen(pbstrRight))
> + return VARCMP_GT;
> + return VARCMP_EQ;
> + }
It would be much more effective to call SysStringByteLen only once for each
string instead of calling it again and again after a failing comparison.
--
Dmitry.
Hi, all
I am developing an swt app only for gtk. I want to embed IE into this
app. I can create a SWT.EMBEDDED composite and get its embededHandle
(an integer).
Then, how to do next? Thanks in advace!
regards,
cloudor