About | Buy Stuff | News | Products | Rants | Search | Security
Home » Gallery

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

ValueMeaningValueMeaning
00000000Reserved00000001Reserved
00000002Reserved00000004Reserved
00000008Reserved00000010Reserved
00000020Code00000040Data (initialized)
00000080Data (uninitialized)00000100Reserved
00000200Contains comments00000400Reserved
00000800Not part of image00001000COMDAT
00002000Reserved00004000Protected (obsolete)
00008000Far Data00010000SysHeap (obsolete)
00020000Purgeable / 16-bit00040000Locked
00080000Preload001000001 byte alignment
002000002 byte alignment003000004 byte alignment
004000008 byte alignment0050000016 byte alignment
0060000032 byte alignment0070000064 byte alignment
01000000Extended relocations02000000Discardable
04000000Cachable08000000Pageable
10000000Shareable20000000Executable
40000000Readable80000000Writeable

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.

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.

File size: 10.5KB.

About | Buy | News | Products | Rants | Search | Security
Copyright © Radsoft. All rights reserved.