AutoHotkey Community

[Icarus]

There seem to be some problems in the two last builds (1.0.46.07 and 08)

In the 07 build, some of my compiled scripts did not obey the ExitApp correctly.
The executable seemed to be closing fine, but it stayed resident in memory, and had to be killed.

This was solved in 08, but in 08 I found another problem, which is harder to explain, but I will try anyway.

I have a script that works perfectly fine on its uncompiled version and also works fine when compiled with the 1.0.46 build.
When compiled with the 08 build, I get inconsistent results - the executable sometimes works as expected, and sometimes does not and create unpredictable, but reprodicible) results.

I use a simple DllCall command in this script, that might be the source of the problem - all other activities in the code seem to be operating fine - but this is just a hunch.

If someone is interested, I can send the executable and/or the code to any email address - the code is too large for a post and contains some includes and additional required files.

For now, I rolled back to the last stable build 1.0.46.

[Chris]

When using DllCall, you must be sure to call VarSetCapacity() when required. Otherwise, the program might become unstable even if no error is indicated. Furthermore, there may be other ways DllCall can disrupt program stability.

If you ever find a short script that reproduces the problem on any PC, please let me know.

[Icarus]

I am using a simple DllCall, copied from somewhere, just to change the wallpaper

DllCall( "SystemParametersInfo", UInt, 0x14, UInt, 0, Str, FinalPaper, UInt, 1 )

(where FinalPaper contains the path to the new bmp wallpaper)

As I mentioned, it works perfectly with previous builds and when not compiled, so I am assuming something changed for the worse in these builds.

How can I compile using a different version than the one installed? If there is an easy way, I may try to create a shorter script that hopefully reproduces the problem.

[Chris]

[Icarus]

Yes thanks - instead, i downloaded the zipped version, and now using the files in this compiler folder to compile.
was unable to reproduce using a shorter script but there is definitely something inconsistent in the behaviour there.

may look deeper and attempt to eliminate unneeded code slowly.

will post back here if i can create an easy to follow reproduction

[Chris]

I appreciate your willingness to look into it further.

[Icarus]

Ok, I think I nailed it.

I am posting here the shortest code I was able to generate that reproduces the problem on 5 XP Pro computers.

In order to make it work, put 4 BMP images in the script dir.
When I tested, I used 1.bmp, 2.bmp 3.bmp and Wallpaper.bmp.

For your convenience, and in case it has anything to do with the bug - I have uploaded the images I used to a web site - get it here (>2mb)

Now, after you have placed the AHK file and the bitmaps in a folder, run the script.

In its uncompiled version, you should see the wallpaper changing every 3 seconds
In its compiled version (with 1.0.46.08 ) - some weird things happen
It will either not change the wallpapers at all, or change them into your desktop color with any gui control in the middle (like a checkbox)

My Wallpaper settings in Windows is set to "Stretch"

Now, one last thing - if you do not see the bug - try placing the entire folder in a different location (or rename it) - The bug only happens with some folder names, only when it is compiled, and only with the 08 build.

I hope this is not a wild goose chase and that it is not my own fault, but I was unable to explain the results.

[Chris]

Since you tested it on so many PCs, I'll take your word for it that it happens. Unfortunately, I can't think of any possible change in the code that would explain this behavior other than the Terminal Server Awareness flag (and even that's a stretch).

Due to a mistake, the current version (.08) probably doesn't have the Terminal Server Awareness flag disabled as intended. Therefore, I've compiled a test version that disables the flag in case it's the culprit.

If you get time to test it, please let me know your results:
http://www.autohotkey.com/misc/AutoHotkeySC-TSAware-Disabled.zip
(Replace your BIN file in the compiler directory with the one in the above zip, then recompile your script.)

Thanks.

[Icarus]

Sure thing.

Will test and post back.

[Icarus]

Ok, tested and the results are the same.
I found that it reproduces consistently only with some directory names.

I put the BMP files and the compiled scripts in this folder, and it reproduces easily:

C:\Scripts\~WallpaperRandomizerBug

Also, the compiled exe is named WallpaperRandomizer.exe
Dont know if its the word "scripts" in the folder that does it, but I thought I'd mention it also.

[Chris]

I can reproduce this bug on Windows XP. The bug first appeared in v1.0.46.01, but I haven't isolated what's causing it.

I currently believe it's more likely to be an OS bug. There have been some posts on the Usenet that SystemParametersInfo() does some unusual memory checking, which perhaps is incompatible with DllCall or some other aspect of the program. Further evidence is that:

• SystemParametersInfo() fails for some filename lengths but not others, even though the successful filenames are at the same memory address as the ones that fail.
  
• The alternate BIN file mentioned below solves the problem even though it is compiled from exactly the same source code. The only difference is that it uses the DLL version of the C runtime library.

One way to work around this is to use the alternate BIN file to compile your scripts: http://www.autohotkey.com/download/AutoHotkey_sc_bin_min_size.zip
Place this smaller version of the AutoHotkeySC.bin file in your AutoHotkey\Compiler folder (overwriting the existing file of the same name). Any compiled script produced in this fashion will be dependent on MSVCRT.dll. Although this DLL is always present on Windows 2000/XP or later, older operating systems do not necessarily have it.

I might continue to look into this; but at this point it doesn't look promising because I have no access to the source code for SystemParametersInfo(), so I can't see why it's behaving this way. It could be that there is some other bug in AutoHotkey that is indirectly causing this; but if so, it must be very subtle because there have been no other reports like this one even though v1.0.46.01 was released over two months ago.

[Icarus]

Thanks.

My workaround is as you mentioned - I am compiling with the BIN version from an older AutoHotkey build - the 06 build - and it works smoothly.

Perhaps a different approach to solving it, would be to "diff" 06 and 08 builds and start rolling back some of the changes in 08.
As I mentioned, something also changed for the worse in 07 build - other compiled scripts of mine - when compiled with 07 - did not ExitApp properly - they stayed in memory and had to be killed.

I consider 06 as the last stable build.

Thanks again for looking into it

[Chris]

[Icarus]

I was unable to reproduce the problem with the 1.0.46.06 build, so i assumed it does not exist there.

But I take your word for it - I may have missed it.

[haichen]

Works with .08. without problem. I can change the name of the dir or move it. Wallpaper change every few seconds.

Amd 1800, winxp sp2, latest updates.