.NET, Windows CE .NET, your comments appreciated...

Hi Y'all,

Im a little in the dark when it comes to .net and would there for like
to bounce 2 scenarios against my fellow Delphi developers to confirm
whether both or either one are plausible (could work) or ludicrous
(could be Im insane) or maybe but look out for ... and ... (could
work, but unsure about something or the other), of course you could
choose to ignore this all together simply because it has something to
do with .net, which also happens to be the reason why I find myself in
 this predicament...B-)

Scenario 1.

Assume you have a calculation engine written in Delphi 3 as a standard
DLL.  You would really love to have this calculation engine running on
a PDA, in the interest of saving time (a rare commodity for
developers) being able to port the Delphi 3 DLL to the PDA would save
100's of hours.  100's of hours which will be used to write it and
test it specifically for a PDA, if the port option doesn't pan out.

Scenario 2.

Is identical to scenario 1 with the only exception been: the
calculation engine is an in-process automation server written in
Delphi 5.

Some Background Info

The PDAs in question currently run Windows CE, and from what Ive read
about the future of Windows CE,  the next version will use a smaller
subset of the .net framework, designed specifically for
resouce-constrained devices, called the .NET Compact Framework.  No
prizes for guessing that the next Win CE version will be called, yup,
Windows CE .NET.  Microsoft claim .NET will provide platform
independence, Bills answer to J2EE, somehow I dont see Big Blue
loosing any sleep over .NET simply because I haven't seen/read
anything about .NET running on a mainframe, say a 390 running MVS..But
like I said previously Ive been living in a cave for the last 3 months
(not literally) and I now find myself on the outside of the jargon
circle looking in.  So if anyone knows of mainframe platforms sporting
the .NET framework, please pipe up and let us know...

So currently it seems as if platform independence really means just
that if however only applicable to HandHelds/PDAs/PocketPCs and PCs.
In theory a single source of code can be used to create an executable
capable of running on different platforms without source modifications
and/or recompiling, provided you restrict yourself to using code only
defined in the smaller subset of the .NET framework (Compact
Framework).  A Visual studio .NET (not that any of us ever expect to
use it :) addon called the Smart Device Extensions (SDE) is available,
this SDE installs the .NET compact Framework.

Possible solutions
(both require waiting for Borland release of Delphi for .net).

Scenario 1

Recompile the DLL in Delphi for .net, deal with any compatibility
issues,  then convert the  DLL into a web service, probably by
creating a web service wrapper to the DLL functions (kinda like one
would use MAPI.pas as a wrapper to the MAPI.DLL, but instead a  web
service which simply calls the DLL functions) , if a DLL can still be
used in the same manner under .net ?? if not then the DLL its self
would need to be converted into a web service.  Provided the code
remains with in the .NET Compact Framework it can then be shipped to a
PDA running Windows CE .NET and the calculation engine would then be
available as a web service to UI applications on the PDA ????

Scenario 2

Recompile the inprocess automation server using Delphi for .Net, once
again eliminate compatibility issues should any arise, if .NET and
more importantly the .NET compact framework support/allow the usage of
COM objects  ????? it can simply then be shipped to and registered on
the PDA ??? if COM is not natively supported perhaps support could be
added as an option ??? if its not supported at all then turn it into a
simply DLL and go with scenario1 ???

 Would anyone care to comment ???

Also what does or why does the documentation/articles I've read refer
to embedded applications .e.g. Development Tools for mobile and
embedded applications.
                  .e.g. Windows XP embedded....

Could anyone recommend articles/web sites other than wading through
the ton of msdn stuff on Microsoft.com.

Overall .NET seems on the surface to be quite interesting and Im sure
thats only because of the oo, in the end we've won, Microsoft has
finally given in and conceded that out of all development techniques
oo stills seems to be the best, and of course lets not forget to thank
them for interfaces, one of the few really useful things to come out
of Microsoft, albeit that its only how brilliantly Borland implemented
them in Delphi that makes them really great.  Perhaps with the new
.NET and VB .NET its time for me find a new email signature...


programming in visual basic is like kicking a dead whale down the