|Home » Gallery
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 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.
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 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.
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.
|00000800||Not part of image||00001000||COMDAT|
|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|
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.
Click here for a more detailed explanation.
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.
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.
File size: 10.5KB.