要是能建议au3的作者再缩小一下解释器的体积就好了

gto250

要是能建议au3的作者再缩小一下解释器的体积就好了，au3支持dllcall，其实完全留个dllcall的解释器就好了，其他的函数都做成UDF的形式，这样子，编译的程序体积一定会很小！

netegg

自己解决呗，把所有要用的函数的定义存在一个文件里，就调用一个就行了

rchockxm

比起 ahk 的確是大多了

gto250

自己解决呗，把所有要用的函数的定义存在一个文件里，就调用一个就行了
netegg 发表于 2009-10-30 21:49

再那样，编译好的文件还是大的，AutoItSC.bin和AutoItSC_x64.bin就已经很大了，我说的解释器体积就是这个

破帽遮颜

au3简单易学就是靠这~
如果单纯的想使用api,建议别用au3了!别的软件不更强大吗?

kn007

我也觉得太大了。。。毕竟没必要的功能也加进去，害我尽量多创建控件，以够本。。。

make2855

同感，我觉得DLLCALL能实现的函数没必要包含在解释器里面，但是au3的官方UDF实在是让人感到无奈，比如我只要用其中一个函数，它会把数个文件一起包含进去，比如我要用 _GUICtrlListViewCopyItems 这一个函数，那么就要包含 "GuiListView.au3"，"ListViewConstants.au3"，"GuiHeader.au3"，"Array.au3","Memory.au3","WinAPI.au3","StructureConstants.au3","SendMessage.au3","UDFGlobalID.au3",这还没把他们各自包含的文件算进去。所以体积大小剧增。可能会更加划不来，而且，速度很慢。而且，au3的dllcall 还是不很方便。

maxkingmax

你可以在编译前，使用　SCITE编辑器　自带的　代码精简工具（ALT+F6）这样只剩下所用的UDF到代码中了，应该可以缩小体积！

gto250

同感，我觉得DLLCALL能实现的函数没必要包含在解释器里面，但是au3的官方UDF实在是让人感到无奈，比如我只要用其中一个函数，它会把数个文件一起包含进去，比如我要用 _GUICtrlListViewCopyItems 这一个函数，那么就 ...
make2855 发表于 2009-10-31 16:01

可以使用脚本精简的工具啊，而且这些都是文本类的内容，用压缩壳压缩的话压缩体积比例还是比较高的,就如同vc等编译一样，只不过au3多了个解释器而已，只要将au3的解释器做的足够小，那不管脚本怎么样体积变化也不会太大

kn007

同意楼上的，另外8楼的XD给我了点启示。。。

make2855

我觉得干脆象FreeBasic那样的编译成机器码多好,不过那就不是au3了,也许au4会这样,哈哈

auto

SCITE编辑器 1.77未找到有精简工具 alt+F6也不是精简功能

gto250

SciTE
汉化版本 1.78

kn007

其实就是Obfuscator（代码迷惑，使用 /striponly参数）

thesnow

要是能建议au3的作者再缩小一下解释器的体积就好了，au3支持dllcall，其实完全留个dllcall的解释器就好了，其他的函数都做成UDF的形式，这样子，编译的程序体积一定会很小！






http://lwc.nhome.cn/code/ ...
gto250 发表于 2009-10-30 21:05

除非必要的函数,官方已经没有再新添加这类函数了.
如果去掉,估计很多脚本都无法使用.
每次脚本中断(script break,脚本破坏性)修改都骂声一片.说新版本兼容性不好.

简单易用,和文件大小控制很是两难.

PS:
1.我写脚本大多无界面的.
2.UPX压缩只是压缩解释器
3.脚本压缩是AU3作者原创的压缩算法.
4.估计API能实现的都去掉,AU3也没人用了.
5.目前官方已经在移除部分不必要的特性以减小体积,如BGR颜色方面的支持.(目前是RGB颜色)
6.官方的特性请求,我提的或者我关注的好几个,都放了快一年半了(状态是真在做)...