{
	"id": "7996c1a5-28b2-4b27-b150-41064bdd52e6",
	"created_at": "2026-04-06T00:22:20.886583Z",
	"updated_at": "2026-04-10T13:12:08.582777Z",
	"deleted_at": null,
	"sha1_hash": "8b261dee592b7d77789b444b7de58a4640ced8b4",
	"title": "Windows Script Interfaces",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 53138,
	"plain_text": "Windows Script Interfaces\r\nBy mikejo5000\r\nArchived: 2026-04-05 14:04:22 UTC\r\nMicrosoft Windows Script Interfaces provide a way for an application to add scripting and OLE automation.\r\nScripting hosts that rely on Windows Script can use scripting engines from multiple sources and vendors to\r\nmanage scripting between components. The implementation of the script itself—language, syntax, persistent\r\nformat, execution model, and so on—is left to the script vendor.\r\nWindows Script documentation is divided into the following sections:\r\nWindows Script Hosts\r\nWindows Script Engines\r\nActive Script Debugging Overview\r\nActive Script Profiling Overview\r\nWindows Script Interfaces Reference\r\nWindows Script Background\r\nWindows Script interfaces fall into two categories: Windows Script hosts and Windows Script engines. A host\r\ncreates a scripting engine and calls on the engine to run the scripts. Examples of Windows Script hosts include:\r\nMicrosoft Internet Explorer\r\nInternet authoring tools\r\nShell\r\nWindows Script engines can be developed for any language or run-time environment, including:\r\nMicrosoft Visual Basic Scripting Edition (VBScript)\r\nPerl\r\nLisp\r\nTo make implementation of the host as flexible as possible, an OLE Automation wrapper for Windows Script is\r\nprovided. However, a host that uses this wrapper object to instantiate the scripting engine does not have the degree\r\nhttps://docs.microsoft.com/scripting/winscript/windows-script-interfaces\r\nPage 1 of 3\n\nof control over the run-time name space, the persistence model, and so on, that it would if it used Windows Script\r\ndirectly.\r\nThe Windows Script design isolates the interface elements required only in an authoring environment so that\r\nnonauthoring hosts (such as browsers and viewers) and script engines (for example, VBScript) can be kept\r\nlightweight.\r\nWindows Script Basic Architecture\r\nThe following illustration shows the interaction between a Windows Script host and an Windows Script engine.\r\nThe steps involved in the interaction between the host and engine are given in the following list.\r\n1. Create a project. The host loads a project or document. (This step is not particular to Windows Script, but is\r\nincluded here for completeness.)\r\n2. Create the Windows Script engine. The host calls CoCreateInstance to create a new Windows Script\r\nengine, specifying the class identifier (CLSID) of the specific scripting engine to use. For example, the\r\nHTML browser of Internet Explorer receives the scripting engine's class identifier through the CLSID=\r\nattribute of the HTML \u003cOBJECT\u003e tag.\r\n3. Load the script. If the script contents have been persisted, the host calls the script engine's\r\nIPersist*::Load method to feed it the script storage, stream, or property bag. Otherwise, the host uses\r\neither the IPersist*::InitNew or IActiveScriptParse::InitNew method to create a null script. A host that\r\nmaintains a script as text can use IActiveScriptParse::ParseScriptText to feed the scripting engine the text\r\nof the script, after calling IActiveScriptParse::InitNew .\r\n4. Add named items. For each top-level named item (such as pages and forms) imported into the scripting\r\nengine's name space, the host calls the IActiveScript::AddNamedItem method to create an entry in the\r\nengine's name space. This step is not necessary if top-level named items are already part of the persistent\r\nstate of the script loaded in step 3. A host does not use IActiveScript::AddNamedItem to add sublevel\r\nnamed items (such as controls on an HTML page); rather, the engine indirectly obtains sublevel items from\r\ntop-level items by using the host's ITypeInfo and IDispatch interfaces.\r\n5. Run the script. The host causes the engine to start running the script by setting the\r\nSCRIPTSTATE_CONNECTED flag in the IActiveScript::SetScriptState method. This call would likely\r\nperform any scripting engine construction work, including static binding, hooking up to events (see below),\r\nand executing code, in a way similar to a scripted main() function.\r\n6. Get item information. Each time the script engine needs to associate a symbol with a top-level item, it calls\r\nthe IActiveScriptSite::GetItemInfo method, which returns information about the given item.\r\n7. Hook up events. Before starting the actual script, the scripting engine connects to the events of all the\r\nrelevant objects through the IConnectionPoint interface.\r\nhttps://docs.microsoft.com/scripting/winscript/windows-script-interfaces\r\nPage 2 of 3\n\n8. Invoke properties and methods. As the script runs, the scripting engine realizes references to methods and\r\nproperties on named objects through IDispatch::Invoke or other standard OLE binding mechanisms.\r\nWindows Script Terms\r\nThis list contains definitions of the scripting-related terms used in this document.\r\nTerm Definition\r\nCode\r\nobject\r\nAn instance created by the scripting engine that is associated with a named item, such as the\r\nmodule behind a form in Visual Basic, or a C++ class associated with a named item. Preferably,\r\nthis is an OLE Component Object Model (COM) object that supports OLE Automation so the\r\nhost or other non-script entity can manipulate the code object.\r\nNamed\r\nitem\r\nAn OLE COM object (preferably one that supports OLE Automation) that the host deems\r\ninteresting to the script. Examples include the HTML Page and Browser in a Web browser, and\r\nthe Document and Dialogs in Microsoft Word.\r\nScript\r\nThe data that makes up the program that the scripting engine runs. A script can be any\r\ncontiguous executable data, including pieces of text, blocks of pcode , or even machine-specific executable byte codes. A host loads a script into the scripting engine through one of the\r\nIPersist* interfaces or through the IActiveScriptParse interface.\r\nScripting\r\nengine\r\nThe OLE object that processes scripts. A scripting engine implements the IActiveScript and,\r\noptionally, IActiveScriptParse interfaces.\r\nScripting\r\nhost\r\nThe application or program that owns the Windows Script engine. The host implements the\r\nIActiveScriptSite and, optionally, IActiveScriptSiteWindow interfaces.\r\nScriptlet\r\nA portion of a script that gets attached to an object through the IActiveScriptParse interface.\r\nThe aggregate collection of scriptlets is the script.\r\nScript\r\nlanguage\r\nThe language in which a script is written (VBScript, for example) and the semantics of that\r\nlanguage.\r\nSource: https://docs.microsoft.com/scripting/winscript/windows-script-interfaces\r\nhttps://docs.microsoft.com/scripting/winscript/windows-script-interfaces\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.microsoft.com/scripting/winscript/windows-script-interfaces"
	],
	"report_names": [
		"windows-script-interfaces"
	],
	"threat_actors": [],
	"ts_created_at": 1775434940,
	"ts_updated_at": 1775826728,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8b261dee592b7d77789b444b7de58a4640ced8b4.pdf",
		"text": "https://archive.orkl.eu/8b261dee592b7d77789b444b7de58a4640ced8b4.txt",
		"img": "https://archive.orkl.eu/8b261dee592b7d77789b444b7de58a4640ced8b4.jpg"
	}
}