How could I embed a manifest file into my executable? Is there any support
for that in VB 6?

Thanks,

-Jalil

Could someone please explain what a manifest file is please. I think that is
has something to do with XP installs and probably Vista but what it actually
does and is used for I would like to know.

Show quoteHide quote

On Tue, 17 Feb 2009 03:48:29 -0600, "Jim Robertson"
<jimrobert***@mts.net> wrote:

A manifest is an XML file which contains some specific additional
information that is used when starting your program.

Under XP this is typically used to get XP visual styles on your
VBClassic controls by telling XP to use the new common controls
http://www.vbaccelerator.com/home/vb/code/libraries/XP_Visual_Styles/Using_XP_Visual_Styles_in_VB/article.asp

Another use is to set access privileges under Vista, for instance to
force your app to always run with Admin privileges. The manifest can
even be embedded into the app as a resource.

http://www.vbaccelerator.com/home/vb/code/libraries/XP_Visual_Styles/Using_XP_Visual_Styles_in_VB/article.asp

Would you know if the simple instructions for the manifest file approach
should work with an aX dll.

I've tried to follow to the letter, the file len is a factor of 4 and named
myApp.dll.manifest

Thanks,
Peter T

I see now for an ActiveX dll it means writing the manifest for the caller
application and in the calling app's folder, which for me is Excel

excel.exe.manifest

This works fine with Office 2003 in WinXP. The Office app's are not supplied
with their own manifest and no problem writing a manifest to a sub folder of
Programs.

With Office 2007 the app's do have their own manifests, which can be edited
to get the XP or Vista styles. Whilst no problem to edit the default
manifest, ie add the necessary or rather rewrite the entire manifest, it
might be difficult to know if I'm starting with a default manifest.

Next problem is the '2007 manifest, in Vista, is also in a sub folder of
Programs. This makes it very difficult to write to (why isn't it in AppData
??)

Third problem. The manifest has side effects, in particular the colour
palette in the  VBA IDE is white'd out.

For 2003 in XP, maybe viable to (say) rename the manifest to correct name
just before showing a form and rename to a dummy name when the form unloads.
In Vista I can't imagine how to do that from code in the aX. Not that I like
this approach anyway.

Any bright ideas, solution or workaround would be much appreciated!

Regards,
Peter T

I don't do much with AX DLLs, and I haven't done more than play with
manifests, but I believe for DLLS the approach is to embed the
manifest in the DLL (using mt.exe
http://msdn.microsoft.com/en-us/library/aa375649.aspx) rather than
adding the manifest to the 3rd party app. This avoids the other issues
that you mentioned such as existing exe manifests, filepath, etc.

The same occurs in the VB IDE if XP styles have been applied via
vb6.exe.manifest, and as far as I know there is no fix for this issue.
Controls need an hDc to use the new style, the colour palette in the
IDE doesn't appear to have an hDc so is rendered black. Similarly
labels for checkboxes/radio buttons in a frame appear black but can be
fixed by placing them in a picturebox inside the frame.

Although an embedded manifest file seems a lot neater, I've decided to keep
mine in a separate file. I use the manifest to turn on the newer Vista and
XP style controls in my app. While that is usually desirable, some people
use their own Windows skins to make the standard controls look they way they
want. Including the manifest overrides their skin, and they end up with a
mish-mash of control appearances. Having the manifest as a separate file
allows them (or me) to rename the manifest, essentially defeating its use,
and letting their skin take over.

I once read that once an app first reads the manifest, it won't read it
again, which would make the above procedure problematic. Buy my testing
indicates that isn't true; it appears to read it every time it starts.

Show quoteHide quote

Still struggling with this!

The above link suggests using mt.exe, which I don't think I have (even if I
do not sure I understand the instructions).

(Steve's link) Randy Birch describes how to embed a manifest here
http://vbnet.mvps.org/index.html?code/forms/vbidevista.htm

The example is for vb6.exe but the method seems to work fine with any vb6
dll. Having got the hang of it quite straightforward.

Sadly even with the embedded manifest I am not getting XP styles (or Vista
styles in Vista). FWIW, I experimented with different manifest length to
rule out getting the "factor 4" requirement wrong. the manifest as a
Resourse was successfully added as type:24.

I came across this link
http://msdn.microsoft.com/en-us/library/ms761394(VS.85).aspx

It suggests this is the method for a  Visual Basic aX dll, but what do MS
mean by "Visual Basic", is that .Net only or any type of aX dll (incl vb6).

Do you think this different manifest, which requires typelib and other
details of the dll, is worth a try (actually I have without success but
maybe I've got something wrong).

Regards,
Peter T

On Thu, 19 Feb 2009 08:23:22 -0500, "Rick Raisley"
<heavymetal-A-T-bellsouth-D-O-Tnet> wrote:

In the car on the way from the shops it suddenly occurred to me that
this is the better approach as far as I can see, since it allows any
computer whizz to delete or rename the manifest and register the
controls normally should (s)he so choose. If you embed the manifest,
that would render this course of action impossible? Probably.

My only gripe (so far) with reg-free com installation is that the
program seems to take slightly longer to load. When it's running there
doesn't seem to be any degradation, but as calls are made upon the
various ActiveX controls, for example when opening a different form,
then I reckon I perceive a slight delay. Only slight, mind you!
Insignificant compared to the tremendous benefit of not having to
register anything.

MM

mt.exe is included in the platform-specific Software Development Kits,
you'll need to find the Windows SDK for your particular flavour of
Windows on the MS site.
In this case it's VB Classic.

Show quote Hide quote In theory I should be able to get it from MSDN. However I'd need to compile
the final dll in W98 (for other compatibility reasons), so I guess(?) there
will not be an mt.exe version available for that.

I can't help wonder though if mt.exe does anything more than what Randy
describes how to do manually (with the jhelp of C++), but I don't know  - do
you?

Amazing?

OK that's good, did you look at the manifest example in that link. It's
slightly different to the one normally sugested for vb6 exe's. If that
different manifest really is required, I'd love to see an example of one
made for a vb6 aX dll, I suspect I'm not getting it right. That is of course
if it has the potential of working with Randy's instructions how to embed in
the dll.

Regards,
Peter T

Show quote Hide quote The only reasons I can think of for an appreciable delay might be (1.) you
can't use the possibly already loaded shared version of a library, and (2.)
you might be loading from slow media such as a CD or flash drive.

The second can be an important concern, because a DLL's code and data
segments may be unloaded and reloaded on demand.  This is much like using
code located on a network share.  It is also why LINK.EXE has specific
options for designating "load from network" and "load from CD" that tell
Windows what to expect (and cause Windows to load and cache everything for
better performance - i.e. "run from swap").  You could probably write a
small drag and drop WSH script to re-LINK your EXEs, DLLs, and OCXs with the
proper option set.


The idea of modifying an application or assembly manifest on the fly is
scary.  Probably even more so than the idea that some "computer whizz" might
delete my manifest and futz around trying to register associated libraries
(breaking everything or overwriting system copies of libraries'
registrations).  If your manifests are trivial that's one thing.  However
there is much more to an application or assembly manifest than "XP styles"
or even COM type information and DLL or assembly redirection.  Part of the
reason for them is to allow the use of libraries differing from the system
versions.  Then you have the trustInfo element that can be vital depending
on what your program does.  Then you have other assembly-selection issues
such as making the program load MSXML 4.0 properly.  Don't forget the "DPI
awareness" element.  There are also new "works with OS version nnn" elements
introduced in Windows 7, and probably in Vista SP3 when it comes out.

"Skinning" strikes me as a terribly gauche practice anyway, but that's just
me and to each his own (and good luck).  I'd rather give the user control
over over the look of his UI instead of overriding it and forcing something
on him that might prevent use of the low-vision themes, etc.  If they have
used something to "skin" the Windows Shell, it ought to work fine with the
6.0 Common Controls selected - or else it's a flawed "skin" isn't it?

It is easy enough to offer both a reg-free COM XCopy-able version and a
regular installation package if required.  You'd just use two different
builds and manifests.

I do this now to provide a per-machine installer package and another
per-user package (which is a new Windows 7 feature that can also be used in
Vista if done carefully, and for VB6 programs requires reg-free COM).
Per-user MSIs are nice because no elevation is required.

For a shrink-wrapped product I can't imagine using an external manifest,
though they can be handy while debugging.


Applications don't "read the manifest."  It is used by the program loader in
Windows.

Oops!  I meant Vista SP2.  Sorry.

Graphic Time Labeling
how to reposition desktop icons
WTF happened to my typelibs?
ADO Recordset Find method Problem
Test (yeah, I know)
Visual Basic 6.0 on 64-Bit system
Re: create pdf file in VB6
VB6 with SQLite: Is there a report generator/viewer?
Shell Function: task ID
How to switch the monitor off through vb6 code?