Allow AutoHotkey to Handle Binary Data

Propose new features and changes
1100++
Posts: 44
Joined: 10 Feb 2018, 19:05

Allow AutoHotkey to Handle Binary Data

28 Jan 2019, 20:43

Currently, in AutoHotkey, when binary data containing a null character is copied by the assignment (:=) operator, passed to a function as a parameter, or returned from a function, any data after the null is lost. Similarly, if binary data containing a null is evaluated by one of =/==/</>/<>, any data after the null is ignored. Can AutoHotkey be changed so that binary data is not lost or ignored in these cases?
Helgef
Posts: 3720
Joined: 17 Jul 2016, 01:02
Contact:

Re: Allow AutoHotkey to Handle Binary Data

28 Jan 2019, 23:24

You can compare data beyond the null character with == in v2. I don't think it is a very good idea though. It cannot be added for these operators in v1, that would break existing scripts. You can call memcmp with dllcall.

Cheers.
User avatar
Drugwash
Posts: 682
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Allow AutoHotkey to Handle Binary Data

29 Jan 2019, 16:20

I disagree, Helgef. The logical expectancy - at least in the asignment case or the equal/different - would be for the entire contents of the variables to be processed. In the assignment case the entire binary contents should be transferred unaltered to the new variable, and in the second a simple binary compare should yield a boolean true or false as a result of the comparison.

I can undesrtand how the latter may be confusing whether it's a string or pure binary data, but at least in the assignment case I see absolutely no reason why it shouldn't be allowed. I've stumbled upon this issue the other day when I wanted to transfer binary data from one volatile variable to a stable one and it didn't work. I expected it to work, it was perfectly logical.
The workaround is for the user to perform too many additional operations that take much more time to be interpreted than run directly, which is a real shame: Global Alloc(), GlobalLock(), RtlMoveMemory(), GLobalUnlock(), GlobalFree(). In time-critical scripts this may be unacceptable.

Please think thoroughly about this. For AHK v1, first.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
nnnik
Posts: 4147
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Allow AutoHotkey to Handle Binary Data

29 Jan 2019, 16:38

We can add a completely new feature which can be used in place of the current binary data functionality and does not change the current binary data functionality.

I personally believe that these names are a very bad choice - The functions they reference are bound to the WinAPI directly however AHK should pursue its own naming scheme which does not rely on WinAPI functionality.
The functions references are both deprecated and have a high overhead.
The concept of Lock and Unlock functions shouldn't be added - chances are that the average user doesn't need them and they only add noise.
RtlMoveMemory is an undocumented name - why add the Rtl - prefix here?
Recommends AHK Studio
User avatar
Drugwash
Posts: 682
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Allow AutoHotkey to Handle Binary Data

30 Jan 2019, 04:34

Apologies, nnnik, but you misunderstood: I didn't suggest adding such AHK functions - was merely stating that in the absence of direct assignment between binary variables, user has to perform all those API calls through DllCall(), which induces a high overhead.

As for those APIs themselves yes, they may be deprecated, but I recently read a topic in the old forum where somebody - Lexikos himself, if I'm not mistaken - performed a speed comparison between GlobalAlloc() and a few similar others, and that one still came up first, despite the statement at MSDN that it would be slower. But that's of no concern for the user - if that operation would be implemented internally I'm sure Lexikos would choose the best available method.

Here's an example code I was working on, extracted from skwire's sWeather and slightly modified by me. It converts a Base64 string into an icon or bitmap and returns the corresponding handle. You'll notice the API uses the variable called Dec to store the result, and I want to transfer its binary contents to another variable, to work with subsequently. But I can't, because a simple Buf := Dec won't copy the entire binary data from Dec to Buf, therefore all the subsequent operations would fail. All those additional DllCalls to GlobalAlloc, GlobalLock etc are required only to perform a simple binary data copy from one place to another.

So what the OP requests and I support that request, is the simple ability to perform assignment of binary data from one variable to another (i.e. b := a). And maybe binary comparison as well (if a = b or if a != b).

Code: Select all

CreateIcon(n, h := False, bmp := False)
{
Static
If h
	h%n% := 0
If h%n%
	Return h%n%
VarSetCapacity(B64, StrLen(%n%) << !!A_IsUnicode)
B64 := %n%
If !DllCall("Crypt32.dll\CryptStringToBinary"
		, "Ptr", &B64
		, "UInt", 0
		, "UInt", 0x1
		, "Ptr", 0
		, "UIntP", DecLen
		, "Ptr", 0
		, "Ptr", 0)
	Return False
VarSetCapacity(Dec, DecLen, 0)
If !DllCall("Crypt32.dll\CryptStringToBinary"
		, "Ptr", &B64
		, "UInt", 0
		, "UInt", 0x1
		, "Ptr", &Dec
		, "UIntP", DecLen
		, "Ptr", 0
		, "Ptr", 0)
	Return False
if (AHKBinaryAssignment=True)  ; which is not, unfortunately
  {
  Buf := Dec
  DllCall("Ole32.dll\CreateStreamOnHGlobal", "Ptr", &Buf, "Int", True, "PtrP", pStream)
  }
else
  {
  hData := DllCall("Kernel32.dll\GlobalAlloc", "UInt", 2, "UPtr", DecLen, "UPtr")
  pData := DllCall("Kernel32.dll\GlobalLock", "Ptr", hData, "UPtr")
  DllCall("Kernel32.dll\RtlMoveMemory", "Ptr", pData, "Ptr", &Dec, "UPtr", DecLen)
  DllCall("Kernel32.dll\GlobalUnlock", "Ptr", hData)
  DllCall("Ole32.dll\CreateStreamOnHGlobal", "Ptr", hData, "Int", True, "PtrP", pStream)
  }
DllCall("Gdiplus.dll\GdipCreateBitmapFromStream",  "Ptr", pStream, "PtrP", pBitmap)
t := bmp ? "HBITMAP" : "HICON"
DllCall("Gdiplus.dll\GdipCreate" t "FromBitmap", "Ptr", pBitmap, "PtrP", h%n%, "UInt", 0)
DllCall("Gdiplus.dll\GdipDisposeImage", "Ptr", pBitmap)
DllCall(NumGet(NumGet(pStream + 0, 0, "UPtr") + (A_PtrSize * 2), 0, "UPtr"), "Ptr", pStream)
;DllCall("Kernel32\GlobalFree", "Ptr", hData) ; probably not needed, if second parameter is True in CreateStreamOnHGlobal()
Return h%n%
}
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
Raccoon
Posts: 49
Joined: 26 Jul 2014, 16:15

Re: Allow AutoHotkey to Handle Binary Data

23 Feb 2019, 08:23

I don't believe the "backwards compatibility breakage" argument should hold water here, unless we mean to protect extreme edge cases where somebody is literally stumbling about with their left and right shoelaces tied together while eating a jar of paste. There shouldn't be a reasonable situation where the current broken behavior is the expected working behavior in a script in the wild.

It may also be unreasonable and sadistic to weaponize backward compatibility concerns as a bargaining chip to bully people to switch to v2. Plus that just makes v1 scripts even less compatible with v2, and in strange nonobvious ways.
User avatar
nnnik
Posts: 4147
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Allow AutoHotkey to Handle Binary Data

23 Feb 2019, 11:47

Comparing binary data like v2 does in AHK v1 would mean that string comparison would break completely.
This comparison only became possible in v2 because lexikos removed a ton of technical debt and overhauled most of the behavior.
We cannot apply those changes in v1 because it would just turn into v2 - we could just remove v1 completely and replace it with v2 alpha and call it v1 but I think v1 should remain seperate.
Recommends AHK Studio
User avatar
Drugwash
Posts: 682
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Allow AutoHotkey to Handle Binary Data

23 Feb 2019, 12:55

Well, then try new operators specifically built for binary operations.
Such as b :=? a, if (a =? b), if (a !=? b).
Would that be feasible?
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
nnnik
Posts: 4147
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Allow AutoHotkey to Handle Binary Data

23 Feb 2019, 16:16

Yeah like I said any new addition is possible since it doesn't break existing scripts.
I'd prefer a different solution like a binary object similar to the file object but thats just my preference.
Recommends AHK Studio
User avatar
Drugwash
Posts: 682
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Allow AutoHotkey to Handle Binary Data

23 Feb 2019, 18:17

Objects might just be overkill for simple operations on binary buffers, IMHO. Or it may just be my lack of familiarity with them.
Either way, something is needed in this regard and I guess it has been for a long time.
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
jeeswg
Posts: 6395
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Allow AutoHotkey to Handle Binary Data

23 Feb 2019, 19:06

- The problems I can see so far are:
- =/==/</>/<>/!=/<=/>= compare as if truncated. (To be expected for the String type.)
- := causes truncation. (Understandable for the String type.) [EDIT: Actually, it appears it doesn't truncate.]
- Returning a variable from a function causes truncation. (Understandable for the String type.)

- Note: you can pass binary data into functions (without causing truncation) by using ByRef parameters.
- It appears that AHK v2 has increased/will increase support for handling binary data.

- What would be good for both AHK v1/v2, would be wrappers for memmove/RtlMoveMemory and memcmp/RtlCompareMemory. Possible names: BinCopy/BinCmp.
- (Note: BinCmp could return negative/0/positive, and the offset of the first difference as an optional parameter.)
- BinCmp gives you the equivalent of =/==/</>/<>/!=/<=/>= (comparison).
- VarSetCapacity and BinCopy would give you the equivalent of := (assignment).
- Returning a variable would still be a problem. However, functions that write to an address, rather than output a variable, are more versatile/useful, because they let you modify *part* of a variable, rather than the whole thing. Also, you could output via a ByRef variable instead. (And perhaps a new 'Binary' type could allow it to be done anyway, in AHK v1.)

- I would be happy with functions as solution.
- (It's possible that if a variable had a 'Binary' type, even in AHK v1, that the operators could be made to behave differently. I'm not necessarily advocating this.)
- (It may be wrong to criticise the current comparison/assignment/function input and output behaviour, since we are using the *String* type in a way it was not necessarily intended to be used, by inserting null bytes/characters.)
- It's been 16 years since AHK was released (2003), almost nobody has complained re. binary functionality, and with my custom BinCopy and BinCmp functions all has been fine, and I haven't felt that anything else is needed.

- Btw one thing to be aware of is this StrLen discrepancy.
- (Although this script does demonstrate the ability to store binary data in objects.)

Code: Select all

q:: ;StrLen reports the length of variables/object values differently
vText := "abcdefghijklmnopqrstuvwxyz"
obj := {key:"abcdefghijklmnopqrstuvwxyz"}
MsgBox, % StrLen(vText) " " StrLen(obj.key) ;26 26
MsgBox, % vText " " obj.key

NumPut(0, &vText, 10, "UShort")
NumPut(0, obj.GetAddress("key"), 10, "UShort")
MsgBox, % StrLen(vText) " " StrLen(obj.key) ;26 5
MsgBox, % vText " " obj.key

NumPut(Ord("_"), &vText, 10, "UShort")
NumPut(Ord("_"), obj.GetAddress("key"), 10, "UShort")
MsgBox, % StrLen(vText) " " StrLen(obj.key) ;26 26
MsgBox, % vText " " obj.key
return
Last edited by jeeswg on 24 Feb 2019, 16:28, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
Drugwash
Posts: 682
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Allow AutoHotkey to Handle Binary Data

24 Feb 2019, 04:49

Maybe also a BinLen() to return the real and accurate size of the binary buffer, since VarSetCapacity() and StrLen() don't always cut it.

I wonder how many scripts have been/are randomly failing all these 16 years because their authors assumed assignment and comparison would seamlessly work for binary data as well as for strings…
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
nnnik
Posts: 4147
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Allow AutoHotkey to Handle Binary Data

24 Feb 2019, 05:29

It's been 16 years since AHK was released (2003), almost nobody has complained re. binary functionality, and with my custom BinCopy and BinCmp functions all has been fine, and I haven't felt that anything else is needed.
You couldn't be more wrong.
- Btw one thing to be aware of is this StrLen discrepancy.
- (Although this script does demonstrate the ability to store binary data in objects.)
This has nothing to do with strLen but rather the fact that you didnt update the StrLen of the variable yet.
For Objects this happens automatically.

Code: Select all

vText := "abcdefghijklmnopqrstuvwxyz"
obj := {key:"abcdefghijklmnopqrstuvwxyz"}
MsgBox, % StrLen(vText) " " StrLen(obj.key) ;26 26
MsgBox, % vText " " obj.key

NumPut(0, &vText, 10, "UShort")
NumPut(0, obj.GetAddress("key"), 10, "UShort")
VarSetCapacity(vText, -1)
MsgBox, % StrLen(vText) " " StrLen(obj.key) ;26 5
MsgBox, % vText " " obj.key

NumPut(Ord("_"), &vText, 10, "UShort")
NumPut(Ord("_"), obj.GetAddress("key"), 10, "UShort")
VarSetCapacity(vText, -1)
MsgBox, % StrLen(vText) " " StrLen(obj.key) ;26 26
MsgBox, % vText " " obj.key
return
This is also offtopic and partially misinformation.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6395
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Allow AutoHotkey to Handle Binary Data

24 Feb 2019, 09:55

- @nnnik: You have a real problem with communication, you need to reconsider your approach. Pretending or exaggerating in an emotional way that other people are misleading/incorrect/in disagreement, and misleading people while accusing other people of being misleading, don't do it.
- It's posts like this that lead people to not want to appear on the AutoHotkey forum any more, and to not want to work on the source code.

- You cite no evidence. I saw little to no pushback re. binary data variables, before this recent thread:
Binary Data | VarSetCapacity | VarSetLength | Heap Object - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=37&t=51356

- You could have just said 'the 'StrLen discrepancy' happens because ...' instead of feigning disagreement.

- The example is ontopic. The thread title is 'Allow AutoHotkey to Handle Binary Data'. My post and others have sought to establish what can/can't already be done. Also, you don't explain the claim of 'partially misinformation'.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4147
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Allow AutoHotkey to Handle Binary Data

24 Feb 2019, 12:56

I wouldn't say that AutoHotkey has facilities to handle binary data. All it has are facilities for manipulating strings which can also contain binary data. They add the extra spice of potential data loss, since everything in AHK is centered around strings with specific string lengths.
The whole thing is a complete mess, totally bodged and needs a real implementation - a complete overhaul.

Code: Select all

var := ""
Msgbox % "created var as empty string:`nStrLen: " . StrLen(var) . "`nCapacity: " . VarSetCapacity(var)
VarSetCapacity(var, 100000, 0x13)
Msgbox % "filled var with a non null byte`nStrLen: " . StrLen(var) . "`nCapacity: " . VarSetCapacity(var)
NumPut(0, var, 0, "UShort")
Msgbox % "replaced first character with 0 character`nStrLen: " . StrLen(var) . "`nCapacity: " . VarSetCapacity(var)
VarSetCapacity(var, -1)
Msgbox % "updated variable`nStrLen: " . StrLen(var) . "`nCapacity: " . VarSetCapacity(var)
var2 := var
Msgbox % "assigned variable to another variable`nStrLen: " . StrLen(var2) . "`nCapacity: " . VarSetCapacity(var2)


var := ""
Msgbox % "created var as empty string:`nStrLen: " . StrLen(var) . "`nCapacity: " . VarSetCapacity(var)
VarSetCapacity(var, 100000, 0x13)
Msgbox % "filled var with a non null byte`nStrLen: " . StrLen(var) . "`nCapacity: " . VarSetCapacity(var)
NumPut(0, var, 0, "UShort")
Msgbox % "replaced first character with 0 character`nStrLen: " . StrLen(var) . "`nCapacity: " . VarSetCapacity(var)
var2 := var
Msgbox % "assigned variable to another variable`nStrLen: " . StrLen(var2) . "`nCapacity: " . VarSetCapacity(var2)
The variable string binary inside the object is updated when you access the key that contains it. The same would happen for any variable that you update - which I have done in my example using VarSetCapacity(var, -1).
StrLen is buffered for performance reasons. Bugs such as this can be problem however as the DllCall documentation states:
When a variable's address (e.g. &MyVar) is passed to a function and that function alters the length of the variable's contents, subsequent uses of the variable may behave incorrectly. To fix this, do one of the following: 1) Pass MyVar as a "Str" argument rather than as a Ptr/address; 2) [v1.0.44.03+]: Call VarSetCapacity(MyVar, -1) to update the variable's internally-stored length after calling DllCall.

Any binary zero stored in a variable by a function hides all data to the right of the zero; that is, such data cannot be accessed or changed by most commands and functions. However, such data can be manipulated by the address operator and NumPut/NumGet, as well as DllCall itself.
The current system is problematic for both strings and binary data. I honestly do not see a single reason to keep it other than not wanting to put in any effort into binary data handling in AHK.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6395
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Allow AutoHotkey to Handle Binary Data

24 Feb 2019, 16:19

I wouldn't say that AutoHotkey has facilities to handle binary data.
- :?: No-one said it did. I recommended BinCopy and BinCmp be added. Possible implementations below (but I'm flexible re. function names/functionality). That's all I want/need. Others can recommend further functionality.

Code: Select all

;==================================================

;returns vAddrDest
JEE_BinCopy(vAddrDest, vAddrSource, vSize)
{
	return DllCall("msvcrt\memmove", Ptr,vAddrDest, Ptr,vAddrSource, UPtr,vSize, "Cdecl Ptr")
}

;==================================================

;e.g. MsgBox, % JEE_BinCmp(&vData1, &vData2, vSize)

;returns: 0 if same, positive if data 1 is greater, negative if data 2 is greater
JEE_BinCmp(vAddr1, vAddr2, vSize, ByRef vOffset:="")
{
	local
	vOffset := DllCall("ntdll\RtlCompareMemory", Ptr,vAddr1, Ptr,vAddr2, UPtr,vSize, UPtr)
	if (vOffset = vSize)
		return 0
	return DllCall("msvcrt\memcmp", Ptr,vAddr1+vOffset, Ptr,vAddr2+vOffset, UPtr,1, "Cdecl Int")
}

;==================================================
- [EDIT: A BinSearch function is another idea. RegExMatch in AutoHotkey ANSI could already do this. Maybe AutoHotkey Unicode could have a RegExMatch 'ANSI' mode.]

The whole thing is a complete mess
- Being critical of things is fine, but if you really want to change things, you should do some AHK or C++ prototypes. Then we would have some useful custom code and/or it becomes part of AHK proper.
Spoiler

- Btw this code suggests that variables are not in fact truncated when you do assignments.

Code: Select all

var := "abcde"
;var := JEE_StrRept(var, 10000)
NumPut(0, &var, 4, "UShort")
var2 := var
MsgBox, % var2
NumPut(Ord("_"), &var2, 4, "UShort")
MsgBox, % var2
MsgBox, % VarSetCapacity(var)
MsgBox, % VarSetCapacity(var2)

- Bonus material. Some examples for outputting binary data from functions in AHK v1.

Code: Select all

;examples for outputting binary data

;return variable (warning: truncates)
MyFunc1()
{
	var := "abcde"
	NumPut(0, &var, 4, "UShort")
	return var
}
var2 := MyFunc1()
MsgBox, % var2
NumPut(Ord("_"), &var2, 4, "UShort")
MsgBox, % var2
MsgBox, % VarSetCapacity(var2)

;ByRef variable (doesn't truncate)
MyFunc2(ByRef var)
{
	var := "abcde"
	NumPut(0, &var, 4, "UShort")
}
MyFunc2(var2)
MsgBox, % var2
NumPut(Ord("_"), &var2, 4, "UShort")
MsgBox, % var2
MsgBox, % VarSetCapacity(var2)

;write to address (doesn't truncate)
;var2 := "....."
VarSetCapacity(var2, 6*2, 1)
MyFunc3(vAddr)
{
	var := "abcde"
	NumPut(0, &var, 4, "UShort")
	DllCall("msvcrt\memmove", Ptr,vAddr, Ptr,&var, UPtr,12, "Cdecl Ptr")
}
MyFunc3(&var2)
MsgBox, % var2
NumPut(Ord("_"), &var2, 4, "UShort")
MsgBox, % var2
MsgBox, % VarSetCapacity(var2)
Last edited by jeeswg on 25 Feb 2019, 10:20, edited 1 time in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Helgef
Posts: 3720
Joined: 17 Jul 2016, 01:02
Contact:

Re: Allow AutoHotkey to Handle Binary Data

25 Feb 2019, 02:32

Hello Drugwash :wave:.
Drugwash wrote:I disagree, Helgef. The logical expectancy - at least in the asignment case or the equal/different - would be for the entire contents of the variables to be processed
The content is a null terminated string, becuase there is no binary type.
at least in the assignment case I see absolutely no reason why it shouldn't be allowed
It is a waste of memory to copy anything beyond the null terminator when you assign a string to a variable, and that is what the assignment operator does, it assigns a string to the variable, because there is no binary type.
Please think thoroughly about this. For AHK v1, first.
Adding a binary type to v1 would mean that the way people write v1 scripts would significantly change, so might as well just switch to v2.
ot
User avatar
Drugwash
Posts: 682
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania

Re: Allow AutoHotkey to Handle Binary Data

25 Feb 2019, 07:57

Hi, Helgef, thanks for replying. :)

I've seen this hint a couple times above that says "might as well switch to v2", but it's not that simple. We have to keep in mind that there are many good old scripts whose authors are not around anymore and it would be quite a shame to break them by unconditionally pushing people towards v2, seeing that version has quite a lot of breaking changes.

The idea of simply adding a handful of functions that could handle variables' contents as binary might just do the trick. As nnnik quoted above from the manual, a variable's contents can be accessed through &var and/or NumPut()/NumGet()/DllCall(). Which means it still contains the binary data and we just need safe ways to access/manipulate it, other than the ones mentioned. BinCopy(), BinCmp(), BinLen() may just be enough for starters.

I think the main problem with AHK is that many people (including myself) are trying to use it as a fully-fledged programming language and when its built-in commands and functions are not enough people resort to direct API calls through DllCall() which brings up the need for binary data manipulation in certain situations. I know I stumbled into such issues myself when trying to build functions/scripts that required the retrieval of the accurate size of a binary buffer, copying the entire contents of a binary variable to another binary buffer and so on.
And as mentioned before, some authors may not have realised binary assignment is not always working, leaving their scripts randomly failing. We may at least have a chance to fix those scripts if their authors are not around anymore, without requiring drastic changes as switching from v1 to v2 might need.

Guys, let's keep it a constructive talk, shall we? ;)
I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.
User avatar
jeeswg
Posts: 6395
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Allow AutoHotkey to Handle Binary Data

25 Feb 2019, 08:27

- @Helgef: It was important to state *explicitly* that := does not cause truncation (in response to Drugwash). (nnnik did not state this explicitly.)
- If any of the tests above were misleading, state the reasons.
- If you or anyone else wants to contribute usefully to this debate, (a) explain what the current situation is, (b) >>>suggest what the future situation should be<<< (the exact behaviour of binary data functions and/or a binary type) (considering both AHK v1 and v2). (I stated the operator/return/'StrLen discrepancy' problems and gave code for BinCopy/BinCmp and 3 return possibilities.)
- I found your opening statement misleading. == *could* compare binary data in AHK v1 (without truncation), *if* we had a Binary type. Do you like that idea or not?
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4147
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Allow AutoHotkey to Handle Binary Data

25 Feb 2019, 10:21

AHK will progress and needs to progress just like the general development of programs and programming styles does.
We want to automate these programs - then we need to adjust to them.
Many of these changes and progresses will change AHK. Maintaining compatability and making sure AHK can tackle these new programs and features is a difficult task that will only succeed for so long.
For example AHK_Basic didn't have an actual ptr type and was incompatible with 64 bit. Yet we moved to 64 bit and those old scripts broke.
Same goes for Ansi/Unicode and similar.

At some point we will have to draw a line and cut off those old scripts. With AHK v2 this line is now in sight.
I'd wish that the change to AHK v2 would be seamless and possibly immediate - however there is a lot of progress that AHK needs to catch up to and many things need changing.
There are only so many people working on the project. If we spend our time working on AHK v1 we might have to neglect v2.
Adding new features to v1 should not be a priority. Other than maintenance no additional new features should be added to v1 unless they are a byproduct of working on v2.

The scripts and functions forums is the place where these scripts are shared. Users share their scripts and after a brief time of activity they are forgotten and won't be maintained.
This works out as long as the language doesn't change too much - but languages change. So over the long run this will cause issues.
Some users do update the topics and the scripts inside. This relies on the fact that users are able to change their posts - something that may change at given time.
Others users external hosts like dropbox or github to share the scripts. I have seen many dead dropbox links - github might be the way to go but it's pretty complex for new people to get into.
However this is one of the weaknesses of the forum and this community and the forum software and the community will have to change/be changed in order to address this issue.
Making AHK do the work by just not changing it is not a path we can go down - this is our job not AHKs.
Recommends AHK Studio

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 6 guests