Customizing LiteStep 3rd edn. 2.1 RC Commands
LiteStep チュートリアル 第3版 2.1 RC コマンド
Author: 河本孝之 (Takayuki Kawamoto, aka philsci);
1st appeared on 23th-26th February, 2003.
Revised on [1st March, 2003] and [8th March, 2003].
References:
ayamame, "litestep.exe", ls mod doc dog.
the LiteStep Documentation Effort Team, "litestep", LiteStep v. 0.24.6 documentation.
necro, "What is threading?", LiteStep FAQ.
Acknowledgement: thanks to ayamame, Fizz.oO, Fuji, hideh, Toshiyuki Itakura, Naoto Kanzaki, ken, Ks, ManiMani, Yusuke Mizukoshi, mth(k), N&R, Hirohisa Teramoto, Taro "O_SAKANA" Todoroki, and especially to the LiteStep Documentation Effort Team.
Copyright©2000-2003 by Takayuki KAWAMOTO.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
A copy of the license is included in the section entitled "GNU Free Documentation License" [translation in ja].
- RC コマンドの書式
- LSNoShellWarning (ExplorerNoWarn)
- LSSetAsShell (SetAsShell)
- LSNoStartup
- LSUseHooks
- LSLogFile
- LSLogLevel
- LSLogMaxSize
- LSLogOnMaxSize
- LSThemeFile
- LSImageFolder
- ThemeName
- ThemeAuthor
- NoSplashScreen, HideApplication
- LoadModule
step.rc には、「コマンド」と呼ばれる一群の命令を記述して LiteStep の動作や概観を設定します。コマンドには、初期設定として記述する「RC コマンド」と、マウスをクリックするなどのユーザーがおこなう動作（狭い意味での「イベント」）に応じて実行される「Bang コマンド」の二つがあります。Bang コマンドについては後述するとして、RC コマンドには LiteStep の基本的なシステム（コアモジュール）を設定するためのコマンドと、一般のモジュールで動作や見栄えを設定するためのコマンドがあります。
ここでは、まず LiteStep のコアモジュールを設定するための RC コマンドを紹介します。具体的には、litestep.exe （ReadConfig() クラス） と lsapi.dll が動作する際に必要な RC コマンドを先に解説して、ショートカットやトレイといった一般のモジュールで使う RC コマンドは個々のモジュールを紹介するときに解説します。
RC コマンドの書式
step.rc に RC コマンドを記述するときの書式は、次のとおりです。
コマンド [... 任意の数の半角スペースかタブ文字 ...] 引数
コマンドと引数（argument）の間には、少なくとも半角スペース一個以上を空けます。日本語環境、例えば shift_jis で入力する全角のスペース（#8140）は、1 バイト文字だけを使う他の文字コード環境では後の 1 バイト（40）が ASCII コードの "@" にあたるので、場合によってはプログラムを混乱させるかもしれません。但し、0.24.5 の頃には半角スペースが無視されるという現象もあったので、コマンドと引数をタブで区切った方がよかった時代もあります（笑。
引数には、ブール値（boolean values）と文字列が使えます。どのコマンドがどういう引数をとりうるかは、それぞれの場合に違っていますので、下記の解説を参考にして下さい。なお、LiteStep で「ブール値」として解釈される引数は、
| 真（デフォルトの動作が有効になる） | 偽（デフォルトの動作が無効になる） |
|---|---|
| TRUE | FALSE |
| YES | NO |
| ON | OFF |
となっています。
上記の表のうち、「デフォルトの動作」という書き方は少し注意が必要でしょう。仮に LSNoShellWarning というコマンドを書くとき、
LSNoShellWarning
とコマンドを書くだけで引数を省略しても動作するのですが、この場合には litestep.exe が内部的に定義しているデフォルトの設定が適用されます。LSNoShellWarning なら TRUE がデフォルトの引数になっているので、このコマンドが有効になります。デフォルトの値が "FALSE"、つまり「そのコマンドを（引数なしで）書くことによってそのコマンドが無効になる」というデフォルト設定は（「無効にするコマンドだけを書く」という趣旨の設定ファイルならともかく）確かに不自然なので、宣言すればそれがそのまま有効になるという解釈は当たり前と思えるかもしれませんが、引数を省略できるできないはコマンドによって違いますから、RC コマンドを書くだけで有効になるとは言っても引数はきちんとつけて下記のように書きましょう。
LSNoShellWarning TRUE
文字列を値として書くときの注意は、可能であれば二重引用符でくくるということです。litestep.exe と lsapi.dll は、半角スペースやタブなどの空白文字を区切り（デリミタ）として、step.rc に記述された設定を最小の単位（トークン）に分解します。このとき、スペースが入っている文字列（例えば Program Files など）を値として使うと、"C:\Program Files" という文字列を指定したつもりが "C:\Program までで切られてしまいます。
そして RC コマンドを書くときには、コマンドと引数を必ず一行に収めるようにして下さい。LiteStep のコマンドを解釈するパーサは、基本的に行志向（"line by line"）の処理をします。したがって、
LSSetAsShell
TRUE
といった複数行にまたがる記述はエラーとなります。
LSNoShellWarning [bool]
古いビルドでは ExplorerNoWarn となっていたコマンドです。現行の LiteStep でも両方のコマンドがサポートされていますが、古いコマンドをわざわざ使う意味はありませんので、古いテーマを導入する場合に ExplorerNoWarn が LSNoShellWarning のことだと分かればよいでしょう。
litestep.exe のデフォルトの動作では、LiteStep がエクスプローラなど他のシェルが動いている中で起動した場合に警告メッセージを表示します。LSNoShellWarning を有効にすると、この警告メッセージを表示しなくなります。特に警告メッセージを表示する理由がなければ、このコマンドを有効にしておきましょう。
| デフォルト設定 | LSNoShellWarning FALSE |
| 推奨設定 | LSNoShellWarning TRUE |
「デフォルト設定」は、LiteStep が内部的に用意しているデフォルトの設定を RC コマンドとして書き表した場合の設定内容です。LiteStep のプログラム内部で RC コマンドをそのまま変数名として使っているわけではありませんが、ここでは「RC コマンドとして表現すればこうなる」という仕方で、推奨設定と対比しやすくしています。
LSSetAsShell [bool]
これも古いビルドでは SetAsShell と書かれていたコマンドです。綴りだけを見ると LiteStep を Windows のシェルとして登録するコマンドみたいに見えますが、実際にはレジストリや system.ini とは何の関係もなく、ソースコードを見る限り USER32.DLL というウインドウ描画用のライブラリと関連付けするためのものに思えます。いづれにせよ、この宣言で何がどうなるのかは公式ドキュメントでも「不明」（Microsoft がこのコマンドで処理される API の仕様を公開していないため）としており、宣言しない（デフォルトの動作に任せる）方がいいとしています。
| デフォルト設定 | LSSetAsShell FALSE |
| 推奨設定 | 宣言しない（つまり上記と同じ） |
Documentation Effort Team のマニュアルなどには、これを宣言するとシェルをリカバリー（落ちたときに復旧）するという解説があります。確かに Windows Me 以降の Windows では、エクスプローラが落ちたときに Windows 側でリカバリーしてくれるのは事実ですが、この宣言をして LiteStep がリカバリーしたのを見たことがない（笑。ということで、開発チームもこれを宣言して何になるのか不明としています。
LSNoStartup [bool]
2002-01-13 ビルドで追加されたコマンドです。これはコマンドライン・スウィッチの -nostartup と同じで、宣言して有効にすればスタートアップ・フォルダの項目を無視します。
このコマンドを TRUE にして設定すべきかどうかは、あなたが LiteStep を再起動する頻度や目的にもよると思います。もしテーマを頻繁に切り替えていたりテーマを自作していて頻繁に再起動しているなら、再起動するたびにスタートアップ項目が起動して「既に起動しています」といったメッセージ・ウインドウが出るのは煩わしいでしょう。ただ、LSNoStartup を TRUE にすると、初回（ログイン後）の起動時にもスタートアップ項目が無視されてしまいます。そのため、スタートアップ項目を全てレジストリの RUN キーに登録する必要があるでしょう。
| デフォルト設定 | LSNoStartup FALSE |
| 推奨設定 | 宣言しない（つまり上記と同じ） |
LSUseHooks [bool]
このコマンドはテスト用のビルドでだけ有効になります。開発用のテスト環境で hook （マウスやキーボードからの入力つまりメッセージを、litestep.exe が横取りして処理すること）を有効にするかどうかを設定します。公開されているリリース版では宣言しても意味がありません。
| デフォルト設定 | LSUseHooks TRUE |
| 推奨設定 | 宣言しない（というかリリース版では使えません） |
LSLogFile [string]
2002-02-13 ビルドからサポートされた、ログファイルのファイル名を設定します。このログファイルには、LiteStep が起動するときの処理が記録されたり、API をサポートするモジュールからのメッセージが記録されたりします。例えば、以下のように出力されます。
02-05-2003 09:11:37 - LiteStep: Starting LiteStep 0.24.6
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\Desktop2.dll"
02-05-2003 09:11:37 - systray: loaded successfully
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\Systray2.dll"
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\Pcp_vol.dll"
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\Hotkey.dll"
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\chronos.dll"
02-05-2003 09:11:37 - Popup2: Constructed
02-05-2003 09:11:37 - Popup2: Initialized
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\popup2.dll"
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\SysVWM.dll"
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\Shortcut2.dll"
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\Tasks.dll"
02-05-2003 09:11:37 - DllMgr: Loaded module "C:\LiteStep\Themes\kobeGraySnow\modules\LSXCommand.dll"
02-05-2003 09:11:37 - TrayMan: No msg passed to systray, msg:1, ico:2, tip:0, hwnd: 0x1B02A8, classname: Connections Tray
02-05-2003 09:11:37 - TrayMan: No msg passed to systray, msg:1, ico:2, tip:0, hwnd: 0x1B02A8, classname: Connections Tray
02-05-2003 09:11:37 - StartupRunner: Running startup menu items.
02-05-2003 09:11:38 - TrayMan: No msg passed to systray, msg:0, ico:2, tip:0, hwnd: 0x1B02A8, classname: Connections Tray
02-05-2003 09:11:41 - DllMgr: Loaded module "lscp.dll"
一つのログを出力できる文字数は 2048 バイトと定められています。
このコマンドは引数に文字列（string）を取って、ファイル名もしくはパスを記述する際に使える文字は全て使えます。但し、半角英数文字とハイフンなど以外の文字でファイル名を指定するのはお勧めしません。
ファイル名の長さについては、9x 系と NT 系で差があると言われています。通常、9x 系の場合はファイル名を含むパス全体の長さを MAX_PATH という変数について 260 文字いないと定めており、NT 系ではファイル名だけの長さを 260 文字と定めています。
値に使える文字列ですが、後に紹介する「環境変数（environmental variables）」を代入することもできます。例えばシステムが予約している $LiteStepDir$ という環境変数は litestep.exe があるフォルダへのフルパスなので、
LSLogFile "$LiteStepDir$litestep.log"
と書けば、litestep.exe と同じフォルダにある litestep.log というファイルをログファイルとして指定したことになります。
| デフォルト設定 | LSLogFile なし |
| 推奨設定 | LSLogFile "litestep.log" |
書式について説明した冒頭の文章でも述べたように、文字列を値とする引数を指定するときは、特に問題がなくても二重引用符（"）をつけておきましょう。
2002-05-22 ビルドの改版履歴（changes.txt）によると、ログファイルのファイル名は "litestep.log" でなければ正しくログが書き込まれなかったようです。この制限（事実上 LSLogFile が無効なのと同じだから）は、2003-02-09 ビルドを使っている現状では既に直っているようですが、lscp.dll でログを見るためには、まだ "litestep.log" でなければならないようです。
値としてファイル名だけを指定した場合には、litstep.exe と同じフォルダにログファイルが作られます。これも 2002 年の前半頃に出ていたビルドでは C:\Documents and Settings\username の中にできてしまうといったバグがありました。
LSLogLevel [int]
ログ取得（出力）時のレベルを設定するためのコマンドで、正の整数（integer）を引数に取ります。ログ取得のレベルは以下のように 1～4 と決まっていて、最大値（nMaxLevel）以上の整数を指定すると、自動で最大値を指定したものと見做されます。
| 1 | LOG_ERROR: エラーを取得 |
| 2 | LOG_WARNING: エラーと警告を取得 |
| 3 | LOG_NOTICE: エラー, 警告と、ユーザーへ通知するための忠告を取得 |
| 4 | LOG_DEBUG: 上記全てとデバッグ用のメッセージを取得 |
| デフォルト設定 | LSLogLevel 2 |
| 推奨設定 | LSLogLevel 4 |
レベルを 4 にしているのは、ログは何であれ全て取得しておくべきだと思うからです。PHP や Perl などのプログラミングをするときもそうですが、何かがあったときに、どういう理由で何がエラーを起こしたのか、という情報を自分で隠して特になることなどありません。
但し、後で解説する「LiteStep コントロールパネル」にログを表示するとファイルサイズが大きいだけメモリを消費します。メモリの消費が嫌な方はレベルを落とすか、ログを小まめにバックアップしましょう。
LSLogMaxSize [int](kB)
kB（キロバイト）の単位で、ログファイルの最大サイズを指定します。2002-05-16 ビルドから使用可能です。
| デフォルト設定 | LSLogMaxSize 0 |
| 推奨設定 | LSLogMaxSize 100 |
この設定は読み込むモジュールの数やレベル設定にも大きく依存しますから、ご自由に設定してよいでしょう。なお、デフォルトの設定が 0 kB になっているのは、次に紹介する LSLogOnMaxSize でのデフォルト動作が !none（何もしない）となっていて、ログファイルのサイズを指定していなければ（最大値が 0 なので、LSLogOnMaxSize に指定されている bang コマンドが必ず実行される）何もしないということになり、ログの初期取得時（はじめて LiteStep を起動したとき）の動作として、何か特別な bang コマンドが実行できるからです。
LSLogOnMaxSize [action] [option]
上記の LSLogMaxSize で指定した、ログファイルの最大サイズ（kB）を越えるログが出力されたときに、このコマンドで指定する bang コマンドをオプション付で実行します。
| デフォルト設定 | LSLogOnMaxSize !none（何もしない） |
| 推奨設定 | LSLogOnMaxSize !clearlog（ログをクリアする） |
!clearlog は、2002-05-13 以降のビルドで有効な bang コマンドです。
本来は、ログファイルをリネームして保存するスクリプトを実行してから !clearog すべきです。mzScript.dll や、他のテキスト処理系のモジュールを導入しておけばよいでしょう。日時からファイル名を生成しておけば、あとでプロパティ（ファイルのタイムスタンプ）を見なくても整理しやすくなる筈です。頻繁に再起動などを行ってから lscp.dll で確認しているような場合に、LSLogMaxSize を小さくしてメモリの節約もできると思います。
LSThemeFile [string]
"ThemeFile" でも代用できます。theme.rc というファイル名で記述した、テーマの設定ファイルがあるパスをフルパスで指定します。
LiteStep では、サードパーティー製のモジュールを読み込んでいろいろな機能を拡張したり概観や操作性をカスタマイズできます。LiteStep がコアファイルとしてすることの他は、すべて「テーマ」と呼ばれるモジュールや画像の一式でまかなってやらなければなりません。
いまでは殆どのユーザーが step.rc だけを使っていますが、過去の LiteStep ではテーマごとの特殊な設定を theme.rc というファイルに分けようとしていました。現行の LiteStep は include 文をサポートしていますから元の theme.rc は obsolete（古い）仕様となりましたが、include できる特別なファイルとして theme.rc があるのは事実です。
| デフォルト設定 | LSThemeFile ""（theme.rc を使わない） |
| 推奨設定 | 宣言しない（theme.rc を使わない） |
include 文で代用できますから、ここでは使わないように宣言せずにおきます。なお、古い仕様で theme.rc を使う方は、
Litestep 0.24.0 Built-in Theme Support Notes, desktopian.org
をご覧下さい。
LSImageFolder [string]
0.24.5 までは PixMapPath というコマンドでした。コマンドの綴り方を統一したのをきっかけに、2000 年初頭に LSImageFolder という名前になりましたが、使い方は同じです。2002-12-19 mzks ビルドの lsapi.cpp を見る限り、まだ PixMapPath も使えるようです。
テーマの画像ファイルを置くデフォルトのフォルダを指定します。このコマンドで "C:\LiteStep\Themes\faverhymer\images" を設定しておくと、step.rc で画像ファイルを指定するときにファイル名だけを指定すれば、LSImageFolder で指定したフォルダの中を探してくれます。
| デフォルト設定 | LSImageFoler $LiteStepDir$images（litestep.exe があるフォルダの中にある images フォルダ） |
| 推奨設定 | LSImageFolder "$LiteStepDir$themes\faverhymer\images" |
後のページで解説する環境変数を使ってテーマのフォルダを指定してやれば、その環境変数を使っても構いません。但し、環境変数の定義をこのコマンドよりも先に書かなければなりません。
ThemeName [string]（半角 25 文字以内）
about ボックス（版数表示）で、テーマの名称を表示するためのコマンドです。自分で作ったテーマを公開するときに指定してもいいと思いますが、個人的に LiteStep を使っているだけなら宣言する必要はないでしょう。なお、ウインドウに表示する都合があって、半角英数字で 25 文字以内と決まっています。
試しに許容文字数以上を設定すると・・・制限されている文字数以上は単に表示されないだけです。なお、制限文字数を 20 と書いているサイトもありますが、実際には 25 文字まで出せます。
| デフォルト設定 | ThemeName なし |
| 推奨設定 | 宣言しない |
ThemeAuthor [string]（半角 15 文字以内）
上記と同じく、about ボックスでテーマの作者名を表示するのに使います。このコマンドも、半角英数字で 15 文字以内と決まっていて、それ以上の文字を指定しても枠から溢れて表示されません。
また、2 バイト文字を設定すると化けます。
| デフォルト設定 | ThemeAuthor (unknown) |
| 推奨設定 | 宣言しない |
なお、0.24.5 までは色の指定を BGR (青:緑:赤）の順番で記述していた経緯があって、順番を RGB にして記述するための ColorRGB というコマンドがサポートされていました。これは 0.24.6 ではサポートされておらず、デフォルトの色順が RGB になっています。
NoSplashScreen, HideApplication
NoSplashScreen, HideApplication は、それぞれ LiteStep のスプラッシュ・スクリーンを非表示にしたり、あるいは LiteStep 自身をタスクとして Alt + Tab で切り替える画面に表示しないようにするといった目的で用意されていたようです。しかし実際にはこれらは無効なコマンドであったため、現行の 0.24.6 ではサポートされていません。
LoadModule [モジュールへのパス] [threaded オプション]
一番最後に紹介しますが、RC コマンドとしては一番重要と言ってもよいでしょう。litestep.exe は、先のページで紹介したコア・モジュールの読み込みは起動時に自動で行いますが、それ以外のモジュールは LiteStep の動作に不可欠ではないため、ユーザーが読み込みたいモジュールを自分で指定して設定する必要があります。そのためには、まずモジュールを読み込んで LiteStep に知らせなければなりません。そのためのコマンドが LoadModule です。
引数である [モジュールへのパス] には、フルパスもしくは環境変数を使ったパスが指定できます。但し、環境変数自体も $LiteStepDir$ という litestep.exe のフルパス情報を起点に定義するので、実質的にはモジュールまでのフルパスを書いていることと同じになります。書式の例としては、
LoadModule C:\LiteStep\themes\faverhymer\module\desktop2.dll （フルパスで記述した場合）
LoadModule $ModuleDir$desktop2.dll （環境変数を使った場合）
などとなります。後で解説する環境変数を使っていないと、パスを部分的に変更する場合などは step.rc についてテキストエディタの全文置換をやることになって不便ですし、step.rc 自体の汎用性が損なわれるため、このチュートリアルではフルパスを使ったパスの指定は基本的に非推奨とします。
これが「モジュールを読み込むコマンド」だと分かれば、個々のモジュールの設定をこのコマンドの「後に」書かなければならないと思うかもしれません。が、LiteStep が step.rc のコマンドなどを読み取って解釈するとき、つまりパースするときは行志向（行を単位として）なのですが、それは設定情報をメモリへ読み込むまでの間です。step.rc などの設定情報を全てメモリへロードしてから個々のモジュールに設定を適用していくので、ポップアップ・メニューの設定を LoadModule ...popup2.dll というコマンドを宣言するより前の行に書いても、動作は変わりません。
このコマンドへは、引数に加えて "threaded" というオプションを追加できます。ここで「スレッド」の説明を LiteStep FAQ から借用すると次のようになります。
"Threading" is an experimental feature which allows the user to force modules to run in their own memory space. To make a module run in threaded mode, simply add the word "threaded" at the end of a LoadModule line in the Step.RC, as shown:
「スレッド」は、モジュールを固有のメモリ領域で扱えるようにするための実験的な機能です。スレッド・モードでモジュールを LiteStep システムへ読み込むには、"threaded" という語を step.rc に記述する LoadModule コマンドの末尾へ次のように追加するだけです。LoadModule $LiteStepDir$\vwm2.dll threaded
Because this is a new and experimental feature, there may be some unexpected and unpredictable results. The following is a list of the advantages of module threading, summarised from Headius' original post to the LiteStep Mailing List:
このオプションは新しくてまだまだ実験的な機能なので、期待外れの結果や予想外の結果が生じるかもしれません。しかし、この機能を使うと、元々は [0.24.5 の主任開発者であった] Headius さんが LiteStep のメーリングリストで報告してくれた、以下のような点で従来のシステムよりも有利となります。
- If a threaded module locks up, it will not prevent the rest of LiteStep from continuing to function normally.
もしモジュールがスレッド化して読み込まれると、LiteStep システムの他の機能が実行されていてもそれに干渉しないようになります。- The time required for LiteStep to startup may be slightly reduced, more so on multiprocessor systems.
LiteStep の起動に要する所要時間はいくらか短縮されるでしょうし、マルチプロセッサのシステムでは更に短縮されるでしょう。- The LiteStep core will function more cleanly, as it is not responsible for taking care of every single loaded module.
LiteStep のコア・モジュールは、読み込まれている個々の外部モジュールの動作がどうなっていようと独立して動作するようになるでしょう。[システム全体が堅牢になる]- The responsiveness of individual modules may increase as more CPU time can be devoted to each module, more so on multiprocessor systems.
個々の外部モジュールについて CPU 時間が多く割り当てられるほど、それらのモジュールに対する反応が向上するでしょう。マルチプロセッサのシステムならなおさらです。- In the future, it will be possible to unload and reload modules that are misbehaving, without requiring a full recycle or restart.
将来は、誤った動作をしたモジュールがあったときに LiteStep システム全体を Recycle したり再起動することなく、そのモジュールだけを Unload したり Reload できるようになるでしょう。As yet there is no definitive list of modules that respond well to threading and those that don't because results often differ widely between systems. It is recommended that you experiment with this feature and report any problems to the Development Team. (...from the LS Manual)
スレッド化によってパフォーマンスが向上するモジュール [モジュール側でもスレッド化に対応して開発する必要があるからでしょう] の完全なリストはまだないので、スレッド化の結果はシステムによってかなり差が出るため、スレッド化の恩恵を受けないモジュールがあります。できればこのオプションを試して、LiteStep の開発チームにフィードバックしてくれるよう望みます。（この部分は LiteStep のマニュアルから取りました・・・）["What is threading?" at LiteStep FAQ]
このように、長文を引用する場合には元のサイトが落ちたり閉じても文意が通るように、本サイトでは原文を併せて表記します。
以上のようにスレッド化のオプションはまだ実験的なものであるため、このチュートリアルではまだ推奨できません。ただ、スレッド化を有効にすることでシステム全体に大きな支障が出るといった報告はなかった筈なので、興味のある方はこのオプションを有効にしてみるとよいでしょう。但し、全てのモジュールをスレッド化するのではなく、もし異常な挙動をした場合に LiteStep システムから切り離して他のモジュールへ悪影響を与えたくないモジュールに限定するべきだと思います。ですから、他のモジュールが動作するために必要という意味で重要なモジュール、例えば popup2.dll が動作するために必要な desktop2.dll とか、Wharf アプリケーションが動作するために必要な wharf.dll などはスレッド化せず、個別に機能が止まっても他のモジュールに影響が出ないモジュールの LoadModule コマンドに threaded オプションを追加するとよいでしょう。
なお Windows のマルチスレッド・システムでは、プログラムを動作させる実行単位を包括的なものから順番で「プロセス（process）」, 「スレッド（thread）」, 「ファイバ（fiber）」と呼んでいます。LiteStep は litestep.exe やコア・モジュール、外部モジュールを全て組み合わせて一つのプロセスとして動作するため、プロセスを終了させると LiteStep システム全体が終了し、それよりも小さな単位であるスレッドやファイバごとにプログラムの一部をユーザーが終了させたり開始させることは普通はできません。そこで、threaded オプションを指定した外部モジュールに !Unloadmodule や !Reloadmodule コマンドを使うことで、擬似的にユーザーがスレッド単位の動作をコントロールできるということになると思います。