1. весь код внести в одну безымянную функцию, вызываемую in-place

(function()
{
})();

Окей.

Да проще отказаться от ресурсов и конвертировать данные в строковые литералы. Согласен, что нужно избегать расширения прототипов тогда, когда это не критично.

Оба способа приемлимы.

Давайте еще подумаем как уменьшить скрипт. Может быть можно справиться с копированием wscript.exe? Если получится, то код существенно сократится. Плюс я говорил об использовании cab.

И вопрос новичка. Создание новой копии wscript.exe обязательно? Читал, но ни разу не пользовался таким свойством.

Естественно, при запуске WScript.exe в порядке приоритета сперва рассматриваются манифесты внутри каталога, где он лежит, а потом уже WinSxS. В этом суть переносного подхода.

Если есть у кого-то мысли по оптимизации

Несколько вариантов. Можно использовать вместе или по отдельности.

1. весь код внести в одну безымянную функцию, вызываемую in-place

(function()
{
})();

2. отказаться от метода Function.prototype.GetResource и полностью перенести функционал в функцию GetResource, чтобы "не засорять" прототип Function. Ведь Function.prototype.GetResource используется единожды - для распаковки ресурсов.
3. Сами ресурсы прятать в комментарии вида /*![[ ]]*/. Такие комментарии (с дополнительным восклицательным знаком) называются "важными" и умными сжимателями кода не удаляются.
4. Рекомендовать два способа использования

Способ А
Вставить предложенный код в начале своего проекта

Способ Б
Положить файл рядом со файлом своего проекта и в его начале выплнить код:

eval(function()
{
// открыть файл
// прочитать содержимое в переменную
// вернуть результат
}());

Как модификация всего. Весь код оформить в виде именованной функции (имя придумайте сами) и использовать почти аналогично сказанному выше

Способ В: используется особенность javascript - неявное "всплывание" объявлений функций

имя_функции();
// начинайте писать код с этого места :)
// вставить код в конце своего проекта

И вопрос новичка. Создание новой копии wscript.exe обязательно? Читал, но ни разу не пользовался таким свойством.

wscript.exe.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity
  type="win32"
  name="wscript.exe"
  version="1.0.0.0" /> 

  <dependency>
          <dependentAssembly>
              <assemblyIdentity
                  type="win32"
                  name="dynwrapx.sxs"
                  version="2.1.0.0" />
          </dependentAssembly>
  </dependency>

</assembly>

dynwrapx.sxs.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity
    type="win32"
    name="dynwrapx.sxs"
    version="2.1.0.0" />

<file name="dynwrapx.dll">
     <comClass
        clsid="{89565276-A714-4a43-912E-978B935EDCCC}"
        threadingModel="Both"
        progid="DynamicWrapperX" />
</file>

</assembly>

Код, который вложен в пост, перечислит открытые окна с использованием WinAPI.

Вкратце по алгоритму. Файл js хранит в себе ресурсы (2 манифеста, ActiveX-библиотеку и wscript.exe). При первом запуске осуществляется их проверка наличия возле файла скрипта. Далее, ресурсы распаковываются, после чего заново осуществляется запуск нашего js, но с помощью распакованного хоста wscript.exe.

Если есть у кого-то мысли по оптимизации, я буду рад слышать. Представляется, что одним из направлений оптимизации является сжатие кода путем вложения cab-архива, в котором находятся все 4 ресурса.