Hi all,
Apologies if this is obvious to everyone; I am struggling. I have two questions.
Consider the following test.wbt which is written in WinBatch Studio:
;========Start of file=======
Pause("",WinName())
;========End of file
Comments just to clarify that there is no more to this file than that one line.
When I click the icon at the top of Studio to run the file, I get what I want:
WBT - C:\Users\Martin\Documents\WinBatch Programs\test.wbt
Good - it correctly gives me the folder where the WBT file is kept.
Now click the icon for compiling (the one with a W on it) and I get a set of options. To ensure that everything is covered, I select Large EXE and include all the extenders available. The target is test.exe in the same folder. Then I click OK and the file is compiled.
Q1) When I run test.exe from the above named folder, I get less information:
WBT - test.exe
Why did it not include the folder?
Next I copy that test.exe onto a thumb drive (by which I mean a USB solid state device). That device is drive F:
Q2) When I run test.exe from drive F: the program does not even run. I get an error message:
C:\Windows\WBDYB44I.DLL
File could not be created.
Probable cause is that you cannot write to the disk or directory shown above.
Why will it not run?
Thanks for any help.
Omega
Q1) The WinName function returns the window caption of the window created by the exe running the script. WinBatch uses part of the command line of the exe to create the caption. The part used is the file name of the script being executed. In the case of a compiled script, the exe of the script is used since the script name is not on the command line. Traditionally, an executable's file name is the first parameter of an executable's command line.
Q2) The error is self explanatory. When you use the large model, the exe needs to extract its payload of DLLs before it can use them. If it can't, you get the error.
Thanks for the reply.
The second question seems obvious to you, but I still do not understand. When running the program from F: drive, why is it not capable of extracting its payload of DLLs before it runs? The same executable, run on the same machine, under the same user, with the same authorisations, but from disk C:, had no trouble. I am do not understand why it is difficult from F: drive.
Your compiled script does not have write permission to the folder that it resides in so it cannot extract the DLLs.You need to give the account executing the script permission to write to that folder. The permissions are in part determined by the manifest settings you set when you compiled your script. To state the obvious, not every folder has the same permissions.
Should also mention that you will get the same error if the drive does not have enough space for the DLLs.
You can find more information about the compiler in the Consolidated WIL Help file or here:
https://docs.winbatch.com/Reference_Guide.htm
Ok thanks
Also consider only using the extenders you actually use in the executable to reduce disk space usage. You can also use the small model. You would need to preposition the DLLs where your application will find them. Your exe will find the DLLs by searching the current directory, the Windows directory, and on directories in the PATH environment variable.
Yes, the "large" model will always have this problem. Instead, I use the "small" model, and just copy the regular winbatch dlls into the shared drive. Then, the compiled exe does not have to extract anything, and just runs. Plus, if you have hundreds of scripts like I do, you save space, since so many of them can share the same dll file.
There's a little hassle of determining what the proper DLLs are, but once that's done, they rarely change. You just have to remember to copy the new system dll over to the shared drive when you update winbatch.
The URL I posted earlier is incorrect. Here is the intended link:
https://docs.winbatch.com/mergedProjects/WinBatch/WINBATCH_HTC001.htm (https://docs.winbatch.com/mergedProjects/WinBatch/WINBATCH_HTC001.htm)
Manifests are discussed here:
https://docs.winbatch.com/mergedProjects/WinBatch/Manifests.htm (https://docs.winbatch.com/mergedProjects/WinBatch/Manifests.htm)
The funny thing is that the error message tells exactly what the problem is, but OP never tells us *why* the thumb drive is read-only. That's really the crux of this thread.