For next\nAdvent of Code,\nI'm loosely planning to use some old Windows, probably\nNT4\n(I wanted to go with 2000 first, but that's a bit slow on my old box,\nand 95/98 are a bit unstable; NT4 might hit the sweet spot?). What was\nmissing in my toolchest for that OS was a small program to print the\nsystem's uptime -- just like uptime on Unix. The only way I knew was to\ndo net statistics server | more and then do the math in your head, but\nthat's a bit cumbersome.
So, I made\na little tool,\nwhich is nothing more than just a thin wrapper around\nGetTickCount().\nWhile at it, I also made an OS/2 version, again just a thin wrapper,\nthis time around\nDosQuerySysInfo(QSV_MS_COUNT, ...).
But can you also do this on DOS?
\nThe little experience I had with this OS family told me that this wasn't\ngoing to be straightforward, and browsing through\nHelpPC\ndidn't make me more optimistic. DOS simply doesn't appear to explicitly\nkeep track of this information.
\nTable of contents:
\nNUL (allegedly)\nThe first thing I found was\nUPTIME.PAS by Mark Aitchison.\nThis program appears to be from 1997, judging by the .timestamps file\nin the repo.
So, what does it do? At the core, it's just this:
\nassign(fyle, 'NUL');\nGetFTime(fyle, t);Since I know very, very little about Pascal (only did some Delphi stuff\n30 years ago), I assumed that these two lines meant:
\nNUL ,It would look something like this in C (OpenWatcom v2,\n_dos_getftime()):
int main() {\n int handle;\n unsigned int r, date, time;\n if ((r = _dos_open("NUL", O_RDONLY, &handle)) != 0) {\n fprintf(stderr, "Could not open NUL: %u\\n", r);\n return 1;\n }\n _dos_getftime(handle, &date, &time);\n _dos_close(handle);\n printf("%04d-%02d-%02d %02d:%02d:%02d\\n", YEAR(date), MONTH(date),\n DAY(date), HOUR(time), MINUTE(time), SECOND(time));\n return 0;\n}But this would only ever print the current date and time for me.\nAitchison's program worked, but mine didn't. What's going on?
\nReading up on the assign() function:
Assign only operates on the program's internal management data and\nhas otherwise no immediate observable effect.\n[...]\nIt merely operates on internal management data.
So ... does this actually open the file? Probably not ... ?
\nRunning Aitchison's program in a debugger (with no debugging symbols and in a very glitchy version of Turbo Debugger, which would eat or duplicate key presses all the time -- argh) eventually got me to this point:
\nIt does call INT 21,57, but the BX register is set to zero.
\nThe program still works, though, and prints the correct uptime. My\nconclusion here is that it has nothing to do with NUL at all, but\ninstead reads the "modification time" of stdin.
I changed my C program to just do this:
\n_dos_getftime(0, &raw_date, &raw_time);This results in the same INT 21,57 call and it indeed prints the uptime now:
\nWhat side effects does this approach have?
\nTo my surprise, things like opening a new command prompt from within\nDOSSHELL still shows the correct uptime. But what does break is using\nctty:
Here's what that screenshot shows:
\nA:\\uptime prints an uptime of 3 minutes and 37 seconds.Switching to the serial console with ctty com1 . (This is a VM and
I connect to that serial console withtelnet localhost 3364 on my\n host.)
Running A:\\uptime in the serial console again now shows an uptime
of just 5 seconds.
ctty con and runningA:\\uptime one last time shows just 2 seconds now.So there are operations that reinitialize the timestamp of stdin and\nbreak this program.
\nIt's also not working on DOSBox, where it just prints garbage:
\nSimilar useless things happen when you run the DOS version on Windows or OS/2, but luckily we have dedicated versions for those systems:
\nAnother program I found was\nUPTIMEC by Javier Gutierrez Chamorro,\nalso in the FreeDOS repo. It's from 2017.
(This one even references the Pascal version and it also claims that\nAitchison's code uses NUL. Is my interpretation wrong or did nobody\nnotice this before?)
Anyway, Chamorro's version works completely different and bypasses DOS (at least regarding time functions): It uses the Real-Time Clock / CMOS directly. As I understand it, it goes like this:
\nSo on the very first start, the "uptime" is probably zero -- assuming the\n"alarm time" was unset so far. Subsequent runs will then show the\ncorrect result, and things like ctty won't break it.
See also:
\nThis program is arguably better, because it can't break so easily, but it does require a little bit of setup. Here it is running on my Dell Inspiron 6400, right after boot and after the system was powered down:
\nIt shows an uptime of 2 minutes, which isn't correct. The program\ncouldn't know better -- it just used whatever "alarm time" was stored in\nCMOS memory,\nand those values are kept between reboots and poweroffs. So the right\nthing to do with this tool is to run it in autoexec.bat as ```\nuptime\n/R
: This resets the value stored in CMOS to the current time, and then\nit will show the correct uptime on the next interactive run on the\ncommand line.\n\nSearching the web also reveals this:\n\n[https://stackoverflow.com/a/44718557](https://stackoverflow.com/a/44718557)\n\nThe idea is to call\n[INT 1A,0](https://helppc.netcore2k.net/interrupt/int-1a-0).\n\nThat StackOverflow post also links to\n[this page](https://www.oocities.org/geoff_wass/dBASE/GaryWhite/dBASE/FAQ/qmidn.htm)\nand quotes a little section from it:\n\nThe second problem comes in because of how BIOS int 0x1A operates. Whenever you call this function to retrieve the system time (the current timer tick value) it also returns the current MIDNIGHT flag and RESETS THE FLAG. But since the BIOS function doesn't update the DOS date, the next time you ask for the date, it will not be updated correctly. DOS is aware of the behavior, so when you call any DOS function, the MIDNIGHT flag is maintained correctly. If you call BIOS int 0x1A yourself, you MUST check the MIDNIGHT flag value and turn it back on if it was set.\n\n\nI only gave this a quick shot. According to the description on HelpPC, this returns the number of seconds since midnight, and that matches my tests. The person on StackOverflow said:\n\nIf nobody has *set* this time using `INT 1A,1`, you will get the\nseconds since boot.\n\n\nHm. I guess someone or something did set it then. :-)\n\nGoing back to Chamorro's code: If we need to call `uptime /R` in\n`autoexec.bat` ... why even bother with any of this CMOS hackery? Why not\nhave our little uptime program write *a file* during boot and store the\ncurrent time there? Then, subsequent runs will compare the current time\nand date to that file?\n\nOf course, this clutters the filesystem. And it's arguably the most expensive solution. But also probably the most solid one? And the most portable one?\n\nIn\n[my tool](https://movq.de/git/retrouptime/),\nI went with the `_dos_getftime(0, ...)` approach for three reasons:\n\n- It doesn't require any setup.\n- It's a purely *read-only* operation.\n- It appears to be good enough for my purposes.\n\nI really only need this every now and then. And I don't really "need" it, anyway, I'm just curious.\n\nIf you know of more, better, different ways, let me know.\n