Getting the Pocket PC device serial number???

I've ported an application from Palm OS to Pocket PC 2003 (basically, had to
rewrite pretty much all of it) from C to embedded VC++. My app is C, not
C++. On the Palm, you simply call a SysGetROMToken function to retrieve the
device unique serial number. I understand the Pocket PCs often don't have
built in serial numbers or functions to calling, making it so much harder to
generate individual activation codes for applications.

I've seen one approach to get the serial number on

http://www.pocketpcdn.com/articles/serial_number2002.html

but I couldn't make it work. It's probably me not being proficient enough in
VC++ 4.0, the approach isn't exactly smoothly explained. I'd like sample
codes to be cut and paste...;-)

Does anyone have suggestions as to how to go about retrieving the unique
serial number, hints/guidance would be much appreciated.

Regards,
Kristian

Bruce
Sun Jun 20 12:31:33 CDT 2004

What's the problem? (no sarcasm intended)

That article has all of the code, it is just in C++ and uses CString (which
is fully documented.) You do know C don't you? Just convert it to C. All
it does is call KernelIoControl to get data and them formats a string.

Heck, you could even test it as is real quick by creating a new Hello World
MFC project and drop the code in. Then *step* through the code.

--
Bruce Eitman (eMVP)
Senior Engineer

Kristian
Sun Jun 20 18:22:20 CDT 2004

Thanks Bruce,

When coming from a developer friendly environment like Palm OS, I guess my
patience runs pretty thin sometimes. Fully documented? You need to include
"afx.h" to compile, which isn't mentioned in the sample code.
KernelIoControl and CTL_CODE do not exist in the API that comes with VC4.

Cut and paste into a new project; no worries. However, cut and paste into my
project source, and I get the following bizarre link error:

uafxwce.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator
new(unsigned int)" (??2@YAPAXI@Z) already defined in
coredll.lib(COREDLL.dll)
uafxwce.lib(afxmem.obj) : warning LNK4006: "void * __cdecl operator
new(unsigned int)" (??2@YAPAXI@Z) already defined in
coredll.lib(COREDLL.dll); second definition ignored
Creating library ARMV4Rel/felles8.lib and object ARMV4Rel/felles8.exp
ARMV4Rel/felles8.exe : fatal error LNK1169: one or more multiply defined
symbols found
Error executing link.exe.
C:\Programfiler\Windows CE Tools\wce420\POCKET PC
2003\mfc\include\Afx.h(420): Could not find the file wceimpl.h.

Now I don't speak Microsoftish, so I don't really know where to start
looking to get this bugger to compile properly.



"Bruce Eitman (eMVP)" <beitmannospam@nospam.neo.rr.com> skrev i melding
news:e9GAkxuVEHA.644@tk2msftngp13.phx.gbl...
> What's the problem? (no sarcasm intended)
>
> That article has all of the code, it is just in C++ and uses CString
(which
> is fully documented.) You do know C don't you? Just convert it to C.
All
> it does is call KernelIoControl to get data and them formats a string.
>
> Heck, you could even test it as is real quick by creating a new Hello
World
> MFC project and drop the code in. Then *step* through the code.
>
> --
> Bruce Eitman (eMVP)
> Senior Engineer
>
>
>

Bruce
Sun Jun 20 19:27:51 CDT 2004

Often when engineers are faced with a new development system, they think
that it is bad. Most of the time it is because they haven't bothered to
spend any time getting to know the tools and OS that they are working with.
It really pays to learn instead of whine. I have not looked at the tools
for Palm, but I do know that Windows is a complex OS with many additional
features. This does make learning the paradigm and the tools a bit complex.

You don't need to get it to compile, it wasn't meant to work with your
application. It is meant to work with an MFC/C++ app, which you are not
developing. No it does not state that in the article, but the article was
written for Win32 API programmers, who would have picked up on this because
of their knowledge of their target and tools. Articles like that simply
can't start at the beginning each time.

So why not port it to your app? It would take about 10 minutes to do so and
you would have already been done. The only thing that is causing you any
trouble is the CStrings. Just change them to TCHAR and call the appropriate
functions instead. All it is doing is adding chars to the last index
(through concatenation) and then creating a string by pulling out chars from
given indices and concatenating them together. Not really rocket science,
and yes CString is fully documented, including that to use it you have to
include afx.h.

CTL_CODE is documented on MSDN, but wrong about the header file, but a quick
search of the include directory finds which file to include.

KernelIoControl is also documented on MSDN, but the header file is not
included, that is precisely why it is defined as extern in the sample.

--
Bruce Eitman (eMVP)
Senior Engineer

Mike
Mon Jun 21 06:23:11 CDT 2004

One thing to keep in mind is that, like on the Palm platform, a significant
number of Pocket PCs do not have a unique serial number embedded in the ROM.
Some iPAQs have a serial number, and (as far as I know) you have to use the
iPAQ SDK to get the information.

I think this may have changed on Pocket PC 2003 / WM2003 devices, but I
cannot say for sure. Your target audience might be all new devices in which
case this may suit you.

I also expanded development from Palm to Pocket PC (using eVB for now, soon
eVC) and then to Symbian phones. I share your frustration. A lot of this is
because these articles aren't aimed at people with no experience in that
platform, and in a lot of cases you will find the solution, it will be a
minor one, and you will think "well, why didn't someone tell me I needed to
do that!"

My problem now is trying to keep up as I have to maintain code for the three
platforms. The PPC is the least of the problems for now as it's BASIC rather
than C or C++ so it is very different. But switching between Palm (with
Codewarrior) and Symbian phone (with Borland CBX) can get confusing.

Mike.

"Kristian Austad" <kristian@austad.net> wrote in message
news:%23cuYKYuVEHA.3024@TK2MSFTNGP09.phx.gbl...
> I've ported an application from Palm OS to Pocket PC 2003 (basically, had
to
> rewrite pretty much all of it) from C to embedded VC++. My app is C, not
> C++. On the Palm, you simply call a SysGetROMToken function to retrieve
the
> device unique serial number. I understand the Pocket PCs often don't have
> built in serial numbers or functions to calling, making it so much harder
to
> generate individual activation codes for applications.
>
> I've seen one approach to get the serial number on
>
> http://www.pocketpcdn.com/articles/serial_number2002.html
>
> but I couldn't make it work. It's probably me not being proficient enough
in
> VC++ 4.0, the approach isn't exactly smoothly explained. I'd like sample
> codes to be cut and paste...;-)
>
> Does anyone have suggestions as to how to go about retrieving the unique
> serial number, hints/guidance would be much appreciated.
>
> Regards,
> Kristian
>
>

Kristian
Mon Jun 21 14:40:01 CDT 2004

This function returns "No serial number", i.e. the call to KernelIoControl
returns FALSE. Anyone see why?

#include <WINIOCTL.H>

extern "C" __declspec(dllimport)
BOOL KernelIoControl(
DWORD dwIoControlCode, LPVOID lpInBuf, DWORD nInBufSize,
LPVOID lpOutBuf, DWORD nOutBufSize, LPDWORD lpBytesReturned
);

#define IOCTL_HAL_GET_DEVICEID CTL_CODE(FILE_DEVICE_HAL, 21,
METHOD_BUFFERED, FILE_ANY_ACCESS)

TCHAR* GetSerialNumberFromKernelIoControl()
{
DWORD dwOutBytes;
const int nBuffSize = 4096;
byte arrOutBuff[nBuffSize];
byte buff2[100];
TCHAR serialstring[100];
BOOL bRes;

bRes = KernelIoControl(IOCTL_HAL_GET_DEVICEID,
0, 0, arrOutBuff, nBuffSize,
&dwOutBytes);

memmove(&buff2[0],&arrOutBuff[40],2);
memmove(&buff2[2],&arrOutBuff[45],9);
memmove(&buff2[11],&arrOutBuff[70],6);
wsprintf(serialstring, L"%02X",buff2);

if (bRes)
{
return &serialstring[0];
}
else
{
wsprintf(serialstring, L"No serial number.");
return &serialstring[0];
}
}

Mike
Tue Jun 22 04:21:47 CDT 2004

What kind of device is it? Does it have a serial number you can read? Per my
other post, not all devices do have.

Mike.

"Kristian Austad" <kristian@austad.net> wrote in message
news:ubXBHe8VEHA.1340@TK2MSFTNGP10.phx.gbl...
> This function returns "No serial number", i.e. the call to KernelIoControl
> returns FALSE. Anyone see why?
>
> #include <WINIOCTL.H>
>
> extern "C" __declspec(dllimport)
> BOOL KernelIoControl(
> DWORD dwIoControlCode, LPVOID lpInBuf, DWORD nInBufSize,
> LPVOID lpOutBuf, DWORD nOutBufSize, LPDWORD lpBytesReturned
> );
>
> #define IOCTL_HAL_GET_DEVICEID CTL_CODE(FILE_DEVICE_HAL, 21,
> METHOD_BUFFERED, FILE_ANY_ACCESS)
>
> TCHAR* GetSerialNumberFromKernelIoControl()
> {
> DWORD dwOutBytes;
> const int nBuffSize = 4096;
> byte arrOutBuff[nBuffSize];
> byte buff2[100];
> TCHAR serialstring[100];
> BOOL bRes;
>
> bRes = KernelIoControl(IOCTL_HAL_GET_DEVICEID,
> 0, 0, arrOutBuff, nBuffSize,
> &dwOutBytes);
>
> memmove(&buff2[0],&arrOutBuff[40],2);
> memmove(&buff2[2],&arrOutBuff[45],9);
> memmove(&buff2[11],&arrOutBuff[70],6);
> wsprintf(serialstring, L"%02X",buff2);
>
> if (bRes)
> {
> return &serialstring[0];
> }
> else
> {
> wsprintf(serialstring, L"No serial number.");
> return &serialstring[0];
> }
> }
>
>

Kristian
Tue Jun 22 11:36:48 CDT 2004

Thanks for your reply Mike.

It's a Fujitsu Siemens LOOX 610, I've been able to compile the example and
get it produce a serial number on that device, but when I rewrite it to
TCHAR* instead of CString and include it in my app, KernelIOControl returns
false.

"Mike" <test@test.com> skrev i melding
news:%23PaccqDWEHA.3892@TK2MSFTNGP10.phx.gbl...
> What kind of device is it? Does it have a serial number you can read? Per
my
> other post, not all devices do have.
>
> Mike.
>
> "Kristian Austad" <kristian@austad.net> wrote in message
> news:ubXBHe8VEHA.1340@TK2MSFTNGP10.phx.gbl...
> > This function returns "No serial number", i.e. the call to
KernelIoControl
> > returns FALSE. Anyone see why?
> >
> > #include <WINIOCTL.H>
> >
> > extern "C" __declspec(dllimport)
> > BOOL KernelIoControl(
> > DWORD dwIoControlCode, LPVOID lpInBuf, DWORD nInBufSize,
> > LPVOID lpOutBuf, DWORD nOutBufSize, LPDWORD lpBytesReturned
> > );
> >
> > #define IOCTL_HAL_GET_DEVICEID CTL_CODE(FILE_DEVICE_HAL, 21,
> > METHOD_BUFFERED, FILE_ANY_ACCESS)
> >
> > TCHAR* GetSerialNumberFromKernelIoControl()
> > {
> > DWORD dwOutBytes;
> > const int nBuffSize = 4096;
> > byte arrOutBuff[nBuffSize];
> > byte buff2[100];
> > TCHAR serialstring[100];
> > BOOL bRes;
> >
> > bRes = KernelIoControl(IOCTL_HAL_GET_DEVICEID,
> > 0, 0, arrOutBuff, nBuffSize,
> > &dwOutBytes);
> >
> > memmove(&buff2[0],&arrOutBuff[40],2);
> > memmove(&buff2[2],&arrOutBuff[45],9);
> > memmove(&buff2[11],&arrOutBuff[70],6);
> > wsprintf(serialstring, L"%02X",buff2);
> >
> > if (bRes)
> > {
> > return &serialstring[0];
> > }
> > else
> > {
> > wsprintf(serialstring, L"No serial number.");
> > return &serialstring[0];
> > }
> > }
> >
> >
>
>

The
Tue Jun 22 15:25:00 CDT 2004

> This function returns "No serial number", i.e. the call to KernelIoControl
> returns FALSE. Anyone see why?
>
> #include <WINIOCTL.H>
>
> extern "C" __declspec(dllimport)
> BOOL KernelIoControl(
> DWORD dwIoControlCode, LPVOID lpInBuf, DWORD nInBufSize,
> LPVOID lpOutBuf, DWORD nOutBufSize, LPDWORD lpBytesReturned
> );
>
> #define IOCTL_HAL_GET_DEVICEID CTL_CODE(FILE_DEVICE_HAL, 21,
> METHOD_BUFFERED, FILE_ANY_ACCESS)
>
> TCHAR* GetSerialNumberFromKernelIoControl()
> {
> DWORD dwOutBytes
> const int nBuffSize = 4096;
> byte arrOutBuff[nBuffSize];
> byte buff2[100];
> TCHAR serialstring[100];
> BOOL bRes;
>
> bRes = KernelIoControl(IOCTL_HAL_GET_DEVICEID,
> 0, 0, arrOutBuff, nBuffSize,
> &dwOutBytes);
>
> memmove(&buff2[0],&arrOutBuff[40],2);
> memmove(&buff2[2],&arrOutBuff[45],9);
> memmove(&buff2[11],&arrOutBuff[70],6);
> wsprintf(serialstring, L"%02X",buff2);
>
> if (bRes)
> {
> return &serialstring[0];
> }
> else
> {
> wsprintf(serialstring, L"No serial number.");
> return &serialstring[0];

Think this is not a good idea. You are returning a pointer to a variable
that is about to get whacked. You should at least make it static.

> }
> }
>
>