From Wiki96
Jump to: navigation, search
(Added the Module Part)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Win96 Run Time, sometimes abbreviated as WRT, is the runtime behind the Windows 96 binaries.
'''Win96 Run Time''', sometimes abbreviated as WRT, is the runtime behind the Windows 96 binaries.


== Features ==
== Features ==
A script executed with the WRT will behave differently than a normal script. Firstly, this script will be able to use <code>FS</code>, <code>FSUtil</code>, <code>WApplication</code>, <code>StandardWindow</code>, <code>registerApp</code> and <code>deregisterApp</code> without having to use the <code>w96</code> namespace before. these script will also be able to use the WRT module API where the <code>module</code> object is available for exporting data and <code>include</code> for getting module exported data. Scripts executed with the WRT will also be executed in an asyncronous context, so it is possible to use top-level <code>await</code>.
A script executed with the WRT will behave differently than a normal script. Firstly, WRT scripts will be able to use <code>FS</code>, <code>FSUtil</code>, <code>WApplication</code>, <code>StandardWindow</code>, <code>registerApp</code> and <code>deregisterApp</code> without having to use the <code>w96</code> namespace. They will also be able to use the WRT module API where the <code>module</code> object is available for exporting data and <code>include</code> for getting module exported data. Scripts executed with the WRT will also be executed in an asynchronous context, making it possible to use top-level <code>await</code>.


== Usage ==
== Usage ==
To execute a script using the WRT, there are 2 options:
To execute a script using the WRT, there are 2 options:


* Start the script with the following shebang: <code>//!wrt</code>
# Have this shebang <code>//!wrt</code> be the first line of the script
* Run the <code>wrtrun</code> command with the path to the script
# Run the <code>wrtrun</code> command with the path to the script in the Terminal.


== History ==
== History ==
The Windows Runtime was introduced in Windows 96 v2 Service Pack 2.<blockquote>"A set of APIs which allow you to easily make apps and include modules, without worrying about the filesystem and stuff like that."
The Windows Runtime was introduced in [[Windows 96 v2]] Service Pack 2.
 
From the changelog:
 
<blockquote>"A set of APIs which allow you to easily make apps and include modules, without worrying about the filesystem and stuff like that."


''Windows 96 devs in the rel2sp2 changelog.''</blockquote>
''Windows 96 devs in the rel2sp2 changelog.''</blockquote>


== Shebang ==
== Shebang ==
The shebang is the first line of a binary. The WRT shebang starts with <code>//!wrt</code>. The shebang denotes that this regular file is a WRT bin, and must be the very first line in any WRT application.  
A shebang is a marker starting with <code>//</code> (or <code>#!</code> in Unix's case which is where this feature comes from), which can contain a path to any executable. It is always placed at the first line of a file. If any file with a shebang is ran like an executable, the program loader loading the file will interpret the shebang and pass the file being ran to the shebang's specified executable as the first argument.
 
In this case, a shebang for the WRT is defined like so: <code>//!wrt</code>. The shebang denotes that the file is a WRT binary, and must be the very first line in any WRT application.  


=== The binary specification (BSPEC) ===
=== The binary specification (BSPEC) ===
The binary specification (BSPEC) is a way to describe metadata for a WRT bin. It always follows the shebang on the same line, where the cumulative line size must not exceed 256 characters.
The binary specification (BSPEC) is a structure which contains metadata for a WRT binary. It always follows the shebang on the same line, where the cumulative line size must not exceed 256 characters.


The BSPEC is a simple JSON object prefixed with <code>$BSPEC:</code> and contains the following fields:
The BSPEC is a simple JSON object prefixed with <code>$BSPEC:</code> and contains the following fields:
Line 31: Line 37:
* <code>ver</code> - The version of the application.
* <code>ver</code> - The version of the application.


Below is an example of a binary specification declaration for the File Explorer application.<syntaxhighlight lang="javascript">
Below is an example of a binary specification declaration for the File Explorer application.
 
<syntaxhighlight lang="javascript">
//!wrt $BSPEC:{"icn":"apps/explorer","cpr":"Copyright (C) Windows 96 Team 2021.","dsc":"System File Explorer","frn":"Explorer","ver":1}
//!wrt $BSPEC:{"icn":"apps/explorer","cpr":"Copyright (C) Windows 96 Team 2021.","dsc":"System File Explorer","frn":"Explorer","ver":1}
</syntaxhighlight>
</syntaxhighlight>


== Modules ==
== Modules ==
A module is a file called by a script in the WRT. Those files will also run in WRT and will have access to WRT features. In addition to this, modules can export data that can be used in other scripts and modules. A module can be called with the <code>include</code> function. It returns a Promise with the module exports.
A module is a file called by a script in the WRT. They will also run in WRT and have access to WRT features. In addition to this, modules can export data that can be used in other scripts and modules. A module can be called with the <code>include</code> function. It returns a Promise with the module exports.


The <code>include</code> function will returns:
The <code>include</code> function returns:


* The <code>module.exports</code> of a JavaScript file.
* The <code>module.exports</code> of a JavaScript file.
Line 45: Line 53:


=== Global Modules ===
=== Global Modules ===
Modules can also be global by declaring a JSON manifest in <code>C:/system/local/lib/modules</code> in the following format: <code>MODULE.json</code> where <code>MODULE</code> is the name of the module when including it. The content of this file should look like this:<syntaxhighlight lang="json" line="1" start="-2">
Modules can also be global by declaring a JSON manifest in <code>C:/system/local/lib/modules</code> in the following format: <code>MODULE.json</code> where <code>MODULE</code> is the name of the module when including it. The content of this file should look like this:
 
<syntaxhighlight lang="json" line="1" start="-2">
{
{
     "libPath": "C:/path/to/module.js"
     "libPath": "C:/path/to/module.js"
}
}
</syntaxhighlight>Then, the module can be accessed from any file by doing <code>include("MODULE")</code>.
</syntaxhighlight>
 
Then, the module can be accessed from any file by doing <code>include("MODULE")</code>.

Latest revision as of 14:49, 28 June 2024

Win96 Run Time, sometimes abbreviated as WRT, is the runtime behind the Windows 96 binaries.

Features

A script executed with the WRT will behave differently than a normal script. Firstly, WRT scripts will be able to use FS, FSUtil, WApplication, StandardWindow, registerApp and deregisterApp without having to use the w96 namespace. They will also be able to use the WRT module API where the module object is available for exporting data and include for getting module exported data. Scripts executed with the WRT will also be executed in an asynchronous context, making it possible to use top-level await.

Usage

To execute a script using the WRT, there are 2 options:

  1. Have this shebang //!wrt be the first line of the script
  2. Run the wrtrun command with the path to the script in the Terminal.

History

The Windows Runtime was introduced in Windows 96 v2 Service Pack 2.

From the changelog:

"A set of APIs which allow you to easily make apps and include modules, without worrying about the filesystem and stuff like that." Windows 96 devs in the rel2sp2 changelog.

Shebang

A shebang is a marker starting with // (or #! in Unix's case which is where this feature comes from), which can contain a path to any executable. It is always placed at the first line of a file. If any file with a shebang is ran like an executable, the program loader loading the file will interpret the shebang and pass the file being ran to the shebang's specified executable as the first argument.

In this case, a shebang for the WRT is defined like so: //!wrt. The shebang denotes that the file is a WRT binary, and must be the very first line in any WRT application.

The binary specification (BSPEC)

The binary specification (BSPEC) is a structure which contains metadata for a WRT binary. It always follows the shebang on the same line, where the cumulative line size must not exceed 256 characters.

The BSPEC is a simple JSON object prefixed with $BSPEC: and contains the following fields:

  • icn - The name of the icon to use.
  • cpr - The copyright holder of the application.
  • dsc - A basic description of the application.
  • frn - The display name of the application.
  • aut - The application author.
  • ssy - The subsystem to use for this application. Can either be gui or cli.
  • ver - The version of the application.

Below is an example of a binary specification declaration for the File Explorer application.

//!wrt $BSPEC:{"icn":"apps/explorer","cpr":"Copyright (C) Windows 96 Team 2021.","dsc":"System File Explorer","frn":"Explorer","ver":1}

Modules

A module is a file called by a script in the WRT. They will also run in WRT and have access to WRT features. In addition to this, modules can export data that can be used in other scripts and modules. A module can be called with the include function. It returns a Promise with the module exports.

The include function returns:

  • The module.exports of a JavaScript file.
  • The parsed content of a JSON file.
  • The raw content of any other file type.

Global Modules

Modules can also be global by declaring a JSON manifest in C:/system/local/lib/modules in the following format: MODULE.json where MODULE is the name of the module when including it. The content of this file should look like this:

{
    "libPath": "C:/path/to/module.js"
}

Then, the module can be accessed from any file by doing include("MODULE").