Migrating code from eVC++ 4.0 to .NET

  • Thread starter Thread starter Andrew
  • Start date Start date
A

Andrew

I am planning to migrate an application from eVC++ 4.0 (PocketPC 2003)
to .NET to run on WindowsXP. The application is layered into "GUI <->
Core <-> HardwareInterface". The GUI is going to be developed in .NET
using C#. My plan of attack is to build the core (uses MFC) as a MFC
dll (using VS.NET 2003 MFC dll project), and wrap the dll using the
[DllImport] feature of .NET to mix the unmanaged (core) and managed
(GUI) code. I am having a difficult time in creating the core dll, as
I am gettting tons of "missing storage-class or type specifier" errors
when compiling. All of the errors are spawned from winbase.h for
Windows Data Types (WORD, DWORD, HANDLE, etc).
Am I going about this the wrong way? Any input is appreciated.
 
Hi Andrew,

Could you be more specific with your problem description?

First of all, you can not develop native applications and dlls with Visual
Studio .NET 2003. VS .NET 2003 only allows you to develop C# and VB .NET
applications and dlls for mobile devices.

If you want to develop native dlls for mobile devices, you can only use
eVC++ 4.0 (for PPC '03 and higher).

The "VS .NET 2003 MFC dll project" should not be in the picture for your
mobile device solution.

I would like to also note that you can not use MFC classes within .NET CF
applications via DllImport. DllImport only helps you call native functions
from native DLLs.

If you need to call methods of MFC classes, you should wrap the class with
exported functions, similar to a COM wrapper.

Thanks

Ercan Turkarslan
Microsoft Mobile Devices Developer Support
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for you reply,

I'll try to explain the problem a little better:

I have a PocketPC application that is layered as so:

GUI <--> Core <--> HardwareInterface

I am want to put the application on the Tablet PC with a new GUI and
Hardware Interface, but leave the Core intact. The new GUI (C# Windows
Form) talks with the Core. The Core uses some MFC classes, so I am
attempting to create a MFC dll. I have selected the MFC DLL template in
the Visual C++ Projects when creating a new project. Once I have the
dll built, I plan to use the [DllImport] feature of .NET talk to between
the managed GUI and unmanaged Core dll. I am having problems building
the dll. I am gettting numerous "missing storage-class or type
specifier" for common Windows Data Types (WORD, DWORD, HANDLE, etc) in
winbase.h.

Am I approaching this incorrectly, or is not possible?

In eVC++ 4.0 there is an option to build for the WCE x86
Platform...excuse my ignorance, but does this mean I can use the dll or
exe created using the x86 build on TabletPC or DesktopPC using a x86
(Pentium) architecture? If so where can I get a x86 SDK for eVC++ 4.0?
(I dont have platform builder)

If these are not possible solutions, what are my options?

Thanks,

Andrew
 
No, you can't generate a Windows CE DLL, EXE, or anything else with eVC and
run it on a desktop operating system. You have to use a different compiler.

Paul T.
 
Andrew,

Have you considered rewriting the core code in C#? That wouldn't allow you
to reuse your C++ code, but you could create a single DLL that could be used
on both TabletPC and CE devices.
 
Let's try to clarify a few points.

1. Tablet PCs run Windows XP
2. Windows CE and Windows XP have different API sets, and often diferent
processor architecture
3. It is impossible to compile an unmanaged binary that will work under
WinCE and WinXP
4. It *is* possible to compile a managed assembly that will run on both
5. Managed code can P/Invoke into "flat" unmanaged APIs, not classes (in the
CF anyway)
6. x86 in Windows CE means either the emulator or a CEPC. While they are on
the x86 processor,
they are still WinCE, not XP

So, based on your stated goal:

1. You don't need eVC at all. you're running purely under XP
2. If you want to try to use this on CE, you must make a CE DLL with your
MFC classes as well
as a class factory and accessors (see the GDN POOM sample for help
there). Desktop MFC
code will likely not drop in, but will require some level of port work.
3. Lastly your linker erros sound like a simple missing #include or similar.
Have you tried to just
make a project from the wizard and build without adding anything new?

Hope this helps.

-Chris
 
Thanks for the replies! Bear with me...

I don't need the Core to work in work in CE anymore. I just need it to
work in .NET.

I did not add any new code to the MFC DLL project before building. I
got rid of almost all the BUILD errors by including windef.h...now I get
"missing storage-class or type specifier" build errors in winnt.h and
winbase.h for CONTEXT/PCONTEXT/LPCONTEXT. I can't seem to get rid of
these.

Chris made the comment "Managed code can P/Invoke into "flat" unmanaged
APIs, not classes." Does this just mean that my I CAN call the
unmanaged DLL? If the code is written in C++, .NET can call C++
classes, (IJW) right?

One other question...is it possible to take the CE code developed in
eVC++ and compile it in CE .NET to use with the C# GUI?

Thanks,
Andrew
 
Andrew,

Yes you can call functions (not methods in classes) in a C DLL from C# on
either the full or compact framework. The C DLL has to be built for the
correct platform however, so for example you'd use VS 2003 to build the
unmanaged C++ DLL for the desktop or Tablet and eVC++ to build the unmanaged
C++ DLL for a CE device (which I understand is not what you need to do,
right?)
 
You're messing up the terminology a bit. You don't *compile* anything in
CE.NET. CE.NET is an operating system, not a build environment. Further,
there is no such thing as the C# GUI. C# is a programming language. You
may create a program with it, targeting the run-time environment of the .NET
Compact Framework on Windows CE and build a GUI application with it. This
is the same process you performed when writing your original program. You
built an EXE which created the application itself. You, apparently, called
into a DLL which you also wrote which was targeted at MFC, which did
something (whether GUI or whatever, we don't know), and provided an
interface to the low-level hardware. The equivalent architecture in managed
code would be:

application (C# or VB.NET) -- intermediate DLL, if necessary, providing
object interface to low-level stuff (C# or VB.NET) -- low-level native DLL
*must* have C, not C++, function interface

If you have code, written in C++ and targeted at Windows CE (whether CE 3.0
or CE.NET 4.x or CE 5.x), you do not have a direct conversion path to
managed code, no. You can take that code and port it to C# (you are
changing languages, so you will have to change the syntax, etc.), and then
compile it with VS.NET to target Windows CE or Pocket PC devices.

Code written in C# or VB.NET *can* call native DLL functions, but, in the
..NET Compact Framework (the pieces that run on Windows CE devices), there is
no support for interacting with classes written in native code. So, what
you need in a native DLL that you want to call is simple C functions, not
C++ classes. Your understanding of what Chris said was wrong.

Paul T.
 
Back
Top