> We don't have to call SHCreateStreamOnFileEx, we can add a suitable
> implementation to msi.
Ah, I see.
I guess this stream cannot escape from MSI. The only way it can be accessed is
through MsiRecordReadStream and MsiRecordSetStream, but it can never be
accessed directly?
In that case, we
> Yes, the concern is that the file could be changed or removed. We should
> test what native does here but it probably means that we need to create a
> stream
> on the file with a sharing mode that denies writing.
So... I tried this out. I do not understand what I found though!
On Windows, afte
I am not able to reproduce the bug anymore :-S.
I hope it'll pop up in the coming days again, if so, I will send you the trace
:-).
I'll also give the sharing thing / SHCreateFileStream a try and see if I can
come up with a unit test...
Regards,
Robert
Dear Hans and dear group,
Thanks for your input!
I altered my local source tree, such that it opens the file exclusively as a
stream. That seems to work.
Having that fixed, at least provisionally, I am now facing another issue: my
MSIs are most of the time very small, only about 5 megs. This is
On Tue, 2012-06-19 at 20:55 +0200, robert.van.h...@serioustoys.com wrote:
> > Yes, the concern is that the file could be changed or removed. We should
> > test what native does here but it probably means that we need to create a
> > stream
> > on the file with a sharing mode that denies writing.
>
Am 19.06.2012 03:09, schrieb Erich E. Hoover:
> On Mon, Jun 18, 2012 at 3:26 PM, André Hentschel wrote:
>> Am 18.06.2012 15:52, schrieb Erich E. Hoover:
>> ...
>>> Changelog:
>>> hhctrl.ocx: Add HTML to Unicode decoding capability.
>>
>> You're adding dead code here, you should maybe merge Pat
Damjan Jovanovic writes:
> Changelog:
> * shell32: add some tests for the Progman DDE interface
Please merge that with the existing tests, assuming that what you are
testing is not already covered.
--
Alexandre Julliard
julli...@winehq.org
Roman Dadkov writes:
> @@ -63,7 +63,7 @@ struct reply_header
> /* this is used to construct the generic_request union */
> struct request_max_size
> {
> -int pad[16]; /* the max request size is 16 ints */
> +int pad[18]; /* the max request size is 18 ints */
> };
You can't change tha
Alistair Leslie-Hughes writes:
> @@ -66,8 +179,6 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason,
> LPVOID lpvReserved)
>
> switch (fdwReason)
> {
> -case DLL_WINE_PREATTACH:
> -return FALSE; /* prefer native version */
Changing this may or may not be a good
On Tue, 19 Jun 2012 23:40:33 +0900, Dmitry Timoshkov wrote:
> Akihiro Sagawa wrote:
>
> > Please ignore these patches. They were sent over 48 hours ago. It seems
> > there is a huge delay between Gmail and wine-patches.
>
> If you are not subscribed to wine-patches the e-mails you send get stuck
Disregard this patch. I added the wrong file to the commit and will resend.
On Tue, Jun 19, 2012 at 12:01 PM, Jeremy Newman wrote:
> This is just english. Did you mean for that to happen?
>
> No need to send the english, as if the xml does not exist, the site will
> always fall back to the englis
Akihiro Sagawa wrote:
> Please ignore these patches. They were sent over 48 hours ago. It seems
> there is a huge delay between Gmail and wine-patches.
If you are not subscribed to wine-patches the e-mails you send get stuck
in the moderation queue.
--
Dmitry.
Vincent Povirk wrote:
> > +if (stat == Ok)
> > +{
> > +memcpy(&new_image->format, &codec->info.FormatID, sizeof(GUID));
> > +free_image_data(image);
> > +if (image->type == ImageTypeBitmap)
> > +*(GpBitmap *)image = *(GpBitmap *)new_image;
> > +
On Tue, 19 Jun 2012 03:39:18 -0300, Bruno Jesus wrote:
> Hi, judging by the subjects I'd say the patches were commited already,
> you're trying to send them again or are they different patches?
>
> http://source.winehq.org/git/wine.git/commitdiff/afdc84cf0366c8e161004bf1e7bf9ccedbb4c45a
> http://s
>> Yes, but a non-bitmap (metafile) cannot have multiple frames.
>
> It actually can have records which represent embedded EMFs.
Really? Well, OK then.
> +if (stat == Ok)
> +{
> +memcpy(&new_image->format, &codec->info.FormatID, sizeof(GUID));
> +free_image_data(image);
>
Vincent Povirk wrote:
> >> Why did you re-implement move_bitmap() ?
> >
> > An image can be not a bitmap.
>
> Yes, but a non-bitmap (metafile) cannot have multiple frames.
It actually can have records which represent embedded EMFs.
--
Dmitry.
>> > + if (stat == Ok)
>> > + {
>> > + memcpy(&new_image->format, &codec->info.FormatID, sizeof(GUID));
>> > + free_image_data(image);
>> > + if (image->type == ImageTypeBitmap)
>> > + *(GpBitmap *)image = *(GpBitmap *)new_image;
>> > + else if (image->t
Vincent Povirk wrote:
> > + hr = IStream_Clone(image->stream, &stream);
> > + if (FAILED(hr))
>
> That's odd. When does that happen?
IStream returned by SHCreateStreamOnFile (wrapped by GdipCreateStreamOnFile)
intentionally doesn't implement Clone, there are even tests for that in shlwapi
> + hr = IStream_Clone(image->stream, &stream);
> + if (FAILED(hr))
That's odd. When does that happen?
> + if (stat == Ok)
> + {
> + memcpy(&new_image->format, &codec->info.FormatID, sizeof(GUID));
> + free_image_data(image);
> + if (image->type == ImageTypeBitmap
2012/6/19 Nozomi Kodama :
+static void test_D3DXSHDot(void)
+{
+unsigned int i;
+FLOAT a[90], b[90], got;
+CONST FLOAT expected[] =
+{ 0.0f, 0.0f, 17.0f, 222.0f, 1300.0f, 5050.0f, 15225.0f,
38612.0f, 86352.0f, 175500.0f, };
+
+for (i = 0; i < 90; i++)
+{
+a[i] = (FL
2012/6/18 André Hentschel :
> http://bugs.winehq.org/show_bug.cgi?id=30820
> ---
> xinha/Xinha.css | 229 +-
> xinha/XinhaCore.js |12107
> ++--
> xinha/contrib/php-xinha.php | 29 +-
> xi
On Tue, 2012-06-19 at 12:36 +0200, robert.van.h...@serioustoys.com wrote:
> I altered my local source tree, such that it opens the file exclusively as a
> stream. That seems to work.
>
> Having that fixed, at least provisionally, I am now facing another issue: my
> MSIs
> are most of the time ver
On 06/19/2012 10:47 AM, Dan Kegel wrote:
> Nozomi wrote:
> +for (i = 0; i < order * order; i++)
>
> I might have written
> int n = order * order;
> for (i=0; i < n; i++)
> to avoid repeating the multiplication every time around the loop,
> even though multiplication is cheap nowadays
I've also added a tests for this pixel format in the patch, which was
submitted yesterday:
http://www.winehq.org/pipermail/wine-patches/2012-June/115268.html
Nozomi wrote:
+for (i = 0; i < order * order; i++)
I might have written
int n = order * order;
for (i=0; i < n; i++)
to avoid repeating the multiplication every time around the loop,
even though multiplication is cheap nowadays, and -O1 will optimize
it out anyway. Staying in the h
On Mon, 2012-06-18 at 14:14 +0200, robert.van.h...@serioustoys.com wrote:
> But then I was thinking: this seems like such an obvious thing to do, that it
> is
> almost suspicious. Was there any reason for copying the file contents to main
> memory and then create a memory stream?
>
> For instance
26 matches
Mail list logo