Manifest

[TimStone]

I see some discussion here on using a .manifest file. In the past I always linked in one, but more recently it was easy to skip it. Instead of an external one in distribution, I simply included it in my .rc file. Reviewing discussions, that seems to be good.

Posts would suggest that current manifest files should include "a lot of things", but for what purpose is not explained. Apparently it is open ground for discussion by some groups relative to the use of them with Win 10 or 11.

So, I would like to know the current advice on including a .manifest file, should it be linked internally, and what should it consist of. A search of this forum seems to not provide a discussion of when, where, how to use them ... except some specific issues.

I'd love some input on this. Thanks.

[Silvio.Falconi]

I see some discussion here on using a .manifest file. In the past I always linked in one, but more recently it was easy to skip it. Instead of an external one in distribution, I simply included it in my .rc file. Reviewing discussions, that seems to be good.

Posts would suggest that current manifest files should include "a lot of things", but for what purpose is not explained. Apparently it is open ground for discussion by some groups relative to the use of them with Win 10 or 11.

So, I would like to know the current advice on including a .manifest file, should it be linked internally, and what should it consist of. A search of this forum seems to not provide a discussion of when, where, how to use them ... except some specific issues.

I'd love some input on this. Thanks.

I correctly use the one provided with the fwh package, in my case of the famous dialog viewtopic.php?f=3&t=42287&start=0 where part of the say and tgroup controls was hidden it was because I used the TRANSPARENT clause to the DIALOG, removed this the dialog worked well it may be that there is a bug to the RADIO MENU class which hides part of the say controls

[TimStone]

Silvio,

I asked the question because the only manifest files in the latest release of FWH seem to be outdated based on the few comments elsewhere in this forum.

They also have one for Windows 10, and 2 for Windows generic with 32 bit and 64 bit.

Perhaps we can have these reviewed and updated to use with Windows 10/11, both 32 bit and 64 bit. The second one is most important since my builds in the future, like Microsofts applications, will be 64 bit programs.

Tim

[Silvio.Falconi]

Silvio,

I asked the question because the only manifest files in the latest release of FWH seem to be outdated based on the few comments elsewhere in this forum.

They also have one for Windows 10, and 2 for Windows generic with 32 bit and 64 bit.

Perhaps we can have these reviewed and updated to use with Windows 10/11, both 32 bit and 64 bit. The second one is most important since my builds in the future, like Microsofts applications, will be 64 bit programs.

Tim

I tried to use the manifest for Windows 10 both the one provided by fwteam and others that I found on other industry forums.

In some procedures I found difficulties such as controls that did not work as they should.

then another quesion....since the first versions of fw I have always understood that fivewin creates windows or makes them create directly to the operating system, if it is really true excuse me for the round of words then because in win 10 or win 11 the style of the windows and Are the dialogs always in the style of win 7 or even win XP?

That is, I am afraid that fivewin does not exactly inherit the style of Windows otherwise what I wrote above is not explained. I am making a software and the main window has the style of Win 10, the dialogs and the child windows have the style of win 7 ....

how do you explain it?

I not believe the cause Is of manifest....

[TimStone]

When attempting to generate a program with a .mak file, using the recommended library, I get errors if I include a Manifest ( using the samples in 22.06 ). If I do not include the manifest, I do not seem to have errors, but perhaps I'm missing something.

If I use Visual Studio 2022 Community, and it's IDE, to build the program, it has it's own internalized manifest embedded in the code. So not using an external manifest seems to work.

Of course I still have the issue with the checkbox builds in 64 bit, but since distributions are created with a .mak file, and that doesn't have the problem, I'll deal with that separately.

So perhaps we don't actually need a manifest file ? Sometimes I see that we need to reference it ( when advice is given ), but I'm not sure why. I was hoping someone could explain it's purpose here.

[Jimmy]

hi,

have a look "into" Manifest Files

c:\fwh64\samples\winxp\WindowsXP.Manifest

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

c:\fwh64\samples\winxp\WindowsXP.Manifest64

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

c:\fwh64\samples\winxp\Windows10.Manifest

Code: Select all  Expand view

<assembly manifestVersion="1.0"
   xmlns="urn:schemas-microsoft-com:asm.v1"
   xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">

the Windows10.Manifest begin with "other" than XP Version

so i "begin" with XP.Manifest64 and add "Rest"

---

this is my Manifest for 64 Bit

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
       version="1.0.0.0"
       processorArchitecture="amd64"
       name="FiveTech Software.FWH64.FiveWin"
       type="win32"
    />
description>FWH64 for Harbour/xHarbour</description>
    <dependency>
       <dependentAssembly>
          <assemblyIdentity
             type="win32"
             name="Microsoft.Windows.Common-Controls"
             version="6.0.0.0"
             processorArchitecture="amd64"
             publicKeyToken="6595b64144ccf1df"
             language="*"
          />
       </dependentAssembly>
    </dependency>

    <application xmlns="urn:schemas-microsoft-com:asm.v3">
       <windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
           <dpiAware>true</dpiAware>
       </windowsSettings>
    </application>

    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <!-- Windows 10 -->
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
            <!-- Windows 8.1 -->
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
            <!-- Windows 8 -->
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            <!-- Windows 7 -->
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
            <!-- Windows Vista -->
            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
        </application>
    </compatibility>

    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <!--
                  UAC settings:
                  - app should run at same integrity level as calling process
                  - app does not need to manipulate windows belonging to
                    higher-integrity-level processes
                  -->
                <requestedExecutionLevel
                    level="asInvoker"
                    uiAccess="false"
                />  
            </requestedPrivileges>
        </security>
    </trustInfo>

</assembly>

[Antonio Linares]

Dear Jimmy,

If we try to use your manifest file instead of the one provided with FWH, I get:

* Application successfully built *
No se pudo iniciar la aplicación; la configuración en paralelo no es correcta. Consulte el registro de eventos de la aplicación o use la herramienta sxstrace.exe de la línea de comandos para obtener más detalles.

Using FWH provided manifest for 64 bits then builds and works fine

[Jimmy]

hi Antonio,

when you look at Property "Details" of EXE can you see "FileDescription"

i use different Settings in *.RC

Code: Select all  Expand view

1 24 WindowsXP.Manifest64

1 VERSIONINFO
FILEVERSION 0,0,1,27
PRODUCTVERSION 1,0,0,0
FILEOS 0x4
FILETYPE 0x1
{
 BLOCK "StringFileInfo"
 {
  BLOCK "040904b0"
  {
   VALUE "FileDescription", "Fivewin TGrid() Demo 64 Bit\000"
   VALUE "FileVersion", "0.4.8.74"
   VALUE "InternalName", "TGRID\000"
   VALUE "LegalCopyright", "Copyright 1983-2022 Yiu-Software\000"
   VALUE "LegalTrademarks", "Harbour"
   VALUE "OriginalFilename", "TGRID.EXE"
   VALUE "CompanyName", "Yiu-Software"
   VALUE "ProductName", "TGRID\000"
   VALUE "ProductVersion", "1.0.0.0"
   VALUE "Comments", "Created by Auge & Ohr\000"
  }
}

BLOCK "VarFileInfo"
{
 VALUE "Translation", 0x0409, 1252
 }
}

AUGEOHR    ICON   RES\OHR2.ICO
MYLOGO     BITMAP RES\AUGE_OHR.bmp
MYAAAA     BITMAP RES\TRANSPAR.bmp
VIEWSMALL  BITMAP RES\VIEW_CHOOSE.BMP
VIEWREPORT BITMAP RES\VIEW_DETAILED.BMP
VIEWICON   BITMAP RES\VIEW_ICON.BMP
VIEWLIST   BITMAP RES\VIEW_MULTICOLUMN.BMP

[Antonio Linares]

Dear Jimmy,

> when you look at Property "Details" of EXE can you see "FileDescription"

Only if you include a VERSIONINFO in your RC file

[Enrico Maria Giordano]

I use just these without any problems:

32bit

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>
</assembly>

64 bit

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>
</assembly>

[Jimmy]

hi Antonio,

Only if you include a VERSIONINFO in your RC file

this is what i do

[Jimmy]

hi Enrico,

this is the "Standard" WindowsXP.Manifest for
32 Bit

Code: Select all  Expand view

processorArchitecture="x86"

64 Bit

Code: Select all  Expand view

processorArchitecture="amd64"

---

i recommend to use "DPIAWARE" so it will NOT depend on Windows "Scale"

also "compatibility" (GUID for supportedOS) and "trustInfo" should be IHMO in Manifest

[Silvio.Falconi]

I use just these without any problems:

32bit

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>
</assembly>

64 bit

Code: Select all  Expand view

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>
</assembly>

thanks...interesting the difference



could you tell me why in win 10 I have two types of windows?
the main is win 10 style and the child is win 7 style why?

[Jimmy]

hi Silvio,

could you tell me why in win 10 I have two types of windows?
the main is win 10 style and the child is win 7 style why?

it is "by Design of xBase" ...

same is under Xbase++ and HMG that MDI Client have Windows 7 Style

---

as i remember i have use a "Trick" with Codejock Skinframework which also work on MDI Client

[Silvio.Falconi]

hi Silvio,

could you tell me why in win 10 I have two types of windows?
the main is win 10 style and the child is win 7 style why?

it is "by Design of xBase" ...

same is under Xbase++ and HMG that MDI Client have Windows 7 Style

---

as i remember i have use a "Trick" with Codejock Skinframework which also work on MDI Client

why doesn't this happen in other programming languages? sample Delphi