RE: msi:RECORD_StreamFromFile bug, help needed
> 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 don't have to use an IStream... I could alter msipriv.h such that MSIFIELD just holds a HANDLE in case the field is a stream. The handle can then be created through CreateFile, and I guess then I could alter the permissions such that it matches the MS implementation... Do you think that that is the way to go? Or is there a deep reason why we should use IStream, and create our own IStream implementation? Regards, Robert
RE: msi:RECORD_StreamFromFile bug, help needed
> 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, after MSI_RecordSetStreamFromFileW, you CAN call DeleteFile on that file. But you cannot open the file for writing; that will give ERROR_ACCESS_DENIED. I found in the specs of DeleteFile that this behaviour is understandable, because " The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. " On the other hand, it says: " The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. " So... I figured that somehow in the MS implementation of RecordSetStreamFromFile they called SHCreateStreamOnFileEx with parameters that allowed it to be scheduled for deletion through DeleteFile, and didn't allow the file to be opened again for writing. So far so good. So I set out to find this combination of parameters and I cannot find it. I saw that for CreateFile, you can pass FILE_SHARE_DELETE, and I guess that that allows for DeleteFile to be called. However, you cannot pass flags to SHCreateStreamOnFileEx that will cause this flag to be set... I am a bit out of ideas now... Maybe SHCreateStreamOnFileEx does NOT actually create the stream, but just opens the file and stores the filename in order to create the stream later on, when it is needed? Thus, some sort of lazy initialization? Any other ideas? Regards, Robert
RE: msi:RECORD_StreamFromFile bug, help needed
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 Van: Hans Leidekker [h...@codeweavers.com] Verzonden: dinsdag 19 juni 2012 13:04 Aan: robert.van.h...@serioustoys.com CC: wine-devel@winehq.org Onderwerp: RE: msi:RECORD_StreamFromFile bug, help needed 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 very small, only about 5 megs. This is wrong. In some > runs, > it goes fine though, and they reach 300 megs, which is the right size. > I find no error messages in the +relay trace... The process seems to be > completely > unpredictable. > > I can see in my Windows temp dir that the temporary files created there do > seem to > add up to about 300 megs, but then when the final MSI is baked, something > seems > to go wrong... (?) > > Would you have any idea of how this could be? > Maybe some race-condition? > > It seems to be unrelated to the other bug (the one described before: > GlobalAllocing > a big block to copy file contents into), because before this fix this current > behaviour also happened in the instances where the GlobalAlloc didn't fail. Can you please open a bug report for this and attach a +msi,+msidb trace?
RE: msi:RECORD_StreamFromFile bug, help needed
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 wrong. In some runs, it goes fine though, and they reach 300 megs, which is the right size. I find no error messages in the +relay trace... The process seems to be completely unpredictable. I can see in my Windows temp dir that the temporary files created there do seem to add up to about 300 megs, but then when the final MSI is baked, something seems to go wrong... (?) Would you have any idea of how this could be? Maybe some race-condition? It seems to be unrelated to the other bug (the one described before: GlobalAllocing a big block to copy file contents into), because before this fix this current behaviour also happened in the instances where the GlobalAlloc didn't fail. Any help would be appreciated! Kind regards, Robert Van: Hans Leidekker [h...@codeweavers.com] Verzonden: dinsdag 19 juni 2012 9:29 Aan: robert.van.h...@serioustoys.com CC: wine-devel@winehq.org Onderwerp: Re: msi:RECORD_StreamFromFile bug, help needed 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, was the intention to have a non-mutable copy in memory, in case > the backing file would be altered later on? 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. > I guess if that's the case, I could just create a copy of the original file in > a temp dir, and mark it as STGM_DELETEONRELEASE. It would take a long time to copy such a large file.
RE: msi:RECORD_StreamFromFile bug, help needed
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. > > So... I tried this out. I do not understand what I found though! > > On Windows, after MSI_RecordSetStreamFromFileW, you CAN call DeleteFile on > that file. > But you cannot open the file for writing; that will give ERROR_ACCESS_DENIED. > > I found in the specs of DeleteFile that this behaviour is understandable, > because > " > The DeleteFile function marks a file for deletion on close. Therefore, the > file > deletion does not occur until the last handle to the file is closed. > Subsequent > calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. > " > > On the other hand, it says: > " > The DeleteFile function fails if an application attempts to delete a file that > is open for normal I/O or as a memory-mapped file. > " > > So... I figured that somehow in the MS implementation of > RecordSetStreamFromFile > they called SHCreateStreamOnFileEx with parameters that allowed it to be > scheduled > for deletion through DeleteFile, and didn't allow the file to be opened again > for > writing. > > So far so good. > > So I set out to find this combination of parameters and I cannot find it. I > saw > that for CreateFile, you can pass FILE_SHARE_DELETE, and I guess that that > allows > for DeleteFile to be called. However, you cannot pass flags to > SHCreateStreamOnFileEx > that will cause this flag to be set... We don't have to call SHCreateStreamOnFileEx, we can add a suitable implementation to msi.
Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability.
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 Patch 1 & 2 > > Since part 2 and 3 are both dependent upon this code I chose to do it > this way in order to aid in any potential debugging and regression > testing (allowing for the easy independent removal of either the ToC > changes or the Index changes). So, would you prefer that I leave it; > just merge part 1 and 2; or merge part 1, 2, and 3. merge patch 1 and (patch 2 or patch 3) -- Best Regards, André Hentschel
Re: shell32: add some tests for the Progman DDE interface
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
Re: ntdll : add ThreadQuerySetWin32StartAddress in NtQueryInformationThread
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 that.
--
Alexandre Julliard
julli...@winehq.org
Re: mmcndmgr: Implement IMMCVersionInfo (try 4)
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 idea at this point, but it
definitely shouldn't be silently sneaked in as part of a different
patch.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 1/3] gdi32/tests: Make GetStockObject tests pass on East-Asian machines. (try 2)
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 > in the moderation queue. Hi Dmitry, Thank you for your advice. I'm not subscribed to wine-patches up to now, so it must be the reason of the delay. I'll subscribe to the list. Akihiro Sagawa
Re: [website] Portuguese translation for release 1.4.1
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 english version already. > > -N > > > On 06/19/2012 09:49 AM, Lucas Zawacki wrote: >> >> From: Lucas Zawacki >> >> --- >> news/pt/2012061501.xml | 13 + >> 1 file changed, 13 insertions(+) >> create mode 100644 news/pt/2012061501.xml >> >> diff --git a/news/pt/2012061501.xml b/news/pt/2012061501.xml >> new file mode 100644 >> index 000..7c0ff9f >> --- /dev/null >> +++ b/news/pt/2012061501.xml >> @@ -0,0 +1,13 @@ >> + >> +June 15, 2012 >> +Wine 1.4.1 Released >> + >> + The Wine maintenance release 1.4.1 is now available. >> + What's new in this release: >> + >> +Translation updates. >> +Various bug fixes. >> + >> +The source is> href="http://prdownloads.sourceforge.net/wine/wine-1.4.1.tar.bz2";>available >> now. >> +Binary packages are in the process of being built, and will appear soon >> at their respectivedownload locations. >> +
Re: [PATCH 1/3] gdi32/tests: Make GetStockObject tests pass on East-Asian machines. (try 2)
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.
Re: [5/5] gdiplus: Implement GdipImageSelectActiveFrame.
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;
> > +else if (image->type == ImageTypeMetafile)
> > +*(GpMetafile *)image = *(GpMetafile *)new_image;
> > +return Ok;
> > +}
>
> You appear to be leaking new_image.
Thanks. I hope that won't prevent accepting other patches in the series.
--
Dmitry.
Re: [PATCH 1/3] gdi32/tests: Make GetStockObject tests pass on East-Asian machines. (try 2)
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://source.winehq.org/git/wine.git/commitdiff/2bb416baa88c28f57bb0f65aa9af9fff603ba60d > http://source.winehq.org/git/wine.git/commitdiff/f503afd86ff9df9467eb1351cffd904ab3674285 Hi Bruno, Please ignore these patches. They were sent over 48 hours ago. It seems there is a huge delay between Gmail and wine-patches. Actually, one of my original patches are missed `static' keyword as Dmitry spotted(*). Therefore, I added the keyword and sent series of patches again. But, during transfer (>48 hours), the original patch was updated by Alexandre, then committed. After a while, my modified version was delivered and tested although they have already been applied. * ... http://www.winehq.org/pipermail/wine-devel/2012-June/095956.html Akihiro Sagawa
Re: [5/5] gdiplus: Implement GdipImageSelectActiveFrame.
>> 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);
> +if (image->type == ImageTypeBitmap)
> +*(GpBitmap *)image = *(GpBitmap *)new_image;
> +else if (image->type == ImageTypeMetafile)
> +*(GpMetafile *)image = *(GpMetafile *)new_image;
> +return Ok;
> +}
You appear to be leaking new_image.
Re: [5/5] gdiplus: Implement GdipImageSelectActiveFrame.
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.
Re: [5/5] gdiplus: Implement GdipImageSelectActiveFrame.
>> > + 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->type == ImageTypeMetafile)
>> > + *(GpMetafile *)image = *(GpMetafile *)new_image;
>> > + return Ok;
>> > + }
>>
>> Why did you re-implement move_bitmap() ?
>
> An image can be not a bitmap.
Yes, but a non-bitmap (metafile) cannot have multiple frames.
Re: [5/5] gdiplus: Implement GdipImageSelectActiveFrame.
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.
> > + 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->type == ImageTypeMetafile)
> > + *(GpMetafile *)image = *(GpMetafile *)new_image;
> > + return Ok;
> > + }
>
> Why did you re-implement move_bitmap() ?
An image can be not a bitmap.
--
Dmitry.
Re: [5/5] gdiplus: Implement GdipImageSelectActiveFrame.
> + 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)
> + *(GpBitmap *)image = *(GpBitmap *)new_image;
> + else if (image->type == ImageTypeMetafile)
> + *(GpMetafile *)image = *(GpMetafile *)new_image;
> + return Ok;
> + }
Why did you re-implement move_bitmap() ?
Re: d3dx9_36 [patch 1of 2]: Implementation of D3DXSHDot
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] = (FLOAT)i;
+b[i] = (FLOAT)i + 0.5f;
+}
+
+/* D3DXSHDot computes by using order * order elements */
+for (i = 0; i < 9; i++)
+{
+got = D3DXSHDot(i, a, b);
+ok(relative_error(got, expected[i]) < admitted_error, "order
%d: expected %f, received %f\n", i, expected[i], got);
+}
+
+return;
+}
+
Making the "a" and "b" arrays 90 elements big doesn't make much sense.
If your D3DXSHDot implementation is correct, for the i = 8 case you
only need 8 * 8 = 64 elements. Also notice that the "expected" array
has 10 elements, while you use only 9.
Also please recheck formatting and whitespaces of this patch and patch 2/2.
Re: [appdb] Upgrade to xinha svn head to fix issues with xinha editors not appearing in Firefox 15
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 +- > xinha/examples/Extended.html | 299 - > xinha/examples/Newbie.html | 12 +- > xinha/examples/XinhaConfig.js | 149 +- > xinha/examples/custom.css | 40 - > xinha/examples/dynamic.css | 56 - > xinha/examples/ext_example-body.html | 202 - > xinha/examples/ext_example-dest.php | 23 - > xinha/examples/ext_example-menu.php | 331 - > xinha/examples/ext_example.html | 16 - > xinha/examples/full_example.css | 48 - > xinha/examples/full_example.js | 97 - > xinha/examples/simple_example.html | 190 +- > xinha/examples/stylist.css | 31 - > xinha/examples/testbed.html | 45 +- > xinha/htmlarea.js | 44 +- > xinha/lang/b5.js | 58 +- > xinha/lang/ch.js | 112 +- > xinha/lang/cz.js | 100 +- > xinha/lang/da.js | 202 +- > xinha/lang/de.js | 338 +- > xinha/lang/ee.js | 100 +- > xinha/lang/el.js | 110 +- > xinha/lang/es.js | 207 +- > xinha/lang/eu.js | 2 +- > xinha/lang/fa.js | 6 +- > xinha/lang/fi.js | 76 +- > xinha/lang/fr.js | 338 +- > xinha/lang/gb.js | 58 +- > xinha/lang/he.js | 128 +- > xinha/lang/hu.js | 128 +- > xinha/lang/it.js | 110 +- > xinha/lang/ja.js | 6 +- > xinha/lang/lt.js | 106 +- > xinha/lang/lv.js | 84 +- > xinha/lang/nb.js | 156 +- > xinha/lang/nl.js | 128 +- > xinha/lang/pl.js | 2 +- > xinha/lang/pt_br.js | 180 +- > xinha/lang/ro.js | 126 +- > xinha/lang/ru.js | 370 +- > xinha/lang/sh.js | 2 +- > xinha/lang/si.js | 100 +- > xinha/lang/sr.js | 2 +- > xinha/lang/vn.js | 112 +- > xinha/modules/ColorPicker/ColorPicker.js | 1494 ++- > xinha/modules/CreateLink/link.js | 190 +- > xinha/modules/Dialogs/dialog.js | 159 +- > xinha/modules/Dialogs/inline-dialog.js | 204 - > xinha/modules/Dialogs/panel-dialog.js | 1 + > xinha/modules/Dialogs/popupwin.js | 291 +- > xinha/modules/FullScreen/full-screen.js | 373 +- > xinha/modules/Gecko/Gecko.js | 1225 ++- > xinha/modules/Gecko/paraHandlerBest.js | 1196 ++- > xinha/modules/Gecko/paraHandlerDirty.js | 116 - > xinha/modules/GetHtml/DOMwalk.js | 519 +- > xinha/modules/GetHtml/TransformInnerHTML.js | 368 +- > xinha/modules/InsertImage/insert_image.html | 345 +- > xinha/modules/InsertImage/insert_image.js | 214 +- > xinha/modules/InsertTable/insert_table.html | 314 +- > xinha/modules/InsertTable/insert_table.js | 153 +- > xinha/modules/InternetExplorer/InternetExplorer.js | 1150 ++- > xinha/plugins/CSS/css.js | 74 - > xinha/plugins/CharCounter/char-counter.js | 106 - > xinha/plugins/CharacterMap/CharacterMap.css | 6 +- > xinha/plugins/CharacterMap/character-map.js | 68 - > xinha/plugins/CharacterMap/lang/de.js | 22 +- > .../CharacterMap/popups/select_character.html | 184 - > xinha/plugins/ContextMenu/1.pl | 38 - > xinha/plugins/ContextMenu/context-menu.js | 383 - > xinha/plugins/ContextMenu/lang/de.js | 100 +- > xinha/plugins/ContextMenu/lang/el.js | 94 +- > xinha/plugins/ContextMenu/lang/fr.js | 98 +- > xinha/plugins/ContextMenu/lang/he.js | 94 +- > xinha/plugins/ContextMenu/lang/nl.js
RE: msi:RECORD_StreamFromFile bug, help needed
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 very small, only about 5 megs. This is wrong. In some > runs, > it goes fine though, and they reach 300 megs, which is the right size. > I find no error messages in the +relay trace... The process seems to be > completely > unpredictable. > > I can see in my Windows temp dir that the temporary files created there do > seem to > add up to about 300 megs, but then when the final MSI is baked, something > seems > to go wrong... (?) > > Would you have any idea of how this could be? > Maybe some race-condition? > > It seems to be unrelated to the other bug (the one described before: > GlobalAllocing > a big block to copy file contents into), because before this fix this current > behaviour also happened in the instances where the GlobalAlloc didn't fail. Can you please open a bug report for this and attach a +msi,+msidb trace?
Re: 'Expensive' expressions in loop limits (was: Implementation of D3DXSHScale)
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, and -O1 will optimize > it out anyway. Staying in the habit of avoiding 'expensive' > operations in loop limits might still be a good idea, since the > optimizer can't always save you. > > Or is that considered ugly these days? Of course as always a definitive "It depends". The safe approach is to *first* optimize for the human reader; the compilers this days are better at optimizing than the average programmer. bye michael
Re: d3dx9_36: Implementation of a test for D3DFMT_A8B8G8R8
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
'Expensive' expressions in loop limits (was: Implementation of D3DXSHScale)
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 habit of avoiding 'expensive' operations in loop limits might still be a good idea, since the optimizer can't always save you. Or is that considered ugly these days? D3DXSHAdd() has the same code, which is where this came from, probably.
Re: msi:RECORD_StreamFromFile bug, help needed
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, was the intention to have a non-mutable copy in memory, in case > the backing file would be altered later on? 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. > I guess if that's the case, I could just create a copy of the original file in > a temp dir, and mark it as STGM_DELETEONRELEASE. It would take a long time to copy such a large file.
