Turbo Studio virtualization - windows

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.

Related

VB.NET file has become an unreadable format

So the images below were originally a vb files. I have just opened it and it looks like this and the compiler won't run it. I am unsure whether this is a compiler error or whether it may have become corrupt because the project is stored on an external drive. It is just these two forms that have broken like this; I have one other form and a module in the same project that are okay but the project can't run because of the two that are broke.
Broken Login Form
Broken Diary Form
If it changes anything, the designer files for the forms are intact it is just the scripting for the forms elements that is broken.
Also, if I can't identify the cause, is there a way to revert it back to the last working version in visual studio to get my code back? Just because I put a lot of time into it.
The data in those files is most likely gone.
IMPORTANT: Do not write anything to that disk drive unless you find that you cannot recover those files.
If you are using a version control system then you can revert to an earlier version.
If you are using Windows 10 and you happen to have stored those files in a location included in what File History saves, you can recover them from that.
If you use some other form of backup, retrieve the files from that.
If you have a separate disk drive with at least as much free space as the one with the corrupted files, you could try running file recovery software as it might be that the zeroed-out file was written to a different place on the HDD.
TinTnMn pointed out in a comment that if you previously compiled the code, you should have executable files in the "obj" and "bin" folders that can be decompiled to recover most of your work
It could be quicker to re-write the code while it is still fresh in your mind.

Managed C++ rename refactoring without keeping files open

I'm currently using Visual Studio 2010 and Visual Assist X to do rename refactorings in managed C++ code. For small codebases or renaming items which are not used very often in the code it works great.
It's almost impossible to rename an item which is used frequently in a large codebase because Visual Assist keeps every changed file open and unsaved. This means if there are a lot of files open the next file takes even longer to be opened.
Since I'm using version control this does not make sense to me because I could revert all the changes if something went wrong.
Is there a way to do that refactoring without keeping files open? Maybe also with another VS extension? I did not find any information about so far...
For example:
I have a solution with about 100 projects, if I rename a class which is used frequently Visual Assist X's execution of renaming takes about 30 minutes or more. It opens every file which must be changed. As longer the renaming runs, the more files are open in VS and the more longer it takes to open another file...
At least there is a workaround.
When I have too many tabs open, I close them via Window / Windows ... and there Ctrl+A, de-selecting one or two needed windows and then "Close Window(s)".
Additionally I use File / Save All excessively. I have it mapped to Ctrl+Shift+S but I'm not sure if this is standard.

editing pre-existing cab files/installer files

I'm currently trying to make a download/install file for a CD, and I've never done this or written any type of coding before so I'm somewhat at a loss. When we last created an installer package (I wasn't employed yet) we used InstalShield, but that was decades ago, and we can't afford the 500$+ price to get it again.
Currently I'm trying to work off the old download package we have. There is the Windows Installer Package (made by InstalShield) called CD Cat v6.msi, and then another file called CDcatv6.exe (which launches a window for the customer to browse options) and then a file called Data.cab which has all the files for the entire catalog in it.
I was thinking perhaps I can just replace a lot of those files with the current information. Replace the CDcatv6.exe file with my v7.exe file (but change the name so its CDcatv6.exe) and then replace all the files in the Data.cab file with the current ones. But that's turning out to be a huge issue.
I did a bit of searching to learn what a .cab file was, and downloaded the Cab File Maker 2.0 (after quite a bit of searching!). I'm having a difficult time using it though, as it wants all the files that I put in it to make the .cab to be in .ddf format. I have no idea what that is, much less how to make it. I tried using 'save as' to do it, but since all the files I need are PDF's there's no option for it and I cant export the files to it either.
I tried looking at other ways that people made Cab files, but I don't know many of the file types or programs their talking about. I'm not a programmer by any means, but I have to learn quick I guess, so any information on how to do this will help greatly. Is it even possible to replace all the files seamlessly and have it work properly? Or is there an easier way to create a fill that the customer can click on and have it download to their desktop?
I don't think simple editing of Data.cab will work. There is installer logic stored in other InstallShield files. It could work if and only if the file set is the same, I mean no files changed its names, no new files added, no new registry entries required etc.
To create a CAB file, use cabarc.exe from Microsoft Windows SDK.
Creating a brand new installer may be a better option. Look at this tools for creating installers:
Advanced Installer
NSIS
WiX toolset (with tutorial)
You best solution is to use dark.exe (part of the WiX toolset).
This will enable to you decompile the MSI and CAB files, edit the installer source as XML and then recompile this into a new executable. Unfortunately this route is not for the faint of heart and what you save on price will cost you in time.
I'm curious how your company created an MSI decades ago, but Sasha is right about time and money trade-offs. However if you're working with Visual Studio, you might try the InstallShield Limited Edition for Visual Studio. It may have enough capabilities to suit your needs.
Thanks for pointing to CABARC, that looks exactly what i was looking for, due to information on:
https://learn.microsoft.com/en-us/previous-versions/bb417343(v=msdn.10)?redirectedfrom=MSDN#top
That make me look how to download it, but i found this post:
Where can I get the cabarc utility?
Where it explains CABARC may be obsolete and there is another utility called MAKECAB that cames with Windows 11, i had try it at command line and it is there.
Thanks a lot.

Create an installer program: read a path to install to, from registry key (something like wix/installshield/nsis)

I would like to create an installer of my program.
However because the installation is quite complicated, I need something more advanced than installshield limited edition.
I have to run another installer from my current one. It doesn't matter if the user press "cancel" or installs the program, I just need to run it.
I have to install a directory structure on user computer which has a lot of files, that's why i'm going mad with wix: 100 files and I should write all of them with my hands in that xml file? Are we mad?
I have to install files from point 2 into a registry key. That's why I was using wix
I played with nsis long time ago and I liked it, but the language is not so nice.
Wix has "similar" problem. I would love using something like C# and things like that otherwise I'll stick with wix but I need a way to add files faster to xml file, can't add 100 files manually.
Any suggestion?
You can give Advanced Installer a try. It has folder synchronization, which means it can batch add contents of folders, with the possibility to filter out certain file name patterns, for example you'd want to filter *.pdb files and add all the rest to the project automatically.
I use it myself and never had a problem.
Wix Heat can generate the wxs source files for you.
You should look at InnoSetup. It has an IDE available that allows drag and drop of files (and multiple select in a file selection dialog), can launch other applications (including additional setup files), create and modify registry settings, and supports pretty complex scripting if needed. It's pretty easy to use, and the documentation is pretty good. It comes with pretty comprehensive sample installations, too.
The installation scripts are created by the IDE and then compiled into an installer, so the script source is editable by hand if needed. It's also not XML, but more like an INI file, so it's a little easier to work with manually as well.
Best of all it's free, and so is the IDE.
I would go back to using NSIS, if you use the HMNSIS editor http://hmne.sourceforge.net/ to write your scripts you can use the Wizard mode to make a list of the files and directory structure you will use in your installer.
Running other installers and registry settings are also easily done with NSIS.

Are .OCA files necessary for program execution?

In the system32 directory I saw an .OCX file with a corresponding .OCA file.
I had thought .OCA files are used only by Visual Basic. Are they therefore unnecessary for program execution and could be removed?
If they are unnecessary, why would there be an .OCA in the system32 folder in the first place?
.OCA files serve as a cache of the extended type library information for its corresponding .OCX file.
If you delete an .OCA file for a control VB recognizes and uses, VB will recreate the .OCA file when you load a project requiring the control. The recreation process takes a little time but comes with no penalty otherwise.
Last reviewed: April 4, 1996
Article ID: Q149429
SUMMARY For every custom control file (.OCX) that Visual Basic uses,
there is an accompanying .OCA file of the same file name. For example,
GRAPH16.OCX has an accompanying .OCA file called GRAPH16.OCA. An .OCA
file is a binary file that functions as both an extended type library
file and a cache for the custom control file.
MORE INFORMATION
A type library is a file or component within another
file that contains OLE Automation standard descriptions of exposed
objects, properties, and methods. The actual working type library for
a custom control used in Visual Basic is a combination of the type
library of the control itself and the additional properties provided
by the framework that wrap the control.
Some of the properties of the control are provided by the framework
and some by the control itself. Programmatically, the properties from
the framework and the control all appear as properties of the control.
In order for these properties to appear, Visual Basic creates an
extended type library when the control is loaded into the toolbox.
Because the process of reading the control's type library and creating
the extended type library is time consuming, Visual Basic caches the
extended type library information into an OCA file.
If you delete the OCA file for a control Visual Basic recognized,
Visual Basic will re-create the .OCA file when you load a project
requiring the control. This re-creation process comes with a time
penalty.
(http://support.microsoft.com/kb/149429)
So, don't worry about including them when you deploy your application.
Sorry to resurrect a zombie thread, but I want to summarize to make sure I understand this.
An OCA file is only needed during compilation of a program and if it is missing, VB will create what it needs so all that is lost is time during compiling. Unless you have really sloppy programming and another homemade dll or ocx needs a particular oca.
If an oca is shipped with a product, it should be able to be safely deleted.
No, they are not necessary for it to execute but they are necessary for the program to run properly (if the program required the file in the first place).
They never need to be deployed with a finished program for it to run.
This could be a dumb attempt to answer, but you could simply rename the file and see if the application quits working. If so, those files are necessairy.
DNA-science is about the same:
Remove a gene and see what stopped "working". De facto, this gene is related to / necessairy for that body-part or whatever.
Re: No, they are not necessary for it to execute but they are necessary for the program to run properly (if the program required the file in the first place).
Since execute and run mean the same thing - what you are saying is that:
it's not required for it to run but it's required for it to run properly??
or alternately
it's not required for it to execute but it's required for it to execute properly??
I am suspecting that the *.OCA files are not required EXCEPT for compiling a program using VB and if they don't exist when you load a project then VB will create any missing OCA files automatically in order to speed up future load or compile operations in VB.
I just deleted EVERY OCA file off my system (I'm a brave man when I'm using a cloned virtual machine to do this).
I then rebooted and ran my software and it worked just fine without ANY OCA files on my entire system. Now it might take a bit longer to load/compile my programs next time as vb will regenerate the OCA files but I'm using an i7 with 16Gb of RAM and an SSD so who cares!

Resources