Avira antiVirus

[jcfuller]

Mike,
  It's a negatory here.

It works fine with this added to the c file.
/* -------------------------------*/
/* Tiny C support for LinkRes2Exe */
/* -------------------------------*/
int dummy __attribute__ ((section(".rsrc")));
/* -------------------------------*/
and using gorc to compile the rc and Mike Hennings LinkRes2Exe to add the compiled res.

OS: Win10 64
------------------------------------------------------------------------------
SET RESTARGET=-O coff
windres -I. %RESTARGET% -i "%F%.rc" -o "%F%res.o"
'------------------------------------------------------------------------------
tcc version 0.9.26 (x86-64 Win64)
-> hellosdk.c
-> hellosdkres.o
hellosdkres.o:1: error: unrecognized file type
'------------------------------------------------------------------------------
gcc version:
gcc (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 5.2.0

hellosdkres.rc

#define MANIFEST 24
#define IDR_XPMANIFEST1 1
#define IDR_VERSION1 1

IDR_XPMANIFEST1 MANIFEST "xpmanifest.xml"

IDR_VERSION1 VERSIONINFO
FILEVERSION 1,0,0,0
PRODUCTVERSION 1,0,0,0
FILEOS 0x00000004
FILETYPE 0x00000000
BEGIN
  BLOCK "StringFileInfo"
  BEGIN
    BLOCK "FFFF0000"
    BEGIN
      VALUE "FileVersion", "1.0.0.0\0"
      VALUE "ProductVersion", "1.0.0.0\0"
    END
  END
  BLOCK "VarFileInfo"
  BEGIN
    VALUE "Translation", 0xFFFF, 0x0000
  END
END


Manifest file


<?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="*"
   name="Company.Product.Name"
   type="win32"
/>
<description></description>
<dependency>
   <dependentAssembly>
      <assemblyIdentity
         type="win32"
         name="Microsoft.Windows.Common-Controls"
         version="6.0.0.0"
         processorArchitecture="*"
         publicKeyToken="6595b64144ccf1df"
         language="*"
      />
   </dependentAssembly>
</dependency>
</assembly>


James

[Mike Lobanovsky]

James,

Try adding an explicit specification of COFF target platform to ensure windres.exe compiles a 64-bit object file, like this:

windres -I. %RESTARGET% -F pe-x86-64 -i "%F%.rc" -o "%F%res.o"

That's however a TDM-GCC spec and frankly, I've no idea whether it's gonna work with your vanilla MinGW installation. I'm not using 64 bits and/or Win 10 so often as to be 100% sure about anything there.

I would also suggest trying their W.I.P. TCC v0.9.27 from their git mob branch instead of the older v0.9.26 because:

1. It provides a civilized VS2015 solution instead of the medieval batch files; and

2. In the three years that have passed since v0.9.26, grishka could've fixed this issue if it's really a 64-bit TCC/COFF compatibility problem rather than 64-bit windres.exe/COFF glitch.

32-bit windres.exe has compiled Windows resources for my TCC v0.9.25 faultlessly for years.


P.S. BTW what is all that #define bloat for in hellosdkres.rc? Aren't a couple of 1's and a 24 simpler, faster and more elegant than all this preprocessor verbosity? This could've also spared you a couple milliseconds or more of your precious life each time you recompile the resources.

P.P.S. You could've used scripted ResHacker alone to the exact same effect instead of the three stages you're using now -- "Tiny C support ...", GoRC, and LinkRes2Exe, with an added bonus of having 100% correct checksum in the resultant PE header field that TCC omits unless its tccpe.c is fixed with a corresponding MapFileAndCheckSumA() call.

[jcfuller]

Mike,
  Thanks for the effort and info.
I thought I would try it to see if it worked with 64bit and it did not.
I really have no interest to explore any further.

James

[Mike Lobanovsky]

I really have no interest to explore any further.

Hmm James,


I must admit I'm not sure now what was really there behind your question but when I'm talking business, business is what I mean.

Below please find a zip with everything you'll ever need to use WINDRES.EXE for linking Windows resources with your 64-bit TCC executables: compilers, sample resources, BAT files, and stuff.


Regards,

.

[Charles Pegge]

Thanks Mike,  for all your suggestions and crc code for PE files.

[jcfuller]

Mike,
  First test using the NUWEN distro worked fine but your example comes in at 160k
Yes I know it's the icon!!
Can we get away with no icon or one much smaller and still get an A++ rating from VirusTotal scan?

When I said I had no interest, it was in building a 0.9.27 tcc 64bit version just to do a little testing.
The 9.26 I have was prebuilt.
Is there a prebuilt windows 64bit 0.9.27 for download or did you build it yourself?
 Thanks again,
James

[Mike Lobanovsky]

Yes James,

The exe size is entirely the icon's contribution. It was the first free icon I came across when googling for "Hello" icons on the net.

You can use any Windows .ICO file in any size and/or resolution and/or composition. WINDRES.EXE will add an appropriate matching ICONGROUP resource automatically.

As for A++, in almost all cases a manifest and a version info will be sufficient. Yet the executables compiled with TCC bear their own distinct "signatures" that can help distinguish them from others, compiled with the more mature compilers like VC or GCC which are apparently on the AV permanent exclusion lists. (you can see that MinGW/TDM binaries themselves carry no Windows resources and nonetheless aren't provoking false AV alarms: low end AV software usually parasitizes on malware databases of other, more intelligent anti-viral packages)

Thus, every 32-bit executable compiled with TCC would bear, a few bytes away from its main entry point, a sequence of automatically generated empty NOP and LEA ESI, [ESI] instructions, apparently for code alignment purposes, which will be sufficient to unambiguously identify it as a TCC creation.

I used yesterday's most recent mob branch zip download (see tcc_git.png below) to rebuild this TCC from scratch in my VS2013. I also have VS2015 CE installed but my VS2013 is a licensed Ultimate so I prefer to use it whenever I can. You can use the VS2015 solution from the zip for that verbatim; the only alteration you need is to reset both projects' properties from the v140 to v120 toolset used in VS2013 (see solution_props.png below).

This solution however lacks a few things to compile a functional TCC package out-of-the-box (which is no surprise for a Linuxoid project, hehe):

• first off, add manually a config.h file to the root directory of your download that would contain only the following two lines:

Code: C

1. #define TCC_VERSION "0.9.27"
2. #define ssize_t unsigned long

• compile the tcc.exe and libtcc.dll binaries from within your Visual Studio. Make sure the targets are set for x64 Release. My compilation went OK without a warning. The binaries will also be automatically copied to the \win32 directory
• this isn't however a working package yet. You will also need TCC's own libraries and tools and a full set of includes to match, as a post-build step. Assuming you have a functional  MinGW/GCC or TDM-GCC or NUWEN installation, run the following batch file from within the \win32 directory where tcc.exe/libtcc.dll now reside. It will build TCC tools and libraries and it will also replenish the \win32\include directory with the common includes from the root directory of your download:

Code: [Select]

@set target=-DTCC_TARGET_PE -DTCC_TARGET_X86_64
@set CC=gcc -m64 -Os -s -fno-strict-aliasing
@goto tools

:tools
%CC% %target% tools/tiny_impdef.c -o tiny_impdef.exe
%CC% %target% tools/tiny_libmaker.c -o tiny_libmaker.exe

:libtcc
if not exist libtcc mkdir libtcc
copy ..\libtcc.h libtcc\libtcc.h
%CC% %target% -shared -DLIBTCC_AS_DLL -DONE_SOURCE ../libtcc.c -o libtcc.dll -Wl,-out-implib,libtcc/libtcc.a
tiny_impdef libtcc.dll -o libtcc/libtcc.def

:copy_std_includes
copy ..\include\*.h include
copy ..\tcclib.h include
copy ..\tests\libtcc_test.c examples

:libtcc1.a
.\tcc %target% -c ../lib/libtcc1.c
.\tcc %target% -c lib/crt1.c
.\tcc %target% -c lib/wincrt1.c
.\tcc %target% -c lib/dllcrt1.c
.\tcc %target% -c lib/dllmain.c
.\tcc %target% -c lib/chkstk.S

:lib64
.\tcc %target% -c ../lib/alloca86_64.S
tiny_libmaker lib/libtcc1.a libtcc1.o alloca86_64.o crt1.o wincrt1.o dllcrt1.o dllmain.o chkstk.o

:the_end
del *.o


Copy my WINDRES.EXE I sent you (it's a TDM-GCC 5.1.0 tool) alongside tcc.exe/libtcc.dll (or add your own if it's equally functional) et voila! you now have a portable distro of latest TCC that can link Windows resources to the TCC-generated executables.

Have a Merry Christmas and a Happy Coding New Year!



.

[Charles Pegge]

Hi Mike,

I've been scrutinisong your crc code above, and comparing it with the standard crc-32 algorigthm, there appears to be an error in the crc32_table function

Code: [Select]

      unsigned long ulPolynomial = 0x04c11db7;
     
      register int i;
      for (i = 0; i <= 0xff; i++) {
        crc32_table[i] = reflect(i, 8) << 24;
     
        register int j;
        for (j = 0; j < 8; j++)
          crc32_table[i] =
            (crc32_table[i] << 1) ^ (crc32_table[i] & (1 << 31) ? ulPolynomial : 0);
        crc32_table[i] = reflect(crc32_table[i], 32);
      }
    }

The final reflect should be in the outer loop. Thus:

Code: [Select]

      unsigned long ulPolynomial = 0x04c11db7;
     
      register int i;
      for (i = 0; i <= 0xff; i++) {
        crc32_table[i] = reflect(i, 8) << 24;
     
        register int j;
        for (j = 0; j < 8; j++)
          crc32_table[i] =
            (crc32_table[i] << 1) ^ (crc32_table[i] & (1 << 31) ? ulPolynomial : 0);
        }
        crc32_table[i] = reflect(crc32_table[i], 32);
   }

Do you agree?

[Mike Lobanovsky]

No Charles,

I can't agree with your placement of curly braces while your verbal interpretation seems correct.

My code simply uses the inner loop written in a one-liner notation; CRLFs do not break a C language code line.

Final reflection is applied to each successive ith element of the table as a post-bit shifting/xoring step after the inner loop has been run for this particular ith element. Please consider a more canonical notation below:

Code: C

1. ........
2.       register int i;
3.       for (i = 0; i <= 0xff; i++) {
4.         crc32_table[i] = reflect(i, 8) << 24; // init ith element with a reflected value of i
5.      
6.         register int j;
7.         for (j = 0; j < 8; j++) {
8.           // bitshift it step-wise and xor it with the polynomial
9.           crc32_table[i] = (crc32_table[i] << 1) ^ (crc32_table[i] & (1 << 31) ? ulPolynomial : 0);
10.         }
11.  
12.         crc32_table[i] = reflect(crc32_table[i], 32); // reflect its final value again
13.       }
14. ........

Multiple variations of this code with and without reflection found on the net would depend on the interpretation of this polynomial as a MSB/LSB value and would differ from one another in the order of operators used according to the rules of precedence in a particular language implementation. After all, it's only the resultant bit sequence that matters. And it will appear the same regardless of the language, if the initial assumption and corresponding choice of instruments are correct.

This code comes directly from FBSL v3.5 sources where it is used for the implementation of BASIC Checksum() routine and own zlib compatible ZIP compression/decompression Deflate()/Inflate() routines, and also for recomputing PE header checksums after the user script has been embedded in the FBSL executable stub. In other words, it's been field tested and proven functional over quite some time.

[Charles Pegge]

Thanks Mike,

My IQ diminishes in the afternoon! Is coffee a remedy?

Here is a more pedantic, though verified o2 version:

Code: [Select]

  int reflect(int r,n)
  {
  xor edx,edx
  mov cl,n
  .ri
   dec cl
   jl fwd ni
   mov eax,r
   and eax,1
   jz fwd nd
    mov eax,1
    shl eax,cl
    or edx,eax
   .nd
   shr r,1
   jmp ri
  .ni
  mov eax,edx
  return
  }

  'print hex ( reflect (0x2,32), 8)

  'http://wiki.osdev.org/CRC32
  'https://www.lammertbies.nl/comm/info/crc-calculation.html

  int t[0x100]
  void init_crc32_table(int*t)
  {
  int a,i,j
  % Polynomial = 0x04c11db7
  for i=0 to 255
    t=reflect(i,8)
    t=t<<24
    for j=0 to 7
      a=t and 0x80000000
      t=t<<1
      if a then t xor= Polynomial
    next
    t = reflect(t, 32)
    @t+=4
  next
  }

  init_crc32_table t

  'def v +", "+mid(hex(t[%1],8),-8)
  'print "crctable... " v 0 v 1 v 2 v 255

  int crc32(sys p,le)
  {
   byte b at p
   int v
   byte i
   int crc=0xffffffff
   while le
     le--
     i=crc xor b
     v=t[i]
     crc=(crc>>8) xor v
     @b++
   end while
   return not(crc)
  }

  'string s="A" 'crc32 should be: D3D99E8B
  'string s="a" 'crc32 should be: E8B7BE43
  string s="123456789" 'crc32 should be: CBF43926
  print hex crc32 strptr s, len s


[Mike Lobanovsky]

Hi Charles,

Looks pretty neat and should be blazing fast once the table is initialized.

[Charles Pegge]

Hi Mike,

crc32 looks a lot better in pure assembler. After all, the algorithm was originally designed for hard-wiring in silicon

For instance bit reflection reduces to iterations of:

shl edx,1 'shift left (msb shifted into carry flag)
rcr eax,1 'rotate thru carry right. Carry flag shifted into msb

Code: [Select]

  'CRC-32
  =======
  'http://wiki.osdev.org/CRC32
  'https://www.lammertbies.nl/comm/info/crc-calculation.html

  int crc32_table[0x100]
  '
  void init_crc32_table()
  {
  % Polynomial = 0x04c11db7
  addr esi,crc32_table
  xor edi,edi
  .ri
   cmp edi,255
   jg ni
   '
   'reflect8
   mov ecx,8
   xor eax,eax
   mov edx,edi
   .rf8
    shl dl,1
    rcr eax,1
    dec ecx
   jg rf8
   '
   mov ecx,8
   .rj
    dec ecx
    jl fwd nj
    shl eax,1
    jnc rj
    xor eax,Polynomial
   jmp rj
   .nj
   '
   'reflect32
   mov ecx,32
   mov edx,eax
   xor eax,eax
   '
   .rf32
    shl edx,1
    rcr eax,1
    dec ecx
   jg rf32
   '
   mov [esi],eax
   add esi,4
   inc edi
   jmp ri
   .ni
  }
  init_crc32_table

  int crc32(sys p,le)
  {
   mov ecx,le
   mov esi,p
   mov eax,0xffffffff
   addr edi,crc32_table
   .ri
    dec ecx
    jl fwd xi
    mov edx,eax
    xor dl,[esi]
    and edx,0xff
    shr eax,8
    xor eax,[edi+edx*4]
    inc esi
    jmp ri
   .xi
   not eax
   return
   '
  }

  'tests
  'string s="A" 'crc32 should be: D3D99E8B
  'string s="a" 'crc32 should be: E8B7BE43
  'string s="123456789" 'crc32 should be: CBF43926
  'print hex crc32 strptr s, len s


[Mike Lobanovsky]

Cool!

GCC doesn't understand Intel asm, and it's a real PITA to write GCC's inline AT&T where there's no direct register notation but rather read/write "attributes" only (or are they called "properties"? ... too lazy to check; I'm currently under Win 10) that also have their own queer "syntax" into the bargain. Not worth the effort at all, though there were some pieces of code like DLL call/DynC/DynAsm interfaces where inline AT&T really proved to be approx. 50% faster than GCC's own va_calls, at least in GCC 4.3.3.

[Charles Pegge]

There is an option for Intel notation, but you still have to interface your variables: %1 %2 %0 etc

gcc -masm=intel myprog.c

Code: [Select]

// gcc -masm=intel asmtest.c
//
// http://stackoverflow.com/questions/199966/how-do-you-use-gcc-to-generate-assembly-code-in-intel-syntax
// http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
// http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

#include <stdio.h>

int main(int argc, char *argv[])
{
  int a=0;
  int b=101;
  int c=102;
  // a=b+c
  asm
  (
    "mov eax, %1;"
    "add eax, %2;"
    "mov %0, eax;"
    : "=m" (a)          // output
    : "m" (b), "m" (c)  // operands "m" from memory : "r" load to register first
    // : "eax","ecx"    // clobbered registers
  );
  printf("a = %d\n", a);
  printf("b = %d\n", b);
  printf("c = %d\n", c);
  return 0;
};


[Mike Lobanovsky]

Not in GCC 4.3.3, Charles.