I would be interested in a Windows version of
BRL-CAD. From what I have read, such a thing
is close to existing. I have even found an
installation package with a beta version, but
it required a key to install. I noticed that
CVS for BRL-CAD has non-developer and
developer versions. Which of these would be
better to use as a basis for Windows version?
And if the developer version is the one, how do
I get a developer name/password?
To save someone from warning me, I am aware of
the risks, etc. associated with using beta
software. I also have enough experience with
low level Win32 programming that I should be
able to debug after a crash to help test the
software. Thanks for any information.
I today found the installable version and source
with MS VC7 files was just released shortly after
I posted. Installation was clean, and it
at least starts OK. I did not look at it much
further yet, but I did notice that the ray
tracing does not work in the main window. I
also found some doc, again I did not look through
all of it yet so I do not know how thourough it
is, but I did see a note about the ray tracing
not being fully supported in Windows yet. Ray
tracing in a separate window worked OK, but it
used a lot of CPU after the drawing was done when
rt was not doing anything. I am trying to
compile now to see how that goes.
The compile did not go well. Based on the
project names, "all" seemed a likely candidate
to build. But "all" did not have much in it.
The next most likely one was brlcad. Using the
options as supplied, I got over 200 warnings
and errors, some of these fatal. Looking at the
fatal errors, libraries are not being found in
the link phase.
Taking another approach and trying to start
simple and work up from there, I started with
libz since I have worked with zlib before.
It compiled with only a few warnings that are
easy enough to fix, but again at the link phase
it could not find file tcl84_d.lib. Since
there was a project called libtcl, it appeared
that this was just a dependency issue. Project
libtcl compiled and linked with only a link
warning related to the options specified. One
of its output files was tcl84_d.lib and it had
a post-build step to copy files. So I expected
the libz build to now work just fine. But it
gave the same error about the library.
It would seem that something is wrong with these
project files. Is there a better set to use?
Also, is a VC6 version of the project files
available? The .NET studios have a lot of space
eaten up by various menus and buttons sprinkled
around so I just prefer using VC6 if possible.
VC7 can read VC6 projects, but a VC7 project is
useless for VC6.
Curious in general and interested in why the
ray tracing did not work in the main window,
I looked through a few of the source files, and
noticed some issues with the Win32-specific
code. These seem more appropriate for the
developers forum, so I will post them there.
Strangely, all of the post-build steps
intended to copy the output files to a common
location were incorrect. After fixing these
in each of the projects, there were no errors.
There were still just over 200 warnings, but
most did not seem dangerous. Nearly all of
them were either due to incomplete function
declarations, unused variables, or implicit
type conversion. I fixed a few, although I
have more interest at the moment in seeing the
program run. There were a few warnings that did
concern me since they involved uninitialized
variables, but I have not looked into this
much yet. At this point I have started mged,
which means at least that all static libraries
and those loaded with the program were resolved.
If there is any interest in getting a copy
of the working project files, let me know.
They require version 7.1 of Visual Studio.
Version 7.0 (the original .NET) does not
I may have been a bit premature writing that
the project works. The compiles and links are
all OK, but running in a debugger fails during
initialization. It appears that Tcl/Tk is not
finding something. Unfortunately, I know little
about Tcl/Tk, so this probably will require me
to step through the initialization very slowly
to see where the problem is.
Looking further ahead, I probably would be
happier with a native Windows gui for both
aesthetics and performance, so it may not
be such a bad thing to see what Tcl/Tk is doing.
I have eliminated about half of the warnings
generated during compilation. My latest total
(at default warning level 3) is a bit under 100.
A few of the warnings that I fixed were actually
errors. Is there some process to submit the
changes to see if anyone wants them? At first,
I was carefully initializing the changes in
comments, but after a while this started to
become too much work due to the sheer number of
I am similarly concerned at the quantity of unchecked changes that you are accruing.. :-) When you get a chance, please post up a patch of some of your changes so they can be reviewed or even better, stop by the IRC channel so we can discuss how to possibly make this a whole lot easier. Direct access is always possible for someone like yourself that sustains a high level of interest, but seeing an initial patch is a necessary first step.
The channel is #brlcad on irc.freenode.net, i.e. the Freenode network. If you've never used IRC, it's basically live group discussions where you join channels that focus on particular topics. The Freenode network that BRL-CAD lives has a large software development following with just about every major open source software represented. There are more details on http://irchelp.org for getting a binary client and connecting. Some popular irc clients are xchat and irssi.
I think we both agree that the number of
changes I have made is getting large and
merging with existing CVS source will become
increasingly difficult as they grow. So I will
complete the changes I am in the process of
making, test them, and then look into how to
submit the changes.
A summary of the changes I am working on or
have completed follows.
- Elimination of compiler warnings from the
Windows build. There are 4 remaining that I
have intentionally left to look at more after I
understand the overall package better.
- Consistent const char **argv for TCL functions
and function pointers. This change followed
from the compiler warnings. A few may still
be hiding somewhere, but this is essentially
done. This was mostly accomplished by adding a
huge number of const keywords, in the
prototypes, definitions, and variables that
referencing the stings being passed.
However, there were a few instances
where the strings were really changed. In all
but one case, I did this the "right" way,
reworking the functions to leave the strings
alone instead of adding the overhead of an
allocate + copy. In that last case, there was
what seemed to be an unlikely situation that
was much easier to handle by making a copy.
- New timing facilities for Windows. The
replacement uses QueryPerformanceCounter()
and QueryPerformanceFrequency() for elapsed
time and GetProcessTimes() for kernel and
user times. The change should be transparent
to the caller, except for getting the right
- libbu modifications
- A winutil file for utilities to work with
Windows. This file currently has only a
single function to change the '\' characters
in a Windows path specification to the '/'
characters used in Unix. This function
was created because I noticed this conversion
being done frequently with the same code
copied and pasted. I made it general in that
it can accept a size for the converted string
so it need not be null terminated and returns
the size of the string since that information
can essentially be found for free and may
be of use to the caller. The ability to
work with strings lacking a null termination
can be useful for both performance reasons
and to allow a string to remain a
const char *. I generally perfer to keep
track of string sizes myself to avoid things
- enhanced bu_bomb() to allow variable
arguments in message.
- bu_vls upgrades. I noticed that in a
significant number of instances, the vls
facility is used to build a small string
that is then discarded. With the current
version, this will always require an
allocation and free. To avoid this, a small
buffer was added to the end of the existing
structure, and the init call points the
string pointer to this buffer. The remaining
bu_vls functions were modified to make
the change transparent to callers of bu_vls.
While making the changes, I noticed that
the bu_vls_trimspace function was implemented
inefficiently with multiple function calls to
process a single character. So this funciton
was rewritten as well.
- Improved efficiency in help messages. The
few instances I had mentioned where the
bu_vls facility was used to create a copy
of a string that does not change were
only the tip of an iceberg. I am under water
now getting to the bottom. I have also
reformatted to some extent when making these
changes to conform with the coding standards
given because I had the alternatives of putting
in fixes that did not conform with the
standards, adding code that did conform that
was surronded by non-conforming code so that
it looked wrong, or fixing the wole thing to
conform. The conventions followed were as
in HACKING with two additions that I prefer.
Braces are always used to group loops and
ifs, with the exception of "else if". This
eases debugging and reduces the chances of
errors when another line is added to existing
code. Finally, the code is limited to a line
length of 80 characters, treating the tabs as
if they had their expanded size. This is
easier to read than lines wrapping around
and makes an occasional printing look much
- Occasional efficiency improvements. One I
recall offhand is replacing something like
if (strlen(s) == 0) with if (*s == '\0') to
avoid the function call, which is doing noting
useful once it finds that the length is at
- Project file fixes. There were problems
with the dependencies that caused a linker
warining that was strange and difficult to
identify. Also the post-build steps were
improved to echo information to the console
and to conditionally rebuild the destination
directories if they do not exist. One
additional thing I want to do in this iteration
is to separate the intermediate files (.obj,
etc. residing in directories Debug and
Release) into their own directory. This will
keep the directories holding the project
files clean, which will make it easier to move
the project from one computer to another.
- Others? I must be forgetting something here...
No, I have never used IRC. I will have to
look into that. I guess I still think in
batch mode. BTW, I still am not sure what
the differences between the Open Discussion
and Help forums are since all the posts seem to
be asking for some type of help, but replies to
this message probably belong in the Developers
forum, so I will look there.
I thought of a few more changes, but I will
transfer this to the Developers forum and
continue it there.
Regarding the VC6 project files I was asking
about, I made my own. So far it is just for
a debug version, but adding a release build
should be substantially less work. Essentially
this was a manual translation with a text
editor and the Version 7.10 files, so it took a
while to do. I did not include the "all" project
since Visual Studio has features like "Rebuild
All" to do a full build. Prior to .NET, Visual
Studio offered an "Export to Makefile" option,
so the VC6 project files could be useful to
for working without the IDE.
I noticed two frequently defined but never
used macros, __win32 and _WINDOWS. I did not
include these in the project files that I made.
Were there plans to do things with these that
cannot be handled with _WIN32/WIN32 macros or
were these old ideas that did not get fully
Old code that hasn't gotten cleaned up yet. The code should exclusively be using _WIN32 and avoiding even using that one at all costs whenever possible.
Granted there are plenty of situations where it may be ideal or desired to utilize something in the win32-specific api (e.g. QueryPerformanceCounter()), but in general the package is moving towards feature-based checks, not system checks.
So even in that case, instead of using _WIN32 the design would be to add a HAVE_QUERYPERFORMANCECOUNTER symbol in the config header and a corresponding check in the configure.ac file (or not, it's not really important if it's win32 only). That way, the symbol can be autodetected for other (non _WIN32) systems where said feature might actually be available.
In all, this is a major on-going effort as the package was based around system checks initially (especially bsd vs. sysv) but that turns into a maintenance nightmare as the years progress. Testing for and/or declaring individual features isolates that feature and makes it easier to automatically accommodate new platforms that emerge.
The raytracer basically sits in a unthrottled idle loop waiting on input (so it can still respond to events, if I recall correctly) causing it to be full-cpu. This only happens on Windows at the moment due to how the event management was set up in the display manager. It should of course be using something more akin to a select() on a socket or at least sleeping to keep things sane.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.