Just a guess, but from the error message (Cannot be run in DOS mode), it sounds like by inserting data into the binary, you are changing the offsets of the subsequent PE format sections, but failing to adjust the appropriate offsets within the PE header.

Hence, when NTLDR attempts to load the executable image by following the now mis-sized offsets, it fails to locate the appropriate sections, and so rejects it with a generic error message indicating that it does not recognise, or cannot make sense of the format of the file.

To correct this would require you to parse the header, figure out which section offsets come after the position where you are inserting your xml, and adjust them by the amount you insert. There is the additional complication that the offsets have to be aligned to certain boundaries. I'm not sure whether these would be 4-byte, 8-byte or conceivably even page-sized boundaries under Vista. Conceivably it could be processor size (32-bit -v- 60-bit dependant. You would need to find a document describing the latest (Vista compatible) definition of the PE executable format. I have previously found these to be available on-line, but depending where you get it, it may or may not be complete description.

Like I say, just a semi-informed guess.

Hi BrowserUK,

Many thanks for the info. I'm googling on it now.

Yesterday I fumbled with the number of whitespaces behind the xml (reducing the whitespaces for the number of chars added).

The mt.exe does all the math for c++ files however for the pdk compiler mt.exe doesn't seem to be fully compliant.

Now in parallel on a colleague's hunch I'm busy applying the "mt.exe -manifest ExeName.exe.manifest -outputresource:ExeName.exe" line to all perl and pdk executables and dlls.

The idea is that possibly some of these pe's are compiled into the perlapp.exe. However I don't put much faith in this idea.

I'll keep you posted.

Many thanks so far for the great pe info!

With kind regards.

DDN

in parallel on a colleague's hunch I'm busy applying the "mt.exe -manifest ExeName.exe.manifest -outputresource:ExeName.exe" line to all perl and pdk executables and dlls.

Actually, I think that could work.

Baring in mind I've never use perlapp and I've only the vaguest notion of what mt.exe actually does.

It seems likely that the manifest checking would not work when you run the distributable .exe resulting from perlapp processing, as (I assume) that is a standalone, all-in-one distributable. It's only when all the bits and pieces of that file are unpacked and decompressed, one of which will be perl.exe and the latter gets run, that the manifest will be checked. Is the right version of perl5x.dll available? Ecetera.

So, theoretically thinking, if you apply mt.exe to everything in your \perl\bin directory, along with all the dlls that are in perl\lib\auto\*\*.dll and perl\site\lib\auto\*\*.dll; and if running the script passes the validation prior to being packaged, it should also pass validation after it's be packaged and unpacked.

Again, that purely a thoughware suggestion.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

<?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="X86"
     name="script.exe"
     type="win32"/>

  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>
[download]

Hi Rob, Just tried out your suggestion. Unfortunately as of Win2003 and now also on Vista, if an internal manifest exists this is executed and any external manifest is ignored. Once I have "manifested" all the exe's from the pdk & perl. (I'm especially thinking of the perl.exe). I'll run a last test. If this doesn't do the trick. I'll post it with a link to this page on ActiveState Thanks anyway! With kind regards. DDN

• "\Perl\bin\perl.exe"
• "\Perl\bin\perl5.8.6.exe"
• "\Perl\bin\perlglob.exe"
• "\Perl\bin\wperl.exe"

• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\netcheck.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pai.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pai_icons.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pdkcheck.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pdklib.dll"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\perl58.dll"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\scineplex.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\tkkit.dll"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\vbsperlui.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\vpmd.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\pdkdebug.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlapp.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlctrl.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\PerlDB.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlfb.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\PerlNH60.dll"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlsvc.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perltray.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\plc.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\vbsperl.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\bin\vpm.exe"
• "\Program Files\ActiveState Perl Dev Kit 6.0\lib\auto\MSI\Util\Util.dll"
• "\Program Files\ActiveState Perl Dev Kit 6.0\lib\auto\Win32\Cabinet\Cabinet.dll"

Dear PerlMonks, Following quote from Mark Minasi at link: WindowsITpro Article 96375 explains this behaviour.

"Or what about the small-but-essential fact that adding an external manifest to a legacy program in hopes of solving a User Account Control compatibility problem works sometimes but not always, thanks to a glitch in the disk-caching algorithm?"

I guess we'll just have to wait praying that the next Vista Service Pack solves this issue.

Regards.
DDN123456