Forums Feature Suggestions Topic modification

Right now it currently does something like the below for the topic set time.

[16:46] * Set by Nickname on Wed Jan 01 12:12:12

Some topics are extremely old. And I think it would be beneficial to have the year included so it's like the below.

[16:46] * Set by Nickname on Wed Jan 01 12:12:12 2003

Thats rather easily scriptable though. The script to do it would be 1 line long.

raw 333:*:echo $color(topic) -tlrbf $2 Set by $3 on $asctime($4,ddd mmm HH:nn:ss yyyy) | halt

But I think this is one of those things that needs to be modified instead of relying on scripting to fix it.

id personally rather see things like 49 day uptime limit get fixed , ability to add a docked button list under the nicklist, updated colors ability added (more than defualt16). rather than worry about how long ago a topic was actually set.

I really don't understand why people won't accept that the 49 day uptime limit CAN NOT BE FIXED. It is a limitation of WINDOWS NOT MIRC. There must be at least a dozen posts that say that exact thing!

That's not entirely true. Using QueryPerformanceCounter() and QueryPerformanceFrequency() with a LARGE_INTEGER allows you to retrieve rediculously high uptimes. If you have c as the counter, and f as the frequency, you can obtain the uptime in seconds via "c.QuadPart / f.QuadPart" Currently, I store it as an __int64, as I don't expect Windows to achieve an uptime that high. Even a 32 bit integer allows for over 136 years.

Well you're right, but not totally right. Not all systems support that. There is the possibility that the hardware installed on a particular system doesn't support a high-resolution performance counter. In which case, QueryPerformanceFrequency will return a value of 0. Additionally, on multiprocessor systems, it is possible (according to MSDN) that bugs in certain BIOS chips can cause incorrect results depending on which processor is queried. This means that you can't be guaranteed that the value returned is the correct value.

Of corse, Khaled could always make a work-around by storing the $ctime value in accordance to each $uptime stat, then do basic $ctime - %ctime instead of relying on the windows counter.

Yes, it will only be ac accurate as your system clock, but $uptime was never really that accurate to begin with.

But ctime doesn't yield milliseconds. And what if you open mIRC up after the initial 49 days?

I am probably wrong but this could also be a processor limitation. When functions, in any language I ever heard of, return a value, it is returned in the AX, or EAX registers of the processor. This can be a pointer, a number, a character, or something else, but it will be no more than 32 bits. If the function returns an integer, not a pointer to an integer, the largest value it could return is 4,294,967,295. The number of milliseconds in 49 days is 4,233,600,000. Most people will not want to use non-standard functions because, if you run the program on a windows platform that the function is not supported on, then the program either won't start, or it will perform an illegal operation. If M$ decided to return an integer instead of a pointer to an integer this does become a windows problem, but it is one that cannot be changed. Since M$ decided to return this value as an integer that represents milliseconds, the longest it will go is for 49 days. I know that there are larger integers in most common OOP languages, but things like the int64 are pointers to larger values, or they could possibly return the value in EAX:EDX. I know that some assembly commands return the values in EAX:EDX, but C/C++ does not, it just returns a value in the EAX register, so most likely that is a pointer to an integer.