Vita was the codename for what are now just the KSoft libraries.
Vita is the logical amalgatmation of many related and dependent codebases, primarily written in C++ and C#.NET, which are produced and developed by Kornner Studios.
Vita began as a closed source project back in November of 2009 (so we predate the PS Vita). It wasn't until the beginning of 2014 when it was transitioned to an open source product.
As of 2020, we've switched to git. Previously, many of the projects were using Hg for source control. Since the move to git, we setup this monolithic repository to link together everything via the power of submodules!
Etymologically speaking, "Vita" is the Latin word for "life". If you're reading this, then it is very likely that coding is a part of your life, as it is to Vita's developers.
KSoft is the codename of the C#/.NET-centric part of the Vita codebase.
The KSoft.BCL (Base Class Libraries) embodies many generalized systems that we have developed to supplement our specialized projects (which are located in external repositories).
Some projects are open source (eg, KSoft.Blam, for targeting the Halo engine), some closed (eg, KSoft.XDK, for targeting multi-generation Xbox Development Kits).
The default license of Vita projects is the MIT License
The KSoft Base Class Library aims to provide a compartmentalized framework which provides functionality not present, or at least efficiently, in the .NET framework proper.
"Compartmentalized", in that non-critical systems like KSoft.Security are outside the actual root assembly, just named "KSoft".
Example functionality which you can't find in the .NET framework is a BitStream class. We also provide utilities for treating and using Enums as actual bit flags, in an optimized and complete manner.
We're also very, very reliant on using T4 Text Templates to generate most code which would otherwise be copy and pasted to fit the context of like-wise types. For example, our static KSoft.Bits (located in KSoft's Bitwise folder) class uses a single T4 template to generate the BitCount() method for the usual unsigned integer types (UInt32, etc)
You will actually be hard pressed to find a decent, comprehensive BitStream class for .NET anywhere on The 'Net. The most comprehensive one that I know of is featured in a CodeProject article. To compare the two:
-
They require a complete, internal copy of the stream's bytes; KSoft supports actual streaming (using a BaseStream) and use a configurable (at compile time) cache 'word' (32 or 64 bits) where bits reside until being flushed to the BaseStream
-
They were last updated in 2005 and have unpatched bugs; KSoft has a tried and tested class. Tested in both regular use and with Unit Tests to validate core operations. A patched version of the article is used in our Unit Testing to check compatibility
-
They have a #region infested, monolithic .cs file; KSoft makes use of partial classes and code generation using T4 to keep the files bite-sized and copy&paste code to a minimum
The .NET framework offers a Enum.HasFlag() object method which you can use to test that an enum. Unfortunately, that method is far from efficient.
Using code generation (via Linq Expressions), we're able to address the inefficiencies found in .NET's Enum.HasFlag(). We don't perform any boxing and can operate on the underlying type (ie, integer) of the enum instead of using UInt64 as a catch-all.
We take this one step further still and provide functionality for Add, Remove, and Modify as methods. What's great about this is that you're able to add a new semantic level to bit flag operations in your code, instead of bleeding your enum values together with the normal bit-wise operators.
If we so desired (and we presently don't), we could even modify the code generator to add checks to DEBUG assemblies that validate the flags being used in bit operations (Test, Add, etc) have named members in the enum type.
If there are other .NET languages which don't (easily) offer bit flag operations on enum types, I'm sure our utilities would prove their use once again in adding such support.
Before you try building any of the projects, first read the requirements you may need.
KSoft.T4 should always be the first thing that gets built. It's the meta assembly used by many of the T4 documents that are found in all the other assemblies. It's only needed when building projects, not at runtime.
NOTE: The BCL contains some C++/cli projects, which cause the 'Win32' Platform to be defined. The only projects that get built with this active platform are these C++/cli projects. Instead, you should opt for the 'x86' and 'x64' Platforms which will also build the .NET assemblies. Long story short, don't select 'Win32' for your active configuration.
However, at the time of this writing these C++/cli projects haven't been populated with meaningful code, so you're currently safe just building for 'Any CPU'