Windows Mobile dev. with .NET

[~~~ .NET Ed ~~~]

I have a question regarding the compact framework and its emulators. I have
a Dell Axim X51v with Windows Mobile 5 and when I tried to create a VS.NET
project (VS 2003) it presented me with possibilities for Pocket PC and
Windows CE. I am confused there, wasn't Pocket PC the "new" Windows CE? or
is WinCE used for the embedded development? I simply want to write a client
application for my Pocket PC (?) WIndows Mobile 5.0 device.

My 2nd question is whether my setup is good, and if not then what I need to
do to get it right:

Target device: Dell Axim X51v
Target OS: Windows Mobile 5.0
Processor: Intel XScale
IDE: VS.NET 2003
Framework: .NET v1.1

I have done quite some .net development but none for the compact framework.

Thx!
Emilio

 

[Chris Tacke [MVP]]

With 2003 you should choose Pocket PC as your target. And no, Pocket PC is
*not* the new Windows CE. Windows CE is a modular operating system. Pocket
PC and Windows Mobile are simply platforms built on top of it.

-Chris

 

[Markus Humm]

Hello,

somebody told me recently that for most programs there isn't that much
difference. Why make one at all? Only for confusion.
On the PC you also have a modular OS. You can decide wether to install
that server tools, webserver etc. or not. It's as simple as that. Why
not let the manufacturer of the PDA decide what to offer his customers
(he's doing that already anyway) and make no difference except which
modules he included. A programm should be able to figure out whether the
needed modules are present or not.

The only problem might be devices with no visible/audible output systems
(e.g. no display).

Greetings

Markus

 

[Paul G. Tobey [eMVP]]

I can build (and do, in fact), a Windows CE device with no display, no
window manager, no shell (obviously), etc., etc. It's only *some* Windows
CE devices that are 'like' Pocket PC or SmartPhone, not all of them.

Paul T.

 

[Chris Tacke [MVP]]

somebody told me recently that for most programs there isn't that much

difference. Why make one at all? Only for confusion.

Isn't much difference between what? CE and PPC? That can be sort of true
or patently untrue. Since CE is modular I can make it very similar or not
at all similar.

On the PC you also have a modular OS.

No you don't (excluding XPe, which is out of the scope of this
conversation). You can install applications and drivers at run time, but
that is not a modular OS. You cannot remove supported features and APIs from
the kernel. kernel32.dll, user32.dll, etc. all have a fixed set of
functions and you're guaranteed that. You cannot say the same for
coredll.dll.

You can decide wether to install
that server tools, webserver etc. or not. It's as simple as that.

That statement shows you don't understand how the OS is actually built.

Why
not let the manufacturer of the PDA decide what to offer his customers
(he's doing that already anyway) and make no difference except which
modules he included. A programm should be able to figure out whether the
needed modules are present or not.

An application cannot figure out what will be available on the device at
compile time and at run time it may be too late (it may be linked to
something that isn't available). It's not simply a matter of a DLL being
present or not, it's also a matter of is a specific function actually in a
specific DLL. Would you want to write an app where you have to call
LoadLibrary and GetProcAddress for every function (even for the Win32
functions)? That's just not a realistic scenario. That's the point of the
SDK.

The only problem might be devices with no visible/audible output systems
(e.g. no display).

I can give you a lot more scenarios than that.

-Chris

 

[Markus Humm]

[snip]

No you don't (excluding XPe, which is out of the scope of this
conversation). You can install applications and drivers at run time, but
that is not a modular OS. You cannot remove supported features and APIs from
the kernel. kernel32.dll, user32.dll, etc. all have a fixed set of
functions and you're guaranteed that. You cannot say the same for
coredll.dll.

Hm, I didn't say much about the kernel. I meant auxilary things (like
the GUI or like DirectX, Multimedia functions etc.)

That statement shows you don't understand how the OS is actually built.

Then it has too much functions in the kernel which don't really belong
there (my opinion).

An application cannot figure out what will be available on the device at
compile time and at run time it may be too late (it may be linked to
something that isn't available). It's not simply a matter of a DLL being
present or not, it's also a matter of is a specific function actually in a
specific DLL. Would you want to write an app where you have to call
LoadLibrary and GetProcAddress for every function (even for the Win32
functions)? That's just not a realistic scenario. That's the point of the
SDK.

Okay if using thins in a static way you're right, but why not make
something simple to be able query what APIs are present at startup time
for the program where no static DLL bindings etc are even performed?
Then the app. could somehow tell the user that something is missing.

For gifing the user some message that some needed component is not
present display or speaker would be sufficient.

Greetings

Markus

 

[Paul G. Tobey [eMVP]]

You can generally tell whether an API class is ready yet, IsApiReady() and
time-out on that, if you want, but, again, if your program is linked with an
import library for a given DLL, it doesn't make any sense to load the
application when the DLL is missing. Being able to check if every single
call in the Win32 API is present or not is far beyond the range of
sensibility for a smallish device.

You can code your program so that it won't error out if a given API is
missing. You don't get an exception when P/Invoking something until you
actually do it and the DLL where it's implemented isn't found. If you
carefully handle every possible exception or pretest for the availability of
the APIs that might or might not be there, then your code is pretty capable
of running on any display-based device (.NET CF itself won't launch a
program on a headless device).

Paul T.

[snip]

No you don't (excluding XPe, which is out of the scope of this
conversation). You can install applications and drivers at run time, but
that is not a modular OS. You cannot remove supported features and APIs
from
the kernel. kernel32.dll, user32.dll, etc. all have a fixed set of
functions and you're guaranteed that. You cannot say the same for
coredll.dll.

Hm, I didn't say much about the kernel. I meant auxilary things (like
the GUI or like DirectX, Multimedia functions etc.)

That statement shows you don't understand how the OS is actually built.

Then it has too much functions in the kernel which don't really belong
there (my opinion).

An application cannot figure out what will be available on the device at
compile time and at run time it may be too late (it may be linked to
something that isn't available). It's not simply a matter of a DLL being
present or not, it's also a matter of is a specific function actually in
a
specific DLL. Would you want to write an app where you have to call
LoadLibrary and GetProcAddress for every function (even for the Win32
functions)? That's just not a realistic scenario. That's the point of
the
SDK.

Okay if using thins in a static way you're right, but why not make
something simple to be able query what APIs are present at startup time
for the program where no static DLL bindings etc are even performed?
Then the app. could somehow tell the user that something is missing.

For gifing the user some message that some needed component is not
present display or speaker would be sufficient.

Greetings

Markus