Karl asked why we used .NET and not standard C++ against the raw Win32 API to write our framework. He moreover observes that a freshly started Creative Docs .NET instance uses 240MB on his machine and takes 30 seconds to launch... That's a lot and reflects typical values for pre 1.5 versions (more on that below).
My own measurements show that version 1.5 has a working set of about 90MB and that .NET heaps account for about 17MB reserved bytes (33MB reserved).
But back to the original question: why .NET and not just C++/Win32 for the framework?
More than 10 years ago I started working on a portable GUI toolkit (visit OPaC historic web site
), which only required very minimal support from the underlying operating system. All the drawing was done internally using a home-made 2D graphics engine, with alpha transparency support. The memory was tracked by a custom garbage collector, which relied on C++ wrapped pointers and reference counting; it was also able to properly handle cycles in complex graphs and I was very proud of it. Serialization and deserialization of object instances was automatic and did not require explicit support.
This was all nice and fun, but tedious to implement and maintain. There were tons of macros which provided something similar to runtime introspection
(what .NET calls reflection
) to support all the framework magic. The project went through several major changes in order to keep up with my ideas of improvements.
But then, Microsoft announced the .NET platform.
I was stunned: they had just developed the whole infrastructure and language (CLR and C#) which I was trying to painfully build in pure C++. It was both a dream coming true and an uncredible nightmare: I could either switch to .NET and benefit from the huge work done by Microsoft or continue to work with my own C++ code, and stay back from the big move.
I did some quick performance tests and was very surprised to discover that .NET was in most areas about as fast as what I had implemented in OPaC, or even faster, so the choice finally proved easy (yet, trashing a few hundred thousand lines of code remained painful).
Switching to .NET was a sensible choice. I lost some control on the low level code, but this is far outweighted by the advantages offered by the CLR/C# duo. The working set has increased (the number of DLLs required to run even a very simple .NET application is high) but this should not be dramatical as memory prices continue to fall. What's 100MB of RAM today, anyway?
For those who are interested in seeing what kind of application could be achieved with the old OPaC framework (on Win32), download an ancestor of Creative Docs .NET, named PAGE, here
. It works only on 16bpp displays, so be sure to configure your display to 65,536 colors before launching it...
I just realised that I did not explain why pre-1.5 versions of Creative Docs .NET used so much memory. The reason is simple: in order to be able to provide information about the fonts installed on the system, the framework loaded all fonts in memory (full
Tracked: Jan 08, 17:24