News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

fpu function needed

Started by bsdsource, January 07, 2014, 01:16:04 PM

Previous topic - Next topic

bsdsource

With #include "\masm32\include\resource.h" in my resource file I still needed to define the 2 I had mentioned.

dedndave

ok - you need the updated version, is all

not sure where to get it - lol
i thought it was up to date with masm32 v11

at any rate, it's like the "windows.inc" of resource files
it defines most of the standard things like "MFT_CHECKED"
you should put it in all your resource files, actually

it doesn't increase size to the EXE file

bsdsource

I'm probably using an older masm32 release. Looks like I'll have to upgrade.  :biggrin:

dedndave

my typical resource file looks like this.....

;#####################################################################################

;StarMap - Resource File - DednDave, 1-2015

;#####################################################################################

#include "\masm32\include\resource.h"

#ifndef  RT_RCDATA
#define  RT_RCDATA                           10
#endif

#ifndef  CREATEPROCESS_MANIFEST_RESOURCE_ID
#define  CREATEPROCESS_MANIFEST_RESOURCE_ID  1
#endif

#ifndef  RT_MANIFEST
#define  RT_MANIFEST                         24
#endif

#ifndef  VS_VERSION_INFO
#define  VS_VERSION_INFO                     1
#endif

#ifndef  VOS_NT_WINDOWS32
#define  VOS_NT_WINDOWS32                    0x00040004L
#endif

#ifndef  VFT_APP
#define  VFT_APP                             0x00000001L
#endif

;*************************************************************************************

#define  IDI_ICON               501

;#####################################################################################

IDI_ICON       ICON    DISCARDABLE  "StarMap.ico"

;#####################################################################################

; manifest file

CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "StarMap.xml"

;#####################################################################################

; file version info

VS_VERSION_INFO VERSIONINFO
FILEVERSION     1,0,0,0
PRODUCTVERSION  1,0,0,0
FILEOS          VOS_NT_WINDOWS32
FILETYPE        VFT_APP
{
  BLOCK "StringFileInfo"
  {
    BLOCK "040904E4"
    {
      VALUE "CompanyName",      "DednDave\000"
      VALUE "FileDescription",  "StarMap\000"
      VALUE "FileVersion",      "1.0\000"
      VALUE "LegalCopyright",   "\251 2015 David R. Sheldon\000"
    }
  }
  BLOCK "VarFileInfo"
  {
    VALUE "Translation", 0x409, 0x4E4
  }
}

;#####################################################################################


that way, whether they assemble with the new or old version of resource.h, the symbols are defined   :t

dedndave

see if this version of resource.h is bigger than the one you are now using
if so, it's more up to date...

http://www.masmforum.com/board/index.php?topic=12791.0

bsdsource

I was looking at the resource file I had and it was dated 2004, so yes it appears I don't have the newest 2009 version. Thanks for pointing out the updated version.

Another interesting resource file example can be found below:

Microsoft VERSION info resource example


I'm attaching my new source code which includes the executable as well.

dedndave

great   :t

the MSDN page doesn't really tell you which parts may be left out of the version control block
it's hard to say - i just know what works - lol
i do know that all entries aren't required

you might google around for more info

Tedd

Quote from: dedndave on March 16, 2015, 02:13:56 PM
icc INITCOMMONCONTROLSEX <sizeof INITCOMMONCONTROLSEX,ICC_WIN95_CLASSES>

INVOKE  InitCommonControlsEx,offset icc


those will be required if the program is to work with a manifest under XP   :t
without them, the window will not appear
A simple call to InitCommonControls is all that's needed.
Amusingly, it does nothing and doesn't even necessarily need to be executed. Its purpose is to ensure the common controls dll has been loaded in your process; the manifest specifies which version of common controls is to be used.


Quote from: dedndave on March 17, 2015, 12:57:51 PM
the MSDN page doesn't really tell you which parts may be left out of the version control block
it's hard to say - i just know what works - lol
i do know that all entries aren't required
The following are required: CompanyName, FileDescription, FileVersion, InternalName, OriginalFilename, ProductName, ProductVersion.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa381058%28v=vs.85%29.aspx
Potato2

dedndave

that's what i meant about the MSDN page

i've used many without the InternalName, OriginalFilename, ProductName, and ProductVersion
seem to work fine

Tedd

I should have said "The following are officially required"
Obviously the program itself works perfectly well with any/all/none; what minimal specific fields a particular AV opts to check (if any, they could simply check versioninfo is present), is down to them.
Potato2

dedndave

i guess, if i were writing such a test, i'd look for a company name and/or author

at any rate, thanks for pointing out the "right" way, Tedd
i may modify my future RC files
adding 4 items seems pretty painless   :P

dedndave

;#####################################################################################

; file version info - use 040904E4 for ANSI apps, 040904B0 for UNICODE apps

VS_VERSION_INFO VERSIONINFO
FILEVERSION     1,0,0,0
PRODUCTVERSION  1,0,0,0
FILEOS          VOS_NT_WINDOWS32
FILETYPE        VFT_APP
{
  BLOCK "StringFileInfo"
  {
    BLOCK "040904E4"
    {
      VALUE "CompanyName",       "DednDave\000"
      VALUE "FileDescription",   "StarMap\000"
      VALUE "FileVersion",       "1.0.0.0\000"
      VALUE "InternalName",      "StarMap\000"
      VALUE "LegalCopyright",    "\251 2015 David R. Sheldon\000"
      VALUE "OriginalFilename",  "STARMAP.EXE\000"
      VALUE "ProductName",       "DednDave StarFlight Utilities\000"
      VALUE "ProductVersion",    "1.0.0.0\000"
    }
  }
  BLOCK "VarFileInfo"
  {
    VALUE "Translation", 0x409, 0x4E4
  }
}

;#####################################################################################

bsdsource

Did some more testing since there was additional feedback. I made the following changes:



  • removed the manifest from my resource file
  • added the required VERSION information that Tedd said was required


No false positive detection with Avast. If I removed either OriginalFilename or ProductName from my resource file Avast triggers a false positive. So now I don't have to have a manifest but need at least OriginalFileName and ProductName added to my resource file to avoid a false positive. No problems if I remove ProductVersion. I find it very strange though.


dedndave

testing with one AV probably isn't conclusive

use one of the multiple online scanners

http://www.virscan.org/

another...

https://www.metascan-online.com/

bsdsource

Good call on the online scanners. So I got some false positives using the online scanners, and this was with everything included in the code in addition to Tedd's input. At this point I'm just sending in my file to each software company that detected my program as harmful. Here's a good website that has direct links to submit false positives:

https://www.opswat.com/blog/what-do-i-do-if-engine-detects-my-safe-file-threat