[Solved] Problems with HashLib.dll in Version 12.1.10

[jpuziano]

Hi Marcus,

I have Macro Scheduler versions 11.1.23 and 12.1.10 both installed on my work PC.

Issue 1: possible bug

The following code works fine run from version 11:

Code: Select all

//Put HashLib.dll in the script directory
Let>HashLib=%SCRIPT_DIR%\HashLib.dll
MDL>HashLib

//Get MD5 hash of a file
LibFunc>HashLib,FileMD5,r1,C:\WINDOWS\system32\msscript.ocx,buf1
MessageModal>r1
Mid>r1_2,1,r1,hash1
MDL>hash1

However, the exact same code fails when run from version 12, no hash value is returned.

From version 11, the value of variable HashLib is:
C:\Documents and Settings\jpuzian1\My Documents\Macro Scheduler 11\HashLib.dll

From version 12, the value of variable HashLib is:
C:\Documents and Settings\jpuzian1\My Documents\Macro Scheduler 12\HashLib.dll

I have a copy of the file HashLib.dll in both places... so why does this work in version 11 but not 12?


Issue 2: documentation error

In the file HashLib.zip which I downloaded from your website, you have a file there called HashLib.txt that explains the use of HashLib.dll however in that file, you have this:

//Get MD5 hash of a file
LibFunc>Hashlib,FileMD5,r,c:\somefile.exe,buf
Mid>r2,1,r,hash
MessageModal>Hash: %hash%

That Mid> line won't work... I believe you meant this instead:

Mid>r_2,1,r,hash

All the usage examples in HashLib.txt have the same error.

To those reading this and wondering why the Mid> line is there, I believe it is there to trim the hash value to the number of characters it has returned as the length of the return value in the resultvar "r".


Issue 3: syntax highlighting problems

In version 12, I see this in the MS editor:

MidStr>r_2,1,r,hash

- Why is the 1 dark blue... shouldn't it just be black?

When I use Mid (the abbriviated form of the command), I see this:

Mid>r1_2,1,r,hash

- Abbrieviated commands should also be colored green... I was expecting this:

Mid>r1_2,1,r,hash


Issue 4: Just a question actually...

I'd like to generate an MD5 hash on a file from within a compiled script. I can't really "Put HashLib.dll in the script directory" because there is no "script directory" as I am running a compiled script on a PC that does not have Macro Scheduler installed. Can I just:

- use "Import Binary File" and carry the HashLib.dll file within the script as a payload

- when my compiled macro runs, it will extract the file to an accessible place on the user's machine like %TEMP_DIR%

- in the LibFunc> line, I can point at where I put the file...

I tried this with version 11 but received the error message "Unable to Locate Script Compiler". That's fine, I really want to use version 12 anyway. Once I get past Issue 1... will this approach work?

Thanks Marcus...

[Marcus Tettmar]

1. Does it work on other files? I'm also finding that it cannot get the hash of msscript.ocx from the windows system folder. I've tried switching on/off file system redirection (I'm in x64) and also specifying SysWOW64 folder instead, but no cigar for some reason. But if DOES work with other files. But then I guess msscript.ocx is in use, so perhaps that is the problem. Given it has to read the contents of the file, perhaps msscript.ocx is locked exclusively and because it is in use, it cannot be read.

2. Not sure why the underscore characters all seem to be missing. Will get that sorted.

3. Syntax highlighting for abbreviated command: noted

4. Yes, you can extract to TEMP_DIR and point LibFunc at it.

[jpuziano]

1. Does it work on other files? I'm also finding that it cannot get the hash of msscript.ocx from the windows system folder. I've tried switching on/off file system redirection (I'm in x64) and also specifying SysWOW64 folder instead, but no cigar for some reason. But if DOES work with other files. But then I guess msscript.ocx is in use, so perhaps that is the problem. Given it has to read the contents of the file, perhaps msscript.ocx is locked exclusively and because it is in use, it cannot be read.

OK, I added another few lines to do an MD5 hash on a file that is definately not in use, just a plain text file in TEMP_DIR... and I put HashLib.dll in TEMP_DIR as well so there shouldn't be any permissions issues... see code below:

Code: Select all

//this time put HashLib.dll in Temp directory
Let>HashLib=%TEMP_DIR%HashLib.dll
MDL>HashLib

//Get MD5 hash of a file
LibFunc>HashLib,FileMD5,r1,C:\WINDOWS\system32\msscript.ocx,buf1
MessageModal>r1
Mid>r1_2,1,r1,hash1
MDL>hash1

//Get MD5 hash of another file
LibFunc>HashLib,FileMD5,r1,%TEMP_DIR%test.txt,buf1
MessageModal>r1
Mid>r1_2,1,r1,hash1
MDL>hash1

Interesting... in v12, the above code fails for the first file but works for the second. Marcus you say that must be because msscript.ocx is in use... well... maybe... but then when I run the above code in v11, I get MD5 hashes for both files.

The only difference is, in one test, I am running v12... and in the other v11. Are you saying, v12 makes use of msscript.ocx (locks it exclusively) while v11 does not?

By the way, running plain old 32 bit XP SP3 here...

[Marcus Tettmar]

I'm not *saying* anything. I'm just guessing possible reasons. Truth is I do not KNOW why it fails and at this stage I can't fathom any credible reason why it would work in v11 and not in v12 on the same system.

I just tried it in v11 and I see the same results. I'm flummoxed. It's the same DLL.

[Marcus Tettmar]

If I copy msscript.ocx to a different location and reference it there, it works.

Are you saying, v12 makes use of msscript.ocx (locks it exclusively) while v11 does not?

I wasn't but I think you hit on something here and now I am.

Add this to the top of your script and run it in v11:

VBSTART
VBEND

You'll get the same problem as in v12.

And now I remember that, yes, there was a change, that if VBScript is installed, v12 always loads it, when a script is executed, whereas v11 didn't unless VB code existed in the script. There were a number of reasons for this - one being that it speeds up script execution.

So, yes, it makes sense now and I should have pondered it longer.

I guess the workaround therefore is to do:

CopyFile>C:\WINDOWS\system32\msscript.ocx,TEMP_DIR
LibFunc>HashLib,FileMD5,r1,%TEMP_DIR%msscript.ocx,buf1

That will ensure it is not in use.

Of course even if you could avoid Macro Scheduler using the file, you would have no way of ensuring something else is not using it, so the above is probably sensible anyway.

[jpuziano]

Hi Marcus,

Fantastic... thanks for the explanation and the cure. Yes, copying the file to %TEMP_DIR% prior to trying to get an MD5 hash on it makes sense... as I should always be able to make a copy of it... and I know my copy will not be in use... and after the I get the hash, I can delete the copy I made.

Its so nice when things make sense... thanks for digging on this one.

On another note, a little birdie has informed me that number strings have always been dark blue in the MS Editor. I did not realize this. I searched for "syntax highlighting" in the help file but no luck. If anyone knows of documentation as to what the colors mean wrt syntax highlighting, please let me know where that is... but if that does not exist, perhaps it should, just a thought...

Thanks again

[Marcus Tettmar]

Yeh I think numerics have always been blue. Probably isn't documented. Not convinced it needs documenting. We can't document every tiny inconsequential thing or the already 248 pages will be even longer and become infinite!

Regarding LibLoad - what do you mean non-Windows? Do you mean non-System? It will only work with Windows DLLs as Macro Scheduler only runs on Windows. Anyway, if you mean non-system DLLs - no they do NOT *HAVE* to be loaded using LibLoad.

Whether system or not, there's only one instance where you would HAVE to LibLoad the DLL first and free it later - and that would be if the DLL needs to keep tabs on something which you refer to later. Consider the WebRecorder IEAuto.DLL.

1. If you're only ever calling one function in the DLL once then LibFunc will do the job fine.

2. If you call lots of functions in the same DLL then a LibLoad followed by LibFuncs referring to its handle will be slightly faster (it won't need to load and unload each time).

3. If you are interacting with a DLL and need to continue to interact with it to maintain data after loading it then you will need to LibLoad it and then LibFunc the functions as otherwise once freed you've lost the link (e.g. as with the WebRecorder IEAuto.DLL where you create a link to an IE instance which is maintained by the DLL and need to interact with it over a series of LibFunc calls). If the DLL was unloaded after the function call that link would cease to exist. A similar example is how the XL or Telnet functions work - a session state needs to be maintained as you use them - with the XL functions you open XL and a handle is created which refers internally to that instance of XL so that you can use it in subsequent XL calls. If implementing these functions with a DLL you'd need to load the DLL once, create the instance and then keep the DLL loaded while you refer to other functions.

There's absolutely no rule that says "non-Windows" DLLs MUST be loaded with LibLoad. That's nonsense.

[jpuziano]

Yeh I think numerics have always been blue. Probably isn't documented. Not convinced it needs documenting. We can't document every tiny inconsequential thing or the already 248 pages will be even longer and become infinite!

I have a thing for complete docs (even if its huge) but that's just me. Yes perhaps this is too small a detail to document. I imagine its hard to know where to draw that line sometimes.

Over the years, I've come to realize that these forums are docs as well and I'm grateful that we can ask a question here and get a straight answer... and often quite quickly too... that's worth a lot.

Regarding LibLoad - what do you mean non-Windows? Do you mean non-System?

Sorry, I already edited my earlier post to remove that and... it was not my statement, I only cut and pasted that in from an email sent to me from someone trying to help... they can elaborate further if they want...

Finally, thanks for all the great info on when LibLoad> is needed... there's a fine example of forum documentation right there.