Chrono Mock
言語日本語

1 つのアプリの時計だけを速く進める

時間を動かせなければ、30 日間の試用期間が切れるのに 30 日かかります。よくある助言はシステム時計を進めることですが、それには管理者権限が必要で、マシン上のほかのすべてのプログラムも道連れになります。これは、代わりに 1 つのプロセスだけを動かします。

どのくらい速く

整数の倍率を選びます。アプリの時計は、セッションが始まった時点から、実際の時計の指定した倍の速さで進みます。

倍率実時間の 1 分が変わるもの用途
x601 時間毎時のジョブ、セッションのタイムアウト、トークンの寿命
x14401 日日次の切り替え、30 日間の試用期間を 30 分で
x4320030 日間の試用期間これを読んでいる間に試用期間全体が終わるのを見る
x5256001 年年次の更新、証明書の期限切れ
x1000000約 1.9 年上限
# いまの実時間から始めて、1 分で 1 日の速さで進める
chrono run "C:\apps\test.exe" --mode x1440

# 選んだ日付から始めて、そこから加速する
chrono run "C:\apps\test.exe" --at 2027-12-01T09:00:00 --mode x1440

# 逆に、時計を完全に止めておく
chrono run "C:\apps\test.exe" --mode frozen
別の Windows アプリを操作しているセッションの録画。左のウィンドウは Chrono Mock で、アプリの時計が 2038-01-19 を実速度の 60 倍で進み、隣の実際の時計は数秒しか動きません。右のウィンドウはテスト対象のアプリで、そのセッション記録は 2038-01-19 に開始し、その間に部屋の中ではわずか 30 秒ほどしか経っていないのに、数分間動いていることを示しています。
実際のアプリを操作している、実際のセッションです。右側のウィンドウに注目してください。テスト対象のプログラムは自身の開始を 2038 年 1 月 19 日と記録し、部屋の時計が数秒しか動いていない間に、そのセッションは数分続いています。速度は、何も再起動せずに実行中に変更されます。

つまずきやすい点: 時計は 2 つある

壁時計、つまり DateTime.Now やその同等物が返すものを加速しても、それだけではカウントダウンは速くなりません。これらは、アプリがオペレーティングシステムに尋ねられる 2 つの別の問いであり、多くのソフトウェアは「30 日」を前者ではなく後者で測っています。

そのため、経過時間の軸、つまりティック数、スリープ、待機、タイマーは、別のスイッチになっています。

  • --scale-duration はティック カウント、スリープ、タイマーもセッションの時計に載せます。オブジェクト待機は回数を数えるだけで、長さは実際のままです。これがないと、x1440 でカレンダーが先へ進む一方、5 秒のタイマーは実時間で 5 秒かかります。例外は日時を指定したタイマーで、これはどのセッションでもセッションの時計に従います。
  • --scale-qpc は、さらに高分解能カウンターもスケールします。Python 3.13 以降の monotonic、.NET の Stopwatch、Java の nanoTime が経過時間を読むのはそこで、スケールするとテストで描画が不安定になったため、既定ではオフです。

倍率がカウントダウンに何もしていないように見えるなら、ほぼ間違いなくこれが理由です。

# タイマーアプリ: カレンダーとカウントダウンの両方を加速する
chrono run "C:\apps\Timer.exe" --mode x60 --scale-duration

# 経過時間を高分解能カウンターで測る Python や .NET のアプリ
chrono run "C:\apps\Job.exe" --mode x60 --scale-duration --scale-qpc

再起動せずに速度を変える

倍率はセッション途中で変更でき、時計はジャンプではなくアンカーを打ち直す方式なので、速度が下がっても後ろに戻ることはありません。時計を直接ジャンプさせることもできます。前方へも、ノートパソコンが時刻サーバーと再同期したあとのように後方へも。これは、ガードなしで経過時間を測るあらゆるものを壊すケースです。

# x60 で実行し、2 秒後に x1440 へ切り替える
chrono run "C:\apps\test.exe" --mode x60 --set-after 2:1440

# 実行し、5 秒後に時計を選んだ時点へジャンプさせる
chrono run "C:\apps\test.exe" --jump-after 5:2028-01-01T00:00:00

できないこと

  • システム時計には触れません。これは制限ではなく、そのための設計です。ただし、サーバー、データベース、ほかのマシンから時刻を読むものは影響を受けないことになり、そうなったときは監査がそれを教えてくれます。
  • ジャンプが変えるのはアプリケーションに見えるものであって、目覚めるタイミングではありません。すでにカーネルに渡されたスリープとタイマーは、設定時に与えられた長さを保ちます。ほとんどのアプリケーションは時計をポーリングするので、実際にはジャンプは効きますが、すべてではありません。
  • 時間を遅くはできません。倍率は 1 以上の整数と、ゼロでの停止した時計だけです。

そのどれかがアプリに届いたかどうかは、仮定するものではありません。セッションが教えてくれます →

試してみる