Embedded C++ or .NET CF?

[Ken]

I'm having an issue with my hardware (Symbol SPT 2800 & 8800) losing battery
charge and hence losing all data that is stored in the non-volatile memory
space. This has the same effect of cold booting the device, so I lose all
data, including .NET CF and my application files.

I do have 10MB of non-volatile memory space which survives cold boot. I'd
like to store some installers in that space so that a cold booted device
could be reinstalled with .NET, SQLCE, and my application. The problem is
that 10MB is not enough space for everything I need to survive a cold boot
(I also store my database file in that space).

My idea is write a small program that can be stored in non-volatile memory
that can be used to download and install .NET and my other components. The
rub is that since .NET will not be installed, I can't just write a .NET
program to do this. So my question is: Should I be looking into Embedded
C++ for this? Or are there other options for my situation?

I already have a web service that can provide me with all the necessary CAB
files I need to get the device back to my desired state. I am ignorant
about Embedded C++, and my fear is that Embedded C++ doesn't provide the
nice plumbing to consume a web service like .NET does. If possible, I would
like to avoid having to write that plumbing.

Secondarily, my web service is returning CAB files as base64 byte arrays - I
am not using DIME. What are the compelling reasons to use DIME?

Thanks,

Ken

 

[Rüdiger Kardel]

Ken,

My idea is write a small program that can be stored in non-volatile memory
that can be used to download and install .NET and my other components.
The
rub is that since .NET will not be installed, I can't just write a .NET
program to do this. So my question is: Should I be looking into Embedded
C++ for this? Or are there other options for my situation?

that's easy with a symbol device:
put the CF-cab in your \application folder (which survives a cold boot)
On a cold boot the device will "execute" files of the type .cpy and .reg. in
this folder.
You can install the CF and than start you C# programm for the rest.

Below I attached an example of how we do a complete install of everything we
need after a cold boot.

Last but not least: RTFM of symbol devices

Ruediger

MyCopyFile.cpy:
\application\roma\netcf.all.wce4.armv4.cab >
\windows\netcf.all.wce4.armv4.cab
\application\roma\asa_ce.ARM.30.CAB > \windows\asa_ce.ARM.30.CAB
\application\roma\OpenNETCF.SDF.WCE4.ARMV4.CAB >
\windows\OpenNETCF.SDF.WCE4.ARMV4.CAB
\application\roma\symbol.all.arm.cab > \windows\symbol.all.arm.cab
\application\roma\ROMAMobileL_WCE4.ARMV4.CAB >
\windows\ROMAMobileL_WCE4.ARMV4.CAB
\application\roma\rsinst.arm.CAB > \windows\rsinst.arm.CAB
\application\roma\PDT9000Settings.exe > \windows\PDT9000Settings.exe
\application\roma\ROMAMobileL.lnk > \windows\startup\ROMAMobileL.lnk
\application\roma\wceldcmd.exe > \windows\wceldcmd.exe

MyRegiytryFile.reg:
;--------------------------------------------------------------------
; FILENAME: Roma.Reg
;

; For Windows CE .NET devices
[HKEY_CURRENT_USER\Software\Symbol\Startup\Programs\Prog10]
"Name"="\windows\wceldcmd.exe"
"Command"="\Windows\netcf.all.wce4.armv4.cab"
"Continue"=dword:0
"ColdBootOnly"=dword:1


[HKEY_CURRENT_USER\Software\Symbol\Startup\Programs\Prog11]
"Name"="\windows\wceldcmd.exe"
"Command"="\Windows\OpenNETCF.SDF.WCE4.ARMV4.CAB"
"Continue"=dword:0
"ColdBootOnly"=dword:1


[HKEY_CURRENT_USER\Software\Symbol\Startup\Programs\Prog12]
"Name"="\windows\wceldcmd.exe"
"Command"="\Windows\symbol.all.arm.cab"
"Continue"=dword:0
"ColdBootOnly"=dword:1


[HKEY_CURRENT_USER\Software\Symbol\Startup\Programs\Prog13]
"Name"="\windows\wceldcmd.exe"
"Command"="\Windows\asa_ce.ARM.30.CAB"
"Continue"=dword:0
"ColdBootOnly"=dword:1


[HKEY_CURRENT_USER\Software\Symbol\Startup\Programs\Prog14]
"Name"="\windows\wceldcmd.exe"
"Command"="\Windows\rsinst.arm.CAB"
"Continue"=dword:0
"ColdBootOnly"=dword:1


[HKEY_CURRENT_USER\Software\Symbol\Startup\Programs\Prog15]
"Name"="\windows\wceldcmd.exe"
"Command"="\Windows\ROMAMobileL_WCE4.ARMV4.CAB"
"Continue"=dword:0
"ColdBootOnly"=dword:1

 

[Alex Feinman [MVP]]

See inline

--
Alex Feinman
---
Visit http://www.opennetcf.org

I'm having an issue with my hardware (Symbol SPT 2800 & 8800) losing
battery
charge and hence losing all data that is stored in the non-volatile memory
space. This has the same effect of cold booting the device, so I lose all
data, including .NET CF and my application files.

I do have 10MB of non-volatile memory space which survives cold boot. I'd
like to store some installers in that space so that a cold booted device
could be reinstalled with .NET, SQLCE, and my application. The problem
is
that 10MB is not enough space for everything I need to survive a cold boot
(I also store my database file in that space).

My idea is write a small program that can be stored in non-volatile memory
that can be used to download and install .NET and my other components.
The
rub is that since .NET will not be installed, I can't just write a .NET
program to do this. So my question is: Should I be looking into Embedded
C++ for this? Or are there other options for my situation?

Can't you store just the .NET CF cab (2.5 MB) and write your app in .Net

I already have a web service that can provide me with all the necessary
CAB
files I need to get the device back to my desired state. I am ignorant
about Embedded C++, and my fear is that Embedded C++ doesn't provide the
nice plumbing to consume a web service like .NET does. If possible, I
would
like to avoid having to write that plumbing.

It is not a whole lot of fun to use a web service from a C++ code. Not that
it can't be done, but it's not pretty.

Secondarily, my web service is returning CAB files as base64 byte arrays -
I
am not using DIME. What are the compelling reasons to use DIME?

Actually there is no reason to return the cab itself from the web service. A
better solution is to return a download Url instead. Check out my article at
http://msdn.microsoft.com/mobility/.../library/en-us/dnnetcomp/html/autoupdater.asp

With this in mind, you can probably use XmlHttp control from your eVC
project as the interface to the web service (need to enable POST requests on
the web service). This is of course if you don't want to store .NETCF cab in
the non-volatile memory

 

[Ken]

Alex,

Thank you for your respone. I had already read your article and was well
down the road to implementing my own version of it.

I'm not sure I fully understand the last sentence of your post:

"This is of course if you don't want to store .NETCF cab in the non-volatile
memory."

Indeed, I would like to save as much room in non-volatile memory as possible
for my SQLCE .sdf file, so I would very much like to install .NETCF (and
everything else) from a remote location. In your article, the updater
applet is a .NETCF Forms app, so presumably you are saying that I should
rewrite the updater applet in eVC and have it function the same way as in
your example. Is that correct?

If so, then it would seem that my challenge, not being familiar with eVC,
would be to figure out how to do the following with eVC:

1) Consume the GetUpdateInfo() method of the web service
2) Download the CAB without using .NET's HttpWebRequest object
3) Invoke the shell process to install the cab

I'll give it a shot. If anyone can recommend resources for the above, I
would certainly appreciate it.

Ken

 

[Alex Feinman [MVP]]

Now that I see why you are unwilling to store even NETCF cab locally (you
did not mention the SDF file before), let me elaborate on the eVC approach.

1. Start with enablling POST requests on you web service. This is done by
uncommenting the line that says
<!-- <add name="HttpPost"/> -->

somewhere inside
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config

2. Now test your equivalent of GetUpdateInfo using a simple VB script on
your PC:

'--- script ---
set x = CreateObject("Msxml2.XMLHTTP")
x.Open "POST", "http://yourhost/yourservice.asmx/MethodName", false
x.Send "param1=value1&param2=value2 etc"

set ret = x.ResponseXml

WScript.Echo ret.xml

'--- end script -----

From the XML representation printed here, you will be able to see where in
the response xml the url you need is (I assume you are familiar with Xml
queries)

3. Now that we know your web service works, you can start looking into
implementing the same thing on the device using eVC 3.
In short you will need to:

CoCreateInstance(CLSID_XMLHTTPRequest)
Call the appropriate methods to invoke web service
call get_responseXML
Call selectSingleNode to retrieve the value you were interested in.

Let me know if you need more help

 

[Ken]

Thank you, Alex, I have been able to complete steps #1 and #2. I understand
what you are saying in #3, but here I encounter my steepest learning curve;
I'm a Java-C# guy, and I'm going to have to send some "Hello World" time in
eVC.

Ken