[PATCH v2 4/6] d3dx10_43: Add D3DX10CreateAsyncTextureInfoProcessor stub.

[Piotr Caban]

Signed-off-by: Piotr Caban 
---
  dlls/d3dx10_43/async.c        | 6 ++++++
  dlls/d3dx10_43/d3dx10_43.spec | 2 +-
  include/d3dx10.h              | 2 +-
  include/d3dx10async.h         | 2 ++
  4 files changed, 10 insertions(+), 2 deletions(-)

[Matteo Bruni]

With the subject prefix changed to "d3dx10:"

Signed-off-by: Matteo Bruni

[Matteo Bruni]

On Thu, May 26, 2022 at 6:33 PM Piotr Caban  wrote:
> Signed-off-by: Piotr Caban
>
> dlls/d3dx10_43/async.c        | 6 ++++++
>   dlls/d3dx10_43/d3dx10_43.spec | 2 +-
>   include/d3dx10.h              | 2 +-
>   include/d3dx10async.h         | 2 ++
>   4 files changed, 10 insertions(+), 2 deletions(-)
> diff --git a/dlls/d3dx10_43/async.c b/dlls/d3dx10_43/async.c
> index ebef97a7e12..d636127475d 100644
> --- a/dlls/d3dx10_43/async.c
> +++ b/dlls/d3dx10_43/async.c
> @@ -456,6 +456,12 @@ HRESULT WINAPI D3DX10CreateAsyncResourceLoaderW(HMODULE module, const WCHAR *res
>     return S_OK;
> }
>
> +HRESULT WINAPI D3DX10CreateAsyncTextureInfoProcessor(D3DX10_IMAGE_INFO *info, ID3DX10DataProcessor **processor)
> +{
> - FIXME("info %p, processor %p stub!\n", info, processor);
> - return E_NOTIMPL;
>
> +}

Just for my own curiosity: have you already thought about how to split
the functions and the source files between those that are to be shared
vs the version specific ones?

[Piotr Caban]

Hi Matteo,

On 6/1/22 15:38, Matteo Bruni wrote:
> Just for my own curiosity: have you already thought about how to split
> the functions and the source files between those that are to be shared
> vs the version specific ones?

The plan is to introduce wine-specific dll with shared code. Currently 
I'm trying to create helpers that later will be moved to this library 
(some modifications will be needed at this point). I'm also trying to 
find out what can/should be moved to separate dll. It's not really 
visible with patches that I have already sent but e.g. HRESULT parameter 
handling suggests that part of the error handling should not be done in 
shared code.

Thanks,
Piotr

[Matteo Bruni]

On Wed, Jun 1, 2022 at 4:14 PM Piotr Caban  wrote:
> Hi Matteo,
>
> On 6/1/22 15:38, Matteo Bruni wrote:
> > Just for my own curiosity: have you already thought about how to split
> > the functions and the source files between those that are to be shared
> > vs the version specific ones?
>
> The plan is to introduce wine-specific dll with shared code. Currently
> I'm trying to create helpers that later will be moved to this library
> (some modifications will be needed at this point). I'm also trying to
> find out what can/should be moved to separate dll. It's not really
> visible with patches that I have already sent but e.g. HRESULT parameter
> handling suggests that part of the error handling should not be done in
> shared code.

Excellent! Yeah, I'm not surprised that splitting the shared parts
won't always be obvious or trivial. I guess we'll get better tests as
a secondary benefit :)