Chrono Mock
BahasaBahasa Indonesia

Buat jam satu aplikasi berjalan lebih cepat

Masa percobaan 30 hari butuh 30 hari untuk habis, kecuali Anda dapat memindahkan waktu. Saran yang biasa adalah memajukan jam sistem, yang memerlukan hak administrator dan menyeret semua program lain di mesin ikut serta. Ini menggeser satu proses saja.

Secepat apa

Pilih pengali bilangan bulat. Jam aplikasi maju sekian kali lebih cepat dari jam nyata, dari momen mana pun sesi dimulai.

PengaliSatu menit nyata menjadiBerguna untuk
x60satu jamjob per jam, batas waktu sesi, umur token
x1440satu haripergantian harian, masa percobaan 30 hari dalam setengah jam
x43200masa percobaan 30 harimenyaksikan seluruh masa percobaan berakhir selagi Anda membaca ini
x525600satu tahunperpanjangan tahunan, masa berlaku sertifikat
x1000000sekitar 1,9 tahunbatas atas
# Mulai dari waktu nyata sekarang, dan jalankan sehari per menit
chrono run "C:\apps\test.exe" --mode x1440

# Mulai pada tanggal pilihan dan percepat dari sana
chrono run "C:\apps\test.exe" --at 2027-12-01T09:00:00 --mode x1440

# Atau tahan jam sepenuhnya
chrono run "C:\apps\test.exe" --mode frozen
Rekaman sesi yang mengendalikan aplikasi Windows lain. Jendela kiri adalah Chrono Mock dengan jam aplikasi pada 2038-01-19 yang naik dengan kecepatan enam puluh kali kecepatan nyata, sementara jam nyata di sampingnya hanya bergerak beberapa detik. Jendela kanan adalah aplikasi yang diuji, yang catatan sesinya sendiri menunjukkan ia mulai pada 2038-01-19 dan telah berjalan selama beberapa menit, dibandingkan baru setengah menit di ruangan.
Sesi nyata yang mengendalikan aplikasi nyata. Perhatikan jendela sebelah kanan: program yang diuji mencatat awal jalannya sendiri sebagai 19 Januari 2038, dan sesinya telah berlangsung selama beberapa menit sementara jam di ruangan bergerak beberapa detik. Kecepatannya diubah selagi berjalan, tanpa memulai ulang apa pun.

Bagian yang menjebak orang: ada dua jam

Mempercepat jam dinding - yang dikembalikan DateTime.Now dan padanannya - tidak dengan sendirinya mempercepat hitung mundur. Itu dua pertanyaan berbeda yang dapat diajukan aplikasi kepada sistem operasi, dan banyak perangkat lunak mengukur “tiga puluh hari” dengan yang kedua, bukan yang pertama.

Maka sumbu durasi - hitungan tick, sleep, wait, dan timer - adalah switch yang terpisah:

  • --scale-duration juga memindahkan penghitung tick, jeda tidur, dan pewaktu ke jam sesi, sementara penantian objek dihitung dan tetap pada durasi sebenarnya. Tanpanya, x1440 memacu kalender ke depan sementara pewaktu lima detik tetap berlangsung lima detik sungguhan - hanya pewaktu yang diatur ke tanggal dan jam tertentu yang mengikuti jam sesi di setiap sesi.
  • --scale-qpc juga menskalakan penghitung beresolusi tinggi. Di situlah monotonic Python 3.13+, Stopwatch .NET, dan nanoTime Java membaca waktu berlalu, dan ia nonaktif secara bawaan karena menskalakannya mengacaukan stabilitas rendering dalam pengujian.

Jika pengali tampak tidak berbuat apa-apa pada hitung mundur, hampir selalu inilah sebabnya.

# Aplikasi timer: percepat kalender DAN hitung mundurnya
chrono run "C:\apps\Timer.exe" --mode x60 --scale-duration

# Aplikasi Python atau .NET yang mengukur waktu berlalu pada penghitung beresolusi tinggi
chrono run "C:\apps\Job.exe" --mode x60 --scale-duration --scale-qpc

Mengubah kecepatan tanpa memulai ulang

Pengali dapat berubah di tengah sesi, dan jam diberi jangkar baru, bukan dilompatkan, sehingga ia tidak pernah mundur ketika kecepatan turun. Anda juga dapat langsung melompatkan jam - maju, atau mundur seperti yang dilakukan laptop setelah menyinkronkan ulang dengan server waktu, kasus yang merusak apa pun yang mengukur waktu berlalu tanpa pengaman.

# Jalankan pada x60, lalu beralih ke x1440 dua detik kemudian
chrono run "C:\apps\test.exe" --mode x60 --set-after 2:1440

# Jalankan, lalu lompatkan jam ke momen pilihan lima detik kemudian
chrono run "C:\apps\test.exe" --jump-after 5:2028-01-01T00:00:00

Apa yang tidak dilakukannya

  • Tidak menyentuh jam sistem. Itu intinya, bukan keterbatasan - tetapi artinya apa pun yang membaca waktu dari server, database, atau mesin lain tidak terpengaruh, dan audit akan memberi tahu ketika itu terjadi.
  • Lompatan mengubah apa yang dilihat aplikasi, bukan kapan ia bangun. Jeda tidur dan pewaktu yang sudah diserahkan ke kernel mempertahankan durasi yang diterimanya saat diatur. Sebagian besar aplikasi menanyakan jam berulang kali, jadi lompatan berhasil dalam praktik - tetapi tidak di semua aplikasi.
  • Tidak memperlambat waktu. Pengali adalah bilangan bulat satu ke atas, ditambah jam beku pada nol.

Apakah semua itu sampai ke aplikasi Anda bukan sesuatu yang perlu diasumsikan. Sesi menyatakannya →

Cobalah