...unless you're doing the types of things COBOL was made for. Such as, dealing with fixed point numbers.

The issue is that some updater programs are expecting to be able to update the program in its original install location.

This is actually regression in OS X. In classic Mac OS, you can move an application anywhere or even rename it and it will still work. Don't like the Application folder organization? Change it!

In OS X, you should be wary of moving any of Apple's applications, since Apple's Software Update seems to be the one that is most guilty of making assumptions. Lately I've been leaving programs dropped by installers in their initial location. But if the "install" is simply dragging an icon from a disk image, you are free to put it in any folder you want.

OS X will automatically find applications in the Applications folder and in any subfolder, and also it scans applications when you click on them. After that, it knows everything it needs to about that application's existence. Usually application paths are not important, so it is OK to move an application, aside from the updater issue.

Another way to create your own "Start Menu" type organization is to create aliases to applications and organize the aliases anyway you want.

The rationalization for why Macs don't have a Start Menu and Window does, is you'd never want users to have to wade through the Program Files folders, since they contains so much more visible files than just the ones you're supposed to run. The Mac has always tried to keep the applications self-contained, so the Applications folder only contains the icons that are of use to the user. If you present the Applications folder as a menu hierarchy it is what would be in the Start menu.

So that's what Dr. Lizardo was doing.

Disk images as an Apple file distribution method originated back in Classic Mac days, all the way back to Disk Copy images in System 6. They are the native Mac version of an archive, which supports the same file meta data as the Mac file system.

It used to be that there were few alternatives that could safely transport files with resource forks: Stuffit Expander (.sit) and binhex encoded files (.hqx, which still required a third party program to decode).

Now Apple's implementation of .zip files can encode some OS X meta data, such as resource forks.

But Disk Images are still popular, because since they are a complete file system in a box, they support all of the same meta data as the source file system: Finder data (aka Finder flags), resource forks, extended attributes, everything.

Another advantage for file distribution is it creates a read-only package of files, rather than dump them all into the user's download folder. Consider if you are distributing an application plus optional files, and you want to give the user the ability to pick and choose what they copy to their Applications folder.

Chrome is doing an end-around security rules that are designed to prevent applications from being installed without sufficient authority. In what way is this a good thing?

The U.S. has such a levy/tax on blank digital audio recording media -- but today it essentially only apples to CD-R Audio discs, not ordinary CD-R discs. CD-R Audio discs would be used in consumer electronics audio recorders, which by law will reject recording on "computer" CD-R discs.

This method does not have the same effect as changing in the GUI. *

When you change an environment variable (including the PATH) in a command prompt, you only affect that command prompt. It doesn't change the parent Windows environment.

Try it: change the PATH in a command prompt, then open up a new command prompt and check the PATH -- your change won't be there.

There are non-GUI ways to change the Windows environment, including updating the PATH inside the Windows registry directly. But then the next trick is getting Windows to realize that the environment has changed and to notify the other tasks. This can be non-trivial.

* in Windows XP, at least

Congratulations, you've just recreated the way it was defined from 1795 until 1799, when they switched to using a standard platinum prototype.

It's also used to dummy out call in a load module. That is, is you have a module where program A wants to call program B, you can replace program B with IEFBR14 and it will just call and return. ... which reveals a bug in IBM's version.

IEFBR14 hasn't changed in years. It is so old that its standard implementation is marked as being a 24-bit program. It doesn't actually have any 24-bit dependencies, but that's the attribute it has: run in addressing mode 24.

So, if you bring it into a load module, the linker will see that you've included a 24-bit program, and it will drag the entire load module into 24-bit mode and force it to load into low-storage. (It will only load in addresses up to 16 MB, rather than the full 2 GBs of address space available to 31-bit programs.)

OK, so you start with pure water, add some substance, dilute it until it isn't there, but the water retains the pattern of the substance that isn't there anymore.

One question:

Where'd you get the "pure" water?

http://blogs.msdn.com/jensenh/archive/tags/Why+the+New+UI_3F00_/default.aspx

With careful timing, all you need is the 1 key.

This isn't taking advantage of using an iPhone; it could just as well used an iPod Touch.

A real geek card using an iPhone would have modulated the GSM carrier so that the nearest speaker would buzz to the tune of a Christmas carol.

Which is pretty funny, because when Mac users are asked to explain why Windows has 100+ times more software products than Mac versions in any retail store, the answer is, "who needs 10 different versions of a word processor? The Mac market only sells the best product and doesn't bother with the crap."