Compiled script crashes with latest version compiled only

[Marcus Tettmar]

UPX was not changed. UPX compresses the EXE. It won't affect the running of the program. If it fails, it won't run it at all. If you like, rename/delete upx.exe and compile again - it will compile without it.

Clearly one thing that will alter the binary nature of each EXE is the version number itself. I should have been more explicit - a compare of the *SOURCE* between 019 and 020 shows *ONE* difference: the version number!

There may be other reasons why the binary file is different. For all we know the compiler or UPX inserts a timestamp. Compression may create some randomness. Without knowing the internals of the compiler used to create Macro Scheduler, or of UPX, inferring anything from a binary compare of the executables is impossible.

What we really need to know is: Is the process really hanging completely or is it just unresponsive? Is there a particular line of code it occurs on? If it's during the delete loop, is there any one particular file it occurs at? What we need is to see a log file.

[Phil Pendlebury]

HI guys, I am sorry for all the time you are putting into this. I am super busy here and that's why I have not been able to follow up as I should.

I will set up for a log file and post it asap.

[jpuziano]

Hi Marcus,

Thanks for the detailed reply.

UPX was not changed.

Verified, the UPX.exe file installed under .19 is the exact same file as installed under .20, same contents (binary compare says they're identical) and even the date/timestamp on the files are the same.

UPX compresses the EXE. It won't affect the running of the program. If it fails, it won't run it at all. If you like, rename/delete upx.exe and compile again - it will compile without it.

Excellent, I renamed UPX.exe and as you said... the macro compiles fine... only larger as its not compressed.

Clearly one thing that will alter the binary nature of each EXE is the version number itself. I should have been more explicit - a compare of the *SOURCE* between 019 and 020 shows *ONE* difference: the version number!

Actually I see *TWO* version numbers comparing the *uncompressed* .19 and .20 exe's... here they are... but these are not the only differences:

• 0015acc0 3D 00 00 00 FF FF FF FF 12 00 00 00 4D 53 43 48 =...ÿÿÿÿ....MSCH
  0015acd0 [ 1 ] * 45 44 5F 56 45 52 3D 31 30 2E 31 2E 31 39 00 00 ED_VER=10.1.19..
  0015acd0 [ 2 ] * 45 44 5F 56 45 52 3D 31 30 2E 31 2E 32 30 00 00 ED_VER=10.1.20..
  
  0016faf0 4D 61 63 72 6F 53 63 72 69 70 74 20 31 30 2E 31 MacroScript 10.1
  0016fb00 [ 1 ] * 2E 31 39 00 FF FF FF FF 08 00 00 00 58 2D 4D 61 .19.ÿÿÿÿ....X-Ma
  0016fb00 [ 2 ] * 2E 32 30 00 FF FF FF FF 08 00 00 00 58 2D 4D 61 .20.ÿÿÿÿ....X-Ma

There may be other reasons why the binary file is different. For all we know the compiler or UPX inserts a timestamp.

I took UPX out of the equation by comparing the uncompressed exe's instead. As for the compiler inserting a timestamp, if you mean the creation date of the compiled exe file, that's outside the data of the file itself. And if the compiler were to insert a timestamp within the binary, I would expect it to be in one place... not dozens of places...?

Compression may create some randomness.

Again, not comparing compressed exe's this time so that's out.

Without knowing the internals of the compiler used to create Macro Scheduler, or of UPX, inferring anything from a binary compare of the executables is impossible.

Normally, I'd agree with you and would not have bothered even looking... except that earlier you said...

There were zero changes to the compiler between 019 and 020. The only change between those two versions was to the UI element - to the Macro Scheduler front end. The fix in 020 was to the hotkey/schedule handling code which does not exist in the compiler. I've just done a diff report between the compiler code of 019 and 020 and it reports zero changes.

To me, it stands to reason then that:

• - if there were zero changes to the compiler *SOURCE* between 019 and 020
  - and if the only change in 020 was to the hotkey/schedule handling code which does not exist in the compiler
  - then if I compile a script using 019
  - then compile the exact same script using 020...
  - then I would expect the 19 and 20 exe's to be identical (except for an embedded version number or two)

Is there a flaw in this logic? Phil says they behave differently... and I can believe that very easily because they are different. Here's a comparison of the uncompressed exe's:

• First file name: E:\Phil's Script compiled under 10.1.19 no UPX.exe
  Second file name: E:\Phil's Script compiled under 10.1.20 no UPX.exe
  
  Summary:
  ```````````````````
  374 : 374 Byte(s) diff 1809951 Byte(s) match 1810325 : 1810325 Byte(s) total

And here's a few lines of the differences beyond the version number differences shown earlier:

• 0019ae00 [ 1 ] * 00 00 00 00 D2 82 13 39 00 00 00 00 00 00 09 00 ....Ò‚.9........
  0019ae00 [ 2 ] * 00 00 00 00 84 7E 23 39 00 00 00 00 00 00 09 00 ....„~#9........
  
  0019ae50 [ 1 ] * 18 00 00 00 08 04 00 80 00 00 00 00 D2 82 13 39 .......€....Ò‚.9
  0019ae50 [ 2 ] * 18 00 00 00 08 04 00 80 00 00 00 00 84 7E 23 39 .......€....„~#9
  
  0019aea0 [ 1 ] * 00 00 00 00 D2 82 13 39 00 00 00 00 17 00 00 00 ....Ò‚.9........
  0019aea0 [ 2 ] * 00 00 00 00 84 7E 23 39 00 00 00 00 17 00 00 00 ....„~#9........
  
  0019af60 [ 1 ] * AE 15 00 80 D8 06 00 80 00 00 00 00 D2 82 13 39 ®..€Ø..€....Ò‚.9
  0019af60 [ 2 ] * AE 15 00 80 D8 06 00 80 00 00 00 00 84 7E 23 39 ®..€Ø..€....„~#9

...and dozens more...

In any case, all I'm saying is, given the lack of change between versions, it seems there should not be as many differences as there are. I'll leave it at that.

What we really need to know is: Is the process really hanging completely or is it just unresponsive? Is there a particular line of code it occurs on? If it's during the delete loop, is there any one particular file it occurs at? What we need is to see a log file.

Hopefully a log file will point us in the right direction.

Thanks for putting up with my comments... and take care.

[Marcus Tettmar]

John,

The timestamp I am referring to is INSIDE the executable. I am not referring to a file system timestamp.

The version number appears ONCE in OUR source, but you may see it more than once in the binary because that version number variable is shown/used in different places. E.g. it's used in each script when the MSCHED_VER variable is preset - it's used in window captions, etc, etc.

Unless you know how both compilers work, unless you can see and understand every line of source code in the compiler we use to create the software, and know what the macroscript compiler does, unless you fully understand the structure of Windows PE files, drawing conclusions from binary comparisons is impossible!

I am close to locking this thread because it is wandering off topic and becoming a time sink. Let's concentrate on the matter in hand and wait for a log file. Or if anyone else has compiled Phil's code and tried it, feel free to report your results.

[jpuziano]

Hi Marcus,

No need to lock the thread... I see that no more can be gained from looking at the binaries. Thanks for your replies and for humoring me.

Take care

[Phil Pendlebury]

Hi guys,

No need to lock Marcus, I know this is a pain. I am so sorry that my info has not been more forthcoming. I have been so busy here and was also hoping that someone else may confirm this.

I am beginning to suspect that the app is merely hanging for a long time due to one file that seems to be holding it up. Why this should develop now I do not know.

I'm afraid I am going to be away for 3 weeks as of a few hours from now. So I just wanted to say thanks for all the follow ups (I have never doubted the support here - it is awesome).

Please don't waste any more valuable time on this and I will follow up when I return

Thanks once again,

Phil.

[papi20ver]

Marcus. Greetings.

I did install the _20 version and .exe (my compiled script) put this message , when just started:

"Error initializing MSSCRIPT control"
So, i press enter and it go away.
At the second time that i start the .exe this problem doesn´t occur.

I did taste on Vista and XP Home. This problem occur only in XP.I believe that may be any small diference on this _20 version that make this error.

Please, help.

Cordially.

Papi

[Marcus Tettmar]

Not sure why you have posted this as a reply to this thread. If you search for "Error initializing MSSCRIPT control" you should find your answer. It just means some DLLs aren't registered properly:

http://www.mjtnet.com/forum/viewtopic.php?t=3297