Home > Blogs > VMware ThinApp Blog

ThinApp Data Containers, Entry Points, and DATs – Oh My!

Often, we get asked one of the following questions or a variation of them:

  • What is a ThinApp Data Container?
    • Is there more than one Data Container?
    • What is the Data Container used for?
    • What does the Data Container do?
  • What are ThinApp Entry Points?
    • What are Entry Points used for?
    • What do Entry Points do?
  • Why does ThinApp sometimes recommend a “.DAT” file?

Often times, when people get to this below screen, one or more of the above questions appear in our email inbox.

ThinApp Java - 6.png

What is a Data Container?

Very simply, a Data Container is “the big Kahuna”. The real name is the “Primary Data Container“. However, to be clear, there is nothing “primary” about it since there can be only one Data Container per ThinApp package. Put simply, this is the file which essentially stores everything. Including the Virtual File System, the Virtual Registry, the ThinApp Runtime (or Virtual Operating System or VOS), ThinApp License, and anything else not listed here.

So what are Entry Points?

Entry Points are nothing more than EXE files which act as shortcuts into the Primary Data Container (moreover, the Virtual Operating System within it) to launch their defined program. To put in other terms, these are the external Windows executables which allow us to launch a ThinApp package (creating the virtual bubble) and directly launch into a specific parent application.

As an example, if we virtualize Office, we’ll most likely have a .DAT file and a bunch of .EXE files. Each of these .EXE files are Entry Points into the Data Container (and subsequently into the Virtual Bubble) to launch the specified app (in this example, Word, Excel, Outlook, PowerPoint, etc.).

ThinApped Office

Where it gets a little tricky to understand (referring to the Setup Capture screenshot at the top of this article) is when capturing a single executable application such as Opera, Firefox, or Adobe Reader. This is because the single Entry Point and the Data Container can be of the same file name, thus allowing us to create a single executable for an entire application.

So why does ThinApp sometimes recommend using a ‘.DAT’ file?

This is actually done for a couple of reasons, the primary being Windows Operating System limitations which prevent executable files from being over certain sizes. When an ‘.EXE’ is over it’s file size limitation for the specified OS, weird things start to happen such as the Icon will not display on the ‘.EXE’ and the app may have issue launching (See the ThinApp Blog article, “Top 10 Questions on ThinApp“).

The other reason is somewhat a benefit of just making smaller executable files – which is, they launch faster since larger executables tend to take a longer time to launch due to loading of the large EXE into memory or due to the Anti-virus solution scanning the large EXE file.

One thing we always like to note is, the Data Container name does not need to be a ‘.DAT’ file – but can be of any file extension! VMware (and formerly Thinstall) chose the ‘.DAT’ extension as it made logical sense to most everyone already. However, we don’t need to use a ‘.DAT’ extension – or any extension at all. For example, we could capture an application and make the Data Container name “ThinApp”, or “ThinApp.Package”, or even “ThinApp.Rocks”! ☺

So, feel free to get crazy and make your ThinApp packages work for you. And don’t forget, this and other additional information can always be found in our ThinApp Online Documentation as well!

This entry was posted in FAQs, Tips and tagged on by .
Dean Flaming

About Dean Flaming

Dean is currently an EUC Architect and member of the VMware End User Computing Enablement and Lighthouse Support teams, working to develop communications and IP around VMware End User Computing products and solutions as well as support many various Lighthouse accounts with their own EUC practices. Prior to this, from 2008 through 2012 Dean was one of VMware's End User Computing Specialists. Throughout his time at VMware, Dean has also written and published various articles, videos, and podcasts regarding VMware's EUC Solutions.