New Version 0.7

I wasn't quite ready to put out a new MMM version but then over the past three days I got two bug reports I couldn't ignore.

Both of these involved a problem with "comma as decimal point" in some international locales.  A very strange coincidence, but right after fixing this the first time a second report of the same problem came in.  This was enough to get me to pull a new release from the MMM codebase now that I have changed it to use the current decimal point character.

Along with the first report a second issue was raised.  Some people actually do compile into folders other than the Project folder it seems.  So MMM will follow the Path32 key in the .VBP file now instead of simply requiring that the compiled EXE be located in the Project folder.  And yes, this appears to be the same issue raised in a comment to an earlier blog post here... that I sort of blew off because I thought MMM was already handling the matter.  Doh!

The bigger changes I have coming along for MMM are not ready for beta release yet.  So only a few additional changes are present in this MMM 0.7 version.  These should not matter much to most users, but details can be found in the readme.txt file in this package.

ZIP Archive, Not EXE

This version has been posted as a simple ZIP archive instead of a self-extracting EXE.  The tools for extracting from a ZIP are extremely common and even Windows has been capable of doing it alone for some time now.  Some people are running MMM on Win9x systems (??) and the self-extractor I was using requires NT crypto libraries, so it could be a problem for these guys.

On the plus side the download is only about half the size as before:  MMM 0.7

As always, let me know about any problems.  Be sure to keep MMM version 0.6.7 or earlier around in case of problems with the new one.

To view the web version or post a comment, go to http://mmm4vb6.atom5.com/hello-europe-mmm-0-7-3344.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/hello-europe-mmm-0-7-3344.html http://mmm4vb6.atom5.com/hello-europe-mmm-0-7-3344.html#c http://mmm4vb6.atom5.com/adox-typelib-in-vist-3290.html Sun, 12 Jul 2009 00:56:15 -0500 Wow, it took me some time to notice it but Microsoft must have been listening.

One of the headaches to watch for in Vista was that DAC 6.0 (and MDAC before that) was not including the compatibility typelibs for ADOX the way they do for ADO.  Suddenly I see we have an option now though: msadox28.tlb is there, which implies that msadox.dll now exposes both sets of interfaces.

Now programs compiled on Win2k or WinXP against ADOX 2.8 should work under Vista SP2 unlike previously.  I had been changing my habits to use late binding for ADOX objects but someday (once all Vista in the world is at SP2?) I won't have to anymore.  We can hope that Win7 RTM ships that way too.... right?

Of course any programs compiled against something like ADOX 2.6 are probably still screwed.  Microsoft was more thorough about ADO compatibility typelibs even on Vista.  Either there is a problem doing this for ADOX downlevel (interfaces too different?) or more likely they want everyone on more secure DAC/MDAC levels anyway.  This means some programs will still need recompilation for Vista.

This also means you can early-bind to ADOX 2.8 when developing on Vista SP2 and expect your programs to work on Win2K or XP as long as MDAC 2.8 is installed there.  That was the other side of the ADOX coin previously: if you used early binding to ADOX 6.0 in Vista your programs would not run downlevel.

Nice theories anyway.  Now to test and verify them!

But Microsoft's error lingers and I'll be late binding ADOX for some time to come.  I just don't trust the whole world to install Vista's SP2 overnight... maybe for years considering that Windows Service Pack Blocker Tool Kit is loose in box jockey land.

Maybe we can hope this change was part of some Windows Update fix and not part of the SP2 package?  Does anyone know?  But I guess that still doesn't mean I can start early binding ADOX again anyway I suppose.

http://mmm4vb6.atom5.com/adox-typelib-in-vist-3290.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/adox-typelib-in-vist-3290.html http://mmm4vb6.atom5.com/adox-typelib-in-vist-3290.html#c http://mmm4vb6.atom5.com/looking-toward-soon-3255.html Sat, 27 Jun 2009 15:23:27 -0500 Early feedback has been full of small feature requests.  Some of these seem odd, like requests to make MMM into a general purpose resource editor or some sort of 24-bit color icon embedder.  Others are just off the wall, like asking that MMM support non-VB development tools (huh?).  Still others make a bit more sense, like requesting that MMM fully install as a development topol and add a "Package with MMM" shell verb for .VBP files.

Other programming tools already offer their own ways to generate isolated applications.  MMM is targeted at VB6 to help make up for Microsoft's failure to support the community.

Version 0.6.8 will probably be an even more minor update than 0.6.7 was.  The main difference will probably be delivering it as an MSI package for full installation, instead of as a self-extracting archive.  This should calm the noise about not knowing "where to put MMM" and "why doesn't MMM show in my Start Menu" and so on.

What I could really use is some feedback about the changes that went into 0.6.7 though.  In particular I'd like to know if the XML encoding changes have solved problems with components having Unicode characters in Descriptions and so on, and whether the new handling of interface versioning is helping those who don't manage component Binary Compatibility closely.

http://mmm4vb6.atom5.com/looking-toward-soon-3255.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/looking-toward-soon-3255.html http://mmm4vb6.atom5.com/looking-toward-soon-3255.html#c http://mmm4vb6.atom5.com/mmm-067-ready-3206.html Sun, 7 Jun 2009 10:52:41 -0500 New Version 0.6.7

As described earlier MMM version 0.6.7 is ready for testing and use.  Download it here.

While I have put it through some extensive testing nobody else has taken a look at it yet so there may be serious imperfections.  More importantly some application manifest XML changes have been made that might need further tweaking to avoid breaking cases that worked fine earlier.  Please report any problems, and fall back to version 0.6.6 if necessary.

That may seem a little alarming, but everyone should keep in mind that MMM remains a work in progress.  There has never yet been a "final release" version at any level of functionality.  MMM remains in an extended beta testing state and this will continue until all planned features have been included and trials have concluded.

For most purposes though it should work just fine.

What is MMM?

For those of you joining us in progress...

Make My Manifest (or MMM) is a utility that was originally intended to make it easier to package Visual Basic 6.0 programs (EXEs) in a way that allows simplified deployment.

In Windows XP Microsoft supplemented the earlier "COM redirection" technique from earlier versions of Windows with a new side-by-side assembly technology.  One aspect of SxS is that it allows the use of isolated asemblies and applications that can contain private copies of COM type information normally stored in the system registry.  This enables something which is often called registration free COM because it allows many COM/ActiveX libraries to be deployed without registering them.

One advantage of reg-free COM is that you can deploy a program which uses a different version of a COM library than the one registered on a target system.  This is not meant to be used to run foreign system components on a mismatched OS, but is used to let several programs co-exist on a system which may use different versions of some same application component or components.  Most of the time this would be used with things like the "VB6 Extended Runtime components" (controls shipping with VB6 that you add to the toolbox), 3rd party component libraries, or your own OCX or DLL libraries that you create as part of an application.

Reg-free COM lets you create a VB6 EXE as an "XCopy deployment package" that does not require formal installation anymore on Windows XP and later operating systems.

Caveats

Note that this assumes you have tested with and can run using the VB6 runtime components that ship with versions of Windows.  I have not worked out any way to isolate the VB6 runtimes yet, so such packages have to "survive" the bugs and limitations of older runtimes your users might have installed on their systems.  The good news is that by the time Windows XP shipped the VB6 runtimes were reasonably stable.  Subsequent XP service packs and newer versions of Windows ship with newer runtimes as well.

You must also be just as cautious as with the Packaging and Deployment Wizard or other tools to avoid trying to isolate and deploy things like system components or components that must be deployed as a suite (bits and pieces of IE, MDAC, etc.).  MMM makes an effort to forcibly exclude such components where it can identify them, which makes the job easier for you.  If MMM still picks up such components you can manually exclude them just as in the PDWizard.  If you want to use installed/registered components instead of supplying isolated copies, manual exclusion works for this as well.

If your program uses late-bound COM libraries you can manually include these in the package, causing MMM to include the library and insert the necessary Type information in the application manifest.  This of course does not apply to things like Office components, which must be formally installed and cannot be practically isolated for the most part.

ActiveX EXEs and DCOM in general require registration, limiting the benefit of MMM and reg-free COM when your application uses these things.

You can certainly use MMM and reg-free COM if your application is an ActiveX EXE in itself, however it will attempt to self-register on first use, which requires elevated privileges for that first run in order to avoid unexpected behavior.  The ActiveX EXE won't be fully isolated (which would defeat the purpose of it being an ActiveX EXE in the first place) but it can use isolated components.  The difference is that you can't simply delete the application folder or move it around on a machine without adjusting its registry entries.

Some VB6 controls cannot be properly isolated until XP SP2 with VB6 SP6 runtimes in place.

What Else Does MMM Offer?

MMM can include the necessary assembly selection entry for Windows Common Controls version 6.0, which use the Visual Styles introduced in Windows XP.  Note that for this to work reliably your program requires a small amount of code to control the loading of this library, but this has been discussed in many places across the Web since Windows XP came out.

MMM can be used to specify a Vista trustInfo section in the application manifest.  The presence of this entry signifies that your program is Vista aware on versions of Windows beginning with Vista and will bypass many AppCompat shims such as filesystem and registry virtualization.  This section can also be used to request a non-default Execution Level, often done to force privilege elevation in Vista or later.

MMM can create an external manifest file for your application, or it can embed the manifest in your EXE as a resource.

You can also manually include non-COM DLLs in your program's package with the DLL location specified.  This lets you place all of your program's COM and non-COM libraries into a dependencies subfolder.  Normally the system DLL Search would not find standard DLLs in a subfolder.

New Stuff

You might want to explore a few links on topics related to new options in MMM.  One of these is the dpiAware option and the other is the (Windows 7) Compatibility option.

Tutorial: Writing High-DPI Win32 Applications

Application Manifest (Windows 7)

http://mmm4vb6.atom5.com/mmm-067-ready-3206.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/mmm-067-ready-3206.html http://mmm4vb6.atom5.com/mmm-067-ready-3206.html#c http://mmm4vb6.atom5.com/security-update-woes-3184.html Sat, 30 May 2009 16:57:07 -0500 I see there is another attempt to release a Security Update to VB6 SP6: Microsoft Visual Basic 6.0 Service Pack 6 Cumulative Update dated 5/4/2009.  See KB957924 for details.

I have not tested it myself yet to determine whether it fixes the problems the earlier attempts have (breaking MSChart20.ocx for one thing, Winsock control for another).  However but I see that other users say it has not fixed the Winsock control that was also broken in earlier attempts.

So far all of the problems I've seen look like bonehead "off by one" errors in the code.

Thus I still recommend this "critical update" be avoided - almost 6 months later.  I hope people who find and can reproduce these problems report them to Microsoft.  It seems to be a free support call since the update is security related.

http://mmm4vb6.atom5.com/security-update-woes-3184.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/security-update-woes-3184.html http://mmm4vb6.atom5.com/security-update-woes-3184.html#c http://mmm4vb6.atom5.com/degraded-progress-3183.html Sat, 30 May 2009 15:35:31 -0500 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.

http://mmm4vb6.atom5.com/degraded-progress-3183.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/degraded-progress-3183.html http://mmm4vb6.atom5.com/degraded-progress-3183.html#c http://mmm4vb6.atom5.com/kb-kb-2848.html Fri, 30 Jan 2009 18:22:21 -0600 I was able to confirm a problem another user uncovered in the MSChart20.ocx (version 6.0.98.13).

I am holding off installing the Security Update myself until we get further news, and I hope a corrected Update.

http://mmm4vb6.atom5.com/kb-kb-2848.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/kb-kb-2848.html http://mmm4vb6.atom5.com/kb-kb-2848.html#c http://mmm4vb6.atom5.com/servicing-regfree-co-2815.html Mon, 19 Jan 2009 08:57:48 -0600 No news, but so far so good on MMM.  No new release ready yet I'm afraid, and it may be late February 2009 before we see one.  Sorry.

For now: MMM 0.6.6 is still current.

Servicing XCopy Deployments

One of the issues we face when creating XCopy deployments with Registration-Free COM is a new challenge in servicing our applications.

Installing applications conventionally means that we use a great many components stored in central locations locatable via the registry.  It also means that Windows Update, downloaded Microsoft patches, etc. all update our applications as a matter of course when users install them.  Not so for our isolated components though.  We keep the old, possibly buggy, and possibly security vulnerability ridden copy of each component library.

This is even a problem for those of us using Reg-Free COM with Windows Installer to perform per-user installs that do not require elevation under Vista or Windows 7.  By the way, expect to hear more about per-user installs once Win7 hits the street.  Short term, consider that as of Win7 (Beta) Microsoft has a designated place for per-user installs now: a folder created under [LocalAppDataFolder]\Programs.

Now we could just periodically repackage and redistribute, hoping users will redeploy.  But is there a better method?  Maybe something that doesn't end up overlaying data files (settings, etc.) that may have changed with usage since the user first unzipped our package?  How do we help the users track versioning unless we replace the EXE with a new one as well, even if only upgrading libraries?

I don't have a general answer to this yet myself.

For XCopy installed applications I'm considering using a small, separate INI-like version.inf file that my Help|About... dialogs reference.  Maybe with nothing but the actual EXE version numbers and a letter suffix for such servicing updates that only upgrade components.  Probably distributed as a smart self-extracting archive that extracts to a temp folder then runs a small utility from temp to ask for the location to update, and then just replaces the impacted libraries and version.inf file itself.

Per-user MSIs can probably use regular Installer patching, but I need to review the caveats again.  They still require individual updating though because they don't use the system copies of libraries that do not come with Windows (the VB 6.0 Extended Runtime Files for example - i.e. the controls bundled with VB6).

Any better ideas?

KB 926857 and KB 957924

This came to mind because of the December 9, 2008 critical security update Microsoft put out.  I won't offer a link (KB 926857) because this Update patch was horribly buggy, installing several faulty controls (version 6.0.98.12).  It was replaced by KB 957924 December 30, 2008 (version 6.0.98.13 controls)* which may be better.

* I have not personally evaluated the new Update yet.

http://mmm4vb6.atom5.com/servicing-regfree-co-2815.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/servicing-regfree-co-2815.html http://mmm4vb6.atom5.com/servicing-regfree-co-2815.html#c http://mmm4vb6.atom5.com/v066-does-not-exp-2627.html Sat, 29 Nov 2008 08:46:28 -0600 The new version of MMM has almost no changes except for eliminating the expiration date.

As I mentioned previously this utility is now stable enough that I am no longer concerned about having seriously imperfect versions floating around in the field.  So to eliminate worries about relying on a tool that will stop working suddenly this feature has been taken out.  MMM is still incomplete and I still consider its status to be in extended beta test release.  I hope to produce a true 1.0 release by the second quarter of 2009.

As with any new release I'd appreciate early feedback about any problems encountered so that I can get them corrected.  This is very important for Version 0.6.6 because all previous 0.6.x releases will stop working as of December 1st, 2008!

In the future I won't l have to worry about running into deadlines as I have this time.

The new download can be found at MMM 0.6.6 in the form of a self-extracting EXE as before.

http://mmm4vb6.atom5.com/v066-does-not-exp-2627.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/v066-does-not-exp-2627.html http://mmm4vb6.atom5.com/v066-does-not-exp-2627.html#c http://mmm4vb6.atom5.com/upcoming-release-2494.html Thu, 13 Nov 2008 05:18:28 -0600 There has been little activity on MMM for some months.  A new version will be posted by December 1st however, and while it will not contain many changes it will remove the time bomb from the program.  MMM is stable enough at this point that I feel quite comfortable doing this.

No new features are expected to make the December release, and there is only one minor bug fix that should be fully tested and included by then.  Most users wil only notice very minor cosmetic changes.

The positive feedback has been very encouraging.  I hope to have some time to get the two major new features finished: online Help and command line "replay" of a saved MMM Project file (command line build).  Along with the second feature I also hope to be able to reload an MMMP file and allow it to be edited and saved, but this may have to come later.

This first subsequent release may become available by February 2009.  The followup release might be sometime before April.  i expect this to be version (finally!) 1.0.0, a true milestone.

But I'll admit this may be ambitious considering how little time I've had recently to work on MMM.

http://mmm4vb6.atom5.com/upcoming-release-2494.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/upcoming-release-2494.html http://mmm4vb6.atom5.com/upcoming-release-2494.html#c