On 4/15/2013 02:50, Hin-Tak Leung wrote:
--- On Sun, 14/4/13, Vincent Povirk wrote:
Well, here's a simple thing you can
check: Does your zlib dll link to
_lseek or _lseeki64? The first one uses a 32-bit offset.
Wine's
implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090)
ex
On Apr 14, 7:20 PM, Hugh McMaster wrote:
>Is there something special/different that needs to be done for the server to
>accept input?
I can answer this myself now.
SERVER_START_REQ
{
req->spi_workarea.right = workarea.right;
req->spi_workarea.bottom = workarea.bottom;
wine_server_cal
Hello
thanks for the review.
I don't think that calling defines is the way to go. Indeed, I tested my patch
and yours. Yours is about 12% slower than mine in my computer.
And now, we try to take care of efficiency of this dll. So, it is not the time
to increase latency.
I used 10 digits sinc
--- On Sun, 14/4/13, Vincent Povirk wrote:
> Well, here's a simple thing you can
> check: Does your zlib dll link to
> _lseek or _lseeki64? The first one uses a 32-bit offset.
> Wine's
> implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090)
> expands that to 64-bit and later t
Well, here's a simple thing you can check: Does your zlib dll link to
_lseek or _lseeki64? The first one uses a 32-bit offset. Wine's
implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090)
expands that to 64-bit and later truncates the file offset to 32-bit.
For a file larger tha
--
On Sun, Apr 14, 2013 22:34 BST Vincent Povirk wrote:
>> considering how old zlib is and the vast number of windows application which
>> uses zlib
>
>Given how many people duplicate the effort to package zlib, the fact
>that they're rarely updated, and the sort
> considering how old zlib is and the vast number of windows application which
> uses zlib
Given how many people duplicate the effort to package zlib, the fact
that they're rarely updated, and the sort of problems gnulib exists to
work around, it would not surprise me if your particular zlib bina
I am porting an application which uses zlib's gzseek quite extensively to do
pseudo- random access of the content of large gz'ed files, in the same manner
of some's use of posix's lseek.
On small test data, it works correctly on wine. (identical result as linux). On
production data - a large 9G
On 13.04.2013 01:55, Nozomi Kodama wrote:
Is there a problem with this patch?
http://source.winehq.org/patches/data/9
Nozomi
Looks pretty much ok, but isn't there a way to reduce the size a bit?
Just see the dirty hack which is attached. D3DXSHMultiply6 will add a
lot of lines too...
On Apr 13, 2013, Charles Davis wrote:
> STOP! You should modify server/protocol.def instead. The file you changed is
> automatically generated from protocol.def, along with a bunch of other files
> needed to make the server interface magic work.
>> On Apr 13, 2013, at 7:39 AM, Hugh McMaster wro
On 13 April 2013 16:37, Stefan Dösinger wrote:
> @@ -965,8 +965,6 @@ static HRESULT texture_init(struct wined3d_texture
> *texture, UINT width, UINT he
> && !(format->id == WINED3DFMT_P8_UINT &&
> gl_info->supported[EXT_PALETTED_TEXTURE]
> && wined3d_settings.rendertarg
11 matches
Mail list logo
