Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Mobile Development
  3. Mobile
  4. Porting WIn32->PPC.

Porting WIn32->PPC.

Scheduled Pinned Locked Moved Mobile
helpcsharpgraphicssysadminquestion
2 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Mike Doner
    wrote on last edited by
    #1

    Hi All, We currently have a client-server application written in Win32 and we're in the process of trying to create a slimmed down version of the client software for the Pocket PC. Our application is a fair size, and uses a few in-house developed DLLs for drawing areas etc. We want to be able to use code contained in these .DLLs on our Pocket PC app to avoid multiple copies of the same code in two projects. We're using VS2003.NET for the Win32 development, and eVC 4.0 for the PPC stuff. Has anyone been in these shoes before? How have they solved the problem? I thought of creating a similar .DLL in my PPC application, and actually link in the sources files from the original.DLL while adding #ifdefs to the .DLL to include functions that I require, then compile them using the evC compiler, realizing that not all the calls we make the .DLLs will be available in the PPC environment. This could be quite messy, but would eliminate the maintenence issue. I realize that some of the calls that the Windows .DLL will make, will not be available in the PPC Edition. We will need to address these individually I think. Any suggestions? Thank you very much. Mike

    M 1 Reply Last reply
    0
    • M Mike Doner

      Hi All, We currently have a client-server application written in Win32 and we're in the process of trying to create a slimmed down version of the client software for the Pocket PC. Our application is a fair size, and uses a few in-house developed DLLs for drawing areas etc. We want to be able to use code contained in these .DLLs on our Pocket PC app to avoid multiple copies of the same code in two projects. We're using VS2003.NET for the Win32 development, and eVC 4.0 for the PPC stuff. Has anyone been in these shoes before? How have they solved the problem? I thought of creating a similar .DLL in my PPC application, and actually link in the sources files from the original.DLL while adding #ifdefs to the .DLL to include functions that I require, then compile them using the evC compiler, realizing that not all the calls we make the .DLLs will be available in the PPC environment. This could be quite messy, but would eliminate the maintenence issue. I realize that some of the calls that the Windows .DLL will make, will not be available in the PPC Edition. We will need to address these individually I think. Any suggestions? Thank you very much. Mike

      M Offline
      M Offline
      Mike Dimmick
      wrote on last edited by
      #2

      That's generally the right approach. I've never really done much desktop drawing code, although there have been a couple of occasions when I've prototyped something on the desktop since desktop development is typically more rapid. I don't know if you're using MFC or not. MFC for Windows CE as supplied with the Pocket PC 2003 SDK is basically a cut-down version of MFC 6.0. You should also be aware that the compilers in eVC 4.0 are based on the Visual C++ 6.0 front-end, and their standards compliance is therefore similar to VC 6.0. If you are using MFC, you'll find most APIs are present. If not, there are a significant number of drawing APIs which aren't available on Windows CE, because they were redundant (for example, MoveToEx, LineToEx are not present because Polyline can do single and multiple line segments) and were therefore removed to make space. MFC simply wraps up these APIs. Windows CE does not support mapping modes. All drawing is done in pixel units, equivalent to the desktop's MM_TEXT mapping mode. You can only create very simple pens (one-pixel-wide dashed pens, any width solid pens, null pens). The path APIs are not available. I had thought that there was a difference between how Windows CE did FillRect and how the desktop does, with regard to filling the right-hand and bottom edges, but it appears that if it was ever a problem it was fixed before Pocket PC 2003 - I can't reproduce it. Perhaps I'd become confused between this and BitBlt. If what you're doing isn't device specific (for example making use of barcode scanner hardware or other OEM APIs), I've found that making use of the emulator does speed up development a little (not relying on a physical connection). If you're going to use an emulator, use the one from VS2005 because it's ARM-based, like the devices, rather than being x86-based like the ones supplied with the Pocket PC 2003 SDK. If you don't have VS2005, download the Microsoft Device Emulator 1.0 package[^] and the appropriate emulator images. To use this with eVC 4.0, run the Device Emulator Manager from VS2005 or from the Device Emulator install directory (DvcEmuManager.exe). Right-click the image you want to use and choose Connect - the emulator starts up. In ActiveSync

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups