I have been having trouble this week with auto-extraction of files from a compiled script. Normally, I use small exes. This week, I've needed to run a script on a bunch of machines that don't normally, so I compiled with Large exe, and selected all the extenders used. I have "skip auto-extraction" unchecked, and "Force large exe..." unchecked. (I also tried with Force checked)
The script gets copied to the desktop and run. Everything worked fine -- all the files extracted. I made some changes to the script, recompiled and tested. Only the main dll extracted, none of the extenders (I test in a VM, so I can roll it back to clean each time). Recompiled, same thing. Recompiled -- everything extracted.
Over the course of this week, I've had to "not recompile" and "recompile some random number of times" to get the extractions to automatically happen. It doesn't seem to be related to the code being signed or not, or the timestamping failing or not (which has also given me a fit this week).
Each of the recompiles results in an exe that is the same size as the others (roughly -- I didn't check the exact size, just that it was 39xx KB). I have admin rights on my VM, and roll it back (so no script has ever been run on it) each test. I've also tested outside the VM and on other machines -- if I don't see everything extract, neither do any of the other machines I tested on. (note that I do not compile in the VM, only test there)
To the best I can tell, I'm not changing any compiler options when I recompile. I'm using compiler v2013b.
Is there something I'm missing or should check?
----
Michael
Are you compiling your scripts on Windows 7? If so , you may be experiencing a problem we have discovered that intermittently prevents the compiler from writing settings and/or version information into the executable. We think the problem is confined to Windows 7 and is the result of a bug in the Windows 7 kernel32 API but we are not completely confident about either of those facts yet.
The problem was discovered by another user last week and we do have a workaround that is currently in testing. It will be included in the next release. In the mean time you could proceed as you are now and recompile until the information is added correctly or you can try compiling on a different version of Windows. Your VM software might come in handy for the latter approach.
Yes, Windows 7 64bit. I'll continue as I am, for now. Thank you, and if I can help with any testing, I'll be happy to.
-----
Michael
If you want to try compiling on a different version of Windows, you could use Windows 7's XP Mode. We use VMWare and it allows you to create an XP virtual machine from the XP Mode download. In our testing the WindBatch compiler worked with out error on a virtual machine created from XP Mode. The XP Mode download can be found here
http://windows.microsoft.com/en-us/windows7/products/features/windows-xp-mode (http://windows.microsoft.com/en-us/windows7/products/features/windows-xp-mode)
I am having this issue.. has it been solved?
You can answer that question for yourself by going to the WinBatch "What's New" web page.
http://www.winbatch.com/whatsnew.html (http://www.winbatch.com/whatsnew.html)
Quote from: RAK on December 26, 2013, 02:22:32 AM
I am having this issue.. has it been solved?
Yes, starting with WinBatch version 2013C. Modified the WinBatch 32 bit and 64 bit compilers to workaround a problem that intermittently prevented the compilers from writing options and version information to compiled script executables on Windows 7.
Reference: http://www.winbatch.com/winbatchversions.html#WB2013C
If you are under a current maintenance plan you can download an update to 2013c from the download page: http://www.winbatch.com/download.html.
If you need to renew your maintenance plan please visit our renewals page: https://commerce.windowware.com/webcgi/webbatch.exe?updates/update.web