Bill Buckels Software Engineer

Buckaroo! Read the inimitable Bill Buckels follow up here

If the expression 'caveat emptor' doesn't apply to use of latter-day commercial software, the Romans should have spoken Greek instead. This is the one arena where its letters should be etched in stone and their meaning burning in a blazing fire.

Bloatbusters™ front runner Blofeld uncovered the following booby trap:

> Also, I found this description of a Windows garbage collection
> program. Sounds interesting.
>
> http://www.escape.ca/~bbuckels/garbage.txt

As ever, people are searching for a solution to the unsolvable Windows 9x problem of dwindling resources and the notorious and well documented memory leaks. (Check Michael Tuck's excellent Windows 9x site for specifics on how this happens and how it is completely unavoidable.)

And right as rain, everywhere you turn, con artists, pseudo rainmakers, and one man medicine shows continue to try to capitalize on end user anxieties. Some want money, others want fame, but whatever the booty of the con, the wares are equally worthless and phony.

The only known cure for the leaks in Windows 9x, aside from re-booting all the time, is to upgrade to Windows NT or Linux. No utility on the market will do anything beyond what the 'operating system' will do on its own, if just left to its own to do it.

But Bill Buckels Software Engineer takes a rather unique and original approach to this dated game. Marketing what he thinks only he knows is a completely useless Win16 program that did precious little even back under Win16 and absolutely nothing now, Software Engineer Bill puts together a diabolical concoction of double talk and fabricated jabberwocky designed to have his unwitting and uneducated site visitors going 'ooh' and 'aah' and drooling all over him. It's pure bull or 'Bill' if you will - right from the start and through to finish. Only Bill Buckels Software Engineer knows this - or so he thinks. But now the dirty secret is out.

Software Engineer Bill is good at obfuscation: he hides the true nature of his pitiful program in a cloud of pseudo terminology that's all jabberwocky mostly plucked straight out of thin air and made up on the spot. Almost no twist of any of the cute and clever phrases has any basis in fact. What's more, this is a 16-bit app - something that is not mentioned anywhere - and its functionality, what there is of it, will not even work under Windows 9x.

Yet no mention is made of this anywhere. Naturally. You're supposed to download his 'garbage' (quite an apt name it must be admitted), install it, and then by means of the typical placebo effect - the way they all 'work' - think there's been some improvement when nothing at all has actually happened, and then come back to Buckels' site a member of the faithful and try out some more stuff, put a few feathers in Software Engineer Bill's cap and a few dollars in his pocket - and it's an old game, a very old game on the PC, one of the worst, most insidious, and most prevalent since the inception of Windows 9x - and it's all 'garbage'.

This small utility attempts to force Windows to adjust the global memory
heap to make the largest possible memory block available for the next
program to use.

Sure - under Win16, and at least in theory. While in practice, nothing happened at all. The call GlobalCompact which is the basis of this smoke and mirrors act was as good as never used by professional developers anywhere, ever, and for good reason: it didn't accomplish a thing.

Win16 had allocation hooks, the 'Global***' family of calls, which directly corresponded to the 'Local***' family for allocating memory, re-allocating memory, and freeing memory. The difference between the former and the latter was that the latter assumed the selector value was in the DS register and the former did not. GlobalAlloc, as its cousin, returned one of two types of data, either a handle (HGLOBAL) or a pointer, this because the type of allocation could vary and was specified in the first function argument, normally resolved to GHND or GPTR. If you wanted a pointer, you simply used an explicit cast.

Back in Win16, both global and local pointers referenced what were known as descriptor tables, where the actual 'segment' value (shifted and then added to the offset value) was stored. This made it possible in theory for the 'operating system' to move things around on the fly.

But in practice this never happened.

When GHND was used, GlobalAlloc returned a handle. You could not access memory with this handle (in theory), but had to 'lock' it for use first by calling GlobalLock. The return value from this call was a pointer to your allocation.

But this was all smoke and mirrors anyway. As any number of Redmond hackers disclosed, a simple macro took one from the handle value to the pointer value and back again. In practice, this memory never moved.

The processor - exclusively Intel back then - could have juggled things around, updating segment values in the descriptor tables as it saw fit, but in practice did nothing of the sort. Not even when GlobalCompact was called. It simply did not happen.

Allocations made with GPTR were placed at the bottom of physical RAM, and allocations made with GHND were placed at the top. This made good sense. The former were officially 'FIXED', the latter officially 'MOVEABLE'. By placing the one kind as low down as possible and the other as high up as possible, the operating system made sure the largest possible contiguous free space was available (remember, this is before the advent of virtual memory - we're still talking actual physical RAM here).

If the 'operating system' had wanted to move things around, it could only have done so with the allocations marked as 'MOVEABLE' - by definition it couldn't touch anything else. But it didn't want to move anything around. GlobalCompact was simply a throw-back to an era before Windows 3.1x 'Protected Mode'.

It waits for a few seconds, empties the clipboard, adjusts the heap, and
writes the results to a log file called GARBAGE.LOG in the current
directory.

Oh lovely. Who asked to have the clipboard emptied? You're editing calmly and comfortably away and then suddenly ZAP! Your clipboard is gone! Words cannot.

If one really needed an application to empty the clipboard - doubtful but nonetheless - such a hack can be written in seconds (about all Software Engineer Bill Buckels should have needed to write 'GARBAGE').

There is no guarantee that garbage.exe will cleanup all the memory since
many variants exist in the Windows environment. Garbage.exe does not
discard unused classes, unused DLL's or unused resources, and depends on
windows to do some of this when called for heap consolidation.

This is so much jabberwocky it's not funny. These are simply buzz words pulled out of a very flimsy rabbit hat. There are no 'variants'; 'unused classes' is a fabrication; the concept 'unused DLLs' simply does not exist; 'unused resources' was nothing you could do anything about back then anyway, as the records in the GDI databases did not have fields specifying who owned what. Even 'heap consolidation' is a bit extreme.

Running garbage.exe twice in a row with a pause in between may yield
improved results on a badly fragmented windows session. Another
variation to try would be to call garbage.exe after a brief pause.

The phrase 'badly fragmented windows session' had us in stitches here. Again, it's all just plucked out of the blue. Nothing like this existed then, and it sure doesn't now. The 'brief pause' had us in hysterics.

Garbage.exe is designed for use with linear batch processes in windows,
since running subsequent iterations of these without garbage collection
in-between may cause an eventual fragmentation of windows resources.

Oh such BIG WORDS! And the classic 'linear batch processes' has got to go into history as one of the best attempts at double talk ever. There is no such thing as linear batch processing, it's all bull, bull, bull. There is no such thing.

And - feeling nauseous now? - what for heavens' sakes is 'fragmentation of windows resources'? Feeling even worse?

It all sounds rather impressive, but actually means nothing at all - except, perhaps, that its author is an enthusiastic con artist.

In doing its memory management, windows starts the next task before the
previous one is completely done, which can create successively smaller
contiguous blocks of memory in the global heap.

Garbage.exe attempts to minimize the effects of this fragmentation.

Too rich for words. We laughed so hard the tears started running. For one, there is no indication, either through empirical studies, perusal of Intel handbooks, or culling of information from Microsoft, that any of this has any basis whatsoever in reality. It's never been heard of anywhere, at any time, in any place. The act of 'concoction' here is so blatant, so obvious, that we couldn't stop belly laughing all over again.

This is so much unqualified 'buckels' that it's not even funny anymore. Again, it's completely made up, it's complete jabberwocky (ok, call it horseshit or bullshit if you want), it's completely plucked out of the blue. As science fiction it might be worth a read, or qualify for one of those stereotypical Hollywood screenplays; but as serious documentation by a 'software engineer' it's a disgrace - it's deliberately misleading, directly criminal. The program itself is trivial - the effort to cloud, confuse, lure, mislead, and obfuscate is on the other hand extremely sophisticated.

The crapola goes on and on in the readme by Bill Buckels Software Engineer, but you've seen enough by now. The flight bags are no doubt bursting at the seams.

We therefore sent a simple letter to 'Bill Buckels Software Engineer', Bcc'ing it to Blofeld at the same time, and used an anonymous offsite domain (Hotmail) to send it. Bluffs like Buckels have a way of wanting to suck up to people who they know can call their bluffs: what was interesting was to see how our software engineer would react to an innocent letter from an innocent lowly end user.

This is a Win16 program. GetFreeSystemResources is a USER.dll call and does not
exist under Win32. 

GlobalCompact didn't do much back then, and now does even less: 

The GlobalCompact function is obsolete. This function is provided only for
compatibility with 16-bit versions of Windows. It has no meaning in the 32-bit
environment.

We couldn't have known then what lode we'd struck. Here's the reply (get ready, this is a nasty one):

So What? Of course this is a WIN16 program. I used it under WIN31. Your
message is pointless and sounds like it was quoted from the Microsoft
Knowledge Base. The Garbage program was written a long time ago and did what
it needed to do back then.

And who might you be? (i.e. Who died and made you God?)

Quit bothering strangers and go to bed. Your patients will suffer if you
don't get your sleep. Or are you some other kind of Doctor?

Physician, heal thyself. If you don't like my website then take a pill and
set-up a website of your own. All I see here is some punk with a hotmail
account who can't mind his own business.

Bill Buckels
Software Engineer

About the most offensive matter in this otherwise extremely offensive letter is the line under the author's name: 'Software Engineer'. Klutz Buckels, aside from being an extremely rabid and nasty individual, is anything but a software engineer.

His rudeness is incomparable - unsurpassed anything we've ever witnessed on the net. And what Buckels sees and what were written are so obviously divergent that only two explanations of his pathological behavior are possible:

1. Bill Buckels Software Engineer is not playing with a full deck.
2. Bill Buckels Software Engineer is panicking because he's been found out.

The truth is most likely a combination of the two.

'So What?' is a strong expression. 'So What?' is that nowhere does Buckels make it clear, either by direct statement or implication, that this is a 16-bit app that is entirely useless under Win9x/NT/2000.

'So What?' means that if radsoft.net hadn't peeked under the hood on this one (both Bloatview and Peeker will expose it, hardly anything else would, especially for an unwitting user), no one would even know today it was a 16-bit app, know how useless it is, and the minions who find Buckels's site in the search engines where he's carefully positioned himself would continue to flock around in the firm belief that this application finally had that something to cure what was ailing them.

'Garbage' is so hopelessly outdated it's not funny: it hasn't been relevant for almost seven years. Yet Buckels continues to advertise it - and nowhere explains it won't work - just to get the hits, the traffic - and of course the bucks.

'So What?' is also that this aging cyberpunk is obviously one very crotchety geezer, who doesn't like being exposed as a fake like this. Of course the information in the letter we sent was not from any Microsoft knowledge base - sheesh - it's from the Win32 API documentation, something Win32 programmers need, something as well that poor software engineer Buckels doesn't seem to have on hand.

You can read it for yourself: you can see how rude these hypocritical bastards can get when their con games are pulled out in the open. The counter argument that Buckels might not be in it for the money holds no water: he still is trying to lure you into believing in his program.

Caveat emptor.

Click here to see the original Google cache for Garbage
Click here to download the gobbledegook generator BuckSpeak (7KB)
Buckaroo! Read the inimitable Bill Buckels follow up here