JScript: краткие сведения о PE файле .

Да я видел, но уже отметил, что интерес представляет не это:

Прочитать значение Subsystem из Optional Header?

Насколько я понимаю речь идёт о чтении заголовка EXE-файла. Вполне возможно, не проверял. И насколько это просто сделать скриптом?

Для чего надо узнать, с помощью какого хоста (WScript.exe/CScript.exe, возможно, переименованного) выполняется скрипт? Для того лишь, чтобы узнать, как себя будет вести WScript.Echo()? Но, если заведомо требуется диалоговое окно, можно использовать
MsgBox() или WshShell.Popup(),
а если нужен вывод в StdOut, то
WScript.StdOut.WriteLine() или
CreateObject("Scripting.FileSystemObject").GetStandardStream(1).WriteLine()
— да, StdOut доступен и в WScript.exe, если его вывод перенаправляется/перехватывается (невозможно только перенаправление в CON):

wscript.exe script.js > log.txt
wscript.exe script.vbs | more
for /f %i in ('wscript.exe script.wsf') do echo %i

MsgBox WshShell.Exec("wscript.exe script.vbs").StdOut.ReadAll()

А вот от того, в консоли или нет выполняется скрипт, зависит управление из него консольных приложений с помощью WshShell.Exec():
если да, то значит так и было задумано и WshShell.Exec() не будет создавать новых окон;
если же нет, то WshShell.Exec() будет запускать каждое консольное приложение в новом окне (именно так себя ведет себя скрипт в примере alexii, выполняющийся с помощью CScript.exe без собственного консольного окна и с перехватом его вывода VbsEdit)
и, чтобы этого не происходило, можно, чтобы скрипт перезапускал сам себя под управлением консольного хоста в скрытом окне.

И тут встаёт обратная задача — получить путь к консольномо хосту сценариев: стоит ли предполагать, что это CScript.exe, находящийся в одном из каталогов, перечисленных в %Path% или возможно лучшее решение?
Я нашёл только запись в реестре:

C:\>reg query "HKLM\SOFTWARE\Microsoft\Windows Scripting Host\Locations"

! REG.EXE VERSION 3.0

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Scripting Host\Locations
    CScript     REG_EXPAND_SZ   %SystemRoot%\System32\cscript.exe
    WScript     REG_EXPAND_SZ   %SystemRoot%\System32\wscript.exe

— Испольуется ли этот раздел для чего нибудь или это только атавизм, присутствует ли он в 64-разрядных системах?

Но задача-то ставилась узнать, какой из хостов используется.

alexii, а что, возможно несоответствие: скрипт может выполнятся в консоли с помощью неконсольного хоста или наоборот? По-моему, задача одна и та же.

В ряде случаев — вызовет.

Если скрипт выполняется не в консоли — это и есть критерий. Нет?

а именно, вызовет ли ошибку

В ряде случаев — вызовет.

Прочитать значение Subsystem из Optional Header?

Насколько я понимаю речь идёт о чтении заголовка EXE-файла. Вполне возможно, не проверял. И насколько это просто сделать скриптом? Скорее всего, в случае wscript.exe/cscript.exe это будет работать однозначно, но всегда ли предопределено, будет приложение исполняться как консольное или нет?

В любом случае речь шла о более скриптовом решении с помощью «утиной типизации» (что на мой взгляд является самым правильным подходом),
а именно, вызовет ли ошибку

CreateObject("Scripting.FileSystemObject").OpenTextFile("CON")

и в итоге сбился. А передумал потому, что в этом случае названия файлов сервера сценариев указаны безусловно, а в том присутствует оговорка в виде слова «обычно».

WScript.Path может указывать как на %windir%\System32, так и на %windir%\SysWOW64

Не обязательно. Описание свойства WScript.FullName из книги «Командные файлы и сценарии Windows Script Host»:

На мой взгляд, излишне по схожей причине.

Замечания, предложения, дополнения?

Скорее дополнение. Но код становится еще более избыточным.

Добавить полный путь до команды mode.com. Возможны два варианта:

абсолютный путь до утилиты
%windir%\\System32\\mode.com

путь относительно сервера сценариев (где WScript.Path может указывать как на %windir%\System32, так и на %windir%\SysWOW64)
WScript.Path + "mode.com"

Который из них лучше?

Пока косвенных проблем не почувствовал. Посмотрим дальше.