Re: Porting from PPC 2003 to WM 5.0

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I have several applications that I've developed using MS eVC C++ 3.0, and
they still work on the 2002, 2003, and Windows Mobile 5 OS devices. So for
now, you can still use this free development system for porting or
developing new apps for the WM 5 OS. The only thing you won't have, is
access to new functions, etc. that is part of the newer development
environments.

A few basic things to note about porting to WM 5 OS:

1) If you're writing info to the Registry File, you need to do a
RegFlushKey() call to ensure that all cached data is written to the file.
Microsoft discourages developers from doing this, but if your application
reads info from the Registry file while it is still running, you'll need to
do the flushing.

2) The appointment, contact, task, email, etc. databases are not stored in
the Object Store as in the previous OSes. You need to use POOM (Pocket
Outlook Object Model) to access such information.

3) If you are using the CEDB databases, they still work in WM 5 OS, although
the updated OS has a new database system called "EDB".

4) Some standard controls (e.g., property sheets, etc.) have a few quirks in
WM 5, so they don't all operate exactly the same way as under the 2003 OS.
This, of course, seems to always be the case when the OS changes.

Hope this helps.

ppcinfo


"Robert Scott" <no-one@xxxxxxxxxxxxxxxx> wrote in message
news:43790e6c.27014808@xxxxxxxxxxxxxxxxxxx
>I have an application that I designed using EVC 3.0 written in C++ but
> not with MFC. It uses only the Win32 API. Except for the little
> warning about possible incompatibilities during installation, my
> application runs as is on Pocket PCs going all the way back to 2001 up
> to devices running PPC 2003 SE. I got rid of the version warning by
> faking a higher version number in the .inf file, as described several
> times in this group (Thank you, group!). I have been distributing
> this program to the end users (professional piano tuners) for 4 years,
> and it is really convenient to have one program that works in such a
> wide range of devices.
>
> Now I am wondering about WM 5.0 on the Palm Treo, which has a square
> screen, and other new platforms. How long can I maintain this
> backward compatibility in one executable? At some point I guess I
> will have to jump to a new toolset and produce a separate executable
> (and installation program) for the newer platforms. The question is,
> when does that become absolutely necessary, and can I continue to use
> free tools to develop for the newer platforms (like the WM 5.0 on the
> Treo). To cover all the popular newer platforms, how many versions
> will I need?
>
>
> -Robert Scott
> Ypsilanti, Michigan


.

Relevant Pages

  • Re: Language to Learn
    ... I'll address you last question first. ... If you need ease of porting to other hardware and OS platforms, ... If you don't mind the learning curve of porting code to various OSes, ... a powerful language, and with M$ distribution tools, easy to create ...
    (comp.programming)
  • Re: standard doubt
    ... Or if a system with 32-bit two's complement integers writes -2147483648 to ... assuming little-endian representation won't reduce that by much. ... Assuming common behaviour simply means that porting to "unusual" platforms ...
    (comp.lang.c)
  • Re: Defining serial port IRQ
    ... Another way would be to move the settings from platform.reg to project.reg, ... project.reg if you want to use the display based or headless device ... > switch platforms, I need to remember to modify platform.reg to the correct ... platform.reg is the last registry file to be ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Porting to TRU64
    ... I have an application which is available in many platforms like HPUX64, ... Now I am porting for the first time to TRU64. ... the chnages that I have to make in compiler flags. ...
    (comp.unix.tru64)
  • Re: Eiffel and portability, which choice ?
    ... At least, I eventually succeeded in porting my small application to SE1.2r5 + GOBO, and moved the generated C code to several platforms (Linux/386, BSD/Sparc). ...
    (comp.lang.eiffel)