Announcement

Collapse
No announcement yet.

Filecopy

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Filecopy

    I have a problem with FILECOPY

    If I go
    Code:
    FILECOPY "abc.xyz", "mno.pqr"
    Then it works

    But if I go
    Code:
    FILECOPY "abc.exe","xyz.ghi"
    then the program hangs. And the only way I can stop it is with Task Manager

    So the problem seems if the FILECOPY source program is a *.exe

    The file that I am trying to copy is a program (obviously) but is not launched

    The problem exists no matter which *.exe file is the source file

    The funny thing is that this worked when the routine was in a larger program. It stopped working when I made it in its own program. it is actually a set of 9 FILECOPY's all copying *.exe into a different name

    Windows 10 and latest PBCC

    Thanks

    Kerry
    [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
    Kerry Farmer

  • #2
    Kerry,
    I don't see the problem here. This works:

    Code:
    Function PBMain
       FileCopy "gbvideo.exe", "test.abc"
    End Function
    Does this match what you're doing?

    Comment


    • #3
      Is abc.exe running?
      Dale

      Comment


      • #4
        I'd suspect AV software interfering with an application trying to access an .exe file. (Renaming executables is a common virus tactic)

        Have you tried it with your AV software disabled?

        Comment


        • #5
          OK here too,
          PBCC PBWIN Windows7 and Windows10.
          I'd suspect AV as well. (Also test when run as admin?)
          Code:
          #Compile Exe        ' PBCC604 , PBWin1004
          #Dim All
          #If %Def(%PB_CC32)
           #Break On
          #EndIf
          #Include "win32api.inc"
          '------------------/
          
          Function PBMain () As Long
          
            Filecopy "Noname-3.exe", "Du.mmy"       ' .exe in current folder
          
            ? error$,,"FileCopy"
          
          #If %Def(%PB_CC32)
            ? "Any key to exit"
            WaitKey$
          #EndIf
          End Function
          '------------------/
          Rgds, Dave

          Comment


          • #6
            Kerry,

            The only solution is to change the settings in your AV scanner, if this is one you own machine, its not a problem but its for a customer on another computer, you may have to change the design of your app to avoid the problem. With an installation of mine, I have to test if the AV stops writing and reading an executable and stop the installation if it does otherwise the real junk end of AV scanners just silently delete the executable files and break the whole application.
            hutch at movsd dot com
            The MASM Forum

            www.masm32.com

            Comment


            • #7
              Thank you

              You are all absolutely right

              I use Nortons

              Turn Nortons off and it works!

              It is a program for distribution - so I need a solution. It is late at night now - but tomorrow I will try a NAME to make it a non .exe file, copy it, and then NAME it back to a .exe file.

              Plan B is to change the design of the system!

              Thank you to all (again!)

              Kerry
              [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
              Kerry Farmer

              Comment


              • #8
                Does you application have a Manifest? Is it signed? Both can help with getting AV to allow it to do things.

                Comment


                • #9
                  The whole thing seems very capricious.

                  I have been playing with my code

                  Sometimes it works and sometimes Nortons jumps in - depending on the structure of the program.

                  it is disappointing that Nortons just hangs - and does not print out a meaningful message
                  [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                  Kerry Farmer

                  Comment


                  • #10
                    Kerry,

                    Stuart's suggestion is important, without both a manifest and version control block you risk triggering some junky AV scanner warning. I personally do them through a resource file RC script but there is a notation in the current versions to do both.

                    This is what an XML manifest file looks like. In a RC script you call it as follows.

                    1 24 "manifest.xml"

                    This is the content of the manifest.
                    Code:
                    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
                    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
                    <description>Your Application Description</description>
                    <dependency>
                    <dependentAssembly>
                    <assemblyIdentity
                    type="win32"
                    name="Microsoft.Windows.Common-Controls"
                    version="6.0.0.0"
                    processorArchitecture="X86"
                    publicKeyToken="6595b64144ccf1df"
                    language="*"
                    />
                    </dependentAssembly>
                    </dependency>
                    </assembly>
                    This is what a version control block looks like.
                    Code:
                    VS_VERSION_INFO VERSIONINFO
                    FILEVERSION 1,0,0,0
                    PRODUCTVERSION 1,0,0,0
                    FILEOS 0x00000000
                    FILETYPE 0x00000001
                    BEGIN
                      BLOCK "StringFileInfo"
                      BEGIN
                        BLOCK "040904B0"
                        BEGIN
                          VALUE "CompanyName", "Your name here\000\0"
                          VALUE "FileDescription", "Basic API Template\000\0"
                          VALUE "FileVersion", "1.0\000\0"
                          VALUE "InternalName", "YourWin\000\0"
                          VALUE "OriginalFilename", "YourWin.exe\000\0"
                          VALUE "LegalCopyright", "\251 2014 Your name here\000\0"
                          VALUE "ProductName", "YourWin\000\0"
                          VALUE "ProductVersion", "1.0\000\0"
                        END
                      END
                      BLOCK "VarFileInfo"
                      BEGIN
                        VALUE "Translation", 0x0409, 0x04B0
                      END
                    END
                    One of the members who use the normal PB technique should be able to help you here if you don't normally use RC scripts.
                    hutch at movsd dot com
                    The MASM Forum

                    www.masm32.com

                    Comment


                    • #11
                      Originally posted by Steve Hutchesson View Post
                      Kerry,

                      Stuart's suggestion is important, without both a manifest and version control block you risk triggering some junky AV scanner warning. I personally do them through a resource file RC script but there is a notation in the current versions to do both.

                      This is what an XML manifest file looks like. In a RC script you call it as follows.

                      1 24 "manifest.xml"

                      This is the content of the manifest.
                      Code:
                      ...
                      This is what a version control block looks like.
                      Code:
                      ...
                      One of the members who use the normal PB technique should be able to help you here if you don't normally use RC scripts.
                      For "the normal PB technique", the manifest would be included by a line:

                      #RESOURCE MANIFEST, 1, "manifest.xml"

                      the Version info would be included by a line

                      #RESOURCE VERSIONINFO followed by a series of #RESOURCE VERSION$ .... lines

                      It's all explain thoroughly in Help under #RESOURCE metastatement







                      Comment


                      • #12
                        I have attached a simple test piece that has both a manifest and version control block. In the XML file you change the <description>popup application</description> to your own text and with the version info, just use the ones you want. You test them with Explorer, right click on the exe and select Properties.

                        Code:
                        ' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
                        
                            #compile exe "kerry.exe"
                            #option largemem32
                            #include "\basic\include\win32api.inc"
                        
                            #RESOURCE MANIFEST, 1, "manifest.xml"
                        
                            #RESOURCE VERSIONINFO
                            #RESOURCE STRINGINFO "0409", "0000"     ' << US English, ascii char set
                        
                            #RESOURCE VERSION$ "Comments",         "Additional info"
                            #RESOURCE VERSION$ "CompanyName",      "PowerBASIC Inc."
                            #RESOURCE VERSION$ "FileDescription",  "My Application"
                            #RESOURCE VERSION$ "FileVersion",      "1.0.0"
                            #RESOURCE VERSION$ "InternalName",     "App By Kerry"
                            #RESOURCE VERSION$ "LegalCopyright",   "Copyright 2018 PB Inc"
                            #RESOURCE VERSION$ "LegalTrademarks",  "My App (r)"
                            #RESOURCE VERSION$ "OriginalFilename", "MyApp.exe"
                            #RESOURCE VERSION$ "PrivateBuild",     "Nope"
                            #RESOURCE VERSION$ "ProductName",      "My App"
                            #RESOURCE VERSION$ "ProductVersion",   "1.0.0"
                            #RESOURCE VERSION$ "SpecialBuild",     "Nothing special here"
                        
                        ' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
                        
                         FUNCTION PBmain as LONG
                        
                            MessageBox 0,"Manifest and version control block","How D",%MB_OK
                        
                         End FUNCTION
                        
                        ' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
                        Attached Files
                        hutch at movsd dot com
                        The MASM Forum

                        www.masm32.com

                        Comment


                        • #13
                          Thanks Stuart and Steve

                          I shall spend some time on that

                          Is it foolproof across all AV's?
                          [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                          Kerry Farmer

                          Comment


                          • #14
                            Nothing is "foolproof" regarding AV's

                            AV producers keep changing the way they try to identify malicious software. The use heuristic methods which they keep changing to stay up with the bad guys. Apart from actual code signatures, they apply all sorts of other cumulative "weights" to different factors (known only to them). If those "weights" add up to a high enough score, your application will be flagged.

                            All you can say is that the absence of a manifest and VI block will almost certainly tilt your application further towards the "malicious" cut off. If it is doing things like manipulating other exe files, it will be treated as even higher risk. What weighting the AV scanner gives to these two and other factors is known only to the producers.

                            Comment


                            • #15
                              Excuse my naivety!!!

                              How do I know that this solution has worked?
                              [I]I made a coding error once - but fortunately I fixed it before anyone noticed[/I]
                              Kerry Farmer

                              Comment


                              • #16
                                Kerry,

                                You can test your exe on sites like Jotti to see if the junky end of AV scanners drop false positives. If you really have to you can advise your client that they should set their AV to accept your application but its better not to have to. Virus/trojan) writers are a bunch of cockroaches at best and like many others I am suspicious about AV writers for exactly the same reason.

                                You can get a look at what is shown with the version control block from Explorer, that will tell you what shows up.
                                hutch at movsd dot com
                                The MASM Forum

                                www.masm32.com

                                Comment

                                Working...
                                X