Getting Started...

[tsapiano]

Hi,

I'm waiting to recieve a new WM2003 device this week with the intention of writing some software for my own purposes (I don't need too much horsepower, and I'd like to shed the weight of the laptop). Anyway, I'm trying to dig through Microsoft's material on what is necessary to do this task and it seems that there are a couple of options that I can work with but not so much information comparing the two.

I purchased VS.NET 2002 a few months back, so I am eligible for the cheap upgrade to 2003 - so the price really isn't an issue. However, I have heard mentions that the .NET CF only allows one to use VB or C# (correct me if I'm wrong) - C# is fine for most tasks, however I still have a lot of tightly coded ANSI C libraries that I originally wrote for embedded applications that I'd rather not have to rewrite (they don't need to use any SDK functions, just basic number crunching) ;)

eVC++ should work well, however I've only recently started developing for the Windows platform (I do UNIX/Linux and embedded applications, etc. professionally) and hence my only experience is with the .NET platform and not the MFC classes. Learning MFC isn't a huge problem, however with .NET around it does seem a little redundant (the windows end of things has so far just been recreational).

Anyway, what I'm wondering is:
(a) if anyone can give me some pro/con lists with the different development toolkits
and,
(b) if anyone has any books that they could suggest for an otherwise experienced programmer wanting to get into PPC development ;)

[KidKomputer]

Your basic choices are eVC++ and VS2003. The pros and cons are really based on the language that you want to write in VB/C# & C++. Although, eVC++ is the only way to get to COM objects and some other functionality. As a java programmer I'd say just bite the bullitt and rewrite your stuff in C# (C# is very similar to java). That way anything you write can be imported into any future .NET programming you do.

If you decide to go this route I'd grab a book on object oriented programming (if you're not familiar with it), and the MS .NET Compact Framework book.

If you decide to go with C++, good luck, as I truly hate that language.

You can also find a list of books here
http://www.devbuzz.com/content/books.asp

[tsapiano]

Your basic choices are eVC++ and VS2003. The pros and cons are really based on the language that you want to write in VB/C# & C++. Although, eVC++ is the only way to get to COM objects and some other functionality. As a java programmer I'd say just bite the bullitt and rewrite your stuff in C# (C# is very similar to java). That way anything you write can be imported into any future .NET programming you do.

Grr, that's what I figured. Using C# will work, the only problem is that anything writen in it is pretty much limited to the Windows platform - if, say, I wanted to port to PalmOS then I'd have to rewrite the code.

Ideally, I'd prefer to write the UI and API-specific code in C# and the core computational engines in C/C++ - however from what I am reading that won't work (well I guess I could write DLLs and use platform invoke - but that is somewhat of a kludgy solution). What exactly is it with VS.NET that doesn't allow other languages to be linked in with C# for this platform - I thought the whole point of the MSIL was to abstract the language from the platform?

Any third party products that allow the different languages to be linked together?

So it basically comes down to the fact that with the current microsoft tools one can _either_ use C++/MFC or C#/.NET (or VB, but I have no real interest there)? How exactly does Microsoft assume that all of the current eVC++ programmers are going to port their programs?

I've used C++ and Java quite a bit, and have been doing object oriented development for years now - For the last few month's I've used C# and while I do like the language I don't like the lack of portability it affords. The reason the libraries are written in simple ANSI C is that pretty much every microprocessor/platform/etc. has an efficient compiler for it and it hasn't changed in years ;)

If you decide to go this route I'd grab a book on object oriented programming (if you're not familiar with it), and the MS .NET Compact Framework book.

I'll take a look at the MS Press book - thanks ;) Any suggestion on material that covers both PPC MFC & .NET CF, as the more I read about this the more it sounds like I should really know both and apply them as necessary :(

If you decide to go with C++, good luck, as I truly hate that language.

The old dog/octopus analogy eh? Yeah, it does have it's moments - however C++ ties a good degree of portability with a high level of performance and the ability to muck with the inner recesses of the system - which, in a lot of cases, makes it quite suitable for my purposes ;)

[KidKomputer]

Grr, that's what I figured. Using C# will work, the only problem is that anything writen in it is pretty much limited to the Windows platform - if, say, I wanted to port to PalmOS then I'd have to rewrite the code.
The only solution I could suggest would be to rewrite in Java and then use the MS Java conversion tool located at
http://msdn.microsoft.com/vstudio/downloads/tools/jlca/default.aspx
I have no idea how well that would work though.

What exactly is it with VS.NET that doesn't allow other languages to be linked in with C# for this platform - I thought the whole point of the MSIL was to abstract the language from the platform?
Right now only VB and C# get complied to the MSIL, so they are the only ones that you can easily link together. I see it as the same as writing RMI calls.

How exactly does Microsoft assume that all of the current eVC++ programmers are going to port their programs?
I don't think they really care, and you still just use eVC++. The big thing is that you can port desktop apps to the pocket pc.

I've used C# and while I do like the language I don't like the lack of portability it affords
I imagine MS will eventually port the .NET runtime to other platforms...eventually.

The MS Press book is the only one out there on the .NET CF right now but you might find some stuff at http://www.gotdotnet.com/
I looked through my library and the only books with any significant MFC info were:
Windows CE Developers Handbook by Terence Goggin
Windows CE 3.0 Application Programming by Nick Grattan & Marshall Brain
They are both written for CE 3.0 though and you probbably want to check out these books in person to see if they have what you are looking for.

[rhmorrison]

...however I still have a lot of tightly coded ANSI C libraries that I originally wrote for embedded applications that I'd rather not have to rewrite (they don't need to use any SDK functions, just basic number crunching) ;)

eVC++ should work well, however I've only recently started developing for the Windows platform (I do UNIX/Linux and embedded applications, etc. professionally) and hence my only experience is with the .NET platform and not the MFC classes.
Why learn the classes at all, use eMbedded Visual C/C++ and program in pure C using the Windows API. The majority of functions are identical and it is actually possible to run the same application under windows if you do some #ifdef...#endif's around the PocketPC specific funtions (for example the Menu and Toolbar functions are somewhat different but the resources are identical).

I am currently writing a Nine Men's Morris program in this way and so far it has turned out very well (I haven't made the necessary #ifdef...#endif's yet to create a Windows program from the same source but I intend to). Of course the main difference is that I have already been programming in pure C using the Windows API for years and therefore it was a natural for me to go this route although the 'real' reason I picked my current method was based on trying out the three available environments:

eMbedded Visual Basic - though this would be a natural whereby for my game program I thought that I might have to do the computer AI player in C and create a DLL that would be invoked from Visual Basic but after I saw that you could dump a menu onto a form but had to create all the menu entries in code I figured "One small step backward for man, a giant leap backward for mankind".
eMbedded Visual C++ - let's you create a really cool 'empty' application with menu, toolbar, etcetera, but in order to run it you have to copy 2 MB's worth of DLL's onto your PocketPC - I figure "Ya, Right!".
so that left me with eMbedded Visual C (i.e. use eMbedded Visual C++ but program in pure C using the WinCE/PocketPC API). I figure when I am done that my application will still be under 175 k (maybe smaller) with NO DLL's. Unfortunately I made the discovery that is increasingly more difficult to find examples or code using the normal Windows API fortunately I have some old programming books and was able to locate some PocketPC C Windows API example code for various purposes.
For me the pure C Windows API is the right choice but if you already own .NET and are familiar with Java then I think that C# may be your better choice. You can still keep your optimized C code and put it in a DLL and access it from your C# code without any problem.

Whatever route you decide to take - HAVE FUN and enjoy the ride...
:soapbox:

[tsapiano]

Why learn the classes at all, use eMbedded Visual C/C++ and program in pure C using the Windows API. The majority of functions are identical and it is actually possible to run the same application under windows if you do some #ifdef...#endif's around the PocketPC specific funtions (for example the Menu and Toolbar functions are somewhat different but the resources are identical).

I'll have to look into that - any good books/websites that have references for the direct API? Just comming in at this point, my first thought was that .NET pretty much covered everything - however it appears that that isn't particularly the case at this point ;)

The only windows API that I've used is the .NET one - and I picked up VS.NET because I needed to quickly develop a windows client for one of my devices (a spectrophotometer). It did the job quite well, and I was able to pick up the important aspects of C# and the .NET framework in a few hours. I also managed to cut and paste enough code to tie the USB DLL into the program (that was something of a pain because the VS.NET manuals had next to nothing on the whole PInvoke system, and the DLL's documentation was writen pre-.NET) ;)

Since then I've written a few purely C# programs for my own purposes, but nothing really serious. Naturally, comming in at this stage I have no exposure with the Windows API or anything prior to .NET ;)

For me the pure C Windows API is the right choice but if you already own .NET and are familiar with Java then I think that C# may be your better choice. You can still keep your optimized C code and put it in a DLL and access it from your C# code without any problem.

That is what I am thinking as well - it should allow me to write the stuff I need portable in a C++ DLL and then the platform dependant stuff in C# - now, I just have to figure out the whole DLL thing ;)

Right now only VB and C# get complied to the MSIL, so they are the only ones that you can easily link together.
Ahhh, that explains a lot of things...

The big thing is that you can port desktop apps to the pocket pc.
That is the one major aspect that I like about the idea - that I can keep a similar code-base for both desktop and palmtop devices. If only it would allow other platforms as well ;)

I imagine MS will eventually port the .NET runtime to other platforms...eventually.
Not holding my breath for that one - even if/when they do I'm sure they won't be putting too much energy into keeping the other platforms working well ;)

PS Any idea how efficiently C# code gets compiled? With PPC2003 supporting XScale optimization so it would be nice to utilize that function - my C# projects really havn't done anything that pushes my computers too hard, however the little PXA255 microprocessor might be a bit more sensitive...

Thanks for the help guys :D

[hudsonmobile]

I am in the same camp as rhmorrison on this one -- if you have the background in straight-up Windows API programming in C, the move to Pocket PC is very straightforward, and you can't beat the compact code that results. Sounds like creating a DLL with all your legacy code and then writing the newer stuff in .NET-land will be most effective for you.

For the direct API (and/or embedded C++ using MFC), my best reference besides the included documentation in Embedded Visual C++ has been a Google search on the microsoft.public.pocketpc.developer newsgroup -- I created a favorites link in my browser that goes directly to a search page, and I haven't spent a dime on programming books. (which, IMHO, have a usefulness that is inversely proportional to their page length)

Here is the Google link I use to search the groups -- I remember having to handcraft it a bit to get the behavior I wanted:
http://groups.google.com/advanced_group_search?q=+group:microsoft.public.pocketpc.developer&hl=en&lr=&ie=UTF-8&oe=UTF-8