Years ago I wrote my process enumeration and management module. It primarily uses the NT Native API, giving it extended capabilities over the standard PSAPI or ToolHelp Windows libraries. When I designed this component, I exposed it as a COM interface. This was because I had originally planned to resell it to other developers.
Years later, I never did resell it, and have no plans to do so. Only Process Lasso uses it. Now, because its a COM control there are occasionally problems with registry cleaners or users who don't have administrative rights to install the component. Who knows why registry cleaners sometime mistakenly target its COM registration. I suspect malfunction on their part.
For a long time now I've wanted to do away with this COM interface, but the risk of an accidental mistake deterred me. I mean, after conversion full regression and memory leak testing of every functional part is required.
Well, I've finally bit the bullet and got rid of the COM interface. Technically speaking, it is a very simple transition. COM interfaces are modelled on C++ classes, making them very easy to turn back into C++ classes. In fact, they can theoretically be referenced as C++ classes as-is. However, practically speaking, some work was necessary, especially with regards to object instantiation and data-type optimization.
Yes, this means I have a lot of regression testing to do. I plan to leave this beta series in beta for some time, back-porting minor updates to the last final build as needed (parallel development, as always).
So, what end effect does this have? Well, there is a substantial reduction in memory use by both the GUI and core engine. There's also a slight reduction in CPU use. Lastly, this opens the door for Process Lasso Portable Edition.
UPDATE: To give a more specific measurement, core engine memory usage has decreased by about 1.5MB on the average computer! This means its often using less than 1MB of RAM.
Enjoy ;)
Years later, I never did resell it, and have no plans to do so. Only Process Lasso uses it. Now, because its a COM control there are occasionally problems with registry cleaners or users who don't have administrative rights to install the component. Who knows why registry cleaners sometime mistakenly target its COM registration. I suspect malfunction on their part.
For a long time now I've wanted to do away with this COM interface, but the risk of an accidental mistake deterred me. I mean, after conversion full regression and memory leak testing of every functional part is required.
Well, I've finally bit the bullet and got rid of the COM interface. Technically speaking, it is a very simple transition. COM interfaces are modelled on C++ classes, making them very easy to turn back into C++ classes. In fact, they can theoretically be referenced as C++ classes as-is. However, practically speaking, some work was necessary, especially with regards to object instantiation and data-type optimization.
Yes, this means I have a lot of regression testing to do. I plan to leave this beta series in beta for some time, back-porting minor updates to the last final build as needed (parallel development, as always).
So, what end effect does this have? Well, there is a substantial reduction in memory use by both the GUI and core engine. There's also a slight reduction in CPU use. Lastly, this opens the door for Process Lasso Portable Edition.
UPDATE: To give a more specific measurement, core engine memory usage has decreased by about 1.5MB on the average computer! This means its often using less than 1MB of RAM.
Enjoy ;)
