EditSo, what's this "Rebase DLL" option and should I use it?
(answer originally in
Softgridguru.com post by ksaunam)
First, a little bit of background:
In 32-bit Windows, every process has linear 2 GB address space (virtual memory, if you will) in their disposal, space that may or may not map into actual physical memory. For most applications, this memory is only partially used and those blocks of memory that are used may or may not reside in actual physical memory. Some of them sit in paging file if they are not needed (provided that they are not reserved from non-paged pool). If you happen to have that /3GB switch enabled for Windows, then processes get 3GB instead of 2GB on the expense of kernel-mode code that then only have 1GB.
When applications load in Windows, all executable code (modules = EXEs and DLLs) in process needs to be put somewhere in that process' 2GB of linear space. In order to know where to put this code, Windows first examines the header of the module being loaded as there's something called base-address in it. This address is practically speaking a suggestion of address where that module should go, but if there happens to be reserved memory in that range already, then Windows need to find out free block of memory to put that code instead (and probably do all sort of other inline address fix-ups as well to accommodate this new location). And as it happens, most compilers write the same base-address to each and every DLL and EXE unless stated otherwise by the programmer, a thing that does not happen that often.
So, what you basically have in your hand, for most applications, is that when application loads, Windows needs to spend extra time to re-locate code segments to free "slots" in memory, if and when conflicts of base-addresses happen.
And this is where DLL rebasing -process enters into picture. It is a process of scanning all executable modules in a given program, and calculating a unique addresses to each of them so that Windows can just go ahead and put them into address in memory that holds no other blocks of code. And this is what Sequencer does as one of the things it does in the end of Installation wizard phase.
Now, especially in multi-user environment (due to high number of processes running), this whole process of doing scan of free memory at runtime for DLLs can have serious performance consequences and that's why rebasing helps particularly in TS scenario. In desktop, with larger applications, it might have some effect but usually not so noticeable as with multi-user environment.
One of the downsides to DLL rebasing, as you can sometimes witness with SoftGrid's rebasing functionality, is that it can potentially break some applications that have internal expectations on where it's DLLs reside in memory. If you go and rebase that application, it usually ends up with application spitting out "Not valid Win32 image" type of error for some DLLs when starting up. That is also why the feature is not enabled by default and probably never will.
So the decision on whether on not to use DLL rebasing needs to be done app-by-app basis, for some application in some scenarios you will gain noticeable performance increases but not necessarily always. Also it should be noted that digitally signed and 16-bit DLLs are not rebased (for the reason that signed DLLs will have invalid signature if anything is modified even on header and for 16-bit the whole process of memory spaces etc. is totally different).
EditThe difference between User Data, User Configuration, Application Data and Application Configuration SoftGrid -attributes
The only real difference is really based on whether you have selected User or Application.
What's selected as subtype (Configuration and Data) does not technically matter, they carry no semantic difference whatsoever. It is probable that in the beginnings of SoftGrid someone from development team thought that client should treat Configuration and Data -types separately, affecting the copy-on-write branching function somehow. But this never got fully implemented and that's why we still have all four combinations available in Sequencer, for backwards reasons no doubt.
But for the User and Application, there is definitive difference (explanation for 4.x series):
When SoftGrid -enabled application is run on the client first time over, everything is coming from the package; registry keys, files and all. But as soon as something from files and directories -side of things changes, say like that
user.dic file that your application uses as user-specific dictionary, the modified file is
not written back to the cache since the cache is read-only for all intents and purposes. Instead, the file is "branched" according by copy-on-write principle (meaning that everything is read from original source as long as it's unmodified but modification creates copy of the file on-the-fly), and the location it physically is branched to is either to inside of UsrVol_sftfs_v1.pkg -file underneath user account's own SoftGrid cache directory (typically %appdata%\SoftGrid Client) or to inside of GblVol_sftfs_v1.pkg -file sitting under system's SoftGrid cache directory. And the choice of which of these to use is dictated by ... SoftGrid File Type (Application / User). These files are also under package-specific directory, so that each package has it own UsrVol and GblVol files.
The basic underlying distinction of User and Application (besides it's technical details above) is to control to whom these changed files are visible to. If it's branched to UsrVol -file under user's own profile directory (meaning that User filetype was used), then the modified file is visible only to that particular user. Any other users of same application on same machine still sees the original file from package or their own branched version if such exists. If however file is branched to GblVol -file under "common cache", the change will be visible to all users on that machine. So you can use these file-types to control how change to various files inside package will show up, sometimes even solving some multi-user issues with marking some files as User.
Before 4.x SoftGrid, the basic branching idea was the same, but then there weren't any UsrVol and GblVol files at all. In pre-4.x clients, all changes were branched as copy-on-write, but each individual file was stored as is under user's cache directory or in system's cache directory, resulting a huge amount of branched files laying around "named" in filesystem. Then, underneath package-specific subdirectory, there was file called
settings.cp, which served as holder for symbolic links pointing to those individual files. So much was improved in 4.x series when we finally got rid of those files cluttering up profiles and all, replaced with clean solution of just two files per package holding all changes.
EditWhat is the effect of "Virtualized" option for folders on Virtual File System -tab
If you have Virtualized -attribute set for folder on the VFS tab of Sequencer, it will cause SystemGuard to handle those folders (and files / folders underneath)
fully virtualized as opposed to handling them as "partly virtualized".
The operational difference between these two types are as follows:
EditFully virtualized folders
Fully virtualized folders will appear on the target system on top (overlayed) of the real filesystem regardless of whether they actually exist or not over there, possibly masking real folders and files if they happen to be present on the real thing. This is handy if you want to make sure that application run from the package does not see any leftover data in filesystem from local installation, for example.
Let's say that we have folder called "%CSIDL_APPDATA%\Myapp" on the VFS -tab, fully virtualized. When running this package on client, application will see folder called "Myapp" in user's Application Data -folder(where ever that may be). Furthermore, if there's already folder under same name in real filesystem, application will
only see one defined inside package, making real equivalent folder totally invisible to application being run.
If application chooses to create new folders or file inside this fully virtualized folder, those additional items will be cached inside user's UsrVol...pkg file and do not appear on real filesystem. On some occasions, this might not be what is wanted as there is not straightforward method of getting access to those cached files and folders outside of the package itself (backup purposes etc.).
EditPartly virtualized folders
Partly virtualized folders will be, content-wise, merged on the client with folders on the same location. What application will see is combined view of folders and files from both the real filesystem and from the package. Those files that conflict (name-wise), will be shown so that the file inside package overrides local one.
One big drawback of partly virtualized folders is their reliance of folder being physically present on target system. What this means is that folder being partly virtualized (Virtualized -option not set on Sequencer) has a reliance on having physical counterpart present on filesystem being overlayed, otherwise it will not show up at all! So any and all partly virtualized folders need to be on the target filesystem as well, otherwise they won't be visible to application being run, even in their VFS -defined form.
New files/folder created to partly virtualized folder will go to the real filesystem whereas files already defined in VFS, if changed, continue to stay cached in virtual environment (UsrVol...pkg file).
Back to the FAQ main page