부족했던 부분을 채운 RunAsDate 대안
RunAsDate는 오랫동안 “Windows에서 이 프로그램을 다른 날짜로 실행하기”에 대한 답이었고, 훌륭한 답입니다. 이 페이지는 둘이 어디서 다른지, 그리고 RunAsDate가 여전히 더 나은 선택인 경우가 언제인지 다룹니다.
나란히 비교
| RunAsDate | Chrono Mock | |
|---|---|---|
| 앱 하나를 가짜 날짜로 실행 | 예 | 예 |
| 시스템 시계를 건드리지 않음 | 예 | 예 |
| 가로채는 시간 함수 | 5 | 44개 (이동 30개, 집계만 14개) |
| 실제보다 빠른 시계 | 제공하지 않음 | 임의의 정수 배율 |
| 시계 멈추기 | 예, 기본 동작 | 예 |
| 앱 실행 중 점프 | 정해진 초가 지난 뒤 실제 날짜로 돌아가는 것만 가능 | 앞뒤로, 원하는 어느 시점으로든 |
| 해당 프로세스만의 시간대 | 문서화되어 있지 않음 | 예, 고정 오프셋 |
| 자식 프로세스가 세션을 상속 | 문서화되어 있지 않음 | 예 |
| 이미 실행 중인 애플리케이션에 연결 | 예, 버전 1.40부터 | 아니요 - 애플리케이션을 직접 시작함 |
| 날짜가 다른 여러 애플리케이션을 동시에 | 예 | 아니요 - 한 번에 세션 하나 |
| 적용 여부를 알려 줌 | 아니요 | 판정, 채널별, 호출 횟수 포함 |
| Electron과 Chromium 앱 | 문서화되어 있지 않음 | 별도의 메커니즘 |
| CI용 명령줄 | 예 | 예, 종료 코드와 JSON 포함 |
| 소스 코드 | 프리웨어, 비공개 | GPL-3.0 |
| 크기 | 다운로드 47KB, 64비트용 57KB | 명령줄 약 2.4MB, 창 포함 약 70MB |
| 오래된 Windows 버전 | Windows 2000까지 | Windows 10과 11 |
“문서화되어 있지 않음”은 그 기능이 RunAsDate 페이지에 언급되어 있지 않다는 뜻입니다. 도구에 그 기능이 없다는 주장이 아닙니다. RunAsDate의 시계는 Move the time forward according to the real time 옵션을 켜지 않는 한 멈춰 있습니다.
가장 중요한 차이
채널 수가 아닙니다. RunAsDate가 자체 문서에서 “현재 날짜/시간을 다른 소스에서 가져오는 애플리케이션에는 영향을 주지 않는다”고 솔직하게 밝히고, 그 뒤로는 자신의 앱이 거기에 해당하는지 직접 알아내도록 맡긴다는 점입니다.
Chrono Mock은 같은 문장을 측정해야 할 대상으로 다룹니다. 모든 세션은 판정, 앱이 실제로 읽은 채널과 각각의 횟수, 놓친 채널, 그리고 앱이 시계를 묻기도 전에 네트워크 연결을 여는 것이 관찰되었을 때의 경고로 끝납니다.
시간이 옮겨진 것처럼 보이지만 실제로는 아닌 앱은 아예 실행되지 않은 앱보다 나쁩니다. 아무 의미 없는 통과 테스트를 만들어 내기 때문입니다. 감사의 동작 방식 →
함수 다섯 개 대 44개 채널
RunAsDate는 GetSystemTime, GetLocalTime, GetSystemTimeAsFileTime, NtQuerySystemTime, GetSystemTimePreciseAsFileTime을 가로챕니다. 벽시계가 읽히는 곳이 거기이므로, 아주 많은 애플리케이션에는 이것으로 정말 충분합니다.
나머지 영역은 날짜에 의존하는 코드가 숨어 있기 쉬운 곳입니다.
- 시간대 - 시간대를 알려 주는 함수 2개와 시간대 사이를 변환하는 함수 6개. 보고서가 엉뚱한 날짜에 찍히는 원인입니다
- 경과 시간 축 - 틱 수와 편향 없는 인터럽트 시간으로, 체험 기간 카운트다운이 보통 측정하는 것입니다.
- 슬립 - 지연이 실제 시계가 아니라 세션 시계 기준의 지연이 되도록. 그리고 객체 대기 - 횟수는 세지만 길이는 실제 그대로입니다
- 타이머 - 대기 가능 타이머, 창 타이머, 스레드 풀 타이머, 멀티미디어 타이머입니다.
- 프로세스 생성 - 설치 프로그램의 자식 프로세스가 현재 날짜가 아니라 같은 세션에서 실행되도록 합니다.
- 네트워크 연결 - 시간이 서버에서 올 수 있다는 신호로 집계합니다
44개 중 30개는 세션 시계로 바뀝니다. 나머지 14개는 집계만 하고 실제 값 그대로 두므로, 보고서는 이동했다고 주장하지 않고 이들을 나열합니다. 벽시계와 시간대는 모든 세션에서 이동합니다. 경과 시간 축과 대기는 --scale-duration으로, 고해상도 카운터는 --scale-qpc로 요청할 때 감시합니다.
RunAsDate가 더 나은 선택인 경우
진심으로 그렇고, 드물지도 않습니다.
- 보통 속도로 날짜 하나만, 지금 당장 필요할 때. RunAsDate는 60KB 미만의 다운로드이고, 익힐 창이 없으며, 오랜 세월 바로 이 일을 해 왔습니다.
- 오래된 Windows를 쓸 때. RunAsDate는 Windows 2000까지 거슬러 올라갑니다. 이 도구는 Windows 10과 11을 대상으로 하며 그보다 오래된 환경에서는 테스트되지 않았습니다.
- 크기가 중요할 때. 47KB 다운로드에 비해 명령줄은 약 2.4MB, 창 포함은 약 70MB이니 비교가 되지 않습니다.
- 판정이 필요 없을 때. 커버리지를 측정한다는 것은 결과를 읽어야 한다는 뜻입니다. 일회성 테스트라면 요청하지 않은 부담입니다.
- 애플리케이션이 이미 실행 중일 때. RunAsDate는 버전 1.40부터 실행 중인 프로세스에 연결할 수 있습니다. Chrono Mock은 애플리케이션을 직접 시작하므로 다시 시작할 수 없는 애플리케이션에는 닿지 않습니다.
- 날짜가 다른 여러 애플리케이션을 동시에 실행하고 싶을 때. RunAsDate는 각각에 고유한 날짜를 줍니다. Chrono Mock은 한 번에 세션 하나를 실행합니다.
둘은 공존할 수도 있습니다. 가벼운 경우를 위해 RunAsDate를 계속 두는 것을 여기 있는 어떤 것도 막지 않습니다.
둘 다 목적으로 삼지 않는 것
두 도구 모두 체험 기간 연장에 관한 검색에 등장합니다. 이 도구는 그런 용도로 만들어지지 않았으며, 그것을 보여 주는 예제, 시나리오, 페이지는 여기에 앞으로도 없을 것입니다. Chrono Mock은 자신이 책임지는 소프트웨어, 즉 자신의 라이선스 만료, 자신의 갱신 로직, 자신의 월말 보고서를 테스트하기 위한 것입니다.
또한 가장 동작할 가능성이 낮은 경우이기도 합니다. 라이선스 보호는 가로채기 어렵게 고른 경로, 즉 공유 사용자 모드 데이터 페이지, 직접 시스템 호출, 서버 등을 통해 일상적으로 시간을 읽으며, 시계가 거꾸로 가는 것은 그런 코드가 탐지하도록 작성된 조건입니다. 감사는 동작하지 않았다고 알려 줄 것이고, 이는 유용한 답이 아니라 솔직한 답입니다.