Crash fix in WSH runtime

[gnh1201]

The existing code forces the invocation of the htmlfile module even in the WSH environment, which can cause crashes on machines where calling the htmlfile module is restricted (e.g., due to unknown changes in IE-related settings).

In the case of WSH (ornon-browser ES3 environment), its usage differs significantly from that of IE (as it is a standalone runtime rather than a web browser), so there is no real need to invoke the htmlfile module. The issue can be resolved by not calling htmlfile at all in the WSH environment.

The related issue is as follows:

• object-create在非浏览器环境下会报错 #1395
• ActiveXObject fallback in core-js #1534
• CScript is Windows and not welsonjs example seems miss leading gnh1201/welsonjs#308

[gnh1201]

#970 #966

[gnh1201]

For now, I’ve only addressed the app crash issue. I’ll update the code shortly with improvements that more closely align with the intended purpose of Object.create.

[gnh1201]

On 32-bit systems only (64-bit is not supported), there is a way to obtain a fresh "Object" constructor. I implemented this in my changes as a function called NullProtoObjectViaSc32bit.

If we cannot give up null-prototype objects, using the NullProtoObjectViaSc32bit approach could be a viable option.

[gnh1201]

I have added a fallback for 64-bit systems.

[johnzhou721]

@zloirock Since people have asked about 3 tickets about this, can we try to accept this PR? ActiveX ScriptControl in WSH 32-bit ships out-of-the-box, 64-bit can be installed by a third-party, and this also catches any exceptions and adds a better error message.

@gnh1201 This looks pretty good. Excited to see people dig this deep to get foriegn objects in JavaScript