Hi John,
1. The VB6 virtual machine's runtime msvbvm60.dll (its US locale build, to be precise) is a system library that comes in every clean Windows installation, original or OEM, localized or not, since Windows 2000. You can find it in the \system32 forlder of any OOTB 32-bit installation, or in the \SysWOW64 folder, under 64 bits. So, you shouldn't worry about the compatibility of your editor with any user PC regardless of the actual Windows version or locale it runs under so long as the editor continues to be re-compiled, if needed, by VisualBasic 6 localized for the U.S. Neither do you have to ship your own msvbvm60.dll with it because every Windows PC already has it installed in its default search PATH. In fact, failure to run your editor on a Windows PC is a 100% sure indication that the PC's Windows installation is broken or has been tampered with.
Official VB6 packages localized for other regions are however not ABI compatible with VB6's original US implementation and would therefore require their own msvbvm60 DLL's to be shipped along with VB6 programs created using such packages. I have checked it personally for legit Russian, French, and Spanish packages of VB6. The situation with warez distros of VB6 may be even worse than that. So, make sure your US VB6 package stays intact and don't allow unauthorized, amateurish recompilations to occur. (yet another headache of an open-source project, hehe...)
2. It is true that in order to support theming, any Windows application must have either a precompiled manifest resource or an associated .manifest file. But VB6's controls aren't simple common system controls that other languages would use. Most of them are superclasses augmented to suppress excessive flicker of ordinary common controls as they are being resized on non-composited desktops of W2K or XP or Classic themes of Vista+ platforms. They also allow for VB6's own backbuffering (the so called Autoredraw mode), which ordinary common controls won't do. Clearly enough, such improvements imply totally different drawing patterns that may be incompatible with the principles of Windows theming now or, more likely, in the future.
VB6 had been designed before Windows themes appeared therefore MS has never guaranteed that manifests would work for VB6 programs under all circumstances or with all Windows builds. All such theming was never officially supported and is totally at the developer's and user's own risk. Luckily enough home-brewn VB6 theming kinda works in most cases.
3. IIRC FBSL has had its own COM layer since the year of 2006 or thereabouts. It's capable of handling both local and inproc servers (i.e. exe and dll COM object sources) and it can also make use of ActiveX technology with some extra programming effort which isn't however too extreme to be totally impractical.
So, I beg your pardon but your proposition on standardizing FBSL to Dave-or-anyone-else-over-there-at-SB's COM does sound a bit out of place to me. Thanks for the invitation tho.
