Ah, VxWorks.

Thanks for the PR. I'm happy to incorporate changes to support VxWorks; worked with it once myself. I'm going to take a closer look sometime soon, but my first question is:

Why do we need all of the VxWorks toolchain-specific project files? Is there no combination of CMake options that will work? For example, could you incorporate a custom toolchain file into your process? Or perhaps just use the Unix Makefile generator with the compiler and linker options set correctly?

Overall my main concern with this stands; the VxWorks toolchain-specific project files ideally don't belong here. I'd be happy to discuss elsewhere how we might manage this; perhaps we can spin up a new repository within the organization that @sulemankm could maintain?

Even if we solve that problem, there's not currently a way to 'inject' the TimeHelper class into the build.

Actually tornado generates a Makefile which can used to build it for Vxworks. However, Tornado/VxWorks toolchain installation is required for building the framework and test anyway. So as installation of Tornado/VxWorks toolchain is a must, then Tornado project fils would come in handy for building the UnitTest++ framework and tests.

Pardon my ignorance but, I'm not really sure what you mean by not being able to "inject" the TimeHelper class into the build.

By "inject" I was hinting at dependency injection; right now the correct TimeHelper is selected at compile time, rather than by a factory or anything like that. If we were to move all of the VxWorks toolchain-specific stuff out into a separate project as I proposed, we would still have to include the VxWorks-specific time helper in the core UnitTest++ build.

Ok, I got your point about injecting dependencies. About the build solution, I think pre-compile-time selection of the appropriate header file is probably the easiest solution.

@sulemankm sorry I left this unattended for so long.

I'm interested in making some of these changes but not all of them. If we can get rid of the VxWorks project files, and figure out how to address the .at issue -- I'm thinking by having GetResults return a wrapper object for VxWorks -- then I'm game. If you're still interested in getting this pull folded in, can you make those changes? Or, add me as a collaborator to this pull request and I'll take a stab at it -- although you'll have to check the compiling for me.

How about GetResults return an object with an overloaded [] operator which internally calls the .at() method for vxWorks. Just a wild idea. I haven't tried it so I'm not sure if it is even feasible. Just a wild idea!