Try-catch support in an ATL COM developed with eVC 4.0 for PPC2003

[Udara W Gunawardane]

Can C++ exception handling (i.e. try-catch) be used in an ATL COM developed
with eVC 4.0 for PPC2003?

The overview of eMbedded Visual C++ 4.0 claims...
"The Microsoft® eMbedded Visual C++ 4.0 tool delivers a complete desktop
development environment for creating applications and system components for
Windows® CE .NET-powered devices.
With new capabilities like C++ exception handling, Run Time Type Information
(RTTI), include STL library components, and a plethora of new debugger
functionality, eMbedded Visual C++ 4.0 provides you with the power and
flexibility to create the most advanced applications for Windows CE .NET."
Is PPC2003 a "Windows® CE .NET-powered device"? I thought it was... pls
correct me.

Assuming what I am trying to do is 'allowed', I tried it out nevertheless,
and this was the chronological outcome.

Firstly, I get, as expected, ...
<Interface>.cpp(14) : warning C4530: C++ exception handler used, but unwind
semantics are not enabled. Specify -GX

Then, once I specify /GX in Project Settings, regardless of the attributes I
have chosen in the "New ATL Object..." wizard, I get...
StdAfx.obj : error LNK2019: unresolved external symbol "void __cdecl `eh
vector destructor iterator'(void *,unsigned int,int,void (__cdecl*)(void
*))" (??_M@YAXPAXIHP6AX0@Z@Z) referenced in function "public: void * __cdecl
ATL::CComTypeInfoHolder::s
tringdispid::`vector deleting destructor'(unsigned int)"
(??_Estringdispid@CComTypeInfoHolder@ATL@@QAAPAXI@Z)

Also, if I choose "Dual Interface" in the "New ATL Object..." wizard, I
additionally get...
<Project>.obj : error LNK2001: unresolved external symbol "void __cdecl `eh
vector destructor iterator'(void *,unsigned int,int,void (__cdecl*)(void
*))" (??_M@YAXPAXIHP6AX0@Z@Z)
<DualInterface>.obj : error LNK2001: unresolved external symbol "void
__cdecl `eh vector destructor iterator'(void *,unsigned int,int,void
(__cdecl*)(void *))" (??_M@YAXPAXIHP6AX0@Z@Z)
<Project>.obj : error LNK2019: unresolved external symbol "void __cdecl `eh
vector constructor iterator'(void *,unsigned int,int,void (__cdecl*)(void
*),void (__cdecl*)(void *))" (??_L@YAXPAXIHP6AX0@Z1@Z) referenced in
function "public: long __cdecl ATL::CComTypeInfoHolder::LoadNameCache(struct
ITypeInfo *)" (?LoadNameCache@CComTypeInfoHolder@ATL@@QAAJPAUITypeInfo@@@Z)

What am I missing out on here?

Thanks a bunch!
UG

[Ori Amiga [MSFT]]

Windows CE .NET 4.2 does support C++ Exception Handling, and Run Time Type
Information (RTTI).

that said, Pocket PC 2003 (and Smartphone 2003) do support C++ Exception
Handling, but do not support RTTI. and so, COREDLL itself on PPC and SP
2003 does not have the necessary RTTI support exports, and hence the
COREDLL.LIB in the SDK does not contain the needed support either.

--
Ori Amiga
Lead Program Manager
Microsoft Mobile Devices

This posting is provided "AS IS" with no warranties, and confers no rights.

"Udara W Gunawardane" <uda...@e-gtp.com> wrote in message
news:eu%23cV5Tc...@TK2MSFTNGP10.phx.gbl...

[Udara W Gunawardane]

Thanks Ori!
I guess that explains why it compiles and links just fine when I choose
"STANDARD SDK" (instead of "POCKET PC 2003") in the WCE Active Configuration
combobox.

Quoting from the eVC 4.0 books online...
"The real power of C++ exception handling lies not only in its ability to
deal with exceptions of varying types, but also in its ability to
automatically call destructor functions during stack unwinding, for all
local objects constructed before the exception was thrown."
But, enabling unwind semantics is a no-no with PPC 2003, because the /GX
switch results in these linker errors (because RTTI is not supported)! That
leaves us developers with only two 'bad' options...
1. Use try-catch without the /GX switch and choose to ignore the
compile-time warning, as well as any consequential undesirable effects. I
guess this puts C++ exception handling on par with SEH on PPC 2003, as far
as cleanup during stack unwinding is concerned!
2. Stick on with SEH till try-catch support becomes proper on PPC.

So, in effect, am I right to say that PPC 2003 has opted to support only a
subset (how large or small it may be) of the Windows CE .NET STANDARD SDK
feature set? What's MS's stance on the degree of compliance required of a
particular OEM's platform with the Standard SDK, in order to certify it as
"Windows CE .NET compatible"? I, for one disgruntled developer, had a lot of
hopes pinned on try-catch support on Windows CE .NET + PPC 2003.

UG

"Ori Amiga [MSFT]" <oria...@online.microsoft.com> wrote in message
news:eEySMGlc...@tk2msftngp13.phx.gbl...

[Ori Amiga [MSFT]]

in essence, yes, you can say Pocket PC 2003 only supports a subset of the
WinCE .NET Standard SDK. the easiest way to tell which specific subset is
supported is by looking at the SDK help documentation -- there are separate
sections for the supported OS APIs and PPC-specific APIs.

that said, we are still looking into some _potential_ ways to alleviate the
pain around C++ exception handling and RTTI on PPC 2003. we have no set
plan in place at this time, but i wanted to let you know we're investigating
possible solutions/work-arounds. if we come up with a feasible solution
we'll post to the newsgroup.

thanks Udara.

--
Ori Amiga
Lead Program Manager
Microsoft Mobile Devices

This posting is provided "AS IS" with no warranties, and confers no rights.

"Udara W Gunawardane" <uda...@empriseit.com> wrote in message
news:ObqUTYq...@TK2MSFTNGP12.phx.gbl...