I'm in the process of building a program that has several external libraries and extensions outside of the main program files. My projects total size is 134.2 MB. I would like to make a portable version of it with Turbo Studio, but I face one glaring problem; After capturing the files and building the project I'm left with a 138.9MB executable. The program does run, but I don't want it to be so bloated.
I would like to bundle the bulk of the data as a separate .dat payload (or equivalent) but I can't seem to find any means of doing this with Turbo Studio. VMware ThinApp and Cameyo both do this automatically after the project exceeds a certain size, but it would appear that Turbo Studio doesn't.
Any help with is greatly appreciated.
There was a hack I had discovered some time ago that did exactly what you were asking.
It appears that the site that described it is not online anymore so read on.
Install your application while monitoring with TurboStudio.
If there are multiple entry points (e.g., a suite like office may have
shortcuts for excel, word etc) then make sure there are shortcuts for those entry points in the Start Menu. If there are not, then click Start, right click on All Programs, then Open All Users. Make sure you create in that folder shortcuts for all your desired entry points (e.g., one shortcut for word, one for excel etc.)
Capture and Diff with TurboStudio. Set your virtualization settings as desired.
Click Output File-->Browse, and select "All files(.)" in the Save as type list. Then enter a filename with the extension .dat
Build your app. You will now get a .dat file instead of an .exe
In the next step you must use ExeBuilder.exe. This file was originally hosted in csgotwisted.com. Do a google search for "2 utilities for spoon studio exebuilder" and it will most likely be the first result. Unfortunately, the link is dead now when I click it. So I uploaded the file to NitroFlare. You can find it here. Put it in the same folder as the .dat file and run it. It will create a shortcut with your executable. Sometimes it misses the icon, but it gives you the option to locate it manually.
I use TurboStudio often and I have found this way to be the most quick and reliable in allowing me to generate small executables and storing the virtual filesystem and registry in a .dat file. In addition, it has the advantage that it can get you multiple entry points and not only one, just like Thinapp does.
I have recently upgraded to Windows 10 from Windows 8.1.
Now I wanted to set an environment variable for my new installation of Apache Maven.
Each time I created the user variable, things were fine. However, I also need to create the system variable where I will need to append the bin directory to the variable that I already create in the user variable to be "path".
Now, each time I do this, I get an error that says "This environment variable is too large". As a result of this, I am unable to create the path.
I have attached an image of this error.
When the PATH environment variable gets overloaded with too many values it reaches a point where you cannot add values any more. Trying the following should solve your problem.
Solution 1:
Create a new system environment variable, say 'NEWPATH'
Assign the bin directory location to 'NEWPATH'
Now append '; %NEWPATH%' to the PATH environment variable
If this still doesn't work then try to copy some part of the PATH environment variable already existing values to the 'NEWPATH' and then append the 'NEWPATH'.
Solution 2:
Check the value of the PATH environment variable if you can group and shorten the paths. For example,
C:\Program Files\Microsoft SQL Server\102\Tools\Binn;C:\Program Files\Microsoft SQL Server\102\DTS\Bin;
can be combined to
C:\Program Files\Microsoft SQL Server;
In this way, you can build more space into your fixed length PATH variable and finally adjust your bin directory location into PATH.
There are a few ways to clean up your path variable. The easiest is to use Rapid Environment Editor. This free utility will,
Remove the duplicate paths (right click → Cleanup Paths)
Remove non-existent folders (shown in red which you need to manually delete)
Replace long paths with short paths (right click → long to short path).
I do the above steps in order and use the third step only for the longest paths until the Path variable size is under control again.
If you want to go more advanced, here's a little C# tool that you can modify to whatever other logic you want to implement.
Another solution, or more a workaround to bypass the PATH environment variable length limit, is to manage your path (add, remove or update) using a PowerShell script;
Capture the current PATH variable by clicking "Edit Text" (see above screenshot) and copy it to your clipboard and save it in a text file as a backup too to avoid bad surprises. This is not mandatory, but will allow you to recover should something go wrong.
Now that it is backed up, add the following to a new PowerShell (.ps1) file (amending the first line below with the folder path(s) you want to add (the part after the + sign):
$newPath = $env:Path + '; C:\Users\....\FirstFolderToAddToPath; C:\Users\....\SecondFolderToAddToPath;'
[Environment]::SetEnvironmentVariable("Path", $newPath, "Machine")
$env:Path = $newPath
This is how I managed to get my (long) PATH variable back after playing with the Windows 10 UI, being caught by the length limitation and losing most of my path.
Try to modify by RegEdit. In my case it works when length is more than 3000.
Press Win + R and enter regedit to open RegEdit. Go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, and modify the value of Path to your path. And restart the computer, and it should work.
In addition to the answer of Swapnil, note that you can modify the maximum length of the Path environment variable - which is otherwise limited to 2048 characters (while a single path has an historical limit of 206 characters).
In Windows 10, you achieve this by setting the LongPathsEnabled registry key to 1, which can be found here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
To access the registry editor: Windows key + R, type Regedit.
Source: Windows 10 “Enable NTFS long paths policy” option missing
Also take a look at this Super User answer: An answer to Windows 10 “Enable NTFS long paths policy” option missing
Note that the error "Environment variable is too large" is related to the whole variable, not the single path currently being added (to answer the "inaccurate advice" comment below).
Additional note: app compatibility
The text in the registry key/group policy related to LongPathsEnabled reads:
Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node. Enabling this setting will cause the long paths to be accessible within the process.`
The caveat here is the term manifested. In general applications need to declare capabilities explicitly in a manifest file; most win32 applications since the days of Windows Vista are manifested. To use long paths, the app manifest needs a longPathAware element:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>
More info here.
Some users complained that LongPathsEnabled is not yet supported by Windows Explorer and other apps, although in general working alternatives can be found. For example, in this forum post an user states that
The only explorer alternative that does support long paths and long file names is total commander. It also allows to edit file names and open/process the files IF the accepting application also uses the extended API function.
Notepad seems to. MKVtoolnix too. Also, very surprisingly, MPC-HC, even though it hasnt been in development for years. Not surprisingly, sucky VLC does not (seriously?) and neither does the lovely PotPlayer.
There is also an interesting SuperUser discussion on this. In particular, this answer describes two feasible alternatives to use long paths: using Cygwin (a *nix emulation layer) or splitting the long path using NTFS Junction Points (essentially a link, like a symbolic link).
I changed all the paths to variables for Program Files and programdata (this one saves like one character, though not as important).
For something like Node.js, I changed the normal path of
C:\Program Files\nodejs\
to
%ProgramFiles%\nodejs\
This can be done with "C:\Program Files (x86)" as well using "%ProgramFiles(x86)%".
It saved me a few characters, but enough that it stopped complaining, I feel.
I found you can do it via PowerShell.
[System.Environment]::SetEnvironmentVariable("PATH", "C:\Program Files (x86......etc.....", "Machine")
So I grabbed the existing system PATH, pasted into Notepad, added my new thing, and then pasted into the "C:\Program Files" bit of the above. Path was updated. Done.
Apparently Rapid Environment Editor will do this for you (from Shital Shah's answer), but you can also shorten the paths to their 8.3 filename version. You will get a lot of mileage with just these two replacements:
C:\Program Files --> C:\PROGRA~1
C:\Program Files (x86) --> C:\PROGRA~2
If you copy your current path into Notepad, first search and replace C:\Program Files (x86) and then C:\Program Files.
Workaround:
Please restart the system. After restarting the system, PATH is no longer empty, but it may get truncated to 2047 (4095) characters
If the system restart does not help, please:
Launch C:\windows\system32\regedit.exe. Go to the registry hive "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" and clean up unnecessary directories from the “Path” key. Restart the system.
Note: In some exceptional cases if the system is not able to start, please:
Login in the safe mode
Open the command prompt shell and type:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path /t REG_EXPAND_SZ /d ^%SystemRoot^%\system32;^%SystemRoot^% /f
For more details:
Limitation to the length of the System PATH variable
In addition to other methods (e.g., PowerShell), I found a nice GUI, "Rapid Environment Editor" that can handle larger text values.
You can also try going through your variables to see if there are any irrelevant paths you could delete. This would free up some space for you to add another or more variables.
So I figured out the same problem I had, I noticed there were many duplicates pointing to the same location.
I removed the duplicates which can be done with the delete option when you go click the "edit Environment Varibles" button.
You could instead edit text, copy the text from there, remove duplicates using any popular apps like notepad, excel (use the delimiter as ; then remove duplicates), or use python (use .split(";"), convert into a set, ";".join(stringSet), copy into a notepad file, then replace \ with \ using the ctrl+ H ie find and replace).
I had exactly the same problem. Eventually I had to delete one of the existing variables to make the total length less than 2047.
Then I could add %MAVEN_HOME%\bin to the path variables.
Workaround: Use the Edit text button and edit your PATH in a text editor.
I found this AutoHotkey script useful, for editing or adding to my extremely long path (3743 chars now):
https://gist.github.com/roblogic/59898966f3ce594eb78a5b6147013194
(I'm not sure what the consequence of such a long path is; I may still have to fix it.)
I googled a lot and also used regedit on my machine, but to avail,
so I'm asking it here :
I need to retrieve the value of VB6.exe working directory from a Visual Basic 6 Addin (by code).
If I remember well, this is the same directory of the executable by default
("C:\Program Files (x86)\Microsoft Visual Studio\VB98\" on my machine (Windows 7 Pro 64 bit))
but it can be changed right clicking the VB6.exe shortcut and typing the desired value in
the 'Start in' field.
Apparently, there is no way to retrieve it from the VBE class ( or any other class in the VBIDE, for that matter).
I guess the only solution is reading it from the windows registry, but which is the proper key ?
I searched it in HKEY_CURRENT_USER\Software\Microsoft\Microsoft Visual Basic , where the TabWidth setting for the IDE editor is saved, and in many other places.
I also made a full registry search : no luck.
Anybody can give me a hint ?
UPDATE
Sorry for the delay, but I spent some time to test this thing.
First thing, I apologize : I jumped to conclusions too soon.
At a first try, rene's code worked and CurDir did not.
After some tests, both worked or failed , apparently at random.
To discover what was wrong, I created a VB6 addin that uses CurDir, GetCurrentDirectory only,
and both GetCurrentProcess and GetCurrentDirectory to retrieve the current directory.
It logs to a file the above values adding App.Path and whether it is running in VB IDE or
as a compiled DLL.
I then copied the addin project folder in various places, launched each in IDE mode and then compiled.
I won't bother you including the full log file .
Please take my word that all three approaches return always the same value.
To be short, it turns out that the returned value(s) depend on the addin project
directory location.
If the directory is under the parent path of VB working directory,
it returns the proper value either in IDE or compiled mode.
In the other case, it returns App.Path when running in the IDE;
if compiled, though, it returns the proper value.
We can say that rene's and D.Ddgg's solutions are equivalent in this case.
I thank both for their help, but the problem remains.
# D.Ddgg :
The directory at the end of the active path is called the current
directory; it is the directory in which the active application
started, unless explicitly changed. An application can determine
which directory is current by calling the GetCurrentDirectory
function.
It looks like the active path changes depending on the running mode.
What do you think about that ?
Am I missing something ?
I was going through the source code of a rainmeter skin and i could not understand :
TextShortcut1=Computer
TextShortcut2=Libraries
TextShortcut3=Internet
TextShortcut4=Media Player
TextShortcut5=Control Panel
TextShortcut6=Trash
TextShortcut7=ShutDown
TextPath1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
TextPath2=shell:Libraries
TextPath3=http://google.com
TextPath4=shell:MusicLibrary
TextPath5=::{21EC2020-3AEA-1069-A2DD-08002b30309d}
TextPath6=::{645FF040-5081-101B-9F08-00AA002F954E}
TextPath7=rundll32.exe user32.dll LockWorkStation
Can anyone tell me what
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
::{21EC2020-3AEA-1069-A2DD-08002b30309d}
::{645FF040-5081-101B-9F08-00AA002F954E}
these are
and also how can we get one of these for a specific location from our computer.
Those are CLSID (Windows Class Identifiers). Certain special folders within the operating system are identified by unique strings.
20D04FE0-3AEA-1069-A2D8-08002B30309D is My Computer
21EC2020-3AEA-1069-A2DD-08002b30309d is Control Panel
645FF040-5081-101B-9F08-00AA002F954E is Recycle Bin
Source:
http://www.sevenforums.com/tutorials/110919-clsid-key-list-windows-7-a.html
In response to the comment:
can i have Class Identifiers for any folder on Computer or is it just
the bunch of those.
There isn't much reason for you to add more clsids, since you can just go to other locations by typing the normal path. This is a set list that is in the registry somewhere for special folders that don't really have "paths" like C:\windows does.
what is "shell:Something" is it a cmd command or location
shell: is similar to above. It is a convenient way of accessing special folders. Here is a good site for a list: http://smallvoid.com/article/winnt-shell-keyword.html . It is more of a shortcut for Windows Explorer to access a specific location than it is a command. You cant use them in batch files as far as I know (no command line stuff).
what is %something% like %temp%
Those are environment variables. You can usually count on certain ones existing, but the user can change these. Here is a list of some more: http://en.wikipedia.org/wiki/Environment_variables#Microsoft_Windows
how do they all differ?
Well, basically, they are just different ways of accessing the same thing. Some things are more backwards compatible than others, so you have to make that choice when the time comes. If you know your app is going to be on Windows 7 and above, you can make use of some of the more convenient shell:something ones. But if it needs to run on Windows 2000, you might have to rely more on older stuff like environment variables. Environment variables can also be customized by the user.
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).