2. Q: Can I use eMbedded visual C++ 4.0 to develop C/C++ applications for my Windows Mobile 5.0 device? A: No, eMbedded Visual C++ 4.0 supports smart device development for Pocket PC 2003, Windows CE 4.2 and Windows CE 5.0. Windows Mobile 5.0 is not a supported platform in eMbedded Visual C++ 4.0. You must use Visual Studio 2005 to develop C/C++ applications for your Windows Mobile 5.0 device. http://support.symbol.com/support/search.do?cmd=displayKC&docType=k…...

We do not support the use of eVC4.0 on any WM terminal now (only CE5.0 ones). See the release notes on the EDMK for C at http://support.symbol.com/support/search.do?cmd=displayKC&docType=k… 0 14665937 ===== ... ...

If developing applications for Windows CE 5.0

Microsoft eMbedded Visual C++ 4.0

Microsoft eMbedded Visual C++ 4.0 Service Pack 4 

If developing applications for Windows Mobile 6.0, Windows Mobile 5.0 or Windows CE 5.0
    Microsoft® Visual Studio 2005    Microsoft® Visual Studio 2008 ......===Therefore what the customers wants to do is a 'cutomers own  risk', we should be careful about implying other than the supported options.That said, with a fair wind and co-operation from the customer it should be possible (as has been said before) to migtrate this to VS2005/8 and get it all working.Richard LH

For Spanish Post project, I developped an EvC4 application to provide single sign-on using Fusion APIs, for MC70 WM5.0. This very same programme (i.e, the exe file) did work fine on MC75 WM6.0; I did not have to recompile or port it in any way. And... it still works on MC75 WM6.1!! I guess what MS means is that FULL support of EvC4 for WM > 5.0 is over; in other words, some functionalities are being more and more discontinued. I suppose the greater WM is, the lesser compatibility functions are, so eventually all that could work is managed code. These are known MS plans, not only for mobile but also for PCs. We must keep this in mind.

The only reason to continue to develop using eVC 4.0 is that it was free. The output (exe, dll, etc.) from this development process will (or will not) continue to run on later OSs based purely on if the included items used during that development process are still present on all the OS involved (APIs, libraries, etc.). Both the Motorola supported development options for Windows Mobile (VS2005/8) are chargeable and available from Microsoft. Thus we have a situation where, because we note that we are unable to continue to support development using the (very old) free platform on Windows Mobile , we instead get sucked into doing just that. Presumbaly to allow a customer/partner to keep their development costs down. The official Motorola position (as regards to development options) is that we have discontinued support for development using eVC 4 on Windows Mobile terminals a while back. We still continue to support its use on CE terminals only. We only support VS2005 or 2008 as our Windows Mobile devlopment options. It is possible to get round this with a degree of work and basic knowledge but it is not a supported option from us. Richard LH

Dave, I use EVC4 to build SymScript - as a PPC2003 project - it will run on all our current platforms, WM5/6. I would suggest that they statically link any required libraries and not rely on the DLL's loading - as this will cause problems. Also any functionality from later OS's they will need to use Loadlibrary and GetProcAddress() to use. Any new projects I would use the VS and at least a CE 5 platform. They do not say what the error is - just that it does not run.

Paul, The point is that they will have to modify the program to move it to MC55, which is what they didn't want.  My PPC2003 programs don't run on the newer platforms, and all of the libraries are statically linked.  SymScript may run because it doesn't have a gui component.

You can use a tool called dumpbin (comes with the compiler) to view what modules are being brought in. If you use the /import option ( http://msdn.microsoft.com/en-us/library/d7k09ee7(VS.71).aspx) you may be able to determine what dependency is lacking and look into bring that over. Another alternative could be to launch the program under complier (need to load the .exe as a project and then kick off a debug run), and watching the output window to see what error is reported. Also is there is a DR watson dump file, take a look at that as well

Unfortunately, your customer is out of luck.  An MC50 application (assuming it's PPC2003) will not run on an MC55 without being recompiled for CE 5.0, at the minimum. Microsoft "broke" the compatibility chain at CE 4.2.  Thus, any application built with CE 5.0 and above will run on the MC55.  If they choose to stay with EVC4 as their development platform, their best bet would be to port the application to CE 5.0. When I'm developing applications for portablility between OS's, I generally stick with the MC9090c50 's DCP which is CE 5.0 and then toss in the latest EMDK (I'm using VS2005).  This was one of the last DCP's which works with both EVC4 and VS2005.   When I've done this, I've had the same executable work on a MC9090 (CE 5.0), MC55 (WM 6.1), MC70 (WM 5.0), MC3090 (CE 5.0), and MC3190(WM 6.1). There are also other considerations.  If they used any of the radio S24 API's in their program, they may no longer work with Fusion on the MC55.   I've ported several applications from the MC50 to the MC55.  So far, it's been mostly a recompile and then fixing the radio code.  I also needed to  adjust the scanner code too since we switched from a laser to an imager scanner.