This is the second version of this application. The previous version will no longer be maintained.
If you landed here looking for information on SxS (side-by-side) manifests, recommend jumping to here as a start.
The project simply creates application-manifests that can be written to disk, clipboard, or VB resource files. The project includes a default/dummy manifest with all known options, as of this date. You would select whichever manifest options you want to include and modify those option values as needed. If you wish to view or replace an existing manifest file, you can import it into the project via the clipboard, disk, or VB resource file. The tool will attempt to parse VB vbp project files and create a new manifest, filling in the Identity element from that file.
The major reasons for revision are several
- Previous version was create only. This version can also edit existing manifests.
- Use Microsoft XML in the background to create and modify the XML
- Use XML stylesheets to help transform the manifest based on export options
- More intuitive design and more modular to assist with future updates by you or me
- Will no longer ignore hand-jammed manifests within VB resource files, i.e., #24 custom entries
- Offers ability to update unrecognized (future) manifest entries imported from elsewhere
The manifest is designed to make use of XML qualified names, internally, and is the default mode. However, when exporting the manifest, you can opt to convert to traditional name spaces if you choose.
Caveat: Not 100% of the manifest options available have been fully tested. Some options can't be tested by me because I don't have the system(s) to perform the desired tests. However, all the options should be technically correct and in accordance with the Microsoft schema for application manifests.
Comments, bug reports, and suggested enhancements are always welcomed.
Code:
Update History
9 Apr 17: Realigned questionable elements to their correct namespace
10 Apr 17: Fixed error noted in post #4 below
13 Apr 17: Fixed new-found error & added minor enhancement. See post #9 below
15 Apr 17: Optional update. See post #11 below
26 Apr 17: Added support to allow editing Assembly Manifests. See post #12 below
29 Apr 17: Optional update. See post #13
16 May 17: Padding bytes of Chr(0) prevented Win10 from applying manifest. See post #14 below
20 Jul 17: A few minor changes plus a couple minor enhancements. See post #21 below
24 Oct 17: Handles UTF8 BOM in imported manifests to prevent MSXML2 from rejecting manifest
25 Oct 17: Found bug when toggling TrustInfo name space. See post #41
2 Sep 19: Added forceFocusBasedMouseWheel option
7 Dec 19: Added activeCodePage & heapType options
options having comma-delimited values can now have those values in specified order
fixed 2 options that were defaulted to the wrong namespace
Last edited by LaVolpe; Dec 8th, 2019 at 11:45 AM.
Reason: uploaded lastest changes
Insomnia is just a byproduct of, "It can't be done"
Compilation Errors
Should you see an error like the following once your app is compiled...
... There are two possible reasons for it:
1. Your embedded manifest file size is not a multiple of 4 bytes. This is a bug with VB6 that SP6 fixed. If you don't have SP6 applied, do so. That fixes a lot more than the problem just mentioned. This tool now ensures it writes dword-aligned manifests to resource files anyway.
2. The manifest syntax/values may not be valid. You will need to view your Windows events log (from the control panel), look at the application log and find your application and the error shown above. In that error you'll see what line number and reason within the manifest (XML) that is causing the problem.
Here is an example of such a windows event error. The "version" value in that line of the manifest is a 4-part format, i.e., 1.0.0.0, not the 2-part format used: 1.0
Activation context generation failed for "C:\Program Files\...\CopyDatabaseWizard.exe". Error in manifest or policy file "C:\Program Files\...\CopyDatabaseWizard.exe" on line 8. The value "1.0" of attribute "version" in element "assemblyIdentity" is invalid.
Note: Adding a manifest with the Common Controls option allows your form's standard controls to be skinned using the current O/S theme. When adding this element, also start your project with the Sub Main located in a bas module, that routine is used to initialize the common controls. Do know that v5 of the common controls in your toolbox is skinnable, v6 in the toolbox is not. Tip: The Help menu can copy a typical Sub Main to the clipboard for pasting into that bas module. Tip: This option allows you to add alpha blended icons to buttons if desired. See post #10 below for an example. Updated: On modern O/S, starting with Sub Main no longer seems to be required if using an embedded manifest. The manifest entry prompts the O/S to call the needed functions. However, on older O/S, there is a bug when using compiled OCXs created in VB that can cause a crash when the compiled application is closed. If that is happening, recommend using Sub Main. Even if not technically needed, does no harm. See this thread where that problem was discovered, jump to post #12 in that thread.
Tip: When exporting manifest to a RES file, the file does not need to exist. The tool will create the new RES file and then insert the manifest. However, don't export to a RES file belonging to a project that is currently open, write access will likely be denied. In this case, simply remove the res file from your open project, update it with this tool, then re-add the res file.
Note: Many options prevent modifying their values. This is simply because only one value is permitted and it is hard-coded. Tip: To show any attributes hidden in the tree view, edit values that are locked, or manually provide a value not in a displayed list of values, hold the shift key down while activating the context menu. Regardless, you cannot enter a blank value if the element/attribute has been flagged as its value cannot be blank.
Tip: Attributes cannot be selected/unselected. How to prevent optional ones from being exported? Set their value to empty/blank. In the "Output" window/form, choose option to not export empty attributes. Optional attributes have the context menu item "Erase". Several can have their values manually entered as a null string. Empty attributes that are exported will have a null value, i.e., <assemblyIdentity ... publicKeyToken=""/>. Optional is not always optional. For example, the publicKeyToken attribute is not optional if it applies. You, of course, are responsible for providing correct values for any item that can be manually entered.
Note: The Identity item cannot be unselected. It is the only required manifest XML element.
Tip: When displaying the Qualified Name context menu item, the base name and NameSpace submenus are FYI only. Since the treeview is designed to be human-friendly for the most part, the actual manifest element name and namespace are not necessarily displayed as they would be if reading the raw XML, if displayed at all. Those submenus give you that info.
Tip: VB is mostly DPI-aware. Adding the DPIAware option to your manifest will prevent your forms being stretched in higher DPI settings your users may be running your app in. However, VB6 is only mostly aware, and there are details that must be addressed. There is a tutorial of sorts on things to consider; here are a few:
- Use TrueType/OpenType fonts everywhere. First step: Assign the form a TrueType font as that is the font that is inherited by most controls added to the form afterwards, negating the need to individually set the font for most controls
- Image controls should have its Stretch property set to True else manually scale as needed
- PictureBox controls should NOT have its AutoSize property set to True else manually scale as needed
- Metafiles are DPI-aware. All other image types are not & may need to be scaled by you
- Controls without Top/Left, Width/Height properties (i.e., Line controls, etc) can fail to position/size correctly unless its form is saved in ScaleMode other than pixels. Always leave the form in twips ScaleMode and only change its ScaleMode at run-time if desired, i.e., in Form_Load
- Always test your app in highest DPI setting available when using the DPIAware option. Minimally, test at 175% DPI. If you are going to see issues, it will be there since internally, VB is not running at the same exact DPI.
Note: For those of you that are familiar with SetProcessDPIAware & SetProcessDPIAwareness APIs, Win10 can prevent their usage with the dpiAwareness and dpiAware elements. May only apply if your app, no embedded manifest, calls those APIs and an external manifest is applied to prevent the API usage. In other words, manifest trumps API calls.
Gotchas: When manifesting VB projects back in the day (XP), frames treated many child controls badly when rendering. That has been fixed for the most part... Except frames within frames. Try it and you should see the problem with the inner frame's caption. The workaround is similar to those old days: place the inner frame in a picturebox & that picturebox in the outer frame. Resize picturebox, change backcolor as needed, and make it borderless. See post #58 for an option to do this at runtime vs. fixing complex projects in the IDE.
IDE Gotchas: If you manifest your IDE for theming, you will likely lose the popup palette to select property colors during design-time. The palette is simply erased, but still there. To fix the problem, I have an add-in that can be used. See that thread
Last edited by LaVolpe; May 10th, 2020 at 02:15 PM.
Reason: constantly updated to add tips & notes
Insomnia is just a byproduct of, "It can't be done"
Pretty much external manifests are history. These manifests are external files with the same name as your application and appending a .manifest extension. The reason why they are becoming history is that any embedded manifest will take priority unless certain registry keys are changed.
To embed a manifest in VB6 project, you can use a tool like the one here or you can create an external manifest and add it to your resource file, in the CUSTOM section. Once added, double click on it and change the Type Field to: #24 and change the Id Field to: 1. Tip: Those can be manually extracted by opening the RES file in NotePad.
If you want your VB6.exe to use an external manifest, unless you plan on using some 3rd party software to embed one into the exe (and hope it doesn't corrupt it), some annoyances are expected. Simply adding an external manifest along side of VB6.exe doesn't guarantee it will be used. You may very well need to change a registry setting to make it happen. After you are sure your manifest is being recognized, you will likely want to go and restore the setting:
After making the change and manifest still appears to not take effect, reboot. It is getting harder and harder to use external manifests within Windows -- and that's probably not a bad thing.
In post #56, page 2, an example of using mt.exe is shown for editing your VB6.exe to insert a manifest.
Here is another way of manifesting the IDE without permanently modifying the VB6.exe file.
1. Create an external manifest. Make it perfect, exactly how you need it
2. Copy the manifest into your VB6.exe folder and name it VB6themed.exe.manifest
3. Now copy your VB6.exe and rename the copy: VB6themed.exe
Now run the new VB6themed.exe. The idea is that since the executable hasn't yet run, it should pick up the manifest the first time.
If that worked, and you later need to change the manifest, you still may have to jump through hoops. You could always repeat the above 3 steps using a different name. If playing with DPI awareness, you may want to create a couple different versions, where maybe one is system DPI aware, one is per-monitor DPI aware, etc.
Last edited by LaVolpe; Apr 21st, 2020 at 04:31 PM.
Insomnia is just a byproduct of, "It can't be done"
1. Start program
2. Select "Application" => "Description"
3. Context menu => "Qualified Name" => "Base Name: description"
Run-time error '9':
Subscript out of range
I'm not entirely sure when it was all fixed, but resources are correctly unpacked with the correct byte size (not rounded to 4-byte multiples) so long as they're smaller than 65520 bytes (which most .manifest files would certainly be smaller). Once you go over 65520 bytes, they do start getting rounded up to the nearest 4-byte boundary.
Best Regards,
Elroy
EDIT1: Also, great work on the above.
Last edited by Elroy; Apr 11th, 2017 at 03:30 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Elroy... Correct. After testing it, it doesn't matter if the manifest manually inserted into the RES file is word-aligned or not. I know that when my code inserts the manifest, it must ensure the entry is word-aligned
Edited: removed some comments, regarding another project, where I may have been misinformed. No clarification will be provided
Last edited by LaVolpe; Apr 11th, 2017 at 02:39 PM.
Insomnia is just a byproduct of, "It can't be done"
Interesting about the alignment if you're doing it through code. I suppose though, since you're also creating the manifest through code, it's easy enough to align/pad it.
(Removed my related comments as well.) Peace, to all.
All The Best,
Elroy
Last edited by Elroy; Apr 11th, 2017 at 03:29 PM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
I have removed a few posts from this thread, including one of my own. It was taking the thread off topic, though it raised some points I feel are worth pursuing. I'll attempt to pursue them by other means.
Uploaded modified project. The modifications include a bug fix and a minor enhancement:
Bug: Adding a new <file> element from the Miscellaneous menu could result in a duplicate key error. Fixed
Enhancement: Holding shift key down while activating the context menu (right click) unlocks any locked item and/or attributes
-- Any item with 'hidden' attributes displays a new menu item: Show Attributes
-- Any item where the Value or Text menu item is disabled, will be enabled
-- Any item where a new value must be selected from a finite list will have "New Value..." appended to the list, allowing manual entries
Some code changes, but a noticeable one should you already have modified the project is that the various cManifestEntryEx class methods that accepts an optional attribute index parameter did accept -1 meaning the method applies to the element vs. an attribute. That has been removed, -1 is no longer a valid index. The MenuActions_Timer event modified due to that change.
Last edited by LaVolpe; Apr 13th, 2017 at 05:59 PM.
Insomnia is just a byproduct of, "It can't be done"
Just a FYI item. Another benefit of adding manifests is the ability to add nice alpha-blended icons to your buttons. This method will NOT work if controls are not themed.
Updated: This method does not work for XP. It is possible to get an image on the button using this technique, but the button will lose its theme and you cannot get both button+text. Potential workaround is using BCM_SETIMAGELIST, something for you to research.
The button icon assignment in the screenshot above was accomplished...
1) Load your alpha-blended icon/bitmap via your favorite method. You will need to destroy the icon/bitmap at some point
2) Here is a generic routine. If button is not themed, then your result is either image or text, not both.
Code:
Private Declare Function GetWindowLong Lib "user32" Alias "GetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long) As Long
Private Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
Private Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByRef lParam As Any) As Long
Private Declare Function GetGdiObject Lib "gdi32.dll" Alias "GetObjectA" (ByVal hObject As Long, ByVal nCount As Long, ByRef lpObject As Any) As Long
Private Declare Function RedrawWindow Lib "user32.dll" (ByVal hWnd As Long, ByVal lprcUpdate As Long, ByVal hrgnUpdate As Long, ByVal fuRedraw As Long) As Long
Private Enum ButtonTextImageAlignment
BS_NO_CHANGE = -1
BS_DEFAULT = 0
BS_LEFT = &H100&
BS_RIGHT = &H200&
BS_CENTER = &H300&
BS_TOP = &H400&
BS_BOTTOM = &H800&
[_BS_MASKALIGN] = BS_CENTER Or BS_TOP Or BS_BOTTOM
End Enum
Private Function SetButtonImage(ByVal buttonHwnd As Long, ByVal imageHandle As Long, _
Optional ByVal Align As ButtonTextImageAlignment = BS_NO_CHANGE, _
Optional ByVal ShowCaption As Boolean = False) As Long
' Return value is the previous image handle, if any.
' You are responsible for disposing of that handle if it was not from a .Picture property
' pass zero for imageHandle to remove an existing image, else pass bitmap/icon handle only
' how alignment works
' Horizontal alignment
' Unless BS_LEFT or BS_RIGHT is passed, alignment is centered
' Vertical alignment
' Unless BS_TOP or BS_BOTTOM is passed, alignment is centered
' If image is being shown, it is positioned first and text positioned afterwards
' when BS_BOTTOM then Image on bottom, then text on top of image
' when BS_LEFT or BS_CENTER then Image on Left, then text right of image
Const BS_BITMAP As Long = &H80&
Const BS_ICON As Long = &H40&
Const GWL_STYLE As Long = -16&
Const BM_SETIMAGE As Long = &HF7&
Const IMAGE_ICON As Long = 1
Dim dwStyle As Long, dwNewStyle As Long, imageType As Long
If Align <> BS_NO_CHANGE Then
dwStyle = Align And [_BS_MASKALIGN]
If dwStyle <> Align Then Align = BS_NO_CHANGE
End If
dwStyle = GetWindowLong(buttonHwnd, GWL_STYLE)
dwNewStyle = dwStyle And Not (BS_BITMAP Or BS_ICON)
If Align <> BS_NO_CHANGE Then dwNewStyle = (dwNewStyle And Not [_BS_MASKALIGN]) Or Align
If imageHandle <> 0 Then
If GetGdiObject(imageHandle, 0&, ByVal 0&) < 24 Then
imageType = IMAGE_ICON
If ShowCaption = False Then dwNewStyle = dwNewStyle Or BS_ICON
Else
If ShowCaption = False Then dwNewStyle = dwNewStyle Or BS_BITMAP
End If
End If
If dwNewStyle <> dwStyle Then SetWindowLong buttonHwnd, GWL_STYLE, dwNewStyle
SetButtonImage = SendMessage(buttonHwnd, BM_SETIMAGE, imageType, ByVal imageHandle)
RedrawWindow buttonHwnd, 0, 0, 1 ' optional if project is themed
End Function
4) Finally, as needed, destroy your icon/bitmap during form_unload, as needed
Code:
DestroyIcon hIcon ' or if bitmap
DeleteObject hBitmap
How did I use a 48x48 icon? Easy way: use your favorite icon editor/parser and single it out to its own file.
If you are asking how to load an icon, suggest starting with LoadImage API
Last edited by LaVolpe; May 13th, 2020 at 03:02 PM.
Insomnia is just a byproduct of, "It can't be done"
Project uploaded to address undesirable effects when running in 200% DPI. This is an optional update since most will never be running this application in 200% DPI. Since I talk about manifesting for DPI-awareness and how VB is mostly DPI-aware, least I should do is make sure the app works well in high DPI.
Should you want to download the changes, here's what changed
- Form size is no longer fixed. At 200% DPI, the form was taller than the screen. So form is resizable, but to prevent resizing the width (which is not what I want), I subclassed the form. Subclassing is optional when in IDE via a message box confirming you will allow it. There is a specific line that can be rem'd out to prevent the message box from displaying (see modWork.SetSizeRestrictions). It will never display once the application is compiled.
- The TreeView control would not scale properly in 200% DPI. Added tweak in Form_Resize event to address that.
- Since form can now be resized vertically, needed to add code to resize the treeview and reposition the textbox
By the way, app looks fine at 200% DPI
Insomnia is just a byproduct of, "It can't be done"
Added moderate support for Assembly Manifests also. This required including nearly 10 new elements, along with ability to merge elements common between both Assembly & Application manifests. This project does not auto-generate assembly manifests; however, you can now edit existing ones or create them from scratch. The Miscellaneous menu has been modified to allow insertion of any Assembly-Manifest related elements.
Other minor changes include defaulting to exclude prefixed element names during exporting of manifests. Can be toggled in the Output window. The "File" menu now has an option to select secondary manifests to be merged with the currently loaded manifest. Since many elements can only exist once in a manifest, any subsequently loaded manifest elements will not overwrite existing elements. For those elements that can exist multiple times, they will be appended. Recommend if using this option, always load the primary/base manifest first, then append other manifests if you want to import their special/custom elements.
Insomnia is just a byproduct of, "It can't be done"
Updates applied, no need to update your previous version if these options are not desired:
1. Added support for optional assembly-manifest windowClass element.
2. Updated a few more help tips for assembly-manifest related elements
3. All manifest elements can be deleted that were appended via the menu: Manifest|Append/Merge Manifest
4. Any elements that offer a list of possible values now offer those values in a separate submenu
5. Added new form to make selection of comma-delimited element values easier vs. relying on the standard vb InputBox() function. See screenshot below. When the "New Value" menu item is clicked, it generates the displayed form with its multi-select listbox. This additional fluff currently applies only to 2 elements:
- windowsSettings/2016/dpiAwareness
- assembly/file/comClass/miscXXX attributes.
Insomnia is just a byproduct of, "It can't be done"
Self-identified a bug. At least with Win10, using null char Chr(0) as padding to word-align manifest before writing to a resource file prevented the manifest from being applied. The fix was simple enough, use a space as padding instead. Patch uploaded in post #1.
Edited: An example of the Windows Event log showed this:
Activation context generation failed for "C:\Users\LaVolpe\Desktop\..\some.exe". Error in manifest or policy file "C:\Users\LaVolpe\Desktop\..\some.exe" on line 29. Invalid Xml syntax.
There was no invalid XML syntax. Everything I have that could open/validate the XML proved that. So out of curiosity, thinking maybe Windows was interpreting null character as end of XML within the res file and bouncing that byte position relative to dWord alignment, determined invalid XML, not necessarily invalid format (generic error probably). The required padding changed to spaces, no modifications to the XML & Windows had no problems.
Edited: Though the above solution appears to work, not satisfied. I'll look at it again and see if the null characters are indeed the problem, which I find hard to believe. This is just a matter of better understanding the res file format more than anything else. There is very little documentation on how the typical 'data' portions of the resource file should look like for sections other than bitmaps, icons, cursors, and string tables.
Edited yet again. It is possible, depending on whether SP6 is installed and/or the size of the embedded manifest, VB will change the size of the resource. When changed, it will included padded null bytes which can generate that error. As of Oct 2017, the tool will now ensure the manifest is padded with spaces, as needed, to prevent any chance of VB padding with null characters. Just a sanity check. This logic applies only when writing to resource files.
Last edited by LaVolpe; Oct 28th, 2017 at 03:23 PM.
Insomnia is just a byproduct of, "It can't be done"
Forgive me if I'm asking a basic question, but can the manifest file be created on an XP Pro computer and then used with a compiled version of the chosen program on a Win10 computer? Or do you have to make the manifest file and compile the chosen program on the same computer that you want it to run on? Sorry for asking what seems a basic question, but Ive always wondered about manifests, so now it's time for me to stay playing around with them.
BTW I love your slogan: Insomnia is just a byproduct of, "It can't be done" I tested out the Insomnia part with a late 3pm to 3am programming session, and found "It can be done" with a "bit of triple blended Coffee and dark chocolate".
Thanks for the info LaVolpe and dilettante. Just editing this post,so as not to clog up this page with extra threads.
I still use XP Pro, Win8 as well as Win10 so I will experiment with manifests on these machines.
In the past I had upload some source code to Planet VB and found that people had problems seeing the program in action, due to the different Operating Systems around. The main problem was that objects turned Black, so I tend to stick with original standard textboxes, shapes, labels and listboxes that came with VB6 Pro to avoid these problems. So I had to weight up whether to have a nice interface or have may program showing correct graphics. I tend to make little maths programs, as I am a teacher so my students need simple GUI's that show up correctly on the various OS's they use. I want to experiment with "Quizzer" (a Lan tester on this codebank site by dilettante) so I need to make sure that all students see the same test on their various computers.
Many thanks for the extra information on manifests. I've always been curious about them, but had not experimented due to the many operating systems around. I had an idea, that one could create say 5 different manifests, and let the program automatically choose the manifest that is specific to the operating system run on that computer. Sort of like, the program runs and identifies Xp Pro as being used and then decides to use the XP Pro manifest, ignoring all other manifests.
Last edited by CreativeDreamer; May 20th, 2017 at 04:07 PM.
... and found "It can be done" with a "bit of triple blended Coffee and dark chocolate".
You know how that slogan came to be then. When I was far younger, I'd program into the wee hours of the morning, more times than I can remember, trying to find a workaround for something that others said VB can't do. At my age now, doing so typically results in some form of regret -- physically, not mentally.
Regarding your question... Supposedly, the O/S will only look at the manifest parts relative to the O/S version. If newer O/S version items exist, they should be ignored completely. It won't matter which operating system you compile your app on since the manifest should be embedded into your resource file. That resource data doesn't change during compilation.
Above being said, I wouldn't suggest adding newer O/S options to the manifest if you haven't tested it, unless you are doing so to pass off to a friend to do the testing for you. Declaring your app Vista (or newer) compatible while only having access to XP would be a guess at best -- always test your app after applying a manifest, for at least two reasons:
1) Make sure the manifest isn't preventing loading your app (results if manifest syntactically incorrect) . The manifest can prevent loading the app for other reasons, for example, requiring an assembly that does not exist. Example: GDI+ v1.1 is assembly included in the manifest and app runs on XP. GDI+ v1.1 typically not installed on XP; therefore, error & app fails to load.
2) make sure the manifest options you chose are not causing some unexpected results, i.e., making your app DPI aware and user loads your app in 175% DPI.
Last edited by LaVolpe; May 20th, 2017 at 12:13 PM.
Reason: typo
Insomnia is just a byproduct of, "It can't be done"
You can also get burned by requesting an alternate assembly that doesn't exist on a downlevel machine. For example GDI+ 1.1 requires Vista or later, or MSXML 4 on XP.
Of course those are both dead OSs now, but there are other less commonly used DLLs with SxS alternatives as well.
You can also get burned by requesting an alternate assembly that doesn't exist on a downlevel machine. For example GDI+ 1.1 requires Vista or later, or MSXML 4 on XP.
Thanx for the reminder. In the past, I've always warned about that with XP-destined apps. Kinda let that slip a bit since XP is no longer supported by Microsoft. But, since people still use XP ... an apt reminder. I'll need to include that in this app's help strings on next update. Updated my comments in my previous post should they be viewed by others.
Edited: Possible workarounds in such cases...
1. Build different deployment versions of your app where each are targeted for a specific range of O/S and manifest adjusted for the O/S
2. With the GDI+ v1.1 example and other like-scenarios... Build your app with the GDI+ v1.1 option in the embedded manifest. Deploy the app along with another external manifest file excluding the GDI+ v1.1 requirement. If the targeted O/S is XP, place that external manifest alongside your app. If Vista or better, don't include the external manifest. XP, by default, uses external manifests and Vista or better, by default, use embedded manifests over external ones. However, I don't recall which O/S actually stopped recognizing external manifests, without registry edits, even when an embedded manifest does not exist.
3. Use external manifests only. But this can be be problematic, because on newer O/S, they are ignored by default. And making them apply requires registry edits and other annoyances. Those registry edits apply to the entire system, not just your app. This should always be a user-choice, not an app deployment choice.
Last edited by LaVolpe; May 20th, 2017 at 12:44 PM.
Insomnia is just a byproduct of, "It can't be done"
Vista switched to giving embedded manifests priority. It was meant to help stave off malware infestations based on an external manifest that substituted a hacked DLL for a system DLL used by a victim application. Manifests can do DLL redirection for standard DLLs (overriding DLL Search) separately from the SxS Assembly and reg-free COM features.
I downloaded and used this today and despite not being too sure what I was at, it worked!
It's really spruced things up.
Thanks very much for providing this, LaVolpe!
Made several changes, none really major. And added a couple of enhancements.
Changes:
- Made final choice on which name space the <trustInfo> element will be assigned to: urn:schemas-microsoft-com:asm.v3. Even though I can find Microsoft sites that use asm.v2 and others that use asm.v3, I have reviewed several Vista Windows exes and those I've reviewed all use asm.v3. Vista was the first O/S to use <trustInfo>. However, the Miscellaneous menu in the app allows you to override and toggle name space version if the need ever arises. Do note that it is possible that both versions will be displayed in the app's treeview if you are loading a manifest that uses asm.v2. In that case, unselect whichever you do not want, before exporting/saving the manifest.
Edited: I'll look at tweaking the above scenario a bit. Auto-unselecting one of them if both exist in the tree. Regardless, if the menu option to toggle the name space version is used, the 1st <trustInfo> item, if two are present, is toggled.
- Reworked the extraction and insertion routines. Major change was to allow you to select a specific manifest type: 1) standard, 2) isolation, 3) isolation without static imports or 4) first manifest found. This was needed for one of the enhancements mentioned later
Enhancements:
- Offered option to specify which manifest type (see above) should be used when saving manifest to a res file. This option is offered in the output window. Previously, one would need to go into the VB resource editor and change that value as needed.
- Offered option to extract manifests from executables (exes). This could be useful if you want to review the manifest within your own executables or within others. Though it is possible manifests can exist in ocx and dll files, the open dialog window only offers exes in its filter. If desired, simply change the file name field in the dialog, i.e., *.dll or *.ocx, for example.
- The main form's Manifest menu was changed up a bit. It does offer a way to specify which manifest type (see above) to be extracted from executables or resource files.
- When viewing the name space, via right click, of element attributes, typically you'd see: {none specified}. That has changed. No manifest attributes currently have their own name spaces. If in the future they do, it will be displayed in that pop-up menu. If any don't, then the parent's name space is displayed instead with a "[Parent]" suffix. Just prevents you having to select the parent element to see the name space.
- The output window has an option to export the entire manifest to a preview window. And the preview window was tweaked a bit to force smaller tab stops. Looks better.
Last edited by LaVolpe; Jul 20th, 2017 at 04:44 PM.
Reason: formatting
Insomnia is just a byproduct of, "It can't be done"
Thank you very much for this forum's content and all that went it.
I guess I am a VB6 has been and a reg-free novice. Has anyone, as yet, put together some instructions to guide a novice through the use of Manifest Creator II?
I have succeeded in creating the .res file and building one of my tiny apps and putting it in the install folder with 'dependency' manifest files and putting the dependency files in a Dependency sub folder and it WORKS!
I guess to do it all of the way, I must incorporate all of the 'dependency' manifest files into the .res file before building.
Would that make it complete: with the app.exe in the install folder and the dependency files in its Dependency sub folder?
Am I getting the drift? ... I guess that maybe I am: I did succeed in building my tiny test app with embedded manifest files. I did need to add to the assemblyIdentity the value: processorArchitecture="x86" for each of the dependency manifest files.
If I can remember how to repeat those steps, I can do the embedded reg-free build for Win7 and Win10.
However I believe there is something else wrong with my manifest files for MSCOMCT2.OCX, threed32.ocx and RICHTX32.OCX .
Can Manifest Creator II create manifest files for the individual dependency files?
Last edited by anderci; Sep 4th, 2017 at 12:52 PM.
My primary application is entirely registration free (aka, portable). It's also all distributed as a single executable, although quite large (189 meg at latest compile). I've got several OCX files, a handful of ActiveX DLL files, a great many Word and Excel templates, a blank Access Database, the SMPlayer movie player program, and a C3D viewer program all bundled into the application's resources. I just "unpack" those things when I need them.
Before I go on, let me say that my program always runs in somewhat unique environments (i.e., hospital settings). As such, there's no possibility of any theme-ing. Also, I insist on 100% DPI (although this drives dilettante nuts). (But the new Win10 virtualization solves this problem.) Therefore, I don't use my internal manifest file for anything other than Side-by-Side (SxS) running of my OCX files. (I use another approach to run my ActiveX DLLs without needing to register them.)
LaVolpe may correct me, but I don't believe his manifest creator is for explicitly setting up the SxS running of OCX files. I don't have to mess with this very often (as my OCX files don't change very often), but I always use a combination of MT.exe and RegSvr42.exe to dig the information out of OCX files for placing in my manifest. There are several threads around these forums that discuss this.
And I also feel a bit like I'm hijacking LaVolpe's thread by discussing it here.
If you want a variety of opinions about SxS operations (with OCX files), maybe you'd let me recommend starting a new thread over in the main "Visual Basic 6" Q&A section.
Good Luck,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
Elroy, correct. This project does not automate building SxS manifests. It is designed for automating application manifests. Though one could use this project to create a SxS manifest but that would be difficult because one would need to fill out all the XML attribute values manually, knowing which ones to add to the manifest. This project was not designed for automating SxS manifests and don't ever expect it will be. The closest it comes is its ability to load an existing SxS manifest, edit it, and export it.
I think there should be a FAQ page or Tutorial on ways to create SxS manifests correctly and completely. That FAQ/Tutorial could include custom tools others have designed and/or usage of existing APIs and/or Windows apps.
Insomnia is just a byproduct of, "It can't be done"
Thank you both for responding. So, I should use RegSvr42.exe to build the .OCX manifest files and then use Manifest Creator II to package them all as well as the dependency (.ocx, .dll, ...) files into my VB6 build .exe ?
SxS manifests can be quite complex. Application manifests basically have elements that are entered once, though there are some that can have multiple entries. With SxS there can be several that have multiple entries and do not apply to application manifests. I wouldn't recommend using this project for creating a SxS manifest from scratch. It could be used that way if the user is very comfortable with all the XML elements that are needed and how each should be filled out. This project has very minimal support for SxS manifests -- basically useful for quickie edits of existing SxS manifests.
I started a thread in the classic VB section of the forum asking if anyone was willing to take on a SxS manifest tutorial. But even if someone jumps on it right away, it will take time to create.
Regarding any other questions about SxS manifests, suggest you start a thread in that classic VB section. You won't get the help you need in this thread. And honestly, I'd appreciate this thread not be used for that purpose.
Insomnia is just a byproduct of, "It can't be done"
In Manifest Creator, after using Create from Project File (vbp), I tried:
The Manifest > Append/Merge Manifest > From File and got the following messages:
No Action Taken
Failed to load the selected file.
Invalid at the top level of the document.
[ OK ]
No Action Taken
Failed to extract any manifest from the selected file
[ OK ]
What usually causes this rejection?
No Action Taken
Failed to load the selected file.
Invalid at the top level of the document.
That error is typically a result of the XML not being syntactically correct in the 1st couple lines. Would have to post your XML to know for sure. That error is passed by the Microsoft XML parser, not due to my code.
No Action Taken
Failed to extract any manifest from the selected file
Now this error is my code triggered by the previous error.
Edited: If a UTF8 BOM is present at the first 3 bytes of the XML, the above error occurs. The Microsoft XML library used doesn't appear to like BOMs. The tool has been modified to look for a BOM if parsing failed, remove it, then resubmit the adjusted XML. Therefore, a BOM will no longer be the source of such an error.
Last edited by LaVolpe; Oct 28th, 2017 at 03:26 PM.
Insomnia is just a byproduct of, "It can't be done"
If you run the project, copy and paste what you posted above into the Manifest Creator II, using menus: The Manifest > From Clipboard.
My gut feeling is that, as a file, there may be a BOM or some other marker on the manifest? That's just a guess. I've seen the Microsoft XML parser fail for reasons I don't understand, like a leading carriage return at top of file, for example. But when I pasted your XML into the project -- no problems. Sorry don't have an answer why it failed when you tried to upload it from file.
Edited: See post #28 comments.
Last edited by LaVolpe; Oct 28th, 2017 at 03:26 PM.
Insomnia is just a byproduct of, "It can't be done"
Yes, 'From clipboard' works smoothly.
OK, it is very critical that your VB6 project is open during all of your steps in Manifest Creator:
The Manifest
- Create from Project File (vbp)
- Append/Merge Manifest
- Export Manifest
I fell astray and was using Manifest Creator with the VB6 project closed. And then, an adventure... (details upon request)
Last edited by anderci; Sep 6th, 2017 at 09:38 AM.
1. How do you make a .res from a .manifest ? (just the big lines)
A res file is a specifically formatted file. Knowing the format is required. If no res file exists, a 32 byte header is created and the manifest is then inserted. The manifest also uses a specific 32 byte header, followed by the XML data. Its placement in the res file doesn't matter as long as it comes after the initial 32 byte header.
Originally Posted by VbNetMatrix
2. in Output option Windows, you got a typo:
>>Manifest Type for Resoruce Files Only
Yepper, should be Resource
Originally Posted by VbNetMatrix
3. why is indent not recommended for .res file ?
if it's mandated (not too) why not simply uncheck it if user select .res as output ?
Not recommend due to extra bytes added to res file that doesn't need to be there. Extra bytes are added to exe when compiled. That's only reason. As for auto-checking/unchecking. Don't want to go there. If user unselects res as output, should I re-check the box? What if user doesn't realize/see the auto-checking/unchecking? Those questions are rhetorical only.
Insomnia is just a byproduct of, "It can't be done"
My bad I think I didn't explain my thought properly... I meant "how" ?
are you using an API or did you coded yourself the subroutine to export in .res ?
although I loved the information you provided, thanks
Originally Posted by LaVolpe
Extra bytes are added to exe when compiled That's only reason.
got that now, thanks, but would it really slow down the reading since it's only a few bytes ?!
Originally Posted by LaVolpe
As for auto-checking/unchecking. Don't want to go there. If user unselects res as output, should I re-check the box?
you're right... you got the proper way. didn't thought of it that way
Originally Posted by LaVolpe
Those questions are rhetorical only.
not sure what you meant... did I offended you ? I apologize if I did, I'm only trying to understand more.
No offense taken in any of your replies. Rhetorical simply means no reply is necessary.
Regarding the writing/reading of the res file. It is like most other "chunk" related files. Each "chunk" describes how many bytes, read/write the chunk header then read/write the chunk data. Chunks can contain wildly different data from other chunks in the file. Each chunk has documentation on how it should be written/read. That is why I said "knowing the format is required".
The res file can be written/read with standard VB functions or APIs. Nothing special there other than preference to write/read in binary mode. The code I wrote myself, no APIs used other than ReadFile/WriteFile. The Microsoft executable rc.exe can create resource files. You have to provide a script for that tool and the scripting language is not too complex but can take some time to become proficient with it. I felt the res file format was easy enough to be able to read/write without use of an additional tool.
got that now, thanks, but would it really slow down the reading since it's only a few bytes ?!
Regarding indentation of the manifest... I'm old-school: don't bloat the application if not needed and if the extra stuff adds nothing to the project.
Last edited by LaVolpe; Sep 11th, 2017 at 09:07 PM.
Insomnia is just a byproduct of, "It can't be done"
thanks for all the provided information, very instructive. As yourself, I like to program myself export function in binary output.
well.. you already saw that in my failed attempt to change VB6 main font source code.
Originally Posted by LaVolpe
Regarding indentation of the manifest... I'm old-school: don't bloat the application if not needed and if the extra stuff adds nothing to the project.
I feel you man. I used to count every bytes of everything, compress my .html and .js files, etc, etc...
in database, I even used a way to "compress" date in 3 bytes without losing the first 2 digit of the year.
I don't feel that same urge today because of how fast computer have became and how annoying hard drive size are.
you're a real inspiration to me Lavolpe. Keep up the good work, hope you got some time someday to finish some of your long awaited project (AIC version 3)
Previously I have used MMM (Make My Manifest). I've just come across Manifest Creator II for the first time, have downloaded it, and am now looking at the main form (running). With MC I've found how to open a .vbp file, but from then on I'm stuck. How do I get the references to the OCX files in my VB6 program into MC? Let's just take one example from the manifest I built with MMM, RICHTX32.OCX. How do I make this dependency known to MC?
How do I get the references to the OCX files in my VB6 program into MC? Let's just take one example from the manifest I built with MMM, RICHTX32.OCX. How do I make this dependency known to MC?
This project can automate application manifests. You are describing a SxS/deployment manifest. This project does not automate those as explained in previous posts. See this tutorial for possible solutions.
Insomnia is just a byproduct of, "It can't be done"
FYI: Project modified to handle a byte-order-mark (BOM) when it exists in a manifest (file, embedded in resource, clipboard). MSXML2 DLL is used to parse manifest XML, but that library does not seem to accept the BOM. Therefore, when importing a manifest fails, the project will now look to see if a UTF8 BOM (3 bytes) precedes the XML data. If it does, it is stripped to allow MSXML2 to parse the data. However, if it is important, and it shouldn't be, the BOM is never written when the project exports a manifest.
Insomnia is just a byproduct of, "It can't be done"