Version 0.500 was the first port of the system from its previous OS/2 incarnation. So there are going to be some gotchas that occured in the port. I also took this opportunity to make signficant fundamental architectural improvements, what the heck since I had it up on the blocks, and that might have introduced some wierdness into previously stable code.
Overall though it seems to have survived quite nicely, validating my ideas about portability. The biggest headaches came with the introduction of a lot of new C++ capabilities into the system, such as namespaces, bool, mutable, and in differences between the previous IBM Visual Age C++ system and the new MS Visual C++ system.
The class and member documentation (the stuff you are reading), is not completed. Its been updated significantly for this release, and its getting closer, but there needs to be more explantory text to go with the details, and the documentation of the exceptions thrown by each method is still incomplete (though much less so than before.)
There are never enough demo programs, I know. I've added more for this release and will do more for the next one. The ones that are there now show a lot of good usage of the system, so make sure and debug through some of them and see what's going on. A full description of the demo programs and what they do is in the Appendices of the offline documentation.
There are only a couple of fractal classes in there so far. Not that this is a limitation per se, since its a framework and you can plug your own in easily. But I hope to get some more to 'put in the box' eventually.
The fractal engine needs some architectural work, which I've really wanted to get to but have not been able to yet. Its quite nice, but a lot of thought on the subject has led me to want to make some improvements to make it easier to use. It would have been done this time, but the port to NT and massive internal improvements took precedence.
Unlike the ray tracer system, there is currently no 'fractal description language' in which the user can describe a fractal in a text file which will be parsed and used to create and render the fractal. I'll definitely be doing that for the next major version.
There is no support for serial port control, NT security, TCP/IP (see Networking), NT services, or OLE stuff. Some stuff, like OLE, probably will never happen because its too Win32 specific. But the other stuff I certainly want to get in place.
This really goes along with the 'Window Support' stuff below, since you need windows to display any graphics you can do. This stuff is not ported over totally yet, but will be in the next major release. Some of it is in this version, but its not complete.
The hard copy docs are still in very rough draft form, so they will improve a lot, and there will be much more of it. But they provide very important information even now, so be sure to read them. Feel free to let me know what you feel about the style and substance of them. This documentation is in MS Word format, so you can use the Write.Exe utility that comes with NT or use Word if you have it, to read or print the docs out.
The networking code has not been ported yet. It only supported pipes in the OS/2 days, and I want to expand it to be more open ended. It will be in the next version. I've worked out a higher level, very abstract, API that will be implemented for communications between CIDLib programs. It will be implemented in terms of the low level classes, which are specific to a particular protocol.
You can plug in your own scene object classes now and they will work very nicely; however, I haven't done the little bit of work required to let you hook your new class into the scene description language parser. It won't be a lot of work, but I just haven't had time to do it yet. Definitely it will be in the next major version, which will make the ray tracer fully extensible.
I also definitely want to add some sort of spacial subdivision scheme to the tracer for the next release. Right now its a brute force intersection tester (though its well written and very optimized to do its job), and could be made able to deal with large scenes much more quickly.
The SDL (scene description language) is not documented at this time, though its pretty easy to figure out a lot of it if you are a ray tracer fan. This is on the slate for the next major release.
Not all of the windowing support has gotten ported yet. There is some in this release, but its not documented or intended for use. It was just easier to leave it in than take it out.
As discussed below in the New Stuff area the message compiler now attaches the messages to the Dll/Exe file instead of loading them from a separate file at runtime. However, the APIs that MS provides to do the attching obviously have problems because this causes some Exe modules to be corrupted if they are not linked incrementally. And, if you do link incrementally it forces the linker to fully rebuild the next time you link. Since release type builds always link non-incrementally, some of the demo programs (Process1 and FileSys3) will be corrupted in the release builds. I'm trying to figure this out now and have a support issue open with MS on this, and it definitely seems to be their problem.
The collections scheme is finally pretty much as it should be. The overall move has been completed of getting everything out of the collections that requires the instantiation class to implement this or that method. The instantiation classes only need to provide copy construction and assignment. Everything else, object equality and relative magnitude comparision, map key opeations, hashing, collection duplication, copying, and comparison are all done via utility classes or global template methods. This avoids having to implement unneeded class methods just to instantiate a collection for them.
The 'by pointer' collections were tossed. There is now only one set (of 'by value') collections, and a new counted pointer class allows these collections to work with objects by pointer. This makes the system smaller and simpler and takes a lot of burden off of me as well.
A singly linked list physical data structure class was added and those logical collections that better fit a singly linked scheme were changed to use it (for better performance and smaller storage requirements.)
Cursors for collections that remain based on the doubly linked list class now support bi-directional iteration.
The encryption system has been much improved now and is ready for some serious expansion in the next release. Its been separated out into its own CIDCrypto.Dll facility in preperation for the implementation of a good number of encryption algorithms.
The Blowfish algorithm was added in this release, which is a public domain algorithm from Bruce Schneier, the author of Applied Cryptography. A new cryptography key class was added make the management of keys more safe and convenient.
Environment variable support is now supported via its own classes, instead of via the TSysInfo class as it used to. There is the TProcEnvironment class for manipulating the process' environment. There is a TEnvironment class for storing, manipulating, and passing around, environments.
The process environment system is lockable so that multiple operations can be done on it atomically. The TProcEnvLocker class provides exception safe locking services for the process environment.
The new TExternalProcess class allows you to execute other processes. You can start them, wait for them to die, extract their exit code, set and query their priorities.
New classes for doing heap debugging (in a platform independent way) are now provided. Look at the TKrnlMemCheck class.
The error dump mechanism now allows you to indicate a dump directory instead of just going to the current directory all the time. If the directory is not set, then it still goes to the current directory. The dump file is now named after the process that died, plus its process id.
A general push was made to get the system more localized and internationalized. Text that was previously hard coded (because of its use in primal boot up code) is now in message files so its translatable. Text for many streamable enums is now loaded from message files so its also translatable.
The TCardinal, TInteger, and TFloat classes (which support formatting of values) now have derivatives which support locale specific formatting. These are the TLocCardinal, TLocInteger, and TLocFloat classes.
A new TMoney class supports formatting of monetary values in a locale sensitive way.
The TTime class now loads its day of week and month strings from message text, so they are translatable.
Many of the formattable enumerations are now loading their text also so that they can be translatable. Enums that are code oriented don't require this but ones that represent things like days of the week or months do.
The message compiler now attaches the compiled binary message file to the DLL/Exe module instead of accessing them as separate files. This makes distribution easier and safer. However, see the beta issues section above, there are problems with the APIs that do this attachment and I might have to undo this if MS does not fix it.
A janitor object was provided for the TSemaphore class, called TSemJanitor, that makes entering a semaphore safe in the face of exceptions. It was the only one of the synchronization objects that did not have its own janitor, and had somehow just been overlooked.
The previously global methods provided by the kernel for raw bit field manipulation are now in a namespace called TRawBits. This pretty much completes the move to get all of the really low level kernel APIs into namespaces.
The ray tracer engine now supports refraction. This allows you to create a whole new set of images. It was a pretty simple addition, I'd just not had time to do it until now.
The streaming system was signicantly reworked and made more efficient and consistent.
The storage efficiency of polymorphically streamed objects was improved by decreasing the amount of space required to store the object type. And, if you need to store lots of small objects polymorphically, there is a new TPolyStreamer class, which will drastically reduce the storage needs of type info.
There is no longer a single base class for streams. Binary and text streams were broken out into separate, unrelated classes, as were their respective abstract stream implementation classes.
Text streams now work in terms of characters, not bytes, so that they act the same regardless of whether the source text is UNICode or ASCII format. Before, you had to take this into account and adjust byte offsets accordingly. Binary streams of course still work in terms of bytes.
The module initialization scheme was modified to make it easier to load translatable text during DLL loading. Lack of a clean ability to do this previously had caused CIDLib itself to use some hard coded text during the boot up process.
As part of this work, the module oriented parts of TFacility were factored out into TModule and TFacility now derives from TModule. During initialization now you will be passed a TModule object that gives you access to messages and resources attached to your DLL facility. This makes the loading of messages much more convenient.
Almost all of CIDLib's own strings are loaded from messages now. There are just a few remaining exceptions, and those will be cleaned up for the next release. This meaks CIDLib fully translatable now.
The testing suite programs are now provided. I was removing them from the build previously, but I'm leaving them in this time so that any modifications you make can be tested. They are far from full 100% coverage of all classes, but they provide good automated testing of the core classes and are always being expanded.
New demo programs have been added to better demonstrate the power of CIDLib.
The TRawStr APIs that handle string copies were being a little over optimized and not emptying out the target string if the source string was an empty or nul string. Oops.
The process registry now works better, and deals with some of the wierdness of NT handles that was causing it to now always work right before.
Some of the global methods for duplicating and comparing collections were not correct. This slipped by because the testing programs that I use were not forcing full instantiations of some collections (so the compiler was only instantiating stuff actually used.) So some compilation errors got through.
Internally, I'm getting 100% API coverage on my regression tests of fundamental classes. This caught a couple of missing APIs (which were in the Hpp file but not implemented), and some obscure errors. Eventually I'll ship the test programs also, for regression testing by people who make custom modifications to the CIDLib code itself.
Soon I'm going to be buying a bug tracking system to help me now that people are starting to report things back to me. I want to be able to put them on the web site and having tracking numbers, etc...
The tCIDFractal::EElemTypes enum was being overly cutsey by having the value of each enumeration value be equal to the bytes used by that element type. Unfortunately, two of them had the same byte size so that caused some ambiguity when trying to figure out what element type was being used in some cases.