Using eVC4 to produce applications for PocketPC 2002

I am not sure which ng is more appropriate so I cross-post this.

What I want to do:
Create executables for PocketPC 2002 using eVC4

What I did:
Basically by experimenting I discovered that by setting linker options
/OSVERSION:3,0 /SUBSYSTEM:WINDOWSCE,3.0
and redirecting default include and lib directories to PocketPC 2002 SDK I
am able to produce aplications that run ok on my PPC02 device.
Of course I have to stay away from missing features such as exceptions but
even if I accidentaly use them the program won't link so it seems to be
safe.

My question:
Are there any problems that I have overlooked? The simple test applications
I created all seem to work fine but this of course doesn't prove anything.

Eugene

Paul
Fri Dec 12 18:00:29 CST 2003

I think that the main question is 'why'? Why not just use the tool designed
to target that environment?

Paul T.

"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:ex60xpQwDHA.3436@tk2msftngp13.phx.gbl...
> I am not sure which ng is more appropriate so I cross-post this.
>
> What I want to do:
> Create executables for PocketPC 2002 using eVC4
>
> What I did:
> Basically by experimenting I discovered that by setting linker options
> /OSVERSION:3,0 /SUBSYSTEM:WINDOWSCE,3.0
> and redirecting default include and lib directories to PocketPC 2002 SDK I
> am able to produce aplications that run ok on my PPC02 device.
> Of course I have to stay away from missing features such as exceptions but
> even if I accidentaly use them the program won't link so it seems to be
> safe.
>
> My question:
> Are there any problems that I have overlooked? The simple test
applications
> I created all seem to work fine but this of course doesn't prove anything.
>
> Eugene
>
>

Eugene
Fri Dec 12 20:42:34 CST 2003

Paul G. Tobey [eMVP] wrote:
> I think that the main question is 'why'? Why not just use the tool
> designed to target that environment?
>

I am porting some VC7 code. The eVC4 sucks but I still can tweak the code to
compile on it. The eVC3 sucks so much that it would require a full rewrite.

Eugene

Michael
Sat Dec 13 11:51:01 CST 2003

Huh? Rewrite your app? The IDE has no bearing on the code you can
write/programs you can run on a particular device. Hell, you can use
notepad as your editor and run command line tools (cl.exe, midl.exe, rc.exe,
link.exe, etc) to build your program.

eVC 3.0 makes it much simpler. You can probably do registry hacks and other
things to get eVC 4.0 to build your Pocket PC 2002 app, but the question
from Paul remains: why? And the answer is *not* "it would require a full
rewrite".

--

Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com


"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:%2381yELSwDHA.3116@TK2MSFTNGP11.phx.gbl...
> Paul G. Tobey [eMVP] wrote:
> > I think that the main question is 'why'? Why not just use the tool
> > designed to target that environment?
> >
>
> I am porting some VC7 code. The eVC4 sucks but I still can tweak the code
to
> compile on it. The eVC3 sucks so much that it would require a full
rewrite.
>
> Eugene
>
>

Eugene
Sat Dec 13 14:26:44 CST 2003

Michael J. Salamone [eMVP] wrote:
> Huh? Rewrite your app? The IDE has no bearing on the code you can
> write/programs you can run on a particular device. Hell, you can
> use notepad as your editor and run command line tools (cl.exe,
> midl.exe, rc.exe, link.exe, etc) to build your program.
>
> eVC 3.0 makes it much simpler. You can probably do registry hacks
> and other things to get eVC 4.0 to build your Pocket PC 2002 app,
> but the question from Paul remains: why? And the answer is *not*
> "it would require a full rewrite".
>

eVC3 compiler throws 500 error messages on the code that is happily compiled
by eVC4. From a cursory look most were related to some template stuff but I
have absolutely no desire to investigate each error and "fix" perfetly
correct code (it compiles on 4 other platforms as well as on eVC4).
I could understand you if eVC3 and eVC4 used the same compiler. As they do
not I find advice "just use eVC3" ridiculous. What if someone told you that
you only can use desktop VC 4 to build applications for Windows 98?

Eugene

Chris
Sat Dec 13 17:37:43 CST 2003

The point is that the compiler for eVC 3.0 is genrally what is required for
building applications for CE 3.0. If it's throwing errors it's likely
because the code is using something unavailble in CE 3.0 (exceptions and
RTTI come to mind, but there are probably others).

I don't think I would trust an app built with eVC 4.0 on a CE 3.0 device -
definitely not in a production environment. And if you run into trouble,
your using an unsupported scenario from MS, so if your customer has an issue
you don't have much recourse.

IMHO, unless it's a test application, or it's for internal, non-critical
use, the risk involved is too high. I can't imagine trying to tell a client
that I'm using an unsupported OS/compiler combination, and I sure wouldn't
do it and *not * tell them. But then, of course, it's not my project.


-Chris



"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:uuX#DebwDHA.1088@tk2msftngp13.phx.gbl...
> Michael J. Salamone [eMVP] wrote:
> > Huh? Rewrite your app? The IDE has no bearing on the code you can
> > write/programs you can run on a particular device. Hell, you can
> > use notepad as your editor and run command line tools (cl.exe,
> > midl.exe, rc.exe, link.exe, etc) to build your program.
> >
> > eVC 3.0 makes it much simpler. You can probably do registry hacks
> > and other things to get eVC 4.0 to build your Pocket PC 2002 app,
> > but the question from Paul remains: why? And the answer is *not*
> > "it would require a full rewrite".
> >
>
> eVC3 compiler throws 500 error messages on the code that is happily
compiled
> by eVC4. From a cursory look most were related to some template stuff but
I
> have absolutely no desire to investigate each error and "fix" perfetly
> correct code (it compiles on 4 other platforms as well as on eVC4).
> I could understand you if eVC3 and eVC4 used the same compiler. As they do
> not I find advice "just use eVC3" ridiculous. What if someone told you
that
> you only can use desktop VC 4 to build applications for Windows 98?
>
> Eugene
>
>

Eugene
Sat Dec 13 19:29:14 CST 2003

Chris Tacke, eMVP wrote:
> The point is that the compiler for eVC 3.0 is genrally what is
> required for building applications for CE 3.0. If it's throwing
> errors it's likely because the code is using something unavailble
> in CE 3.0 (exceptions and RTTI come to mind, but there are probably
> others).
>

Compiler throws errors because it doesn't understand C++ language. When you
use something unavailable on the target platform it is generally the linker
who complains. For example exceptions will cause linker error about not
found __CxxThrowException and __CxxFrameHandler. (btw it is quite possible
to implement these by yourself and have exceptions on PPC02 too)

<theory>
A compiler builds the code for a given processor(s). The object files it
produces contain machine opcodes that will run on any version of
processor(s) it supports. Since both PPC02 and PPC03 can run on the same
hardware it is reasonable to conclude that eVC4 compiler will produce a
valid code that can run on PPC02.
The linker is another matter. It produces the PE format file that is bound
to a specific platform. It is possible that format of .exe it produces or
some artifacts it introduces into the image will cause it to malfunction on
another system.
</theory>

Now what my experiments seem to show is that there are no major differences
between PE image produced by eVC3 linker and eVC4 linker apart from the OS
and subsystem version. eVC3 linker sets those to 3.0 while eVC4 to 4.x. The
refusal of PPC02 to run eVC4 produced images is clearly the result of it
checking the image version. By forcing the linker to set the correct version
and giving the compiler and linker correct headers and libraies from PPC02
SDK it is possible to make them produce supposedly correct executables.

My only question was whether someone is aware of any other reason why the
produced image may be incorect (some special assumtions linker makes or
such).

> I don't think I would trust an app built with eVC 4.0 on a CE 3.0
> device - definitely not in a production environment. And if you
> run into trouble, your using an unsupported scenario from MS, so if
> your customer has an issue you don't have much recourse.

This is 100% true but I am willing to take the risk.

> IMHO, unless it's a test application, or it's for internal,
> non-critical use, the risk involved is too high. I can't imagine
> trying to tell a client that I'm using an unsupported OS/compiler
> combination, and I sure wouldn't do it and *not * tell them. But
> then, of course, it's not my project.

If I were to count every instance where I had to use stuff unsupported or
undocumented by MS I would run out of fingers and other parts of the body
pretty quickly :-) The customers I produce software for don't give a damn
what and how I did. All they care about is whether it works and does so
reliably. Judging from the general quality of PPC software I have seen the
last point doesn't depend in any way on the usage of the MS blessed compiler
;-)

Eugene

Michael
Sat Dec 13 21:46:22 CST 2003

Verify the warning level is the same.

Beyond that, I've built tons of C/C++ code using the eVC 3.0 compiler/linker
to build Pocket PC 2002 apps. And, if we polled the audience, we'd find
tons more people who built tons more C/C++ code using the same
compiler/linker to build Pocket PC 2002 apps.

It's true that Pocket PC 2002 (actually *all* Windows CE platforms based on
Windows CE 3.0 and earlier) do not support C++ SEH and RTTI. You seem to
know that, and most definitively the people who shipped the compiler knew
that, too. It is then possible they have the compiler throw warnings if you
have it in your code? (I don't know from experience - I've never tried
it).

There is no runtime support for C++ SEH/RTTI on Pocket PC 2002, and so if
you somehow build one that uses it, it will either fail to load or crash and
burn if you attempt to run in on Pocket PC 2002. So go ahead - try to build
away using eVC 4.0. Best of luck.

And, yes, the opcodes will be valid. Doesn't mean it will work. For
SEH/RTTI, the runtime support must be there.
--

Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com


"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:uZISHHewDHA.2464@TK2MSFTNGP12.phx.gbl...
> Chris Tacke, eMVP wrote:
> > The point is that the compiler for eVC 3.0 is genrally what is
> > required for building applications for CE 3.0. If it's throwing
> > errors it's likely because the code is using something unavailble
> > in CE 3.0 (exceptions and RTTI come to mind, but there are probably
> > others).
> >
>
> Compiler throws errors because it doesn't understand C++ language. When
you
> use something unavailable on the target platform it is generally the
linker
> who complains. For example exceptions will cause linker error about not
> found __CxxThrowException and __CxxFrameHandler. (btw it is quite possible
> to implement these by yourself and have exceptions on PPC02 too)
>
> <theory>
> A compiler builds the code for a given processor(s). The object files it
> produces contain machine opcodes that will run on any version of
> processor(s) it supports. Since both PPC02 and PPC03 can run on the same
> hardware it is reasonable to conclude that eVC4 compiler will produce a
> valid code that can run on PPC02.
> The linker is another matter. It produces the PE format file that is bound
> to a specific platform. It is possible that format of .exe it produces or
> some artifacts it introduces into the image will cause it to malfunction
on
> another system.
> </theory>
>
> Now what my experiments seem to show is that there are no major
differences
> between PE image produced by eVC3 linker and eVC4 linker apart from the OS
> and subsystem version. eVC3 linker sets those to 3.0 while eVC4 to 4.x.
The
> refusal of PPC02 to run eVC4 produced images is clearly the result of it
> checking the image version. By forcing the linker to set the correct
version
> and giving the compiler and linker correct headers and libraies from PPC02
> SDK it is possible to make them produce supposedly correct executables.
>
> My only question was whether someone is aware of any other reason why the
> produced image may be incorect (some special assumtions linker makes or
> such).
>
> > I don't think I would trust an app built with eVC 4.0 on a CE 3.0
> > device - definitely not in a production environment. And if you
> > run into trouble, your using an unsupported scenario from MS, so if
> > your customer has an issue you don't have much recourse.
>
> This is 100% true but I am willing to take the risk.
>
> > IMHO, unless it's a test application, or it's for internal,
> > non-critical use, the risk involved is too high. I can't imagine
> > trying to tell a client that I'm using an unsupported OS/compiler
> > combination, and I sure wouldn't do it and *not * tell them. But
> > then, of course, it's not my project.
>
> If I were to count every instance where I had to use stuff unsupported or
> undocumented by MS I would run out of fingers and other parts of the body
> pretty quickly :-) The customers I produce software for don't give a damn
> what and how I did. All they care about is whether it works and does so
> reliably. Judging from the general quality of PPC software I have seen the
> last point doesn't depend in any way on the usage of the MS blessed
compiler
> ;-)
>
> Eugene
>
>
>

Chris
Sat Dec 13 22:44:08 CST 2003

I think the point we're all trying to make here is this:

There are quite a few of us with a fair amount of CE experience. It seems
that you have a solid C++ background, but not in CE. The experience is
saying that you really should use eVC 3.0 for targeting a CE 3.0 device. Of
course you can opt to do whatever you like and ignoring the voice of
experience is one option. Not quite sure why you asked for advice on the
newsgroup, though, if you simply wanted to ignore it.

-Chris



"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:uZISHHewDHA.2464@TK2MSFTNGP12.phx.gbl...
> Chris Tacke, eMVP wrote:
> > The point is that the compiler for eVC 3.0 is genrally what is
> > required for building applications for CE 3.0. If it's throwing
> > errors it's likely because the code is using something unavailble
> > in CE 3.0 (exceptions and RTTI come to mind, but there are probably
> > others).
> >
>
> Compiler throws errors because it doesn't understand C++ language. When
you
> use something unavailable on the target platform it is generally the
linker
> who complains. For example exceptions will cause linker error about not
> found __CxxThrowException and __CxxFrameHandler. (btw it is quite possible
> to implement these by yourself and have exceptions on PPC02 too)
>
> <theory>
> A compiler builds the code for a given processor(s). The object files it
> produces contain machine opcodes that will run on any version of
> processor(s) it supports. Since both PPC02 and PPC03 can run on the same
> hardware it is reasonable to conclude that eVC4 compiler will produce a
> valid code that can run on PPC02.
> The linker is another matter. It produces the PE format file that is bound
> to a specific platform. It is possible that format of .exe it produces or
> some artifacts it introduces into the image will cause it to malfunction
on
> another system.
> </theory>
>
> Now what my experiments seem to show is that there are no major
differences
> between PE image produced by eVC3 linker and eVC4 linker apart from the OS
> and subsystem version. eVC3 linker sets those to 3.0 while eVC4 to 4.x.
The
> refusal of PPC02 to run eVC4 produced images is clearly the result of it
> checking the image version. By forcing the linker to set the correct
version
> and giving the compiler and linker correct headers and libraies from PPC02
> SDK it is possible to make them produce supposedly correct executables.
>
> My only question was whether someone is aware of any other reason why the
> produced image may be incorect (some special assumtions linker makes or
> such).
>
> > I don't think I would trust an app built with eVC 4.0 on a CE 3.0
> > device - definitely not in a production environment. And if you
> > run into trouble, your using an unsupported scenario from MS, so if
> > your customer has an issue you don't have much recourse.
>
> This is 100% true but I am willing to take the risk.
>
> > IMHO, unless it's a test application, or it's for internal,
> > non-critical use, the risk involved is too high. I can't imagine
> > trying to tell a client that I'm using an unsupported OS/compiler
> > combination, and I sure wouldn't do it and *not * tell them. But
> > then, of course, it's not my project.
>
> If I were to count every instance where I had to use stuff unsupported or
> undocumented by MS I would run out of fingers and other parts of the body
> pretty quickly :-) The customers I produce software for don't give a damn
> what and how I did. All they care about is whether it works and does so
> reliably. Judging from the general quality of PPC software I have seen the
> last point doesn't depend in any way on the usage of the MS blessed
compiler
> ;-)
>
> Eugene
>
>
>

Eugene
Sun Dec 14 03:29:12 CST 2003

Chris Tacke, eMVP wrote:
> I think the point we're all trying to make here is this:
>
> There are quite a few of us with a fair amount of CE experience.
> It seems that you have a solid C++ background, but not in CE. The
> experience is saying that you really should use eVC 3.0 for
> targeting a CE 3.0 device. Of course you can opt to do whatever
> you like and ignoring the voice of experience is one option. Not
> quite sure why you asked for advice on the newsgroup, though, if
> you simply wanted to ignore it.
>

I'm sorry guys. I understand your answers come with the best of intentions
but it they don't really help. I asked a very straightforward question and
so far didn't get any legible answer apart from "you really shouldn't be
doing that becuase it is bad". If you know why it is bad please say so. If
nobody have ever tried what I am asking about just say so (and I would know
that this is untested territory and I am on my own) or don't answer.
Refering to some vague "experience" is fine but please could someone tell me
what _was_ this experience.

Eugene

Eugene
Sun Dec 14 03:52:31 CST 2003

Michael J. Salamone [eMVP] wrote:
> Verify the warning level is the same.

I did that.

> Beyond that, I've built tons of C/C++ code using the eVC 3.0
> compiler/linker to build Pocket PC 2002 apps. And, if we polled
> the audience, we'd find tons more people who built tons more C/C++
> code using the same compiler/linker to build Pocket PC 2002 apps.

I have no doubt about it. I already said that my problem is some code base
being ported from other platforms. If I will ever wish to write specifically
for PPC02 I will undoubtely use eVC3.

> It's true that Pocket PC 2002 (actually *all* Windows CE platforms
> based on Windows CE 3.0 and earlier) do not support C++ SEH and
> RTTI. You seem to know that, and most definitively the people who
> shipped the compiler knew that, too. It is then possible they have
> the compiler throw warnings if you have it in your code? (I don't
> know from experience - I've never tried it).

I don't have exceptions or RTTI in my code. The errors eVC3 gives me (at
least those that I had patience to look on) have nothing to do with any
platform support issues. They relate to language only (apparently some
template finctions that eVC4 and others are happy about are not ok with
eVC3). As I said in my intitial post I use PPC02 SDK with eVC 4. If I used
any of the features missing from this SDK the compiler or linker will tell
me.

> There is no runtime support for C++ SEH/RTTI on Pocket PC 2002, and
> so if you somehow build one that uses it, it will either fail to
> load or crash and burn if you attempt to run in on Pocket PC 2002.
> So go ahead - try to build away using eVC 4.0. Best of luck.

Thanks.

> And, yes, the opcodes will be valid. Doesn't mean it will work.
> For SEH/RTTI, the runtime support must be there.

Thanks again. Wasn't that the question I asked? I _know_ that opcodes will
be valid, I _know_ that EH and RTTI are not there, I _know_ how to compile
while setting a correct warning level, I _know_ all the APIs that my
application consumes and I _know_ that they are a subset of all the API
exposed by PPC02. Finally I _know_ that it doesn't mean it will (always)
work. What I asked was if anyone here knows why it might not work.

Eugene

ddl
Sun Dec 14 14:12:22 CST 2003

This question may have become a tad more interesting recently. Did I read the
notice from MSDN correctly that eVC3 is one of the packages being removed from
download in less than a month in connection with the Sun Java settlement?

Dan Lanciani
ddl@danlan.*com

Michael
Sun Dec 14 16:24:54 CST 2003

We use STL in our code - and build with eVC 3.0 compilers. But, we do
disable these two warnings: 4503 and 4786. If those are the warnings you
are getting, just put these lines in a common header file - ahead of the
template stuff you are using:

#pragma warning ( disable : 4786 )
#pragma warning ( disable : 4503 )

If there are other warnings, decide for yourself if they are benign or not
for your code and, if they are, turn them off.

If you still feel you need to use the eVC 4.0 compilers/linkers to build
Pocket PC 2002 binaries, then, as mentioned, this is unsupported. However,
assuming all your code uses functionality available on Pocket PC 2002, then
I can't think of a reason it wouldn't work. Make sure you are including 3.0
headers and linking to 3.0 libs.

--

Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com


"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:%23wE1VTiwDHA.1756@TK2MSFTNGP09.phx.gbl...
> Chris Tacke, eMVP wrote:
> > I think the point we're all trying to make here is this:
> >
> > There are quite a few of us with a fair amount of CE experience.
> > It seems that you have a solid C++ background, but not in CE. The
> > experience is saying that you really should use eVC 3.0 for
> > targeting a CE 3.0 device. Of course you can opt to do whatever
> > you like and ignoring the voice of experience is one option. Not
> > quite sure why you asked for advice on the newsgroup, though, if
> > you simply wanted to ignore it.
> >
>
> I'm sorry guys. I understand your answers come with the best of intentions
> but it they don't really help. I asked a very straightforward question and
> so far didn't get any legible answer apart from "you really shouldn't be
> doing that becuase it is bad". If you know why it is bad please say so. If
> nobody have ever tried what I am asking about just say so (and I would
know
> that this is untested territory and I am on my own) or don't answer.
> Refering to some vague "experience" is fine but please could someone tell
me
> what _was_ this experience.
>
> Eugene
>
>

Chris
Sun Dec 14 16:32:52 CST 2003

Yes. There was a large list. The full text also states that they will
re-release all of them shortly, as soon as they remove the VM from each.

-Chris


"Dan Lanciani" <ddl@danlan.*com> wrote in message
news:1183351@news1.IPSWITCHS.CMM...
> This question may have become a tad more interesting recently. Did I read
the
> notice from MSDN correctly that eVC3 is one of the packages being removed
from
> download in less than a month in connection with the Sun Java settlement?
>
> Dan Lanciani
> ddl@danlan.*com

ddl
Sun Dec 14 19:05:44 CST 2003

In article <ubZl4IpwDHA.3140@TK2MSFTNGP11.phx.gbl>, ctacke[at]Open_NET_CF[dot]org (Chris Tacke, eMVP) writes:
| Yes. There was a large list. The full text also states that they will
| re-release all of them shortly, as soon as they remove the VM from each.

Interesting. The version I received had only a very short list of packages
which would be re-released (eVC3 not included) and didn't say "shortly". I
was wondering if I needed to start downloading in a hurry... :)

Dan Lanciani
ddl@danlan.*com

| -Chris
|
|
| "Dan Lanciani" <ddl@danlan.*com> wrote in message
| news:1183351@news1.IPSWITCHS.CMM...
| > This question may have become a tad more interesting recently. Did I read
| the
| > notice from MSDN correctly that eVC3 is one of the packages being removed
| from
| > download in less than a month in connection with the Sun Java settlement?
| >
| > Dan Lanciani
| > ddl@danlan.*com

Eugene
Sun Dec 14 21:40:11 CST 2003

Michael J. Salamone [eMVP] wrote:
> We use STL in our code - and build with eVC 3.0 compilers.

I don't use STL in this project but out of curiosity how do you use STL when
excpetions are not available? I mean if you add stuff to vector for example
the normal STL would report out of memory error with an exception. Do you
have some modified STL that uses return codes instead? If so is it publicly
available?

> But, we
> do disable these two warnings: 4503 and 4786. If those are the
> warnings you are getting, just put these lines in a common header
> file - ahead of the template stuff you are using:
>
> #pragma warning ( disable : 4786 )
> #pragma warning ( disable : 4503 )
>
> If there are other warnings, decide for yourself if they are benign
> or not for your code and, if they are, turn them off.

Sure thing. These two are old friends from VC5 times :-) I am getting errors
not warnings unfortunately.

> If you still feel you need to use the eVC 4.0 compilers/linkers to
> build Pocket PC 2002 binaries, then, as mentioned, this is
> unsupported. However, assuming all your code uses functionality
> available on Pocket PC 2002, then I can't think of a reason it
> wouldn't work. Make sure you are including 3.0 headers and linking
> to 3.0 libs.

Thanks!

Eugene

Detlef
Sun Dec 14 15:08:59 CST 2003

Eugene,
I hate having a tons different built environments on my system. So I always
try to use the latest common one. In case of PPC2002 or WM2003 it's eVC
4.0. So attached please find the settings I use to built PPC2002 AND WM2003
compatible binaries for drivers (DLL), today plugins and applications. I
did not discovered any problem yet. It works as long as you don't use any
function not available on PPC2003 but I am sure you know about.

Here are the changes needed for emVC 4.0:
-----------------------------------------
Project --> Settings --> C/C++ --> Preprocessor Definitions:

change "_WIN32_WCE=$(CEVersion)" to "_WIN32_WCE=300"
change "$(CePlatform)" to "WIN32_PLATFORM_PSPC=310" (for PPC2000 just
"WIN32_PLATFORM_PSPC")
change "UNDER_CE=$(CEVersion)" to "UNDER_CE=300"


Link --> Project Options:
-------------------------
change "/subsystem:$(CESubsystem)" to "/subsystem:windowsce,3.00"


btw. there's still a problem nobody could fix yet. If you have to debug
both on PPC2002 as well as on WM2003 you need to do that with two different
development machines and setup. Either the platform manager for eVC 3.0
would not eccept WM2003 devices or eVC 4.0 will not accept PPC2002 device.
:(

Ozma
Mon Dec 15 02:26:04 CST 2003

Hmm... I'm downloading it this moment...
http://download.microsoft.com/download/9/d/2/9d2f6ee8-4c75-4749-86df-2dd5189
e6081/evt2002web_min.exe
eVC3 2002 ed
65K already got....
"Dan Lanciani" <ddl@danlan.*com> wrote in message
news:1183351@news1.IPSWITCHS.CMM...
> This question may have become a tad more interesting recently. Did I read
the
> notice from MSDN correctly that eVC3 is one of the packages being removed
from
> download in less than a month in connection with the Sun Java settlement?
>
> Dan Lanciani
> ddl@danlan.*com

Michael
Mon Dec 15 09:56:39 CST 2003

We have an STL that doesn't throw exceptions. I believe we got it from
stlport.com.


--

Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com


"Eugene Gershnik" <gershnik@hotmail.com> wrote in message
news:eITfB1rwDHA.540@tk2msftngp13.phx.gbl...
> Michael J. Salamone [eMVP] wrote:
> > We use STL in our code - and build with eVC 3.0 compilers.
>
> I don't use STL in this project but out of curiosity how do you use STL
when
> excpetions are not available? I mean if you add stuff to vector for
example
> the normal STL would report out of memory error with an exception. Do you
> have some modified STL that uses return codes instead? If so is it
publicly
> available?
>
> > But, we
> > do disable these two warnings: 4503 and 4786. If those are the
> > warnings you are getting, just put these lines in a common header
> > file - ahead of the template stuff you are using:
> >
> > #pragma warning ( disable : 4786 )
> > #pragma warning ( disable : 4503 )
> >
> > If there are other warnings, decide for yourself if they are benign
> > or not for your code and, if they are, turn them off.
>
> Sure thing. These two are old friends from VC5 times :-) I am getting
errors
> not warnings unfortunately.
>
> > If you still feel you need to use the eVC 4.0 compilers/linkers to
> > build Pocket PC 2002 binaries, then, as mentioned, this is
> > unsupported. However, assuming all your code uses functionality
> > available on Pocket PC 2002, then I can't think of a reason it
> > wouldn't work. Make sure you are including 3.0 headers and linking
> > to 3.0 libs.
>
> Thanks!
>
> Eugene
>
>

r_z_aret
Mon Dec 15 10:22:51 CST 2003

On Fri, 12 Dec 2003 15:48:27 -0800, "Eugene Gershnik"
<gershnik@hotmail.com> wrote:

>I am not sure which ng is more appropriate so I cross-post this.
>
>What I want to do:
>Create executables for PocketPC 2002 using eVC4

Many of us have had the luxury of writing apps _for_ Windows CE, and
have been doing it long enough that our code is compatible with eVC 3.
Some of us have been carefully building to lowest common denominator
so our source code works with just about any Microsoft compiler.

But I can certainly sympathise with someone who _has_ a bunch of code
that already works on "big" Windows and wants to port the program to
CE. My sense is that eVC 4 is a lot less restrictive, and thus
preferable. I think you already know you have to choose whether to
rewrite or use unsupported methods. I know I've seen some serious
discussions about these methods, but am not sure where. You might try
http://groups.yahoo.com/group/windowsce-dev


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com

Eugene
Mon Dec 15 11:38:33 CST 2003

r_z_aret@pen_fact.com wrote:
> On Fri, 12 Dec 2003 15:48:27 -0800, "Eugene Gershnik"
> <gershnik@hotmail.com> wrote:
>
>> I am not sure which ng is more appropriate so I cross-post this.
>>
>> What I want to do:
>> Create executables for PocketPC 2002 using eVC4
>
> Many of us have had the luxury of writing apps _for_ Windows CE, and
> have been doing it long enough that our code is compatible with eVC
> 3.
> Some of us have been carefully building to lowest common denominator
> so our source code works with just about any Microsoft compiler.
>
> But I can certainly sympathise with someone who _has_ a bunch of
> code
> that already works on "big" Windows and wants to port the program to
> CE. My sense is that eVC 4 is a lot less restrictive, and thus
> preferable. I think you already know you have to choose whether to
> rewrite or use unsupported methods. I know I've seen some serious
> discussions about these methods, but am not sure where. You might
> try
> http://groups.yahoo.com/group/windowsce-dev

I have found a thread that talked about these issues there. Thanks a lot!

Eugene

Eugene
Mon Dec 15 13:30:27 CST 2003

Michael J. Salamone [eMVP] wrote:
> We have an STL that doesn't throw exceptions. I believe we got it
> from stlport.com.

Interesting. By default STLPort substitutes the following

TerminateProcess(GetCurrentProcess(), 0);

for any "throw" when on WinCE. It is also possible to substitute something
else as long as you do not return to the caller. This is probably enough to
write for WinCE from scratch but could be a big problem when porting.

Eugene

Eugene
Tue Dec 16 22:21:49 CST 2003

Detlef Jenett wrote:
> Eugene,
> I hate having a tons different built environments on my system. So I
> always try to use the latest common one. In case of PPC2002 or WM2003
> it's eVC
> 4.0. So attached please find the settings I use to built PPC2002 AND
> WM2003 compatible binaries for drivers (DLL), today plugins and
> applications. I did not discovered any problem yet. It works as long
> as you don't use any function not available on PPC2003 but I am sure
> you know about.
>
> Here are the changes needed for emVC 4.0:
> -----------------------------------------
> Project --> Settings --> C/C++ --> Preprocessor Definitions:
>
> change "_WIN32_WCE=$(CEVersion)" to "_WIN32_WCE=300"
> change "$(CePlatform)" to "WIN32_PLATFORM_PSPC=310" (for PPC2000 just
> "WIN32_PLATFORM_PSPC")
> change "UNDER_CE=$(CEVersion)" to "UNDER_CE=300"
>
>
> Link --> Project Options:
> -------------------------
> change "/subsystem:$(CESubsystem)" to "/subsystem:windowsce,3.00"
>

Thanks! This pretty much corresponds to what I have been doing so it looks
like I am on the right road.


> btw. there's still a problem nobody could fix yet. If you have to
> debug both on PPC2002 as well as on WM2003 you need to do that with
> two different development machines and setup. Either the platform
> manager for eVC 3.0 would not eccept WM2003 devices or eVC 4.0 will
> not accept PPC2002 device. :(

Yeah I am suffering from this too :-( I wonder why so many people consider
the situation with eVC3/eVC4 normal. Just imagine what would happen if for
example VC7 wouldn't be able to debug executables on Windows 98 (or require
major tweaks to even compile for it). I can only assume that either the eVC
group at MS is crazy or the company is playing some dumb marketing game.

Eugene