views:

1751

answers:

3

Thanks to the gurus at StackOverflow. You guys are awesome. I posted on question on detecting idle time on a Compact framework application and got answers very quickly. When I tried the suggested solution on my Windows XP development box, I get this error

Unable to load DLL 'coredll.dll': The specified module could not be found. (On Windows XP)

After googling for sometime I understood that OpenNETCF libraries are trying to launch coredll.dll to detect the idle time but this dll is shiped with only Windows Mobile OS. As we are developing the application on a Windows XP PC and dont have access to Windows CE device now, we are struck with the problem.

Is there any way to get coredll.dll on Windows XP? Any other solution to this problem?

Updated: we are targeting the application for device running on Windows Mobile 6 Professional

A: 

You can't run OpenNetCF in a Windows PC. You need to use a Windows CE emulator. This comes with the Windows CE SDK.

kgiannakakis
+6  A: 

I'm confused. The question was specifically about Compact Framework, which is for Windows CE. If you don't have your target hardware yet, then use an emulator.

In this specific case, the SDF is not P/Invoking to do this, it's using an IMessageFilter implementation. You could easily do the same for the desktop.

But that said, you simply can't develop a CF application targeting XP. What that means is that if you create your app using the full framework, targeting the desktop, and expect it to just run when you get your CE device, you're in for a big surprise. If targeting both OSes is a design goal, then there's a lot of work to be done, and most UI stuff is not transferrable (I'd actually recommend using different UI assemblies for the two targets and common business logic).

EDIT1

I guess to more fully answer the question of "can I get coredll.dll for my desktop?" the answer is a resounding "no". There are a multitude of reasons this wouldn't work (it's in ROM, it's hardware dependent, it's not actually a file, but fixed up to execute in place, it's compiled for a different OS, it may be compiled for a totally different processor, etc).

You have a couple options. You could try to create a desktop version of coredll.dll that exported all of the functions you want and proxies them to the kernel32, user32, etc DLLs. That's a boatload of work (been there, tried that).

You could try to write code that will work for both platforms. Doable, but also quite challenging.

The short of it is, unless you absolutely must target both, you don't want to try to. Get an emulator, virtual PC or some sort of eval system, and target that.

ctacke
We dont't a device emulator that supports our requirements. The application is developed for a custom device with resolution 1000x600 and I could not find any emulator with that resolution. That is the reason why we are launching the application as a standalone on XP box. We are prepared for the surprises in the UI when we deploy it on the actual we are expecting in the near future :)
Gopinath
ctacke,thanks for the detailed info. We are targeting only one device platform. Out of all the solutions your proposed, getting a device emulator seems to be best solution. I tried the emulators link you have provided above. It's already installed on my PC.How do I get an emulator that simulates 1000x600 display?
Gopinath
The DeviceEmulator 3.0 display driver doesn't support enough memory for that resolution (except maybe if you drop the color depth way, way down - it's got a maximum framebuffer size).
ctacke
A: 

Write code that works for both platforms.

In our solution anything that is going to touch the platform is abstracted out to different objects. Therefore we have a IPlatformServices object (that returns stuff like IPowerManagement, IPrinter etc) we have two different implementations a PCPlatformServices and a CEPlatformServices and the one returned is based on the Environment.PlatformID value. In your scenario you want 2 different IdleDetector objects one for CE and one for Desktop. Aye its a bit of a pain to identify and abstract all this but you will need to do this is you want compatability between the two different platforms.

Our "PCPlatformServices" is mainly mocks in our case as we only want desktop compatibility to test things more quickly that don't interact with the hardware (like app code / business logic)

Quibblesome

related questions