Degraded progress: better than no progress?

Hello Again

Yes, it has been quite some time since my last post here. Progress has been disappointingly slow, probably for the same sorts of reasons you experience in your own projects:

Other priorities such as family, health, finances in the present economy, and programming efforts with much higher priority.
Laptop that was being used to squeeze in time to work on MMM died, it now appears permanently. All I'll say is there is a brand of computer I won't trust again soon as well as a certain chipmaker.
An amazingly large number of feature requests for MMM, and a few minor and serious glitches that finally have been isolated. Most of these have also been corrected, which is even better!

Bad News, Good News

The bad news is that the MMM 1.0.0 version that I had anticipated for April 2009 release just isn't even close to ready. But the good news is that a new 0.6.7 beta version has almost passed testing and should be ready for release very soon.

The most difficult part of MMM 1.0.0 is a major rearchitecting of the code in order to support two important features. The first is to allow loading a previously saved .MMMP file and regenerating the manifest. The second very highly requested feature is the ability to use MMM in command line mode against a previously saved .MMMP file for scripted builds.

Splitting MMM in Two

The latter may require that I split MMM into two separate programs. It just isn't possible to create a truly stable program that can work properly as both a GUI and a command line program. For some of the reasons I refer you to How do I write a program that can be run either as a console or a GUI application?

So then the question is: "Duplicate significant amounts of logic across the two programs, or factor out most of the manifest generating logic into a common DLL?"

Holy Dependency, Batman!

To me the answer is obvious: use a common DLL. Yet even raising this casually in correspondence seems to engender disgust and hostility for some reason. This is the obvious course of action, and since I package MMM using reg-free COM anyway an ActiveX DLL should be far from any kind of burden.

I suppose this goes back to the paranoia some VB6 programmers have about any sort of dependency, especially COM dependencies. I think it goes back to the trouble people have with deployment when they don't spend enough time doing it to ever understand the process.

In any case I'm leaning toward a shared library, and probably will go that way unless somebody can offer a compelling reason not to. But I had truly thought this was the obvious course of action.

The 1.0.0 Delay, Welcome to 0.6.7 (soon)

So anyway, with all of the additional changes since 0.6.6 it has been hard to bring forth 1.0.0 because I now have two codebases to fit each change into and two sets of code to test. The result is that I am backing away from releasing a 1.0.0 right now (it really is not ready anyway) and working on 0.6.7 so that people can benefit from the improvements.

A short list of changes worth noting includes:

Minor UI changes and fixes.
Small cleanup of the manifest trustInfo section for better stability across Windows versions.
Small change to manifest XML to allow it to be modified via MT.EXE without breaking it (almost nobody needs this, but the need does exist).
Correct the discovery and manifest formatting of typelib COM versions (once and for all I hope).
New optional dpiAware section in the manifest.
New optional Compatibility section for Windows 7 and later.
More thorough XML entity encoding for textual attribute values in manifests.

These may not all meet the cut for 0.6.7, since I would like to put it out here ASAP.

I suspect you will want to hang onto MMM 0.6.6 for at least a short time. The new beta includes so many changes that I am worried about new bugs that break programs you already have working with MMM now. The back and forth between 0.6.7 and 1.0.0 shakes my confidence a bit as well.

1.0.0 is a major fork in the road and though most of the same logic is there it has been drastically reassembled into a different internal object model. Keeping the flow consistent was difficult too, which made it tricky to back-port changes in 1.0.0 to the old 0.6.6 codebase.

I have not found any serious problems and none I could not correct, but testing will be very important for this new beta. The good news here is that your programs should either work properly or fail immediately if a problem exists. Unraveling any problems that occur is usually the hard part, so please include as much information as you can (don't forget to include the manifest if an external manifest file can be used to reproduce the problem).

I'm pretty sure i have found and fixed things that cause MMM itself to crash. Report these too when they occur.

The Future of MMM

This is a topic that has run hot and cold over the years.

MMM started as a casual in-house solution to a deployment problem for a few fairly small applications. A move into .Net and Java meant that it was discarded for this purpose long ago.

I only work on MMM on my own time. Whether the status of MMM ever changes is something only time will tell. It will probably never become shareware as I had originally hoped. VB6 development shrinks day by day and people are not willing to pay for such a simple tool. If a full soruce release becomes available it will probably be after 1.0.x is stable.

At the same time I have fielded a few queries about either licensing the source or acquiring exclusive rights to it. I suspect this is motivated by a desire to incorporate some of the logic into another product rather than take on MMM to improve and market it. As I said my own market research never showed any potential for even a shareware product, let alone anything offered commercially.

So far the offers have been neither solid enough nor valuable enough for me to consider. Ideally somebody with the motivation and resources would offer to acquire MMM and offer it as supported freeware through at least 2016. Under such terms I might be glad to offer complete and exclusive rights for $1, given assurances I could believe.

Until then, my plan going forward is to produce a stable 1.0 and simply release the source at that point.

Delphi? C++? VB.Net?

I've had some feedback that strikes me as quirky. A few people have asked why MMM "only supports VB6." I'm puzzled about what development system they'd want MMM to support besides VB6. Most of the alternatives already have good tool support for reg-free COM manifests, don't they? And besides that, the goal of MMM was to offer something wizardish on the order of the PDW for casual VB6 developers to use.

It might be possible to coerce a version of MMM to process a VB5 project. I'm not sure how valuable this is considering that Windows does not ship with the VB5 runtimes and VB5 itself has not had the changes made to permit full support of reg-free controls as VB6 has.

For that matter MMM isn't doing anything especially exotic. A distressingly large part of the code is just Ui management and simple bookkeeping. The clever parts probably comprise less than 5% of the logic. So while MMM does incorporate a few "tricks of the trade" that are obscurely documented (if at all) for the most part creating a similar tool isn't really much of a challenge.

So Back to Work

I'll get back on 0.6.7 now, and so you should see it fairly soon. Perhaps even as soon as a week from now if the next round of testing goes well. Remember, I depend on community testing of new MMM versions. But if you find a problem and do not report it I can't do too much about it.

Thanks for reading this long post, and thanks to those who have taken the time to report bugs and be patient with me about working them out. I also appreciate your suggestions even though not all of them make it into MMM and some of them take forever to do so.

Posted at Saturday, May 30, 2009 03:35 PM
In General Category | Permalink