Leaderboard

Has anyone looked at setting up parellel 3.3.8 and 3.3.10 environments? This might be useful for replying to problems/questions.

AutoIt v3.3.10.0 has been released. Big thanks to everyone involved in this release, including past and present contributors, beta testers, moderators and MVPs. It really is a massive group effort! There's still a lot to do in future releases, but at least we have got a stable release out there that we can build on There are too many changes and fixes to list here, but some highlights include: 90+ bugs fixes and additions to the main AutoIt executables. 90+ bug fixes and additions to the user defined functions (UDFs). Much improved Unicode support within the regular expression engine for non-English character sets. Extensive AutoItX changes, including an easy to use .NET Assembly interface and a set of PowerShell CmdLets. Download it here. Complete list of changes: History

Please check _SQLite_Startup for the $iForceLocal parameter. BTW if the application is going to be distributed in a corporate environment, you may prefer to FileInstall the DLL. Then you better user x86 compile to be compatible with x86 & x64 OSes.

The main reason why ability to #include a3x-es was added was to move number of built-in functions from compiled binaries (raw .bin interpreters used by the compiler) into precompiled private au3 files. The idea was to extend and use pragmatic directives to "include" needed precompiled files/functions. To me it never made sense why compiled executable should include all built-in functions even though they were never used by user's code. Considering AutoIt is dllcall capable and also since some time works with all kind of objects either late or early bound, all preconditions for the idea were made. Really large number of functions can be taken out of the binary stub with no performance hits. Functions like Beep, Mouse..., Reg..., Tcp, Udp, and tens of others which aren't any faster because of being part of the binary code. Of course that some functions can't be taken out, for example Adlibs or some that do lots of calculation like Pixel-whatever but large number of others are very good candidates. Anyway, the idea was to do something like this: #pragma use(socket) TCPStartup() ;... ...and in case of au3 script which is run by AutoIt.exe TCP functions would be built-in (even not necessary) and in case of compiled executable Aut2Exe would add needed a3x code with functions written for it in simple easily maintainable AutoIt code. This way the size of compiled executables would really depend just on set used functions plus absolute minimum interpreter needs and wouldn't have burden of unnecessary code. Pragma directive would be mandatory for code that uses Execute or some other run-string function, but for "normal" code it can even be dropped out because compiler can detect used functions itself.

I agree. I'm always wary of exe bloat and try and keep it to a minimum. I used to have a rule that the AutoIt.exe couldn't be more than 100KB compressed. But features add size in the current architecture and that's why I resist features when a UDF is acceptable. It's always a balance - not one that I always get right either. Yeah, that was the whole point of .a3x along with a super-permissive license for redistributing autoit3.exe. If I were distributing lots of files it's how I would do it. I don't have the skill or the time to create a proper compiler so that's all I've got. It's always been compiled with every file shrinking option that can be done. We don't have any exceptions/c++ stream features enabled - and we don't use any of the STL classes. The initial compile is done in "minimize size" mode which gives: 850KB (Visual Studio 2012) 820KB (2010) One of the biggest increases in size this release was because we had too many bugs in the math functions (we were using bespoke assembly code for all these functions since 2003) and we finally had to use the VC runtime ones to fix things - this instantly added 60KB, ouch, but at least it's fixed and other future math functions won't mess up or add more size. Even compiled without the VC runtime in static mode it is 666KB - so still in the "people will moan" territory and not worth the hassle of making everyone install the VC runtimes. You'll notice that the current release exe is actually 70KB bigger than I mention above. That's because we then run it through a few common operations and use the Visual Studio tools to analyse performance and then recompile the hotspot functions for speed. The resulting file sizes between the different compilers vary wildly at this point and generally the latest compiler tends to perform better. VC 2010 in this mode gives a much much bigger exe than 2012 and it's about the same speed (a touch faster). This 70KB vs the speed boost is another aspect to weigh up - the perf boost significant enough that I choose to use it. We also add a far bit of bloat when we reduce bugs. We tend to use a lot of string classes and smart pointers in new code and this is totally worth it to reduce those impossible to find bugs that haunt AutoIt for years. Many of the bugs fixed this release were due to some buffer overrun or buffer miscalculation, especially when different people are touching the same source. When old functions are revisited they tend to get the same treatment. Totally worth it IMO. Supporting older OSes also adds some KBs - not much but 10's of KBs. We have to check for, and dynamically load functions, and perform cleanup afterwards. We have wrapper functions that allow this to be done in an easy way but they are all C++ classes that add a little size because they perform various checks and auto-clean up in as hassle free (and bug free) manner possible. In general I try to stick with an OS level that is under MS support which usually (not always) corresponds to the latest compiler level. At the moment we are going one step beyond that in supporting XP RTM and adding some ugly compiler hacks to allow this. 3.3.12.0 will be changed to XP SP3 which will remove another set of these dynamic functions. I rambled on a bit there, but thought some of the internals might be of interest.

The simple answer is no.

thanks for sharing I will look for this in new year, now I try to had a holiday Thanks I also cared, so I called TeamViewer and I talked about it about half a year ago. As you can see listen to my advice. Moreover, I reported to them, about 10 comments and problems, including one very important from the point of view of data security. Do not be afraid does not apply to data security. Just what is happening with the system clipboard, in case if it is open several sessions at the same time. I do not know if you noticed but in version 8 to version 9 TeamViewer and storage system is transferred automatically between sessions, regardless whether TeamViewer window is active or not. Independently from that session is open to all sessions always have access to the system clipboard all connected workstations. Data are transferred simply everywhere in all directions without any taboos.

press ctrl+F1 to get the SciTE4AutoIt3 helpfile

The #ForceRef directive is used by AU3Check and is documented in the AUtoIt3 Helpfile. (use the search to find it) The other directives are part of SciTE so can be found in the SciTE4AutoIt3 helpfile. Jos