Page 1
Page 2
Page 3
Microsoft Embedded Developers
Conference (DevCon) Nov. 28-30, 2001
I've just returned from this year's
embedded DevCon and I feel that there was so much useful
information presented that those who couldn't attend shouldn't
be left out in the cold. There will likely be a mixture
of feelings from current application developers as to the
direction that Microsoft is taking us, but I'm most definitely
in the camp that views it as "a large improvement that
will start with a steep learning curve and fits of growing
pains."
The conference was held at the Bellagio
hotel in Las Vegas, Nevada - a city of extreme opulence.
The conference spanned three days - four if you attended
Tuesday's tutorial sessions (which I did not). Each day
consisted of a continental breakfast, morning "break-out"
sessions, lunch, afternoon "break-out" sessions
and dinner. There were also several hands-on tutorial sessions
run repeatedly across the three days and the Windows XP
Embedded launch party Thursday night.
First, I'd like to thank Microsoft.
Recently I was awarded the Windows Embedded MVP- eMVP (embedded
most valuable professional) status, and as such was invited
to attend both an MVP appreciation lunch as well as two
MVP only deep tools reviews that took place at DevCon. (Note
To learn more about Windows Embedded Community and MVPs
you can visit: http://www.microsoft.com/windows/embedded/community)
In addition, I would like to thank Rubicon Technologies
for picking up my travel expenses to this event.
The following is a distillation of my
notes and thoughts from the sessions I attended. Since I
haven't mastered being in more than one place at one time,
there were a lot of sessions I didn't attend (largely hardware
and XPE sessions), but I did try to attend everything that
I felt would be applicable to today's eVB application developer.
I did manage to attend a few unrelated sessions that piqued
my interest, which I will still cover briefly.
Wednesday, 11/28
11:15 - 12:30: Moving from eVB to VB .NET Compact Frameworks
Paul Yao
This session was the eye-opener for
eVB developers. They unequivocally laid out the future (or
lack of future) for eVB. eVB version 3.0 is the last version
of eVB. eVB will continue to be supported on Pocket PC 2000
(old Pocket PC) and Pocket PC 2002, but it will not be supported
on Windows CE version 4.0.
As a side note, CE 4.0 = Talisker =
CE .NET, although these terms are often used interchangeably
the official name is Windows CE .NET. The .NET Compact Framework
(.NETcf) and the Smart Device Extensions (SDE) for Visual
Studio .NET are currently available as a tech preview. The
beta versions are expected in the first quarter of 2002
and the release will likely be late in the second quarter
(June or July?) of 2002. .NETcf will be supported on all
Windows CE .NET devices. It will only be supported on 3.0
devices that are on the Pocket PC platform. That means HPC,
HPC Pro and HPC 2000 will not support .NETcf.
What does this mean to eVB developers,
and developers in general?
- Start learning VB .NET. If you intend
to write anything for CE 4.0 devices, you'll have to make
the shift. It may be painful, but it's worth it.
- If you currently have eVB applications
or are wrapping up eVB applications in the near future,
put them into "maintenance mode." Support them,
but avoid extending or offering new features to them.
- If you want to target the HPC Pro
or HPC 2000, eVB is your only choice (for VB development
anyway).
So what will the VB developer get out
of moving to .NET (other than a future in CE development)?
Well the SDE are going to provide most of the features of
desktop VB .NET development. You'll use the same IDE for
development. You'll have true OOP. You'll have the ability
to do threading as well as create actual EXEs and DLLs.
Best of all, you'll get a real emulator.
Microsoft has, thankfully, redone the
entire emulator. It is now an actual CE image running in
a shell. Sure, it's going to be a memory hog (I'd say don't
even try developing on a machine with less than 512 meg
of RAM), but it will emulate a device almost exactly. I
say almost because it can't easily emulate device-specific
hardware or processor specific instructions, so physical
device testing will not go away.
You'll also get access to other cool
stuff like collections, structures, IrDA, SOAP, the SQLClient
provider (we'll cover that later), and strong XML support.
What sacrifices are going to be made?
Well, if you're familiar with .NET for the desktop, you'll
find a few things missing in the SDE and .NETcf. You won't
have Web Form support or the ability to host Web Services
on a CE device.
You won't have COM interoperability.
That means no direct calling of COM libraries. While this
seems quite huge, it can be worked around by creating a
DLL (in C++) that can act as a proxy between the COM object
and a caller. Microsoft is expecting to provide a wizard
that will create this proxy code for you, so hopefully it
won't be a huge issue. On the positive side, this method
is supposed to be significantly faster than the COM interop
on the desktop, and it may well be an alternative for the
desktop.
SDE applications will require the .NETcf
runtime libraries to be on the device. In the tech preview
build that equates to about a 3 meg footprint, but the final
release goal is about 1 meg.
Lastly, just like on the desktop, .NET
managed code is "semi" interpreted. It's not p-code
interpreted like eVB, but the apps compile to Microsoft
Intermediate Language (MSIL) with is then just-in-time compiled
(or JITTED) at runtime (by the JITTER, of course). This
is a performance hit over native C++ code, but still way
faster than eVB ever thought about being.
Next Page