I noticed that to find elapsed time in the
Windows version, src\librt\timer-nt.c uses time(),
which has a resolution of 1 second. Is there a
reason why more accurate calls from the Win32 API
(e.g., QueryPerformanceCounter()) were not used?
The comments in this file mention that the
it is used for finding times on the NT family
of OSs. Should I read from this that
BRL-CAD will not run on the 9x family or
am I reading too much into that one comment?
If it does not, what specifically does not
I wrote a replacement based on Win32 API
GetProcessTimes(). This allows much higher
resolution on the wall clock time. CPU
time has problems in the previous version due
to the implementation of clock(). Win9x does
not implement GetProcessTimes() or another way
to find CPU usage by a thread or process. So
I was curious how clock() was implemented.
I found that even in NT, it just returns elapsed
time, NOT CPU time. My replacement returns
kernel and user times for NT and a negative
value for 9x to indicate that the information
Is this fix readily available anywhere? :) I don't see a link nor is it in the patches tracker..
See my earlier post. I will certainly include
it along with my other changes.
Regarding the Win 9x compatibility, in case
you are not aware of it, the Win32 API is
implemented slightly differently in each
family. Windows 95 was built to run with
4 M of RAM, so some things just did not fit
in. In other cases, it appears that it was
an unfortunate case of two development teams
not communicating. I have a fondness for
Windows 95, so I try to write programs that are
compatible with it unless there is a very good
reason to use a newer feature. Usually it is
not that difficult but some uncommon things are
implemented very differently.
Only because that code was written quite a while ago before there even existed a comprehensively tested Windows port and it hadn't been looked at since. QueryPerformanceCounter() is indeed the way to go.
That comment wasn't meant to imply it only runs on the NT family. If anything, the comment reflects that the code was simply written and tested on NT only. It just happened to still work as the port to Windows was worked on and nobody noticed.
There is also nothing intentionally (and hopefully nothing unintentionally) being used that outright prevents the package from functioning on any of the Win32 platforms. Since we don't have a dedicated Windows developer at the moment working on the project consistently, there is only so much time and effort that can be put into "officially" supporting more than XP right now. But again, that is mainly just due to resources and time. As more (Windows) open source devs get involved in the project, this can easily change. I'm certainly hoping more devs like yourself become involved, and are perhaps even interested enough in becoming a part of the dev team. ;-)