Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Compact Framework / April 2006

Tip: Looking for answers? Try searching our database.

Windows Mobile dev. with .NET

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
~~~ .NET Ed ~~~ - 29 Mar 2006 23:26 GMT
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] - 29 Mar 2006 23:45 GMT
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

>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
[quoted text clipped - 17 lines]
> Thx!
> Emilio
Markus Humm - 30 Mar 2006 18:36 GMT
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] - 30 Mar 2006 18:52 GMT
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.

> Hello,
>
[quoted text clipped - 13 lines]
>
> Markus
Chris Tacke [MVP] - 30 Mar 2006 18:55 GMT
> 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 - 03 Apr 2006 19:33 GMT
[snip]

>> On the PC you also have a modular OS.
>
[quoted text clipped - 4 lines]
> 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.)

>>  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.

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

>> Why
>> not let the manufacturer of the PDA decide what to offer his customers
[quoted text clipped - 10 lines]
> 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.

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

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] - 03 Apr 2006 19:43 GMT
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]
>>
[quoted text clipped - 50 lines]
>
> Markus

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.