Compatibility with WPS Office et.exe: ensure AppDomain created like excel.exe

Hello Excel-DNA team,

I'm opening this issue to discuss ​​improving compatibility with WPS Office​​, specifically its spreadsheet component et.exe. Currently, it appears that the Excel-DNA runtime loader does not create an AppDomain when running undering et.exe(the main process for WPS Spreadsheets), where as it does so correctly for Microsoft Excel's excel.exe.

Verification Method and Observations​​

To pinpoint the root cause of the issue, I conducted a critical test: ​​temporarily renaming the WPS Spreadsheets process et.exe to excel.exe​​.

1、​​Test Result​​: After renaming, the Excel-DNA add-in ​​loaded and ran normally within WPS Office​​, exhibiting behavior consistent with its operation in Microsoft Excel.

​​2、Inference​​: This result strongly suggests that the current Excel-DNA runtime loader ​​determines whether to initialize the AppDomain and related environment by checking the host process's image name​​. Since et.exe is not on its recognized whitelist, it is ignored, preventing the add-in from functioning properly.

​​3、Suggested Solution and Questions​​

Based on the above test, the most straight forward and effective solution would be to ​​modify the function responsible for identifying the host process in the runtime loader​​ (e.g., IsRunningOnClusteror a similar function), adding et.exe to the whitelist.

I noticed a potential function in the code (or similar logic) and suggest modifying its condition as follows:

// Suggested code modification: Add recognition for "et.exe" in the condition

```cpp
BOOL IsRunningOnCluster()
{
// Our check is to see if the current process is called Excel.exe.
// Hopefully this doen't change soon.

TCHAR hostPathName[MAX_PATH];
DWORD count = GetModuleFileName(NULL, hostPathName, MAX_PATH);

std::wstring hostPath = hostPathName;
StripPath(hostPath);

if (CompareNoCase(hostPath, L"EXCEL.EXE") == 0 || CompareNoCase(hostPath, L"ET.EXE") == 0)
{
return false;
}

return true;
}
```
​​What I'd like to confirm with you is​​:
1.Is this modification technically ​​feasible and reasonable​​?

2.Could this change introduce any potential ​​compatibility risks​​ or ​​side effects​​?

3.Are there any other ​​more recommended or elegant approaches​​ to implementation?
Thank you for considering this enhancement.