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] |
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++で書くと
...
}
arm版のWindows の処理はそっちでやってるのかも ?・ω・
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.
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.