We've made a few changes since the last version posted and things look good.  I decided to post this update but please note that it has not been tested as thoroughly as most of the earlier releases!

So be sure to test your MMM'ed applications packaged using MMM 0.12 thoroughly before releasing them.

See the Change Log (Related\MMMChangeLog.txt) for details.  Here are the notable changes though:

• Another attempt to improve/correct the DPI-Aware node of the manifest.
• A change to TLB handling to prevent them from being included.  TLBs are not normally needed at runtime.  If you do need to include them add them yourself via Add Files or copy them to the target folder afterward.
• An attempt to cope with Microsoft patches that ended up causing "duplicate" coClass entries in MMM's manifests.
• Better (we hope) handling of non-creatable classes contained in some VB6-supplied OCXs.

I hope this addresses some concerns you too may be facing in these areas.  And of course I hope this version doesn't break anything or make things worse in some way.

Get the new version by downloading:

MMM-0-12

To view the web version or post a comment, go to http://mmm4vb6.atom5.com/yes-update-0-12-5479.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/yes-update-0-12-5479.html http://mmm4vb6.atom5.com/yes-update-0-12-5479.html#c http://mmm4vb6.atom5.com/just-some-notes-4979.html Thu, 23 Feb 2012 04:41:02 -0600 I hope everyone is getting some use out of MMM or the various offshoot projects either based on it or inspired by it.

My friend Jeff tells me there have been a few recent mentions of MMM in the forums and even the old Microsoft VB newgroups some folks are keeping alive.  He passed on a few comments I thought I might try to respond to:

Beta.  All released versions of MMM were "beta" and there has never actually been a finished edition released into the wild as either source or object.  Much of that was related to some non-sharable source code it took a while to replace, but most of it was because a finished product was always meant to provide a batch/command line build option as well as reuse/editing of those MMMP files.

Manifests.  As long as MMM as been called MMM it has generated an unsanctioned form of application manifest with inline assembly information.  This seems to work for any version of Windows tested so far, starting with XP.  But the "proper" way to do this is for the application manifest to reference separate assembly manifests associated with libraries the main program depends upon.  You can best accomplish this using other manifest generators if you need to.

SxS failures.  There are probably a lot of these, but maybe the most common one comes from installing one of the repeated broken attempts at the 2008 "security rollup" patch from Microsoft on your development machine.

As I mentioned in earlier posts, not only do these broken libraries contain some odd duplicate entries in their typelib info that cause MMM manifests to fail... they also contain numerous "off by one" coding errors that can make them either entirely useless or time bombs.  Some Winsock properties return String values with a one-character truncation.  MSChart has many issues such as collection indexes off by one, leading to GPF type crashes.  Sadly there isn't any uninstall for these patches.

A way to spot this issue when SxS failures occur is to examine the generated manifest and look for the duplicated entries.

http://mmm4vb6.atom5.com/just-some-notes-4979.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/just-some-notes-4979.html http://mmm4vb6.atom5.com/just-some-notes-4979.html#c http://mmm4vb6.atom5.com/there-is-another-4881.html Fri, 28 Oct 2011 02:06:04 -0500 Another new MMM beta release, that is.

I never expected to be doing this, but within just a very short time of posting my previous entry here on MMM and DPI Awareness my old buddy Jeff Smith (of Aunt Belle's) called and gave me an earfull.

Better than just telling me how "full of it" I am, Jeff had test cases and a solution!

So I'm posting an 0.10 beta version with full source, and this will probably be the "final final" MMM release.  For those who have already forked 0.9 Final with your own improvements, there is only one change: the resource DPIAWARE was replaced and MMM was recompiled.

The new package contains the updated resource file and a compiled version of MMM.  The importable text file stored as DPIAWARE is: MMM 0-10\Res\manifest.dpiaware.txt

Hopefully this cures any other DPI-related woes people have been having when using MMM's DPI Awareness option when creating application manifests.

Thanks again, Jeff.  And apologies to the VB6 community.  Keep up the good fight!

Be careful with this, I did not have a chance to do exhaustive testing and may have broken something else or somehow screwed up the build:

MMM-0-10-FINAL-src.zip

I will try to keep this up for at least a year after this date.

http://mmm4vb6.atom5.com/there-is-another-4881.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/there-is-another-4881.html http://mmm4vb6.atom5.com/there-is-another-4881.html#c http://mmm4vb6.atom5.com/highdpi-revisited-4880.html Thu, 27 Oct 2011 23:41:31 -0500 While I can't offer any sort of support anymore, remember that in the previous post here the final source code was made available.  This should allow people to locate and fix bugs they find or add new features.

High-DPI Awareness

Lately I've been buried in emails (most end up routed into a "MMM support issues" folder I rarely look at now) whinging on about problems with programs where the manifest had "High-DPI Aware" selected.

I cannot reproduce any "bugs" in this myself though I'm not saying there aren't issues. But please note that it makes no sense to mark a program High-DPI Aware if it isn't!

I direct you to the MSDN article on the subject: User Interface - High DPI Awareness.

Marking an application in this way is a declaration of capabilities.  Telling Windows that it's true when it is not is just asking for trouble.  The link given above is a brief guide to the changes you must make to a program before it should try to "wear the badge" of High-DPI Awareness.

Here is the fragment MMM adds to the application manifest when you seelct the DPI-Awareness option:

Note that this is precisely the information MSDN documents as required.  it also works fine for my own programs and those of many others.

Switching Windows to XP DPI-scaling only masks your DPI bugs.

Duplicated comClass Entries

Some people have installed faulty "updates" to several VB6 controls.  These have broken many controls with "off by one" errors throughout various properties and methods.

They have also broken binary compatibility and thus add extra registry entries on a system that already has properly functional VB6 controls installed.  One symptom of this is that many members of the classes involved will get two <comClass/> entries in the manifest that MMM produces.

MMM cannot "fix" this.  It is the result of a machine that has been trashed by installing a faulty update from Microsoft.  These "VB6 controls" security rollups" (and note Microsoft tried, tried, and retried getting these right - and never did) are not pushed via Windows Update, so you must have done it explicitly yourself.

As far as I know there is only one reliable fix: reformat and reinstall Windows, then avoid installing the bad updates again.

http://mmm4vb6.atom5.com/highdpi-revisited-4880.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/highdpi-revisited-4880.html http://mmm4vb6.atom5.com/highdpi-revisited-4880.html#c http://mmm4vb6.atom5.com/pscript-portable-sof-4617.html Fri, 05 Aug 2011 14:25:58 -0500 I am not in a position to do any more work on MMM right now, but I have cleaned up and repackaged a small utility that can be useful with "MMMed" programs meant to be run from portable media.

Portable Applications

One thing MMM is useful for is creating portable software in VB6.

But what I have found is that some programs just work a lot better if their data is on the hard drive.  The performance is better, "wear" on flash memory drives is less, and for CD-based runs anything that needs to be altered in use (even if you don't need the updates afterward) just won't work on your source medium.

I got sick of CMD/BAT files quickly, the dangling console windows are extra clutter and just plain ugly.  WSH scripts worked as a wrapper, but when I use the computers at my local library the scripts fail: they have WSH, the FSO, etc. locked down for safety.

PScript

So I ginned up a custom script host for running wrapper scripts, and I'm calling it PScript (as opposed to Microsoft's CScript and WScript).  So far it does the job just fine.

PScript exposes a fairly small object model to the scripts, which can be written in VBScript or JScript.  Most of the object model provides disk operations such as copying files and folders.  There is also a Run to run your wrapped application.

The basic idea is to launch a PScript run instead of your application program itself.  The script will copy work files from a folder or folders on your portable media to a hard drive location, such as a folder created under AppDataLocal.  Then the script runs your program and optionally waits for completion.  After your program is closed (or crashes) the script can copy back altered data and clean up the hard drive folder(s) you used.

Your portable application should be basing writable data file locations on its current directory and drive (CD) or rely on command line parameters.  The script can set CD before the Run of your program to point to the work file location.  Or if your program pays atetntion, it can pass command line arguments to it as well.

Finding PScript

While retaining Copyright, I am making PScript source and binary available for anyone to use and create derivative works from.  You can find all of this along with documentation over at:

PScript - Portable Software Script Host

I hope some of you find it useful.

http://mmm4vb6.atom5.com/pscript-portable-sof-4617.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/pscript-portable-sof-4617.html http://mmm4vb6.atom5.com/pscript-portable-sof-4617.html#c http://mmm4vb6.atom5.com/mmm-source-now-freel-4562.html Sun, 24 Jul 2011 09:03:10 -0500 After a lot of work to get final clearance on all of the code used in MMM and to "clean room" replace everything else I could not get cleared, we're there.

The most recent version of MMM can now be made available in source code form.  While still copyrighted, anyone is allowed to use it for their own purposes including derivitive works.  There is no source license and no promise of support at any level.  All other developers who worked on MMM over the years have signed off on this or their code has been replaced by all new code.

Effectively you are free to do as you wish with the source aside from claiming that you wrote it yourself.

I hope this goes a long way toward helping people get features they have needed or get past bugs that have frustrated them.  It has been a long struggle here trying to find ways to get around external restrictions on releasing the source.  In many places snippets or modules at issue were downright silly to haggle over but this is finally done, with only a modest expense in legal fees.

The downside of this is that there are now some really "rough patches" in the source.  A lot was hacked out and new code grafted in without enough time spent to harmonize the result.  But this is the same source that 0.9 was compiled from, so we can have a little confidence that no new major headaches were introduced.

This blog will probably be closing with this entry, and may "go dark" after July 2012.  The source download should remain available until the same date if not a little longer.

Life, the economy, and technology all go through changes.  I hope that MMM has been useful to some of you and that you can put the source to good use at last.  Good luck!

MMM 0.9 FINAL (with source)

http://mmm4vb6.atom5.com/mmm-source-now-freel-4562.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/mmm-source-now-freel-4562.html http://mmm4vb6.atom5.com/mmm-source-now-freel-4562.html#c http://mmm4vb6.atom5.com/fixing-those-sxs-syn-4442.html Thu, 14 Apr 2011 12:19:31 -0500 Well it seems as if more people are stumbling over problems when they use buggy libraries and package via MMM.

I'm, pretty sure I've found the culprit: bad attempts at encoding illegal XML characters combined with very poor quality libraries you are trying to use.

I won't mention names, you know who they are if you've had these troubles.  It seems that they've been creating libraries where there are typelib comment strings that are improperly terminated.  It looks like they think you can just slop your C string buffer in there and everyone will stop at the first NUL and ignore your buffer garbage.  Clearly somebody is using poor build tools that don't understand a BSTR or something.

If they make a blatent error like this can you trust the rest of their code to work right?  I wouldn't.  Be afraid.

I should talk, clearly MMM wasn't up to the task of protecting you from code that breaks the rules.  Wait a minute... that's not MMM's job!

Give the new version a spin, I hope it addresses the matter to your satisfaction rather than creating new headaches.

Download (still) beta version 0.9 here.

http://mmm4vb6.atom5.com/fixing-those-sxs-syn-4442.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/fixing-those-sxs-syn-4442.html http://mmm4vb6.atom5.com/fixing-those-sxs-syn-4442.html#c http://mmm4vb6.atom5.com/a-long-wait-small-up-4378.html Tue, 15 Mar 2011 14:04:55 -0500 Yes it has been a very long time since the last update.  And worse yet only a few changes are here.  I hope they help some of you though - and don't break anything you have been using!

See the readme file for details.

No, there is still no way to reload and rebuild from a saved .MMMP file.  This just isn't anything I've gotten back to for a long time, so only the most pressing issues I have fixes for are addressed.  I hope to get back to VB6 programming again on a regular basis someday, I agree it still has a lot of life left in it.  MMM has been working well for me on the occasions where I need to make a fix to one of my own applications.  I hate to hear about problems the rest of you have that I can't do anything about though.

Please: If you have a bug send me a zipped Project folder with a test case that fails if at all possible.

And no, I still don't have clearance for a few things in MMM that would let me release the source.  I have "clean room" recreated two classes though by paying another VB6er who has never seen the source.  That leaves two more I hope he can reproduce, or that the authors release me from Copyright restrictions soon.

As most of us know the economy has driven us into other things besides VB6 for income.  I'm appalled at the low-dollar people being hired even to do VB to VB.Net now who don't have a clue about VB (and I wonder about their VB.Net understanding).  Yikes!  At least I make a few dollars coming in to troubleshoot when their employers get desperate enough.  I think I'm down to two new VB6 projects a year now however.

I hope things are going well for the rest of you.  Good luck with this 0.8 version.

Oh yeah, the download: MMM 0.8

http://mmm4vb6.atom5.com/a-long-wait-small-up-4378.html

To create your own Blog at Atom5, go to http://www.atom5.com]]> http://mmm4vb6.atom5.com/a-long-wait-small-up-4378.html http://mmm4vb6.atom5.com/a-long-wait-small-up-4378.html#c http://mmm4vb6.atom5.com/hello-europe-mmm-0-7-3344.html Sat, 15 Aug 2009 12:56:15 -0500 There won't be a version 0.6.8 as suggested earlier.  For whatever reasons several people seem to want another version numbering scheme to be used, one that exposes the build number.  So now we're at MMM 0.7!

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.

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