Sometimes it's necessary to determine the actual manufacturer or model of the device your app is running on, at runtime. These cases are rare, since usually you want to determine the presence of a particular PalmOS feature, and there are APIs to do that. It's not straightforward to determine device type, because the technique has evolved over the life of the OS.

I derived this information experimentally, or by perusing header files, or by contributed observations from other developers. If it's wrong, blame me and not PalmSource or the licensees. The contradictions shown in this table are clear support for PalmSource's oft-repeated advice to use supported API's to query for particular capabilities (like color, VFS, wireless network) at runtime and not to depend on looking up the device model.

mysql_connect failed: Access denied for user 'mgweb'@'localhost' (using password: YES)No data (Access denied for user 'apache'@'localhost' (using password: NO).

If you have information to add, please send it to me. You can extract information from your device like this:

UInt32 deviceID, companyID, miscFlags;

Err devErr, compErr, miscErr;


devErr = FtrGet(sysFtrCreator, sysFtrNumOEMDeviceID, &deviceID);

compErr = FtrGet(sysFtrCreator, sysFtrNumOEMCompanyID, &companyID);

miscErr = FtrGet(sysFtrCreator, sysFtrNumHwrMiscFlags, &miscFlags);


if (!compErr) WinDrawChars((Char *) &companyID, 4, 20, 30);

if (!devErr)

WinDrawChars((Char *) &deviceID, 4, 20, 45);


You'll have to look at the value of miscFlags as an integer, masking it with hwrMiscFlagIDMask. For Handspring devices you probably have to look at deviceID as an integer instead of 4 characters.

Or if you prefer, you can run the program pixelcheckD.prc and send me the results. If your device isn't in the table above, lend a hand and send me your info. Send me the Maker, Device, and the string printed below the pitch value. If you're really ambitious, measure the length of the line next to "2 cm" and tell me how long it really is. The solid square should be just large enough to contain a US quarter.

For the capabilities of particular devices, see or the individual manufacturers' web sites.

Alvin Mok has a list of Palm-powered device HAL ID's.

Dan Royea maintains a PalmOS device evolutionary tree, if you're interested in seeing how device capability has evolved.

Some comments on determining device type (from this palm-dev-forum thread):

Date: Fri, 21 Dec 2001 15:10:57 -0800
To: Hal Mueller ,
   "Palm Developer Forum" 
From: Jim Schram 
Subject: Re: Device model and manufacturer--more information

At 12:42 PM -0800 2001/12/21, Hal Mueller wrote:
>It looks to me like there have been 2 schemes for telling devices

Actually, there are four schemes in total:

  - hwrMiscFlags (I think this includes the original Palm Pilots,
Personal, Pro, III, IIIx, IIIc, V, Vx, VII)

  - hwrMiscFlagsExt (I think this includes the IIIx, Vx, VIIx)

  - 'hwid' ROM token (first 4-byte integer = device primary ID
assigned by Palm; followed by
                      second 4-byte integer = device secondary ID
assigned by the Licensee)

  - sysFtrNumOEMCompanyID, sysFtrNumOEMDeviceID, sysFtrNumOEMHALID
tuple (all devices running 3.5 or later)

>The original one was to store a system feature at
sysFtrNumHwrMiscFlags, with a distinct value for each new device--such
as hwrMiscFlagIDJerry or hwrMiscFlagIDSumo.  Of course, you have to
know what those macro values are; they're mostly defined in

Correct, although the file in which these #defines resided has changed
through various releases of our SDKs (for example, values for
hwrMiscFlags and hwrMiscFlagsExt used to be defined in Hardware.h many
many moons ago).

>Later, beginning with OS 3.5 and the introduction of the HAL (no
relation!  that's harware abstraction layer), there are two new
features available:  sysFtrNumOEMDeviceID and sysFtrNumOEMCompanyID,
with a range of values that is also defined in HwrMiscFlags.h.

There's also sysFtrNumOEMHALID which uniquely identifies the version
of the HAL code a particular device is using. This may or may not be
useful to you, depending on how and for what you're using the device
identifier info. For example, some products use the same HAL for
multiple devices, usually when their internal hardware is so similar
to that of another product it makes more sense to just handle the few
differences within the same code base. That's very useful to Palm when
developing System Updates which patch broken HAL functionality.

> However, older devices upgraded to 3.5 or later still use the old
scheme--a Palm V will report hwrMiscFlagIDSumo for its ...MiscFlags,
and will not have values stored for ...CompanyID and ...DeviceID.

That's not entirely true. Let's say you've upgraded a 3.1 device to
3.5 by flashing a new Big ROM. Your device will now use the
feature-based mechanism. However, if you examine the results from the
Small ROM debugger stub, which would still be version 3.1, then you'll
see the old non-feature-based mechanisms being used. Continue the boot
sequence, dropping into the Big ROM's debugger stub, and you should
see it switch over to the new feature-based mechanism. That's entirely
normal unless you re-flash the whole entire ROM including a new boot
ROM, which generally isn't possible on production devices because the
boot ROM has been permanently flash-write protected.

>So how do you know whether you have an old style or new style feature
set?  if sysFtrNumHwrMiscFlags is hwrMiscFlagIDCheckOEMFtrs, you
should look for ...DeviceID and ...CompanyID.
>Except that not all licensees obey this rule.  In fact, only Palm
follows it completely.  And there are discrepancies between what the
header file says and what the devices say.  Kyocera's headers in their
SDK advocate a completely different method of determining whether
you're on a Smartphone.

We can only build and recommend methods of device identification... we
can't really enforce them upon everyone who wants to build a Palm OS
device. Sorry... the issue was becoming quite a mish-mash of
solutions, so we've moved to the feature-based approach in the hopes
that this will reduce some of the administrative issues surrounding
its enforcement.

Please realize that we *are* trying to make sure every device can be
uniquely identified by *some* means.

>There are 3 mystery devices, made by Palm, listed in the header that
don't seem to have been shipped:  hwrMiscFlagIDThumper,
hwrMiscFlagIDTouchdown, and hwrMiscFlagIDCobra2.  Anybody know what
those are?

Thumper was the code name for the original PDQ-800 from
Qualcomm. Touchdown was the original Palm Pilot. Cobra was the Palm

>The header file says that the Palm V, Vx, and IIIx all are
hwrMiscFlagIDSumo (makes sense, internally the same device).  But in
fact the IIIx says it's hwrMiscFlagIDBrad ('brad'), which is also what
the original Handspring Visor claims to be.  I toss this tidbit out
not to complain, but to warn you that the information I've compiled
may well lead you astray if you use it instead of Palm's published
methods for determining device capabilities at runtime.

Yup, that's because they all use the same "before-there-was-a-HAL" HAL
layer code base. So you check the hwrMiscFlagsExt field for the
sub-ID. PITA ain't it? :oP

I wish I could hand you a single list of all the IDs and
identification schemes ever used by Palm and our Licensees, but
unfortunately, such a list just doesn't exist. It's been sort-of on
our to-do list for some time, actually to come up with a simple piece
of sample code which unique IDs each and ever device ever made,
but... there's really never been a need for it internally, so more
important things end up getting done first. Sigh... in any case, I
hope some or all of this info helps!

Happy Holidays!

Jim Schram
Palm Incorporated
Partner Engineering

Determining PalmOS Make and Model at Run Time