[PATCH] d3dx9: Avoid closing invalid handles.

Matteo Bruni matteo.mystral at gmail.com
Wed Dec 23 16:43:57 CST 2020


On Wed, Dec 23, 2020 at 2:30 PM Akihiro Sagawa <sagawa.aki at gmail.com> wrote:
>
> On Tue, 22 Dec 2020 21:34:34 +0100, Matteo Bruni wrote:
> > On Mon, Dec 21, 2020 at 2:44 PM Akihiro Sagawa <sagawa.aki at gmail.com> wrote:
> > >
> > > Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50373
> > > Signed-off-by: Akihiro Sagawa <sagawa.aki at gmail.com>
> > > ---
> > >  dlls/d3dx9_36/util.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> >
> > Do you know why it fails to map the file in the first place? Maybe it
> > simply doesn't exist?
> Yes, the file simply doesn't exist.
> It fails to load the specific .bmp file by D3DXCreateTextureFromFile and
> trys to load non-existent .dds/.png files next.

Okay, good to know.

> > FWIW I'd like to eventually replace map_view_of_file() entirely with
> > plain file loading, i.e. ReadFile and such. That's something for after
> > the code freeze though.
> Just curiously, why is plain file loading better?
> Could it be that page boundaries?

Using plain heap memory would avoid requiring page-size alignment and
granularity for the allocated memory, which is marginal but nice to
have on 32-bit in particular. But the main reason is that applications
might have the file already (or, still) open, perhaps because they
just created it, and IIRC you can't really use a more lax share mode
in CreateFile() if you want to call CreateFileMapping() onto it.
I feel like there was a somewhat recent bug along those lines (perhaps
to one of the other d3dx libs) but, of course, now I can't find it...



More information about the wine-devel mailing list