Latest Beta

[Valik]

Here's a common pitfall: Not understanding the C++ standard. Prior to VC10, VC gave you non-const iterators when working with a std::set giving the illusion that the set was mutable. This was wrong and non-standard. VC10 corrected this issue, however, it turns out that tylo was relying on the incorrect mutability of a set to implement something in Au3Check. When we started compiling Au3Check with VC10 we received compiler errors. My first fix was not right. My second fix changed from a std::set to a std::map which are mutable. The compiler is now happy, the code doesn't crash (at least on the example where it previously crashed) and it seems to function correctly.

So rule #1: When using a standard library, understand how the library works regardless of what the compiler lets you do.

[MvGulik]

#1932

I think I'll change that so that the beta doesn't touch those keys.

Did no think of that one. ... Would it in that case not also make sens to let the beta install (no SciTE4AutoIt3 install present.) Not overwrite the production Def files. ("<AutoIt>\SciTE\au3.keywords.properties" and "<AutoIt>\SciTE\api\au3.api")

But just to put them in the "<AutoIt>\Beta\SciTE\*". location.

[Jon]

3.3.7.2 (25th May, 2011) (Beta)

Some extensive changes to DllStructs implemented. Watch for bugs.

- Added: Struct/EndStruct in DllStructCreate() to solve X86/X64 data alignment.

- Changed: Compiling with VC10. Added workarounds for Win2000/XP RTM to allow execution of AutoIt, Aut2Exe, Au3Info, Au3Check and AutoItHelp.

- Fixed #1860: DriveStatus Returns Ready with blank value.

- Fixed #1854: StringIsFloat returns 1 on non float numbers.

- Fixed #1910: Please change $TTN_GETDISPINFO to $TTN_GETDISPINFOW.

- Fixed #1844: SplashTextOn crops variable when used with opt 32 and @CRLF / @LF.

- Fixed #1932: Uninstaller, windows-register, App Paths. (+beta).

- Fixed #1929: SetMenuColor() does not work on 64bit OS.

- Fixed #1479: X64 ListView WM_NOTIFY Message.

UDFs:

- Fixed #1920: Script crashes with error reported in Security.au3 at line 85

- Fixed #1895: Bugs in _GUIScrollBars_Init().

- Fixed #1891: _ArrayDisplay (......,i$iTranspose,...) wrong description.

[guinness]

- Fixed #1479: X64 ListView WM_NOTIFY Message.

Brilliant, Thanks!

[wraithdu]

Could we get a more in depth explanation of the structure changes and how exactly the new 'struct' and 'endstruct' keywords influence internal alignment? I'm reading the help file and I just can't put the picture together in my head. For example, how is this 32 bytes in x64?

DllStructCreate("int;STRUCT;ptr;int;ENDSTRUCT;int") ; structure is 32 bytes under  a Windows 64-Bit and 16 under Windows 32-Bit

Edited May 25, 2011 by wraithdu

[Jon]

Could we get a more in depth explanation of the structure changes and how exactly the new 'struct' and 'endstruct' keywords influence internal alignment? I'm reading the help file and I just can't put the picture together in my head. For example, how is this 32 bytes in x64?

DllStructCreate("int;STRUCT;ptr;int;ENDSTRUCT;int") ; structure is 32 bytes under  a Windows 64-Bit and 16 under Windows 32-Bit

It's really hard to explain, but the details are sort of described: http://en.wikipedia.org/wiki/Data_structure_alignment#Data_structure_padding

The basics of it is that when you include a "struct" within a struct (like many Win32 structs) then you have to "pad" the various members to fit certain alignments. In previous versions of autoit we aligned members but didn't properly align nested structs. This only really became apparent on x64 but there were x86 bugs too.

[Valik]

Jon, you're not tagging these beta releases.

[guinness]

I don't know if this is worthy of a bug report, but the UPX exe that was shipped with the latest beta was V3.05, yet V3.07 is available.

[ProgAndy]

- Added: Struct/EndStruct in DllStructCreate() to solve X86/X64 data alignment.

It's not bad, but I would prefer a more hierarchical approach. (including array of structures, accessing of substructure values via member.value, different alignment for the subsrtucture, and nested subsrtuctures) Maybe I ask for too much for a scripting language

[Mat]

I think you ask too much for a language that implements structures using strings... The most you can hope for at the moment is possibly adding '.' to the list of allowed characters (currently just alphanumeric or underscore). I don't see any reason why not, and it would give the same effect...

That said, how about this:

$t = DllStructCreate("int Num; (int X; int Y) Point")
DllStructSetData($t, "Point.X", 42)

And ultimately:

$t = DllStructCreate("int Num; (int X; int Y) Point[2]")
DllStructSetData($t, "Point[1].X", 42)

Edited May 26, 2011 by Mat

[Jon]

Jon, you're not tagging these beta releases.

Crap, I thought I was missing something.

[wraithdu]

It's really hard to explain, but the details are sort of described: http://en.wikipedia.org/wiki/Data_structure_alignment#Data_structure_padding

The basics of it is that when you include a "struct" within a struct (like many Win32 structs) then you have to "pad" the various members to fit certain alignments. In previous versions of autoit we aligned members but didn't properly align nested structs. This only really became apparent on x64 but there were x86 bugs too.

So I looked through the StructureConstants.au3 file and a bit of that article, and I think I understand a bit better. How did you decide which structs to wrap in struct/endstruct though? For non-nested structs, I would have thought it would have been all or none. In fact, the help file implies that wrapping the entire struct in struct/endstruct has no effect. Is that the case?

[Ascend4nt]

Two things:

1. Verified that the latest beta works on Windows 2000. Good work Jon

2. Messed around with new DLLStruct Struct/EndStruct directives, they appear to work, although I'm still unsure I understand alignment completely. Does it make sense for a structure to be an odd number of bytes (with types such as word, ptr, etc followed by a terminating 'byte')?

I just updated my debugging tool which now works with Struct/EndStruct and reports end-of-structure padding if it helps anyone.

*edit: clarification of 2nd thing

Edited May 26, 2011 by Ascend4nt

[Jon]

So I looked through the StructureConstants.au3 file and a bit of that article, and I think I understand a bit better. How did you decide which structs to wrap in struct/endstruct though? For non-nested structs, I would have thought it would have been all or none. In fact, the help file implies that wrapping the entire struct in struct/endstruct has no effect. Is that the case?

JP did the constants, it looked like he wrapped the structs that were getting used within other structs. struct/endstruct is implied at the "top" level, so adding it in there does nothing additional, yes.

[Jon]

2. Messed around with new DLLStruct Struct/EndStruct directives, they appear to work, although I'm still unsure I understand alignment completely. Does it make sense for a structure to be an odd number of bytes (with types such as word, ptr, etc followed by a terminating 'byte')?

No, it should never be an odd number of bytes if it's got members like word in it. Got an example?

[Ascend4nt]

No, it should never be an odd number of bytes if it's got members like word in it. Got an example?

Hmm.. seems to happen when I use 'align' with anything other than 8. For example, this returns 33 bytes:

$sStruct='align 4;short;ptr;Struct;ptr;byte;EndStruct;byte'
$stStr=DllStructCreate($sStruct)
ConsoleWrite("Struct size:"&DllStructGetSize($stStr)&@CRLF)

[Jon]

Hmm.. seems to happen when I use 'align' with anything other than 8. For example, this returns 33 bytes:

$sStruct='align 4;short;ptr;Struct;ptr;byte;EndStruct;byte'
$stStr=DllStructCreate($sStruct)
ConsoleWrite("Struct size:"&DllStructGetSize($stStr)&@CRLF)

Ah yes, that's a part of the code we've been discussing. There's a check in there that only pads when using the default alignment of 8. I'm pretty sure it should always pad but I'm struggling to find exactly how align should affect the end padding. All the docs I've looked at just say "changing align also has an effect on the end padding" but don't say how.

[jchd]

Nitpick about Struct doc: a few typos.

This needs to be done to respect alignment inside the entire structure creation. No need if all datatypes are in the defined structure as an implicit structure alignment is done.

Structure size is an integral multiple of its alignment, which requires padding after the last member.

missing double quotes (in bold red) in the first 2 DllStructCreate dicussion

DllStructCreate("int;STRUCT;ptr;int;ENDSTRUCT;int") ; structure is 32 bytes under a Windows 64-Bit and 16 under Windows 32-Bit

DllStructCreate("int;ptr;int;int") ; structure is 24 bytes under a Windows 64-Bit and 16 under Windows 32-Bit

Edited May 26, 2011 by jchd

[James]

Oh god, if Jon doesn't understand this new structure stuff, how are we supposed to?

I'd really, really like to see what Mat was talking about #410 that would be sweet! But asking too much.

[ProgAndy]

Ah yes, that's a part of the code we've been discussing. There's a check in there that only pads when using the default alignment of 8. I'm pretty sure it should always pad but I'm struggling to find exactly how align should affect the end padding. All the docs I've looked at just say "changing align also has an effect on the end padding" but don't say how.

The padding should be fairly simple: Consider the substruct as one block of bytes and pad it respectively. At least, that is what I do here and it seems to work:

Edit: Sorry, this works only if the Substruct is already starting at a correct address so ignore this post.

Edited May 26, 2011 by ProgAndy