A discussion of the approach to solving the issue of the Microsoft Standard C# Libraries involving writing custom libraries from scratch.
The Plugs approach is harder conceptually and requires a little background of how Microsoft’s standard C# libraries are structured.
Microsoft’s standard C# libraries are not purely to provide low-level code for higher level code to use. In fact, for the most part, they are IL code that references other bits of code within the standard libraries. Only a few core classes and functions call into lower level code such as the Microsoft Win32 libraries.
The implication of this is that you can keep some of the Microsoft standard C# libraries’ code and just plug the calls to the lower level code (e.g. calls to Win32 libraries). Unfortunately, most of the basic standard libraries were designed to be used as user-mode code not kernel code, so most of the basic library classes and functions need to be plugged to be able to compile the kernel.
-
Uses Microsoft’s existing standard C# libraries saving work in:
- Programming
- Structure design
- Research of required classes etc.
- Reduces the amount of code needed to be programmed
- Allows two development teams to work dependently but simultaneously – one on the kernel code, one on plugging the stuff used by the kernel code.
- Complicates the kernel compiler hugely as it has to deal with “plugged” methods and classes etc.
- Potentially doubles the compile time since plugs might have to be scanned before the rest of the compile can necessarily happen
- Ties Fling OS into Microsoft’s libraries’ structures and any “intern hack” code they have!
- No control over the inner code of the libraries and tied into MS .Net versions which may become unavailable.
- Hard to maintain
- Very complex conceptually and to program
- Requires additional work to find out what needs plugging, how to plug it to match MS’s original functionality etc.
- May cause problems later with MS IP
- Probably some more stuff that can’t be thought of right now…