Home » GalleryRadsoft XPT — Industrial Strength Software
Blobview Software quality assurance tool
How much can you tell about a program before running it? The ideal - 'everything' - is unattainable but Blobview comes very close.
Or you might be experiencing system difficulties: dwindling resources, general sluggishness, and of course you want to know what is causing it. Again, Blobview to the rescue.
Knowing how to use Blobview is a bit of an art, but with time you'll get good at it, be able to recognize telltale signs in executables, and avoid running programs that only yield you grief.
Blobview will tell you the following.
Tab 1: General
Image Size
Image size is the size of the image when loaded into memory. This is not the same as the size of the file on disk. It depends on, among other things, the system's allocation granularity (i.e. the page size). This figure will give you a more accurate clue as to how much RAM the monster will soak up. And with some install app images the figure here can be surprisingly low - this is because their official size does not include the bulk they're carrying.
File Alignment
The portable executable file format is a streamlined view of almost exactly how an image will reside in memory at runtime. It's made that way on purpose. Program loads are supposed to be fast and painless. Virtual memory is normally chunked out at 4KB pages and in an image file the granularity is normally set to 512 bytes. Swapping more at once makes the system use RAM faster and keeping the image file granularity down conserves disk space. All solid thinking.
File alignment never used to be a problem, that is until Microsoft decided to do all in their power to convince people Windows 98 is faster than Windows 95. The concomitant update to Developer Studio will now default to a file alignment making for faster loads on Windows 98 - equal to the image alignment, which is normally eight times that size. Whether Windows 98 loads programs faster is debatable; but any file alignment larger than 512 bytes is wasting space on your disk.
Binding
Binding gets the load addresses of all the image's dependencies and maps them into the proposed address space of the executable, resolving conflicts if it can. So bound images load faster, because all the hookups are baked into the image and don't have to be calculated at runtime.
But binding only makes sense when it's done on the machine where the software is going to run. Many install programs today bind their executables at the end of the install process - this is very smart. So if the image you're looking at is bound, check to make sure you have a copy of an original unbound image. If you don't, and you are sure the install program didn't bind it, contact your ISV.
Tab 2: Data Directories
Shows you what the image is carrying around. The Win32 PE format allows for 16 data directories, of which 15 are today in use and defined as follows:
ARCHITECTURE. Used to be called the copyright directory, or the description string.
BASERELOC. The base relocation table. Perfectly ok to have with a DLL, but not with an EXE. If the file you're looking at is an EXE and this directory is listed, something is wrong.
BOUND_IMPORT. This directory is used when the image is bound.
COM_DESCRIPTOR. A COM runtime descriptor. Don Box must be proud. This could be a sign your system will really sag.
DEBUG. This directory is not supposed to be used in a release build. Raise an eyebrow.
DELAY_IMPORT. Delay load import descriptors. Relatively new. Bloat monsters can cheat by not loading all their dependencies at runtime, but only as they're needed. It makes the monsters appear to load faster. Raise an eyebrow.
EXCEPTION. The exception directory.
EXPORT. The export directory. Important for all images, especially for DLLs.
GLOBALPTR. A machine value directory used on MIPS platforms.
IAT. The import address table. A very important directory.
IMPORT. Not the same as bound imports or the address table. Used for the runtime hook ups.
LOAD_CONFIG. The load configuration directory.
RESOURCE. The resource directory. Resources are accelerators, bitmaps, dialogs, string tables, cursors, icons etc. - watch out for six digit data here.
SECURITY. The security directory.
TLS. Thread local storage. Great stuff - and if the image uses thread local storage, this is where it will be kept.
Tab 3: Debug Info
Release builds should at the very most have a few hundred bytes here, for use on only the most critical of occasions. They're supposed to be satisfactorily debugged before they're shipped, you're not supposed to be your ISV's guinea pig.
Be sure to check with Peeper too - PE headers contain a wealth of information.
Tab 4: Dependencies
All the modules the image file will load - and all the modules these modules will load, and so on. Based on the environment you're running when you do this test. Hold down Alt and double click on any module name in the leftmost column to invoke properties and version info. Jump to any name in the Dependencies list by double clicking on it. Back track back to where you started from by clicking the 'Back' button on the General tab.
A few mouse clicks and you can trace an entire dependency chain. This feature has to be seen to be believed.
Tab 5: Incremental Linking
C++ applications build so slow that it became necessary to invent incremental linking. Unfortunately developers sometimes forget to turn it off when creating a release build.
Tab 6: Runtime Conflicts
Something to really watch out for. Runtime conflicts indicate that the system loader will encounter difficulties when launching the application. Most often it will succeed, but this can often - operative word 'often', not always - be a sign that the executable was built incorrectly.
Rebasing
The entire operating system is rebased prior to shipment, i.e. the load addresses of system modules (mostly DLLs) are calculated to both avoid runtime conflicts and to use every possible byte of virtual address space. Normally they're rebased from the top of User Mode memory and on down, giving ISP applications the greatest possible area to work in, from low in User Mode memory and on up.
It therefore follows that your ISV should show the same care when releasing its software. If this tab shows all proprietary DLLs loading at the same default address, something is very wrong.
Tab 7: Sections
Sections with the same characteristics can be combined, but there's a trade off: slower program loads. So unless there's half a dozen listings here, you're all right. In general, combining sections at build time can be risky business.
Sections not connected with 'resources' and with '80' at the end of their characteristics are uninitialized, and you'll find them mentioned under Uninitialized Data as well.
Section Characteristics
Value
Meaning
Value
Meaning
00000000
Reserved
00000001
Reserved
00000002
Reserved
00000004
Reserved
00000008
Reserved
00000010
Reserved
00000020
Code
00000040
Data (initialized)
00000080
Data (uninitialized)
00000100
Reserved
00000200
Contains comments
00000400
Reserved
00000800
Not part of image
00001000
COMDAT
00002000
Reserved
00004000
Protected (obsolete)
00008000
Far Data
00010000
SysHeap (obsolete)
00020000
Purgeable / 16-bit
00040000
Locked
00080000
Preload
00100000
1 byte alignment
00200000
2 byte alignment
00300000
4 byte alignment
00400000
8 byte alignment
00500000
16 byte alignment
00600000
32 byte alignment
00700000
64 byte alignment
01000000
Extended relocations
02000000
Discardable
04000000
Cachable
08000000
Pageable
10000000
Shareable
20000000
Executable
40000000
Readable
80000000
Writeable
Section characteristics fall into three categories: alignment, contents, and access rights when in memory. All three categories must match if two sections are to be combined.
The values (note that special value 00000000 is reserved as well: a section may not have no characteristics):
Tab 8: Strings
Strings embedded in an image which may give you an idea of what the application will be up to when run.
Blobview looks through the entire image file, because these things can be embedded almost anywhere. Each string has its own significance: some indicate the image itself is bloated; others indicate that the image, when run, will attempt to bloat or damage your system. There are no guarantees here, only indications. But as such they are usually very accurate.
Tab 9: Uninitialized Data
This shouldn't be a problem with most modern images. If there's anything here, talk to your ISV.
Tab 10: Unoptimized Code
All code in a release build should be optimised. In this context 'optimised' means code properly generated for a release build and nothing more. 'Unoptimised code' is therefore code which is not properly generated. Anything at all in this box - contact your ISV.
Saving Reports
If your ISV want to know how you dug up all this dirt, click 'Save Report' on the General tab, save the bloat report to disk, and send it to them. Compliments Radsoft.