WindowsCodecs.dll内のCLSID_WICJpegQualcommPhoneEncoder は実装がない

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{68ED5C62-F534-4979-B2B3-686A12B2B34C}] @="WICJpegQualcommPhoneEncoder"

[HKEY_CLASSES_ROOT\CLSID\{68ED5C62-F534-4979-B2B3-686A12B2B34C}\InProcServer32]
@=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,\ 00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,77,00,69,00,\ 6e,00,64,00,6f,00,77,00,73,00,63,00,6f,00,64,00,65,00,63,00,73,00,2e,00,64,\ 00,6c,00,6c,00,00,00 "
ThreadingModel"="Both"

WICJpegQualcommPhoneEncoder のGUIDの定義があって WindowsCodecs.dllの中にもGUIDらしきものがあるので、レジストリ設定して使えるか試してみた。
逆アセンブルしてみると、定義はあるんだけど、実態が無かった。

ちなみに、Windows.Media.dll の方には呼び出し処理はあった。

L103EFEEF: xor bl,bl
  cmp [ebp+10h],bl
  jz L103EFF37
  test edi,edi
  jz L103EFF37
  mov eax,00000080h
  cmp [ebp-74h],eax
  jl L103EFF37
  cmp [ebp-70h],eax
  jl L103EFF37
  lea ecx,[ebp-000000B0h]
  call SUB_L1011BEC0
  lea eax,[ebp-000000B0h]
  push eax
  push L1007B4F4
  push 00000001h
  push 00000000h
  push L10071E44
  call [api_ms_win_core_com_l1_1_0_dll_DelayImport_CoCreateInstance]
  test eax,eax
  jns L103EFFE2

ちなみに c++で書くと

if(CoCreateInstance(CLSID_WICJpegQualcommPhoneEncoder, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&pEncoder))) {
 ...
}
みたいな感じ

arm版のWindows の処理はそっちでやってるのかも ?・ω・

おすすめ

4件のフィードバック

  1. helper より:

    The CLSID_WICJpegQualcommPhoneEncoder is a class identifier (GUID) that is associated with the Qualcomm Phone Encoder for JPEG images within the Windows Imaging Component (WIC) framework. It is used for encoding JPEG images using Qualcomm-specific algorithms.
    In the registry settings you provided, the CLSID_WICJpegQualcommPhoneEncoder is defined under the HKEY_CLASSES_ROOT\CLSID registry key. The InProcServer32 subkey specifies the path to the DLL (WindowsCodecs.dll) and sets the ThreadingModel to “Both”, indicating that the COM object can be accessed by both single-threaded and multi-threaded applications.
    However, despite the presence of the registry entry and the associated GUID definition within WindowsCodecs.dll, it seems that the actual implementation of the WICJpegQualcommPhoneEncoder functionality is missing or not available in the DLL.
    On the other hand, you mentioned that there is a calling process related to WICJpegQualcommPhoneEncoder within the Windows.Media.dll. This suggests that the functionality might be implemented in a different DLL (Windows.Media.dll) rather than WindowsCodecs.dll. The disassembled code snippet you provided indicates the use of the CoCreateInstance function to create an instance of CLSID_WICJpegQualcommPhoneEncoder, but the actual implementation details are not visible in the provided code snippet.

  2. helper より:

    The CLSID_WICJpegQualcommPhoneEncoder is a class identifier (GUID) that is associated with the Qualcomm Phone Encoder for JPEG images within the Windows Imaging Component (WIC) framework. It is used for encoding JPEG images using Qualcomm-specific algorithms.
    In the registry settings you provided, the CLSID_WICJpegQualcommPhoneEncoder is defined under the HKEY_CLASSES_ROOT\CLSID registry key. The InProcServer32 subkey specifies the path to the DLL (WindowsCodecs.dll) and sets the ThreadingModel to “Both”, indicating that the COM object can be accessed by both single-threaded and multi-threaded applications.
    However, despite the presence of the registry entry and the associated GUID definition within WindowsCodecs.dll, it seems that the actual implementation of the WICJpegQualcommPhoneEncoder functionality is missing or not available in the DLL.
    On the other hand, you mentioned that there is a calling process related to WICJpegQualcommPhoneEncoder within the Windows.Media.dll. This suggests that the functionality might be implemented in a different DLL (Windows.Media.dll) rather than WindowsCodecs.dll. The disassembled code snippet you provided indicates the use of the CoCreateInstance function to create an instance of CLSID_WICJpegQualcommPhoneEncoder, but the actual implementation details are not visible in the provided code snippet.

  3. helper より:

    I see the other post and you are correct in pointing out the discrepancy in the number of arguments in the CoCreateInstance function.
    The CoCreateInstance function is indeed defined with five parameters, as you mentioned:
    HRESULT CoCreateInstance(REFCLSID rclsid, IUnknown* punkAggOuter, DWORD dwCLSCTX, REFIID riid, LPVOID* ppvObj);
    In the disassembled code snippet you provided, it shows five arguments being passed to the CoCreateInstance function. The missing argument you mentioned seems to be the REFIID riid parameter, which represents the interface identifier of the requested interface.
    Regarding the usage of IID_PPV_ARGS, it is a helper macro that expands into code that resolves the REFIID parameter and passes it correctly. It essentially splits the fourth and fifth parameters of CoCreateInstance into the interface identifier and the address of the output pointer. So, when using IID_PPV_ARGS(&pEncoder), it resolves to:
    __uuidof(*(&pEncoder)), IID_PPV_ARGS_Helper(&pEncoder)
    This ensures that the correct interface identifier is passed as the fourth parameter and the address of the output pointer is passed as the fifth parameter.
    To summarize, when using the CoCreateInstance function, you can either manually pass the interface identifier and the address of the output pointer, as in:
    CoCreateInstance(CLSID_WICHeifEncoder, NULL, CLSCTX_INPROC_SERVER, IID_IWICBitmapEncoder, (LPVOID*)&pEncoder);
    Or you can use the IID_PPV_ARGS macro, which resolves the interface identifier and the output pointer address automatically, as in:
    CoCreateInstance(CLSID_WICHeifEncoder, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&pEncoder));
    I apologize for any confusion caused by my previous response, and I hope this clarifies the usage of CoCreateInstance and IID_PPV_ARGS.

  4. helper より:

    I see the other post and you are correct in pointing out the discrepancy in the number of arguments in the CoCreateInstance function.
    The CoCreateInstance function is indeed defined with five parameters, as you mentioned:
    HRESULT CoCreateInstance(REFCLSID rclsid, IUnknown* punkAggOuter, DWORD dwCLSCTX, REFIID riid, LPVOID* ppvObj);
    In the disassembled code snippet you provided, it shows five arguments being passed to the CoCreateInstance function. The missing argument you mentioned seems to be the REFIID riid parameter, which represents the interface identifier of the requested interface.
    Regarding the usage of IID_PPV_ARGS, it is a helper macro that expands into code that resolves the REFIID parameter and passes it correctly. It essentially splits the fourth and fifth parameters of CoCreateInstance into the interface identifier and the address of the output pointer. So, when using IID_PPV_ARGS(&pEncoder), it resolves to:
    __uuidof(*(&pEncoder)), IID_PPV_ARGS_Helper(&pEncoder)
    This ensures that the correct interface identifier is passed as the fourth parameter and the address of the output pointer is passed as the fifth parameter.
    To summarize, when using the CoCreateInstance function, you can either manually pass the interface identifier and the address of the output pointer, as in:
    CoCreateInstance(CLSID_WICHeifEncoder, NULL, CLSCTX_INPROC_SERVER, IID_IWICBitmapEncoder, (LPVOID*)&pEncoder);
    Or you can use the IID_PPV_ARGS macro, which resolves the interface identifier and the output pointer address automatically, as in:
    CoCreateInstance(CLSID_WICHeifEncoder, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&pEncoder));
    I apologize for any confusion caused by my previous response, and I hope this clarifies the usage of CoCreateInstance and IID_PPV_ARGS.

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です