Jump to content
scintilla4evr

CompileIt - an experimental AutoIt-to-machine code compiler

Recommended Posts

Hi. 

I have Code Blocks installed and nothing much to do with it... :(

Welcome to Code::Blocks 13.12!
Code::Blocks is a full-featured IDE (Integrated Development Environment) aiming to make the individual developer (and the development team) work in a nice programming environment offering everything he/they would ever need from a program of that kind.
Its pluggable architecture allows you, the developer, to add any kind of functionality to the core program, through the use of plugins...

I get this error when compiling the Hello, World!.c ...

#include "#1 - Hello, World!.h"

// Globals

// Script entry
int main() {

au3_consolewrite(string_variant(L"Hello, World from machine code AutoIt!"));


return 0;
}
______________________________
Build log:

mingw32-gcc.exe   -c "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.c" -o "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o"
mingw32-g++.exe  -o "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.exe" "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o"   
C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o:#1 - Hello, World!.c:(.text+0x16): undefined reference to `string_variant'
C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o:#1 - Hello, World!.c:(.text+0x22): undefined reference to `au3_consolewrite'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 0 warning(s) (0 minute(s), 0 second(s))

Perhaps the ChakraCore.dll is in the wrong place? 

Skysnake

Edited by Skysnake

Skysnake

Why is the snake in the sky?

Share this post


Link to post
Share on other sites
43 minutes ago, Skysnake said:

Perhaps the ChakraCore.dll is in the wrong place? 

Okay, so the ChakraCore.dll has nothing to do with the actual C code compilation process - it's used to execute the parser used to convert AutoIt code to C. You got the resulting C code, so ChakraCore had done its job.

And with the build, the reason why it doesn't work is the fact that the C files from CompileIt's include/ directory had not been compiled with the input source code.

So, I would recommend using the CompileIt.exe for compiling those scripts.

But if you find Code::Blocks more comfortable, just add the files from CompileIt's include/ directory to your project. The build should continue just fine.

Edited by scintilla4evr

Share this post


Link to post
Share on other sites

:)

Got this far

-------------- Build: Debug in CompileItExample (compiler: GNU GCC Compiler)---------------

mingw32-gcc.exe -Wall -g  -c "C:\AutoIt\CompileIt\project\#1 - Hello, World!.c" -o "obj\Debug\#1 - Hello, World!.o"
mingw32-gcc.exe -Wall -g  -c C:\AutoIt\CompileIt\project\AutoItFuncs.c -o obj\Debug\AutoItFuncs.o
C:\AutoIt\CompileIt\project\AutoItFuncs.c: In function 'au3_stringlen':
C:\AutoIt\CompileIt\project\AutoItFuncs.c:32:5: warning: passing argument 1 of 'wcslen' from incompatible pointer type [enabled by default]
     return int_variant(wcslen(vt.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:133:40: note: expected 'const wchar_t *' but argument is of type 'int *'
 _CRTIMP size_t __cdecl __MINGW_NOTHROW wcslen (const wchar_t*);
                                        ^
C:\AutoIt\CompileIt\project\AutoItFuncs.c: In function 'au3_stringreverse':
C:\AutoIt\CompileIt\project\AutoItFuncs.c:38:5: warning: passing argument 1 of 'wcsrev' from incompatible pointer type [enabled by default]
     return string_variant(wcsrev(vt.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:185:42: note: expected 'wchar_t *' but argument is of type 'int *'
 _CRTIMP wchar_t* __cdecl __MINGW_NOTHROW wcsrev (wchar_t*);
                                          ^
C:\AutoIt\CompileIt\project\AutoItFuncs.c: In function 'au3_stringcompare':
C:\AutoIt\CompileIt\project\AutoItFuncs.c:44:5: warning: passing argument 1 of 'wcscmpi' from incompatible pointer type [enabled by default]
     return int_variant(wcscmpi(vt1.data_ptr, vt2.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:173:29: note: expected 'const wchar_t *' but argument is of type 'int *'
 int __cdecl __MINGW_NOTHROW wcscmpi (const wchar_t * __ws1, const wchar_t * __ws2);
                             ^
C:\AutoIt\CompileIt\project\AutoItFuncs.c:44:5: warning: passing argument 2 of 'wcscmpi' from incompatible pointer type [enabled by default]
     return int_variant(wcscmpi(vt1.data_ptr, vt2.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:173:29: note: expected 'const wchar_t *' but argument is of type 'int *'
 int __cdecl __MINGW_NOTHROW wcscmpi (const wchar_t * __ws1, const wchar_t * __ws2);
                             ^
mingw32-gcc.exe -Wall -g  -c C:\AutoIt\CompileIt\project\CompileIt.c -o obj\Debug\CompileIt.o
C:\AutoIt\CompileIt\project\CompileIt.c: In function 'variant_getstring':
C:\AutoIt\CompileIt\project\CompileIt.c:86:9: warning: return makes pointer from integer without a cast [enabled by default]
         return *((wchar_t*)vt.data_ptr);
         ^
mingw32-g++.exe  -o bin\Debug\CompileItExample.exe "obj\Debug\#1 - Hello, World!.o" obj\Debug\AutoItFuncs.o obj\Debug\CompileIt.o   
Output file is bin\Debug\CompileItExample.exe with size 53.05 KB
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 5 warning(s) (0 minute(s), 0 second(s))

My cbp project file

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
	<FileVersion major="1" minor="6" />
	<Project>
		<Option title="CompileItExample" />
		<Option pch_mode="2" />
		<Option compiler="gcc" />
		<Build>
			<Target title="Debug">
				<Option output="bin/Debug/CompileItExample" prefix_auto="1" extension_auto="1" />
				<Option object_output="obj/Debug/" />
				<Option type="1" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-g" />
				</Compiler>
			</Target>
			<Target title="Release">
				<Option output="bin/Release/CompileItExample" prefix_auto="1" extension_auto="1" />
				<Option object_output="obj/Release/" />
				<Option type="1" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-O2" />
				</Compiler>
				<Linker>
					<Add option="-s" />
				</Linker>
			</Target>
		</Build>
		<Compiler>
			<Add option="-Wall" />
		</Compiler>
		<Extensions>
			<code_completion />
			<envvars />
			<debugger />
			<lib_finder disable_auto="1" />
		</Extensions>
	</Project>
</CodeBlocks_project_file>

which results in

compileIt.png

:):):):):):):):):):):):):):):):):):):):):):):)

You rock man!

Skysnake

 

Edited by Skysnake

Skysnake

Why is the snake in the sky?

Share this post


Link to post
Share on other sites

Well done,
So this potentially will have faster execution times to what it can support so far ...
Was looking to see something like this already done !

Thanks for sharing

Share this post


Link to post
Share on other sites
21 minutes ago, Deye said:

So this potentially will have faster execution times to what it can support so far

Well, according to some simple tests I performed while developing new features, CompileIt reached about 2x faster execution. But when I got to loops with a lot of iterations, it sometimes executed slower than AutoIt, because the whole thing is not optimized in any way.

But then again, let us wait and maybe things will change :)

Share this post


Link to post
Share on other sites

Development suggestion? My problem is this: the compiled EXE is so fast, its almost impossible to see it processing...  Suggested solution: include a standard "filewrite" option to write to disk during execution.  Much like AutoIt's FileWrite or FileWriteLog functions.  Then one can trace the EXE activity.

Perhaps there is a different/better solution?

:)


 

Edited by Skysnake

Skysnake

Why is the snake in the sky?

Share this post


Link to post
Share on other sites
1 hour ago, Skysnake said:

Development suggestion? My problem is this: the compiled EXE is so fast, its almost impossible to see it processing...  Suggested solution: include a standard "filewrite" option to write to disk during execution.  Much like AutoIt's FileWrite or FileWriteLog functions.  Then one can trace the EXE activity.

Perhaps there is a different/better solution?

:)


 

File manipulation/creation functions are on the to-do list, but first I want to make sure that Strings are more functional (for example, adding the & operator).

Share this post


Link to post
Share on other sites

A huge undertaking, good luck with the project @scintilla4evr!


A cross-platform implementation of the AutoIt language

My contributions to the AutoIt Community ##AutoIt at freenode, real-time chat

3fHNZJ.gif

Spoiler

If I have hurt or offended you in anyway, Please accept my apologies, I never (regardless of the situation) intend to do that to anybody.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By TheDcoder
      Hi, I thought I would never post a C/WinAPI related question in this forum ever, but here we are after a few years and me having learnt enough of C to write a basic console program
      My issue is that I am trying to read my child process's stdout output but ReadFile never returns if the child exits or if it is killed... very strange , I have been trying to work my way around this. The options I can think of are:
      Create a new thread and check for existance of the process constantly while reading Somehow make the pipe asynchronous (overlapped) so that I can read it in a non-blocking manner Fix ReadFile to return when the process ends Obviously I would prefer No. 3, I just want to make my program work. Here is my code if you guys want to take a look:
      // No text highlighting for C/C++ but we have it for C#? Blasphemy! bool allium_start(struct TorInstance *instance, char *config, allium_pipe *output_pipes) { char *cmd; // Figure out the command string for execution if (config) { char *parameters = " -f -"; cmd = malloc(strlen(instance->tor_path) + strlen(parameters) + 1); if (!cmd) return false; strcpy(cmd, instance->tor_path); strcat(cmd, parameters); } else cmd = instance->tor_path; // Prepare startup info with appropriate information SecureZeroMemory(&instance->startup_info, sizeof instance->startup_info); instance->startup_info.dwFlags = STARTF_USESTDHANDLES; SECURITY_ATTRIBUTES pipe_secu_attribs = {sizeof(SECURITY_ATTRIBUTES), NULL, true}; HANDLE pipes[2]; if (output_pipes == NULL) { CreatePipe(&pipes[0], &pipes[1], &pipe_secu_attribs, 0); output_pipes = pipes; } instance->startup_info.hStdOutput = output_pipes[1]; instance->startup_info.hStdError = output_pipes[1]; instance->stdout_pipe = output_pipes[0]; // Stored for internal reference if (config) { // Reuse the pipes array to store standard input pipes CreatePipe(&pipes[0], &pipes[1], &pipe_secu_attribs, 0); instance->startup_info.hStdInput = pipes[0]; } // Create the process bool success = CreateProcessA( NULL, cmd, NULL, NULL, config ? true : false, 0, NULL, NULL, &instance->startup_info, SecureZeroMemory(&instance->process, sizeof instance->process) ); // Free command string if needed if (config) free(cmd); // Write config to Tor's standard input unsigned long bytes_written; if (success) { WriteFile(pipes[1], config, strlen(config), &bytes_written, NULL); // Work around for simulating Ctrl + Z which sends the substitution character (ASCII 26), // this is needed in order for Tor to detect EOT/EOF while reading the config WriteFile(pipes[1], &(char){26}, 1, &bytes_written, NULL); } CloseHandle(pipes[1]); // Return on failure if (!success) return false; } char *allium_read_stdout_line(struct TorInstance *instance) { char *buffer = instance->buffer.data; // Check for valid buffer and allocate if needed if (instance->buffer.size == 0 || !buffer) { buffer = instance->buffer.data = malloc(instance->buffer.size = 80 + 1); if (!buffer) return NULL; } // Process the input unsigned int read_len = 0; while (true) { // Read data unsigned long bytes_read; if (ReadFile(instance->stdout_pipe, buffer, 1, &bytes_read, NULL) == false || bytes_read == 0) return NULL; // Check if we have reached end of line if (buffer[0] == '\n') break; // Proceed to the next character ++buffer; ++read_len; // Resize buffer if it is full if (read_len == instance->buffer.size) { char *new_buffer = malloc(instance->buffer.size += 50); if (new_buffer) memcpy(new_buffer, instance->buffer.data, read_len); free(instance->buffer.data); if (!new_buffer) return NULL; instance->buffer.data = new_buffer; buffer = instance->buffer.data + read_len; } } // Terminate the new line with null character and return // Special handling for Windows, terminate at CR if present buffer[read_len >= 2 && buffer[-1] == '\r' ? -1 : 0] = '\0'; } The allium_start function creates the redirection pipes and the child process, the other allium_read_stdout_line function reads from the stdout pipe created by the first function, ReadFile in this function does not return when the child ends or gets killed.

      I appriciate the help of the WinAPI gurus here, thanks in advance!
    • By argumentum
      AutoIt Machine Code Algorithm Collection
      By Ward, November 11, 2010 in AutoIt Example Scripts 
      Posted November 11, 2010 (edited) I have already published a lot of AutoIt UDF about algorithm, but all of them only support 32 bits or so called X86 system. Recently I got a computer with Windows 7 64 bits, so I finally added X64 support to most of my old projects. Besides, I also added some new. For example, some compression algorithm and SHA3 Candidates.
      Following are the algorithms list:
      Checksum   CRC16   CRC32   ADLER32 Compression   FastLZ   LZF   LZMA   LZMAT   MiniLZO   QuickLZ Encode   Base64   ARC4   XXTEA   DES   AES Hash   Checksums (CRC16/CRC32/ADLER32)   MD2   MD4   MD5   SHA1   SHA2 (SHA224/256/384/512)   SHA3 Candidates     BLAKE     BMW (Blue Midnight Wish)     CUBEHASH     ECHO     SHABAL     SKEIN Some points to mention:
      All of the subroutines have one or more examples to demonstrate the usage. Since the function and usage of subroutine are easy to understand. A complete subroutines and parameters list are unavailability now. Sorry for my lazy. All of the subroutines here invoked by Lazycat's method (through CallWindowProc API). My MemoryDLL UDF is not necessary this time. Although MemoryFuncCall (part of MemoryDLL) is still good, but inevitably, it is slower than CallWindowProc. Some subroutines have the same name with my old machine code version UDF. But for some reason, I rearrange the position of the parameters. Please not mix up. If you notice, yes, checksums are duplicated. But they receive different parameters. One is the old style, and another use the same interface as other hashes. Choose what you like, but don't use them in the same time. Some algorithm already supported by the standard UDF "Encryption.au3". But I still provide them, because some system lack of the full support of Windows Crypt Library. If you are looking for only one hash algorithm, for example, used in encryption, I suggested "SHABAL_TINY.au3". Although it is a bit slower then SHABAL, but it is smaller, and it supports different size of output (from 32 to 512 bits).
    • By Dreamfire
      Hi,
      Since today, exe's are being flagged as having a trojan by Windows Defender (Fuery.B!cl)
      Version:  3.3.14.3 - SciTE Version 3.7.3



       

    • By Earthshine
      So, I made this console app--using TreeWalkers of course to walk the UI Tree-- that starts at the root and looks for enabled, active controls--and in piping that to a file, I got this (edited, lots of controls in that list), above. LOL, so, those commands that are stored in memory are control elements! Sweet. this UIAutomation stuff is awesome. @junkew got me into this, blame his IUIAutomation kit. So there is this OLD vb OCX that is super ornery, but his kit can manipulate it, even if it is just SendKeys, So I must build a C# wrapper of my own... LOL this stuff is so cool. I have tried TestStack.White and MANY other wrappers, they seriously suck, no support either.
      I used canned Microsoft example code too for the most part. This is an extreme for me though, our modern stuff I can test easily enough, but I want my own kit to use to discover and poke around with. I like to use the IUIAutomation tool as a sanity check too, it's very useful.
       
    • By scintilla4evr
      This is an experimental AutoIt-to-machine code compiler, written in AutoIt, JavaScript and C.
      Make sure you have GCC installed and configured within CompileIt before using.
×
×
  • Create New...