The manifest file (abt.exe.manifest) controls aspects of a VAST application’s appearance.

The look and feel of the VAST Platform(VA Smalltalk) application is controlled by a manifest file that has the same file name/ext as the runtime executable, but with a .manifest suffix (<appname>.exe.manifest). VAST Platform ships with abt.exe.manifest which does this for the development environment. The inclusion of a manifest file defers decisions about some GUI appearance elements to Windows, so basically, if the file exists, you should get the current look of the Windows level you are running on. If not, you should get the older look and feel.

With the widespread use of high DPI, VA Smalltalk programs, some pre-9.2.2 VA Smalltalk applications did not show well on Windows 10 and later. Changing the property of the executable (<appname>.exe) Property changes are stored in the Windows registry and take precedence over the manifest (<appname>.exe.manifest) settings.

Beginning in VAST 9.2.2, the with abt.exe.manifest shipped with VAST Platform (VA Smalltalk) causes User Interface Components to be aware of HiDPI settings in Windows.

Some users have experienced an inconsistent ability to retain the Windows XP look and feel of their VA Smalltalk applications on newer Windows platforms such as Widows 7+. Other users have not seen HiDPI disabled (aka the VAST image is unaware of HiDPI) in their image after altering the manifest to disable HiDPI. Why is the manifest not behaving as described here?

If you completely removed the manifest file, or re-introduced it, the following describes the situation

Windows caches the information related to a manifest file, and if it has done so, does not look for and read an existing manifest file again, presumably until a reboot, but that is not always the case. The work-around is to touch the .executable file (<appname>.exe) so that the modified date/time is changed. This seems to trick Windows into reading the existing manifest file again.

Here is a link to a free open source touch application that runs on Windows:

There is a set of utilities at the following link that can help you diagnose this issue. In particular, the ManifestUtils\TraceManifestLoading.cmd app can be used to verify when a manifest file is loaded and when it is not:

If you edit the manifest (e.g. abt.exe) file to turn on/off then. The best workaround is just change the creation date of the .exe (e.g. abt.exe) which makes Windows believe it's new, and therefore invalidates the cache and causes Windows to read the abt.exe.manifest file.

One way to do this is to open a command window and execute e.g. copy /b abt.exe +,, or whatever your executable is named. This touches the file with the current date and time.

To recache a manifest file, see http://csi-windows.com/blog/all/27-csi-news-general/245-find-out-why-your-external-manifest-is-being-ignored

If the properties of your <appname>.exe. have been customized, those properties (recorded in the Windows Registry) take precedence over the settings in <appname>.exe.manifest.

The property is settable on Windows 10. To the pertinent properties in abt.exe, open the Properties and click on the Compatibility tab. Clock on “Change high DPI settings” button to open a dialog . Notice the “Override high DPI scaling behavior. Scaling performing by:” check box. In order to work properly, this should be