flat assembler
Message board for the users of flat assembler.

Index > Windows > Time Freezer

Thread Post new topic Reply to topic

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania
Borsuc 18 Jun 2009, 21:57
Yesterday I was bothered by the fact that timestamps may change when you simply copy/add directories/files to an archive or to disk. I am perfectionist (nevermind that I don't care about people "discovering" how fast my computer can copy/archive files).

So I made a stupid app that will reset the system time to a given date every [Delay] milliseconds, where [Delay] is optional (you can enter it), by default is 200.

I have no idea if there is such app out there but I doubt it's only 1KB large in Windows Cool

(anyway just an excuse for me to make a really small, and somewhat useful, app with the Manual PE method Razz)

it was written somewhat in a rush so don't expect it to be very clean or otherwise perfect code (if you care about the source).

It also processes the command line arguments manually, could be useful as a template for apps like this Smile

cheerrs, hope you find some use to it.

here's the readme:
Time Freezer is a very small and stupid application that will reset your system time to a given data every given milliseconds. This is somewhat akin to freezing it although the milliseconds delay will be there.


freezer <Year> <Month> <DayOfWeek> <Day> <Hour> <Minute> <Second> [Delay]

The valid values for these parameters are:

Year: 1601 - 30827
Month: 1 (January) - 12 (December)
DayOfWeek: 0 (Sunday) - 6 (Saturday)
Day: 1 - 31 (day of the month)
Hour: 0 - 23
Minute: 0 - 59
Second: 0 - 59

[Delay] is an optional parameter. It specifies the delay between successive resets of the clock, in milliseconds. The default value, if it is not supplied, is 200 milliseconds. This was chosen so it would not overload slow systems. You can try with much smaller values (especially with multiple cores), but BE CAREFUL not to make it too small as it may overload your system.

Remember that Time Freezer adjusts its own priority and makes it REALTIME which makes it of higher priority than system processes. So when it needs to reset you can be sure nothing (except another realtime program, if you have any running) will stand in its way. That is why resetting too often may overload your system. The reason I chose to do it in REALTIME is because I wanted it to also "freeze" the clock for system processes or Windows stuff, like when copying files/directories. Now you can use it to, for instance, make copied files have almost the same timestamp -- previously people could have figured out how fast your machine could copy files by looking at differences in timestamps. I don't really care much about that but I am an organized person and having the (almost, a few milliseconds off) same timestamp looks more polished or professional or whatever you want to call it.

NOTE: For some reason you will not be able to open up the Date and Time Properties (it will use 100% CPU) if the delay is too small, but otherwise it's barely using 4% of CPU on my old laptop (Mobile AMD Sempron CPU).

The valid values for Delay are 0 through the maximum allowed in 32 bits (4294967295). If it's higher it aborts instead of overflowing -- because a wrong (small) value can have serious effects on your system.

Please note that quotes ARE NOT allowed in the parameters EXCEPT the program name. Also note that no other characters than digits are allowed. It will abort if it detects any. Also if you will add an extra parameter/argument it will also abort.

Filename: Time Freezer.zip
Filesize: 8.88 KB
Downloaded: 193 Time(s)

Previously known as The_Grey_Beast
Post 18 Jun 2009, 21:57
View user's profile Send private message Reply with quote

Joined: 15 Sep 2006
Posts: 181
Goplat 20 Jun 2009, 19:42
Changing the system time can mess some programs up, and you have to have administrator privileges to do it... To manipulate file timestamps, I think it's better to use the SetFileTime API.
Post 20 Jun 2009, 19:42
View user's profile Send private message Reply with quote

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania
Borsuc 21 Jun 2009, 00:11
Yes I know it can mess stuff up, but for copying seems to work.
Setting filetime can also be a good way, but there are two things of note. First of it isn't "realtime" (or it would be very slow).

Either way, this is not changing the "tick" count or the actual clock -- just the date, which is based on that clock. I haven't encountered any problems so far with it. (unless a program explicitly uses the date to do time offsets, but that is wrong design, it should use GetTickCount or something like that instead).

Previously known as The_Grey_Beast
Post 21 Jun 2009, 00:11
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.