Recently Browsing 0 members
No registered users viewing this page.
Hi AutoIT Masters,
Sorry again but Just want to know if you have any idea why the AutoIT scripts converted into 32-bit.exe files are being deleted by AV but not 64-bit.exe. If we raise it to the AV whitelisting, they come back saying it is false positive.
I disabled AV and everything goes well.
OS: Windows 10 - 64 bit
Thanks for the help.
here is a Autoit3 v220.127.116.11, 64 Bit installation on windows 10 with current updates.
In a simple script I'm Dllcall'ing a 64 bit dll.
# T1.au3 Local $name = "T1DLL.dll" if (FileExists($name)) Then ConsoleWrite("DLL '" &$name &"' exists" &@CRLF) EndIf Local $DLL = DllOpen($name) if (@ERROR OR $DLL = -1) then ConsoleWrite("DllOpen ERROR=" &@ERROR &" DLL=" &$DLL &@CRLF) Else ConsoleWrite("DllOpen Success" &@CRLF) endif DllCall($DLL, "none:cdecl", "SomeFunction", "str", "DLL Call from T1.au3") if (@ERROR) then ConsoleWrite("DllCall ERROR=" &@ERROR &" DLL=" &$DLL &@CRLF) Else ConsoleWrite("DllCall Success" &@CRLF) endif The C code contains one 64 bit OpenCV call: cv::destroyAllWindows();.
Excuting T1.au3 with SciTE gives:
If the c code is compiled *without* the OpenCV call T1.au3 runs successful:
I checked T1DLL.dll, it's definitely a 64 bit dll.
What could cause the problem?
Any hint would be very much appreciated.
Searching and searching but I'm unable to find anyone with a proper solution. I see a lot of similar questions on this topic, but nothing that really provides what I'm looking for.
Basically, I just want to convert a 8 byte hex value to unsigned integer. I.e. "FFFFFFFFFFFFFFFF". I'm working on SNMP opaque data types, and UINT64 values end up as signed INT64 when I use the internal processing of AutoIt. (Yeah, I know, this is because AutoIt always uses signed)
Example ( I know you guys love example code snippets haha, so here's a two-liner):
$sUINT64 = "FFFFFFFFFFFFFFFF" ConsoleWrite( Dec($sUINT64) ) -1 is not the result I want, of course.
And I don't want "1.84467440737096e+019" either by adding manually in AutoIt. I need the decimal value (as a string) of 264 = 18,446,744,073,709,551,616
Anyone got a clever UDF for this? Or will I have to write one myself, adding and multiplying each hex value, and generating a text string as a result? I know how it can be done, I just hoped someone already had done it so I could steal their code.
I'm having a problem creating a 64 bit exe using Aut2Exe. I'm running on a Windows 7 64 bit PC and OS.
If I compile my test script using a right click on the test script I can successfully create a 32 bit or a 64 bit exe. I can easily check this by looking at the properties of the exe, compatibility settings where, for the 64 bit exe compatibility settings "below" Vista are not available whereas, for the 32 bit exe they are.
If I compile using Aut2Exe (running it from a non-compiled au3 script) then, using the method above, both the 32 bit and 64 bit builds appear to actually be 32 bit exes. The file, MakeTest.au3 is attached.
If I try to do the same build using the command line input for Aut2Exe I can build the 32 bit version OK but the 64 bit build returns the error "Unable to read in AutoIt stub file. (AutoItSC.bin)". Surely it should be looking for AutItSC_x64.bin if I use the /x64 switch shouldn't it?
If I try to run Aut2exe_x64 from the command line I get the "not recognised as an internal or external command" message.
However, double clicking on Aut2exe_x64 and using the UI that's displayed I do get a 64 bit version built.
I'm very confused - I really need to use a script to compile both 32 and 64 bit versions as the whole thing is part of an automatically built installation "application". Can anyone make sense of it for me or ami I just being stupid?
This is a Wrapper for Pugixml, made with C++ by me and uses the version 1.2.
pugixml is a light-weight C++ XML processing library. It consists of a DOM-like interface with rich traversal/modification capabilities, an extremely fast XML parser which constructs the DOM tree from an XML file/buffer. pugixml enables very fast, convenient and memory-efficient XML document processing. However, since pugixml has a DOM parser, it can't process XML documents that do not fit in memory; also the parser is a non-validating one, so if you need DTD or XML Schema validation, the library is not for you.
The Xml parser(Pugixml) is distributed under the MIT license:
This means that you can freely use pugixml in your applications, both open-source and proprietary.
Load/save XML files to an in-memory document object model (DOM). Add name/value attribtes to nodes. Numerous methods for iterating over the nodes in a document. Built in XPath. Full Unicode support. MsXml Independent. Has about 47 Functions.Works on: Microsoft Windows 2000, XP, Server 2003, Vista, 7, Server 2008. 32 bit
Not supported any more due the fact that I had a hard drive failure therefore lost the source code of the DLL.
Note: I have also included a 64bit DLL but as I don't have a 64bit computer it remains untested.