How to get a WM5 device's O/S Version in a call without using RAPI?

  • Thread starter Thread starter Neville Lang
  • Start date Start date
N

Neville Lang

Hi all,

Currently, I have an app compiled in VS2003 that I want to also be able to
run on WM5 devices for my customers. My custom installer uses MSI and RAPI
calls for installation of my app. Currently, before I transfer the correct
CAB for the device, I do a RAPI call to get the device's operating system
version. This app has been designed for PPC 2002 and WM2003 including Second
Edition, and therefore you need to know which CAB to install. I have found
my app runs well on a WM5 device as I have it running on my Dell Axim X51v
but I need to be able to know the device's operating system version for WM5
devices so I know what CAB version to download.

The problem I am having is that some Pocket PC Phone Edition with WM5 , like
the i-mate JasJar, seem to make RAPI unavailable. Does anyone have another
idea / method of determining the i-mate JasJar's o/s version without using
RAPI?

BTW, this is to be my last patch update of my app under VS2003 and want it
to deploy it onto WM5 devices since my customers are wanting this
requirement. The next release of my app, after this patch update, will be a
major update and will be compiled with VS2005 and use CF2, but for the
interim period, I need to be able to use my current VS2003 compiled code on
all WM5 devices.

Regards,
Neville Lang
 
Why exactly do you need to determine device type? Since you're using VS
2003, it's a managed application and binaries should be exactly the same for
all platforms from PPC 2000 to WM 5.0.

Which means your application can use single CAB for all. There's no need to
deploy NETCF V1 SP3 since it's in ROM on every WM 5.0 device.



If that's the case, you can use this technique:
http://msdn.microsoft.com/library/d...us/dnnetcomp/html/deploy_cf2_apps_cab_msi.asp


Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
Ilya,

Thank you for your response. For the last few years, I detect the device o/s
to install the right CAB file. For example, PPC2002 requires an ARM.cab
while WM2003 + SE requires an ARMV4.cab file. Generally, there should not be
too many differences but I did built this into my installer to be safe. I
now know that the ARMV4.cab does run on my WM5 Pocket PC but more of that
later.

As for WM5 devices, it seems I still may need to detect the operating system
to vary the install logic in my custom installer. As it stands, my VS
2003-generated installer does not cleanly install correctly, and so my
customers require a change. Currently, I copy down the CAB file to the
device using RAPI and then run the CeCreateProcess on the device, again
using RAPI. This is the method I have employed. I do not use the ActiveSync
AppMgr approach since my custom uninstaller is driven from the Add or Remove
Programs in the Control Panel.

For WM5 devices, the Windows installer seems to fail when trying to install
my app onto a WM5 device, like Dell Axim X51v. The Windows Installer rolls
back so there is no entry in the Add or Remove Programs section on the
desktop's Control Panel. However, after the roll-back has occurred from the
desktop side, the CAB has been actually transferred to the device - it is
sitting in the root folder of the device. It seems that the CeCreateProcess
must have failed to start the CAB install on the device side. I am looking
into this at the moment. If you tap on the CAB using File Explorer then it
runs.

I am using a MSI and RAPI type of custom installer because while controlling
the install of the device CAB, I also need to install some EXEs on the
desktop side to act as linkages for my app to communicate with a third-party
app on the desktop side. Due to the fact that my app installer is currently
used for PPC 2002 devices up to WM2003SE (at the moment), my installer also
checks that .NET has been installed on both the device and the desktop.
PPC2002 devices did not have it there and nor did Win98 desktop computers.
My customers (consumers) can have a wide range of equipment, and I want my
app to install on all of these combinations. As I stated on my last post,
this will be the last patch update for my app so it includes WM5 devices.
The next major version of my app will be compiled under VS2005 and use CF2,
so my PPC2002 customers will then need to upgrade their equipment. I am also
likely to discontinue Win98 desktop side installations too at that time.

So, it seems (I think) that I still need to detect the device's o/s to
slightly vary my install process in my custom installer / uninstaller. While
I think this should be OK for Pocket PCs like the Dell Axim X51v (RAPI is
enabled), it is the Pocket PC Phones, like the i-mate JasJar that some of my
customers have purchased, where they want to continue using my app. and so I
need to solve installation to that type of device because it seems that RAPI
can be disabled on these devices. If anyone has an installation solution for
an unsigned app to install onto the WM5 Pocket PC Phone Edition, where RAPI
is disabled, I would be interested. Unfortunately, I do not have one of
those devices for testing.


Regards,
Neville Lang
 
Please consider switching to CeAppMgr. It's easy to use and it also can pick
correct CAB for the device provided CABs contain appropriate device
information.
You should be able to specify NETCF V1 CABs for PPC 2002 and 2003 in a
separate INI and install NETCF the same way as your application.

Advantages of using CeAppMage include:

- It works on devices with RAPI disabled.
- It works if device is disconnected.
- It is a standard way to install CE applications and it's easy for users to
manage them.

Also, you can register/unregister your application from CeAppMgr in ARP as
you used to do.


Please don't mind article below mentions NETCF V2, it would work for V1 the
same way.


Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
Ilya,

Thanks again for your reply to this topic.

I have avoided using the AppMgr so that my customers would not use the
ActiveSync install / uninstall feature because my Installer needed to not
only copy a CAB to the device but to also add folders, files and registry
entries to the desktop for the interworking with the third-party app. In
other words, I have complete control over the installation process on both
the device side and the desktop side using my custom installer / uninstaller
(via Windows Installer).

From what I understand, if my app was to use ActiveSync's AppMgr then if a
user were to uninstall it via ActiveSync then, while my app would disappear
from the device side, the desktop side would remain. My understanding is
that the Windows Installer custom uninstaller is only triggered when a user
clicks on the Remove button for a program listed on the Add or Remove
Programs in the Control Panel of the desktop. This is what I do now. Can you
tell me if my custom installer was to install my app to the AppMgr then if a
user of mine removed the app via ActiveSync, then would my custom
uninstaller program be called to complete the removal of my things on the
desktop? If so, is there something I can see on how to do this.

If the above question is yes, then I would consider going down the AppMgr
path. As you well know, it is very important (from a system view) that an
uninstaller completely removes all installed folders/files/registry entries
from both the device side and the desktop side, and so I still want to
comply with this practice.

Regards,
Neville Lang
 
Yes, you can uninstall your desktop installer from CeAppMgr.exe Add/Remove
programs if user chooses to completely remove the application.

To do so your INI file could include optional "Uninstall" entry.



Please see this for details:



http://msdn.microsoft.com/library/d...sdk5/html/wce51conusingapplicationmanager.asp



Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
Ilya,

I have tried out installing my VS2003 compiled app using MSI and my now
modified custom installer / uninstaller and fixed up the Uninstall option in
the AppMgr's ini file. It all now works so I am pleased. Thank you for those
clues.

However, my app on the device side creates files during its execution. I
found that the ActiveSync uninstaller knows nothing about these and does not
delete them, leaving my app's folder behind. Is there any way I can inform
the uninstaller on the device side to remove the files created at runtime?

On checking Google for the above query, it seems there is a reference to an
Uninstall_Exit function in C++. What do I need to do on the device side to
trigger that, if that is the best way of removing runtime-created files?

Previously, I was doing all of this using my custom uninstaller and manually
removing these files via RAPI. Since Pocket PC Phones with WM5 seem to block
RAPI, I now need to use the ActiveSync approach.

Regards,
Neville Lang
 
Yes, your device CAB file should do all the clean up, not the desktop
installer. It's really necessary considering device application can be
removed manually at any time via "Remove programs" applet on device without
using desktop installer at all. Also, device might be disconnected upon
removal of desktop installer.



To do so you can add placeholder files to your CAB so WCELOAD would delete
them for you upon removal.

For example, if you creating file "foo.txt" in your application, add an
empty "foo.txt" to the CAB.



Alternatively you can do clean up from setup DLL you've mentioned.

There's a setup DLL sample in SDK. You would need to change it to delete
files and add it to the CAB file as described here:



http://msdn.microsoft.com/library/d..._Using_Installation_Functions_in_Setupdll.asp

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
Ilya,

As a follow up, I did create zero-byte length filenames that are created at
runtime and added these filenames to my INF so the CAB would be built with
these in it. Then when the user clicks on the Remove button on the
ActiveSync AppMgr screen, these files are then removed on my device. So,
everything works nicely.

I guess if I were also adding Registry entries on the device at runtime then
I would definitely require the Uninstall_Exit function in the Setup.dll, as
there is no easy workaround for these.


Regards,
Neville Lang
 
Actually, CAB file can create and remove registry entries for you as well.
Please see this for details:



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesetup/html/_wcesdk_AddReg.asp


Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

*** Want to find answers instantly? Here's how... ***

1. Go to
http://groups-beta.google.com/group/microsoft.public.dotnet.framework.compactframework?hl=en
2. Type your question in the text box near "Search this group" button.
3. Hit "Search this group" button.
4. Read answer(s).
 
Ilya,

Thank you for pointing me in this direction. Overall, I can now see that the
INF with the AppMgr installer seems to overcome everything for a clean
uninstall.

Regards,
Neville Lang
 
Back
Top