Day: February 8, 2006

After spending a day working with my father to setup a pair of motion sensor lights on my brother’s house, I come back inside and sit down to work on my 15″ Aluminum Powerbook. To my horror I find some large drops of black ink on the smooth silver cover.

So I had picked up a bottle of Goo Gone earlier in the day so that my brother could remove the tree sap from his hands after trimming the base of his Christmas tree. Knowing that the citrus based formula of Goo Gone was unlikely to damage the finish of my laptop, I quickly sprayed some on to remove the ink.

To my extreme disappointment, the ink was not completely removed. Most of it was gone, but the was a noticeable stain left. After several additional treatments removed more of the ink, I sighed and resigned myself to the existence of the stain. My brother recommended an extended treatment, so he put more on the stain and left a white napkin on the solution to soak.

Even more of the ink was removed, yet a noticeable stain still remained. After a decision of diminishing returns, my brother placed a small amount of Method-brand dishsoap on the area that was cleaned as per the recommendations on the Goo Gone bottle. To our surprise (and joy) the rest of the stain was removed after cleaning the soap of with a damp cloth.

I am now considering using the Method dishsoap on my entire case (minus the speaker grilles, keyboard, and touchpad/button).

As the former Macintosh guru in Valdosta State University’s Department of Information Technology, I was called upon on several occasions to rescue hapless Mac-users who had managed to screw up their font installations, whether by monkeying with the fonts without knowing what they were doing, or by honest mistake.

One of the questions often asked was “Where are my fonts anyway?” Other questions included the every popular “Which fonts do I have to leave alone for my Mac to work?” or “Why isn’t font management in Mac OS X as easy as it was in Mac OS 9?”

Well, I can’t answer the question on ease of use, but the others are answerable.

Where are my fonts anyway?

In the old days of Classic Mac OS, the fonts were all stored in the Fonts folder inside the System Folder or inside the System suticase itself. This led to huge System files and massive Fonts folders, but it did allow everyone to easily find their installed fonts.

So for those who want to know where the fonts are in OS X, here’s a list:

Location	Path
Program specific font folders	/Library/Application Support/application/Fonts
	/Applications/application/Fonts
User Fonts	/Users/username/Library/Fonts
Local Fonts	/Library/Fonts
Network Fonts	/Network/Library/Fonts
System Fonts	/System/Library/Fonts
Classic Fonts	/System Folder/Fonts

Which fonts do I have to leave alone for my Mac to work?

Another popular quandry is what fonts are required to left intact for proper functionality of Mac OS X itself. The following fonts reside in /System/Library/Fonts and should remain unmolested:

• AquaKanaBold.otf
• AquaKanaRegular.otf
• Geneva.dfont
• Keyboard.dfont
• LastResort.dfont
• LucidaGrande.dfont
• Monaco.dfont

Other Mac OS X applications, such as Mail, iCal and TextEdit, require that other fonts also be installed.

For a more exhaustive article on this topic, as well as more detailed information on the required fonts and a comparison of various third-party tools that can be used to manage them, please check out the October 2005 issue of MacAddict magazine.

So everybody wants there website to be useable by the handicapped. Which of course means that sooner or later, your boss is gonna walk into your office and say

“Johnson, I want my disabled nephew to be able to navigate our site by the end of business on Friday.”

Now if you have an atypical boss, this demand will be levied on Monday morning, first thing, but as we all know, most bosses don’t work that way.

So what is a poor web-slinger to do? Well, one thing you could try is a little-used HTML attribute called access keys. Access keys allow you to associate a hyperlink in a webpage with a particular keystroke on the keyboard.

Sounds cool, right? So why is it used so sparingly? The reason is because only a small handful of the available browsers support this attribute.

For more on access keys, visit the article Accesskeys: Unlocking Hidden Navigation, over at the excellent site A List Apart.

So, here I am at my brother’s house in Atlanta, GA for Thanksgiving. He has an “snow” Apple Airport base station setup using WEP encyrption and with no SSID broadcasting.

The sad thing was that every time I woke my laptop up from sleep it refused to automatically re-connect to the network.

Now I knew that if the network was broadcasting an SSID that I would have been given a checkbox to mark to “Save the password,” but I doubted that my brother was going to lower his security levels just for me. Knowing that there had to be a solution to this problem that did not involve an major security risks, I set out to find it.

In a thread on the forums at macosxhints.com I found a reference to the property list for the Airport configurations.

This file is named com.apple.airport.preferences.plist and it is kept at the following location /Library/Preferences/SystemConfiguration.

What I found was that in this file under the branch List of known networks there is a child for each of the Airport networks that has been “saved.” After investigating this, what I found was the listing for my brother’s network was missing the key for SecurityType.

Seemed easy enough to add the new child to the network key at set the name of the property and the value. Only problem was that even after opening the file using sudo /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist I was informed that I did not have the requisite permissions to save the changes. Undaunted, I changed the permissions on the file, made my changes, then put the permissions back.

Now after waking from sleep, my latop recognizes the network as it should. And all is well in laptop land.

By David Garcea

This article is intended to show you how you to create applications that run on the Palm OS using Mac OS X. The majority of the tools used in this article are free and open source, the rest are inexpensive shareware or donationware. You do not need any previous Palm OS programming experience to understand the material in this article.

For years, Palm OS development on Macintosh was done using the Metrowerks CodeWarrior integrated development environment. CodeWarrior is very powerful, but that power comes at a great expense – $399. In addition, Metrowerks has dropped support for Macintosh computers in the latest version – CodeWarrior Development Studio for Palm OS Version 9.0. Thankfully, there is an alternative that is just as powerful, and free. It’s called PRC-Tools and it’s an open source project available at a repository called SourceForge.net.

PRC-Tools is a collection of unix based tools for creating Palm OS applications using C and C++. Luckily for us, MacOS X is also based on unix, an open source derivative of FreeBSD called Darwin to be exact. This means that we too can use these tools. In order to do this, the PRC-Tools package needs to be compiled on MacOS X. If you are comfortable with the command line and building unix applications, you can do this yourself, but as Mac users we expect things to be easier. Thanks to a group of Mac developers called Zenonez, we can install PRC-Tools using a standard MacOS X installer package.

Make sure you have installed the latest version of Xcode from the Xcode Tools (Aka Developer Tools) CD that accompanies MacOS X. You can also download the latest version from Apple. This article assumes you are using Xcode 1.5 or later. Then download the PRC-Tools installer package from here:

http://www.zenonez.com/prctoolsx/index.html.

Install PRC-Tools by double clicking on the package and running through the installer.

Once you have downloaded and installed the PRC-Tools package, you have almost everything that you need to develop Palm OS applications using the command line, which is accessible from the Terminal application. But using a Mac means we shouldn’t have to work with the command line and we don’t. Instead, we can use Xcode, Apple’s free integrated development environment.

Launch Xcode and create a new project using the File menu. In the New Project Assistant, select the “GNU Make” option and click Next. Selecting “GNU Make” means that Xcode will use the command line utility called make to perform the operations needed to build your application. Name the project and select a directory to keep it in, then click Finish.

Create a new file using the File menu. In the dialog that appears, select “Empty File in Project.” Name the file “Makefile”, making sure to use the same capitalization, and then click Finish. This is the file that Xcode will pass to the make utility to tell it how to compile your application. Click on the Makefile in Groups & Files list to edit it. If the editor does not appear, select “Toggle Embedded Editor” from the “View” menu or click the Editor button in the toolbar.

Enter this code into the file and save.

MacPalmDev.prc: MacPalmDev.c MacPalmDev.h MacPalmDev.rcp
        m68k-palmos-gcc MacPalmDev.c -o MacPalmDev
        m68k-palmos-obj-res MacPalmDev
        pilrc MacPalmDev.rcp 
        build-prc  MacPalmDev.prc "MacPalmDev" XXXX *.grc *.bin

The first line specifies that in order to build the file MacPalmDev.prc, it needs to have MacPalmDev.c, MacPalmDev.h and MacPalmDev.rcp. If those files are not present, an error will occur when you try to build the application. The remaining lines are the commands that will be executed on the command line to build the application. This is a very simple Makefile that was made specifically for this project. You may want to learn how to create you own Makefiles so that you can create a generic one for all of your applications. For more information on creating Makefiles, read the make manual at:

http://www.gnu.org/software/make/manual/make.html

Create another new file using the File Menu. This time, make it a C file, and name it MacPalmDev.c. Make sure the checkbox for creating the MacPalmDev.h file is checked and then click Finish.

Click on the MacPalmDev.h file in the Groups & Files list to edit it. Remove the line that contains “#include ” because it is inappropriate for Palm OS development. Then add this code to the bottom:

#define MainForm        1000
#define MessageLabel    1001

Click on the MacPalmDev.c file and add this code at the bottom:

#include 

Boolean MainFormHandleEvent( EventPtr theEvent )
{
    FormType *frmP;

    if( theEvent->eType == frmOpenEvent )
    {
                frmP = FrmGetActiveForm();
                FrmDrawForm( frmP );
                return true;
    }
        
    return false;
}

Boolean AppHandleEvent( EventPtr theEvent )
{
        FormPtr         frmP;
        
        if( theEvent->eType == frmLoadEvent )
        {
                frmP = FrmInitForm( theEvent->data.frmLoad.formID );
                FrmSetActiveForm( frmP );
                FrmSetEventHandler( frmP, MainFormHandleEvent );
                return true;
        }
        else if( theEvent->eType == appStopEvent )
        {
                frmP = FrmGetActiveForm();
                FrmEraseForm( frmP );
                FrmDeleteForm( frmP );
                return true;
        }
                
        return false;
}


UInt32 PilotMain(UInt16 cmd, MemPtr cmdPBP, UInt16 launchFlags)
{
    EventType theEvent;
    
    if( cmd == sysAppLaunchCmdNormalLaunch )
    {
        FrmGotoForm( MainForm );
        do
        {
            EvtGetEvent( &theEvent, evtWaitForever );
    
            if (! SysHandleEvent( &theEvent ))
                if (! AppHandleEvent( &theEvent ))
                  FrmDispatchEvent( &theEvent );
    
        } while( theEvent.eType != appStopEvent );
    }
    
    return errNone;
}

This code has been compacted for use in this article. It is not intended to demonstrate good programming practices. All this code does is display a single form. To learn more about programming for Palm OS, visit:

http://www.palmos.com/dev/tech/overview.html.

Create an empty file in the project and name it MacPalmDev.rcp. Then add this code to it:

#include "MacPalmDev.h"

FORM ID MainForm AT (0 0 160 160)
BEGIN
    TITLE "Made With A Mac"
    LABEL "This application was made on MacOS X!" ID MessageLabel AT (1 50)
END

This is a resource file that defines the user interface elements that will be displayed by your application. Your Makefile calls the PilRC command line application and passes it this file, which is converted into binary resource files.

This file only displays a message on the screen. A real Palm OS application will have much more code in this file. You could write the entire file yourself, if you first study the PilRC User Manual, or you could use an application that is currently under development called PalmBuilder. The version available on their website is still in the beta stage but we hope that it will be available in a final release soon because it is very useful.

If you are migrating an existing project from CodeWarrior, you will probably already have resource files in the form of Constructor files. There is another open source project called rsrc2rcp that will convert the files for you. You may have to review the resulting .rcp files to make sure they are correct, but this application will save you a lot of time.

You are now ready to create the application. Select Detailed Build Results from the Build menu. This will open a window that contains three panes, although some may be closed. You want to make sure the center pane is visible because this is where all the action will be. The top pane shows simplified results of the build process, the center pane contains a log of what is actually occurring on the command line, and the bottom pane allows you to fix errors in your code.

Click the Build button in the toolbar and watch the center pane. It should look similar to the Makefile that we created earlier. If the build fails, check the center pane for clues to the cause. In this case, there is most likely a typo in your code. Check the code and try again. When the build succeeds, switch to the Finder and look in the project’s folder. You will see several files that were not there before. The one you want to focus on is the MacPalmDev.prc file. This is your Palm OS application. Now you have to test it.

To run your Palm OS application, you could install it onto an actual Palm OS device but that is too time consuming, especially since you will probably be recompiling and installing the application dozens if not hundred of times before the application is perfect.

It would make things much easier if you could just run the application on your Mac, and you can. You will need to download POSE, the PalmOS Emulator, from here:

http://www.palmos.com/dev/tools/emulator/

You will also need to acquire a ROM file. Instructions for doing so are included in the link above and in the POSE documentation included with the downloadable archive.

Once you have POSE installed and running, drag the MacPalmDev.prc file and drop it onto POSE. This will install the application into the emulator. You may have to refresh the display to see the application. Try selecting the Unfiled category, that is where your application should be. Click on the application to launch it and you should see a form that says “This application was made on MacOS X!”

Most of the time, your application will not behave as desired the first time. In this case you will have to use a debugger to find the problems. PRC-Tools comes with a special version of the gdb command line debugger but Xcode can not provide a user interface to it. As a Mac user, I like to avoid using the command line whenever possible, so I created an application called Bug Off, which acts as a graphical user interface to the PRC-Tools version of gdb. Bug Off is shareware, which means you can use it for an evaluation period (30 days) before you decide if you want to purchase it. The only limitation you will encounter while evaluating the software is that you can only have three breakpoints at one time. You can find information on purchasing Bug Off here:

http://www.trinfinitysoftware.com/bugoff.shtml#purchase

If you are experienced with using gdb, you may prefer using the command line as it is faster, otherwise you may find Bug Off very useful.

There are several online communities available that can help you develop Palm OS applications on MacOS X. Here are a few:

Zenonez Forums

Palm Source: Mac Development Forum

Palm OS: Programming Recipes

As I have begun developing part-time in ASP, I ran into a problem running IIS in Windows XP Pro. Apparently Microsoft has limited the ability to run multiple sites under Windows XP Pro.

While there are some command-line hacks to work around this, as well as some dll’s that can be used to alleviate the problem, there is also a utility I ran across to help with this problem.

The utility is IIS Admin which was developed by firstserved, a web hosting provider.

This little program allows you to easily create, and switch between, multiple sites running on IIS on a Windows XP machine.