Leaderboard

You guys were so close! I tried @MattyD's code as completed by @Nine and the first run through I got the same old error message. But then I adjusted the line that creates the BSTR being passed in (the filename) by changing wstr to str. With that change, the call to the decryption DLL succeeded and I actually got back 12,677 bytes -- the exact number of bytes of the decrypted file contents. However, that string was jibberish instead of being the actual text. My guess was that the DLL was returning an ANSI string rather than Unicode, so I changed the $tBstr definition to use char rather than wchar. And it worked! I got my entire decrypted file contents just as pretty as you please. So here's the modified version that worked: Local $hDLL = DllOpen("XYZDECRYPT.DLL") Local $sFilename = "C:\Test\MyTestFile.xyz" Local $aCall = DllCall("OleAut32.dll", "ptr", "SysAllocString", "str", $sFilename) Local $aCall2 = DllCall($hDLL, "ptr", "DECRYPTXYZFILE", "ptr", $aCall[0], "long*", 0) Local $tBstr = DllStructCreate(StringFormat("long len;char str[%d]", $aCall2[2] + 1), $aCall2[0] - 4) ConsoleWrite("Char count received = " & $aCall2[2] & @CRLF) ConsoleWrite("Byte count received = " & $tBstr.len & @CRLF) ConsoleWrite("String received = " & $tBstr.str & @CRLF) DllCall("OleAut32.dll", "none", "SysFreeString", "ptr", $aCall[0]) DllCall("OleAut32.dll", "none", "SysFreeString", "ptr", $aCall2[0]) DllClose($hDLL) Thanks for the help! And quite impressive work seeing as how you didn't have access to the actual DLL for testing.

@WildByDesign Thanks, I'm glad you like it. I hope you will like the rework even more. With the Rework I did now, AutoItObject is not needed anymore. It only uses UDFs included with AutoIt now. The reworked UDF also makes it really easy to show Files in the TreeView as well. Just set $bShowFiles to true when adding a view. I would encourage you to switch to the new UDF, as the old one was a more early work from me. It had some bugs and was a lot less performant. @argumentum Yes, I saw that too and it also had some design mistakes and is completely redone now. It should not have these issues anymore. But feel free to tell me, if you find some anyway

Good job again @MattyD. Not taking any merits here, but for completeness : Local $hDLL = DllOpen("XYZDECRYPT.DLL") Local $sFilename = "C:\Test\MyTestFile.xyz" Local $aCall = DllCall("OleAut32.dll", "ptr", "SysAllocString", "wstr", $sFilename) Local $aCall2 = DllCall($hDLL, "ptr", "DECRYPTXYZFILE", "ptr", $aCall[0], "long*", 0) Local $tBstr = DllStructCreate(StringFormat("long len;wchar str[%d]", $aCall2[2] + 1), $aCall2[0] - 4) ConsoleWrite("Char count received = " & $aCall2[2] & @CRLF) ConsoleWrite("Byte count received = " & $tBstr.len & @CRLF) ConsoleWrite("String received = " & $tBstr.str & @CRLF) DllCall("OleAut32.dll", "none", "SysFreeString", "ptr", $aCall[0]) DllClose($hDLL) ps. if there is memory leak, you should also consider freeing $aCall2[0]

Ok - May have jumped the gun before, the previous version will likely fail. When using SysAllocString to create the bstr, the returned pointer takes us to the character array. The "length" field is in memory before this... Local $sFilename = "C:\Test\MyTestFile.xyz" $aCall = DllCall("OleAut32.dll", "ptr", "SysAllocString", "wstr", $sFilename) ;Create Bstring Local $iFilenameLen = StringLen($sFilename) Local $tBstrFilename = DllStructCreate(StringFormat("long Len;wchar Filename[%d]", $iFilenameLen + 1), $aCall[0] - 4) ;$aCall[0] is a ptr to the wchar array! ConsoleWrite("Char count = " & $iFilenameLen & @CRLF) ConsoleWrite("Byte count = " & $tBstrFilename.Len & @CRLF) ;should be double $iFilenameLen, as its a wstr ConsoleWrite($tBstrFilename.Filename & @CRLF) So to correctly pass a bstr, I think its something like this for unicode... ;Unicode version Local $sFilename = "C:\Test\MyTestFile.xyz" $aBstrCall = DllCall("OleAut32.dll", "ptr", "SysAllocString", "wstr", $sFilename) $aCall = DllCall("XYZDECRYPT.DLL", "ptr", "DECRYPTXYZFILE", "ptr", $aBstrCall[0], "long*", 0) Or this for ANSI... ;ANSI Vesrion Local $sFilename = "C:\Test\MyTestFile.xyz" $aBstrCall = DllCall("OleAut32.dll", "ptr", "SysAllocString", "str", $sFilename) $aCall = DllCall("XYZDECRYPT.DLL", "ptr", "DECRYPTXYZFILE", "ptr", $aBstrCall[0], "long*", 0)

I did.

I can confirm that it isn't a null character that tells VB that it's the end of the string. Some of the encrypted files are data rather than just plain text. Still ANSI, but containing non-printing ASCII characters, including plenty of Chr(0) characters. So I don't know what kind of magic VB does when it calls the DLL to get the entire string without knowing in advance how big it's gonna be. I know the function does return the number of bytes in the string as the second parameter in the function call, but I don't do anything with that. I just assign my string variable the return result of the function and that's it. It's automagically the right size and contains every byte of the decrypted data, no more and no less. In looking for information about how VB6 can receive a string as a return value from a DLL function, I found (via the WayBack Machine) a paper written by Microsoft in 1996 detailing how to write a DLL that could work with VB5 (which still applies to VB6). Here's the link, jumped to the relevant portion: https://web.archive.org/web/20051215232620/http://vb.mvps.org/tips/vb5dll.asp#:~:text=5%3A Passing and Returning Strings From my limited understanding of what this says, it looks like the DLL (which was written to work with another flavor of BASIC other than VB but apparently works the same way since it works with VB) returns the string as a BSTR created using SysAllocStringByteLen. This (according to https://learn.microsoft.com/en-us/previous-versions/windows/desktop/automat/bstr ) is a composite data type that consists of a length prefix, a data string, and a terminator. Beyond that, I'm out of my depth to figure out how to get AutoIt to pass in a BSTR as the first parameter (the name of the file to be decrypted), and then to assign the BSTR returned by the function to an AutoIt variable. But hopefully this bit of info may tell someone who knows a whole lot more than I do what I need to do.

Just for the heck of it: I've modified my forked repo extension code to include these standard shortcuts/tasks : Tidy (Ctrl+t) Au3Stripper (Ctrl+Shift+x) AddIncludes (Ctrl+Shift+m) .. and think this works nicer than defining the tasks.json. Also added a fix to be able to cope with the -1 returncode from Tidy.

When you learn to ride a bike, you don't ask your parents every 100 metres whether you're doing it right. As long as you don't fall, you're doing it right. It's the same with programming. If it works, then you've done a lot of things right. Maybe not efficiently or according to all the rules of programming, but it works. You've been working with AutoIt long enough that you should have this confidence in your own abilities and not have to ask after every 5 lines of code. Have more confidence! If it works, then it's good. If you get wrong results or error messages, that's the time to ask. Just my 2 cents worth! Written with the help of DeepL.com translator

This "only" happens when it is the first variable we search for in a script. Please try this AutoIt3Wrapper.au3, and that example should also work now. Sorry about me being slow to understand that was an issue and only focussing on the PS1 & TASKS issue. EDIT: spend some time today to make the adding of include files process faster and updated the beta to v25.205.1420.5. Please check if that works better/faster for you too.