I am about to finally *commit* product porting and new development 
under VS20xx.  Currently have VS2005 and successfully recompiled all 
our projects and MFC applications. 139 of 150  projects in total where 
moved over.  But we never felt good to release it as an update.

About VS2010, we definitely going to upgrade to it, and I heard it is 
the "new VC6 (VS98)" - that excited me.  I am not like going to waste 
time downloading the RC and go thru any hassles installing it.

Can people with VS2010 now tell me about about their experiences and 
reality?  Such as:

I didn't like the class wizard in VS2005.  Is it better?

What about controls?  Was the property editor extended to better 
support extended aspects with controls (less sub-classing requirements))?

One of the reasons I didn't want to commit to VS20xx compile based 
product packaging and distribution was based of new OS and different 
flavors of OS SxS and manifest stuff.

The beauty of having a product under VC6 was that it was design purely 
for WIN32 and never had to worry about the version of windows users 
had.  That seem to change now.

So I guess, the deeper questions and answers I see is what are the 
"new got yas," if any?

Thanks

PS:  What is WPF overall? A new GUI foundation? Do you recommend WPF 
over MFC?

-- 
HLS

I am using the RC, and at the moment, what I can say is that it has all the IDE defects of
VS2002..VS2008, plus when you build a new project, ALL THE DEFAULTS ARE WRONG which
creates a bizarre  project that looks like VS.  You have to double-check EVERY settings
page to get rid of the crap they are doing "by default"...apparently, the goal is NOT to
make it easy to write applications, but to write applications that look really cool,
whether they make sense or not.

It has crashed several times on me, meaning that the fundamental reliability failures of
the IDE that started with VS2005 and continued into VS2008 have not been fixed, in spite
of the fact the editor is a total rewrite (and it is the same crappy UI design as all
previous editors, meaning they reimplemented a deeply flawed design without making a
single important improvement).  So if you liked the old piece of crap, you will like the
new editor, because it is the same piece of crap, reimplemented.

OTOH, the compiler supports the latest C++, including the ability to use "lambda
expressions" which are really, really cool.  There is also the Parallel Patterns Library
(PPL) which is utterly cool and probably worth the change.  Better support for debugging
threads, and if you get one of the top-of-the-line versions, you get really nice
performance analysis tools, again worth the effort of the upgrade.  

Bottom line: it is no worse (from my perspective) than VS2008, with lots of really good
features (code generation in the 32-bit compiler is significantly improved, using some of
the techniques from the 64-bit compiler), so you get a better MFC, a better STL, a better
C++ language, and better code generation, and that's just the C++/library picture.  EVen
though the IDE regularly crashes, it is not as unreliable as VS2008; the editor, which I
don't use anyway, is no worse than the crap we've had for 20 years (because MIcrosoft does
NOT understand how to build a text editor!), and everything else is much better.
					joe

On Sat, 27 Mar 2010 10:53:21 -0400, Hector Santos <sant9442@nospam.gmail.com> wrote:

>I am about to finally *commit* product porting and new development 
>under VS20xx.  Currently have VS2005 and successfully recompiled all 
>our projects and MFC applications. 139 of 150  projects in total where 
>moved over.  But we never felt good to release it as an update.
>
>About VS2010, we definitely going to upgrade to it, and I heard it is 
>the "new VC6 (VS98)" - that excited me.  I am not like going to waste 
>time downloading the RC and go thru any hassles installing it.
>
>Can people with VS2010 now tell me about about their experiences and 
>reality?  Such as:
>
>I didn't like the class wizard in VS2005.  Is it better?
>
>What about controls?  Was the property editor extended to better 
>support extended aspects with controls (less sub-classing requirements))?
>
>One of the reasons I didn't want to commit to VS20xx compile based 
>product packaging and distribution was based of new OS and different 
>flavors of OS SxS and manifest stuff.
>
>The beauty of having a product under VC6 was that it was design purely 
>for WIN32 and never had to worry about the version of windows users 
>had.  That seem to change now.
>
>So I guess, the deeper questions and answers I see is what are the 
>"new got yas," if any?
>
>Thanks
>
>PS:  What is WPF overall? A new GUI foundation? Do you recommend WPF 
>over MFC?
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

One of the serious (to me) defects of VS2010 (and the VS2008 Feature Pack) is that the
classes still include the CWinApp-derived class, BUT THERE IS CODE EVERYWHERE THAT USES
"TheApp."  First, nowhere should this class be included, except in its own implementation
..cpp file; second, there should have been a cleaner interface from components to the
application, but given the fundamental defect where this silly header file was included
everywhere, the programmers were funamentally slovenly and USED it, not realizing that in
REAL systems the first thing we do is get rid of it so there are no meaningless
dependencies introduced in the build.

I find this deeply offensive.
				joe

On Sat, 27 Mar 2010 20:59:58 -0500, Joseph M. Newcomer <newcomer@flounder.com> wrote:

>I am using the RC, and at the moment, what I can say is that it has all the IDE defects of
>VS2002..VS2008, plus when you build a new project, ALL THE DEFAULTS ARE WRONG which
>creates a bizarre  project that looks like VS.  You have to double-check EVERY settings
>page to get rid of the crap they are doing "by default"...apparently, the goal is NOT to
>make it easy to write applications, but to write applications that look really cool,
>whether they make sense or not.
>
>It has crashed several times on me, meaning that the fundamental reliability failures of
>the IDE that started with VS2005 and continued into VS2008 have not been fixed, in spite
>of the fact the editor is a total rewrite (and it is the same crappy UI design as all
>previous editors, meaning they reimplemented a deeply flawed design without making a
>single important improvement).  So if you liked the old piece of crap, you will like the
>new editor, because it is the same piece of crap, reimplemented.
>
>OTOH, the compiler supports the latest C++, including the ability to use "lambda
>expressions" which are really, really cool.  There is also the Parallel Patterns Library
>(PPL) which is utterly cool and probably worth the change.  Better support for debugging
>threads, and if you get one of the top-of-the-line versions, you get really nice
>performance analysis tools, again worth the effort of the upgrade.  
>
>Bottom line: it is no worse (from my perspective) than VS2008, with lots of really good
>features (code generation in the 32-bit compiler is significantly improved, using some of
>the techniques from the 64-bit compiler), so you get a better MFC, a better STL, a better
>C++ language, and better code generation, and that's just the C++/library picture.  EVen
>though the IDE regularly crashes, it is not as unreliable as VS2008; the editor, which I
>don't use anyway, is no worse than the crap we've had for 20 years (because MIcrosoft does
>NOT understand how to build a text editor!), and everything else is much better.
>					joe
>
>On Sat, 27 Mar 2010 10:53:21 -0400, Hector Santos <sant9442@nospam.gmail.com> wrote:
>
>>I am about to finally *commit* product porting and new development 
>>under VS20xx.  Currently have VS2005 and successfully recompiled all 
>>our projects and MFC applications. 139 of 150  projects in total where 
>>moved over.  But we never felt good to release it as an update.
>>
>>About VS2010, we definitely going to upgrade to it, and I heard it is 
>>the "new VC6 (VS98)" - that excited me.  I am not like going to waste 
>>time downloading the RC and go thru any hassles installing it.
>>
>>Can people with VS2010 now tell me about about their experiences and 
>>reality?  Such as:
>>
>>I didn't like the class wizard in VS2005.  Is it better?
>>
>>What about controls?  Was the property editor extended to better 
>>support extended aspects with controls (less sub-classing requirements))?
>>
>>One of the reasons I didn't want to commit to VS20xx compile based 
>>product packaging and distribution was based of new OS and different 
>>flavors of OS SxS and manifest stuff.
>>
>>The beauty of having a product under VC6 was that it was design purely 
>>for WIN32 and never had to worry about the version of windows users 
>>had.  That seem to change now.
>>
>>So I guess, the deeper questions and answers I see is what are the 
>>"new got yas," if any?
>>
>>Thanks
>>
>>PS:  What is WPF overall? A new GUI foundation? Do you recommend WPF 
>>over MFC?
>Joseph M. Newcomer [MVP]
>email: newcomer@flounder.com
>Web: http://www.flounder.com
>MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

> PS: =A0What is WPF overall? A new GUI foundation? Do you recommend WPF
> over MFC?
>

WPF will take you away from managed world to .Net, which is managed.
WinForms and now WPF are available in .Net and obviate the need to use
MFC in .Net world. In general, you would not use MFC in .Net, unless
you have a very good reason to do so(existing controls which you dont
want to migrate to .net).

--
Ajay

Ajay Kalra wrote:

>> PS:  What is WPF overall? A new GUI foundation? Do you recommend WPF
>> over MFC?
>>
> 
> WPF will take you away from managed world to .Net, which is managed.
> WinForms and now WPF are available in .Net and obviate the need to use
> MFC in .Net world. In general, you would not use MFC in .Net, unless
> you have a very good reason to do so(existing controls which you dont
> want to migrate to .net).

Thanks for the clear explanation.   Whats the difference from WPF and 
WinForms.

Would you say that MS is merging the .NET technologies anyway for MFC 
based code once compiled under VS2005 and more so with VS2010?

In other words, does a distribution for a VS2010 recompiled MFC applet 
with no explicit action on my part to include WPF/WINFORM, will it 
still required some level of .NET to be installed on a end-user machine?

For example, when I was playing with this OCX CTabStrip a few days 
ago, I noticed without further investigating or testing it as a 
standalone that it was loading .NET system dll.

This has been one of my concerns and not getting committed to VS2005 
development and staying with VS98 for my products until we are really 
to full commit to the new GUI foundation and/or .NET. I didn't want to 
get caught with MS ever increasing nature of indirect hooking into 
more managed and centralized sub-system for our customers, at least 
not yet.  Now we are more ready to do so - or not be too concern about 
it.  The market is more ready for it.

Is it safe to say that if I include and OCX/COM into the MFC package, 
there will be some managed sub-system requirement when its recompiled 
under VS2010?


-- 
HLS

On Mar 29, 3:54=A0pm, Hector Santos <sant9...@nospam.gmail.com> wrote:

> Thanks for the clear explanation. =A0 Whats the difference from WPF and
> WinForms.

WinForms came originally with .Net. WPF is the newer framework.
WinForms is now essentially not going to see enhancements(it will be
still part of .net).

> Would you say that MS is merging the .NET technologies anyway for MFC
> based code once compiled under VS2005 and more so with VS2010?

That happened long ago. Users who use MFC, dont typically use .Net .


> In other words, does a distribution for a VS2010 recompiled MFC applet
> with no explicit action on my part to include WPF/WINFORM, will it
> still required some level of .NET to be installed on a end-user machine?

No. A pure MFC app has no dependency on .Net.

> For example, when I was playing with this OCX CTabStrip a few days
> ago, I noticed without further investigating or testing it as a
> standalone that it was loading .NET system dll.

Then there is something worng. You shouldnt be depending upon .net if
you are pure MFC. It has nothing to do with VS2005 or VS2010. You
should identify by running Depends etc as to why do you have this
dependency.

--
Ajay

"Hector Santos" <sant9442@nospam.gmail.com> wrote in message 
news:Opk8um3zKHA.5940@TK2MSFTNGP02.phx.gbl...
> Is it safe to say that if I include and OCX/COM into the MFC package, 
> there will be some managed sub-system requirement when its recompiled 
> under VS2010?
>

No, .NET is not required for MFC apps in VS2010.  VS2010 has the VC6-style 
ClassWizard, a welcome-back addition.  It also has Windows 7-oriented 
enhancements to MFC.  And an MFC ribbon designer (for the ribbon that 
debuted in VS2008 Feature Pack).  None of which make MFC a particularly good 
productive or modern framework to develop in this decade, but it's still the 
best MFC to date.

-- David
 

"Hector Santos" <sant9442@nospam.gmail.com> wrote in message
news:#C0QC1bzKHA.5940@TK2MSFTNGP02.phx.gbl...
> I am about to finally *commit* product porting and new development under
> VS20xx.  Currently have VS2005 and successfully recompiled all our
> projects and MFC applications. 139 of 150  projects in total where moved
> over.  But we never felt good to release it as an update.
>
> About VS2010, we definitely going to upgrade to it, and I heard it is the
> "new VC6 (VS98)" - that excited me.  I am not like going to waste time
> downloading the RC and go thru any hassles installing it.
>
> Can people with VS2010 now tell me about about their experiences and
> reality?  Such as:
>
> I didn't like the class wizard in VS2005.  Is it better?
>

It's like the one from VS6.


> What about controls?  Was the property editor extended to better support
> extended aspects with controls (less sub-classing requirements))?
>

No.  MFC remains a thin layer on the common controls.


> One of the reasons I didn't want to commit to VS20xx compile based product
> packaging and distribution was based of new OS and different flavors of OS
> SxS and manifest stuff.
>

They took out the manifest stuff (at least relating to CRT redists) so it is
now like VS6 in that regard.  The CRT/MFC/ATL redists aren't manifested
anymore, there is no SxS installation of these anymore.  So it is back to
DLL hell, for these.  But just sticking them into your .exe folder works
without any additional work now.


> The beauty of having a product under VC6 was that it was design purely for
> WIN32 and never had to worry about the version of windows users had.  That
> seem to change now.
>

What do you mean?  Even VS 6 you still had to set _WIN32_IE, _WINVER, etc.
correctly.  This is still the case.


> So I guess, the deeper questions and answers I see is what are the "new
> got yas," if any?
>

The IDE is slightly slower than VS2008, so you need a beefy machine to run
it.  Build times are pretty quick.

> Thanks
>
> PS:  What is WPF overall? A new GUI foundation? Do you recommend WPF over
> MFC?
>

MFC is a GUI framework, requiring Windows.  WPF is a GUI framework requiring 
..NET.  WinForms is another GUI framework requiring .NET.

WPF is the newest one, and now there is starting to become available decent 
books on the subject, so you have a hope of mastering the steep learning 
curve.  (WinForms is very similar to MFC, both use HWND's, but WPF is very 
different.)  I favor Apress books "WPF Illustrated" and "WPF Recipes in C# 
2008".

In addition, WPF is a superset of Silverlight, which is how you program the 
recently announced Windows Phone (which replaces Windows Mobile).  So for 
career longevity, learning WPF/Silverlight is inevitable.  Now that Windows 
7 ships with .NET Framework 3.5 SP1, the preinstalled base of .NET is 
growing considerably in the mainstream.  While this doesn't help if you want 
to target .NET 4.0, .NET is in general becoming very attractive.

-- David 

Ajay Kalra wrote:

>> In other words, does a distribution for a VS2010 recompiled MFC applet
>> with no explicit action on my part to include WPF/WINFORM, will it
>> still required some level of .NET to be installed on a end-user machine?
> 
> No. A pure MFC app has no dependency on .Net.
> 
>> For example, when I was playing with this OCX CTabStrip a few days
>> ago, I noticed without further investigating or testing it as a
>> standalone that it was loading .NET system dll.
> 
> Then there is something worng. You shouldnt be depending upon .net if
> you are pure MFC. It has nothing to do with VS2005 or VS2010. You
> should identify by running Depends etc as to why do you have this
> dependency.

OK, so the bottom line, VS2010 does not add .NET dependency to "pure" 
MFC applications.

Ok, thanks, I can go on without worrying about it. ;)

-- 
HLS

David Ching wrote:

> "Hector Santos" <sant9442@nospam.gmail.com> wrote in message 
> news:Opk8um3zKHA.5940@TK2MSFTNGP02.phx.gbl...
>> Is it safe to say that if I include and OCX/COM into the MFC package, 
>> there will be some managed sub-system requirement when its recompiled 
>> under VS2010?
>>
> 
> No, .NET is not required for MFC apps in VS2010.  VS2010 has the 
> VC6-style ClassWizard, a welcome-back addition. 


Yes, that excites me.

> It also has Windows 
> 7-oriented enhancements to MFC.  And an MFC ribbon designer (for the 
> ribbon that debuted in VS2008 Feature Pack).  None of which make MFC a 
> particularly good productive or modern framework to develop in this 
> decade, but it's still the best MFC to date.

OK, so the "extra" controls, that is still pure MFC? or OCX/COM?

-- 
HLS

On Mar 29, 4:45=A0pm, Hector Santos <sant9...@nospam.gmail.com> wrote:
> Ajay Kalra wrote:
> >> In other words, does a distribution for a VS2010 recompiled MFC applet
> >> with no explicit action on my part to include WPF/WINFORM, will it
> >> still required some level of .NET to be installed on a end-user machin=
e?
>
> > No. A pure MFC app has no dependency on .Net.
>
> >> For example, when I was playing with this OCX CTabStrip a few days
> >> ago, I noticed without further investigating or testing it as a
> >> standalone that it was loading .NET system dll.
>
> > Then there is something worng. You shouldnt be depending upon .net if
> > you are pure MFC. It has nothing to do with VS2005 or VS2010. You
> > should identify by running Depends etc as to why do you have this
> > dependency.
>
> OK, so the bottom line, VS2010 does not add .NET dependency to "pure"
> MFC applications.
>

That has been the case since day one. Regardless of what VS you use,
MFC app by default will not have any .Net dependency.

--
Ajay

David Ching wrote:

>> One of the reasons I didn't want to commit to VS20xx compile based 
>> product packaging and distribution was based of new OS and different flavors 
>> of OS> SxS and manifest stuff.
>>
> 
> They took out the manifest stuff (at least relating to CRT redists) so 
> it is > now like VS6 in that regard.  The CRT/MFC/ATL redists aren't manifested
> anymore, there is no SxS installation of these anymore.  So it is back to
> DLL hell, for these.  But just sticking them into your .exe folder works
> without any additional work now.


Great!

>> The beauty of having a product under VC6 was that it was design purely 
>> for WIN32 and never had to worry about the version of windows users had.  
>> That seem to change now.


> What do you mean?  Even VS 6 you still had to set _WIN32_IE, _WINVER, etc.
> correctly.  This is still the case.


Yes, I always keep that to a minimum to maximize WIN32 across all 
Windows OS from 95-based OSEs to NT based OSes.  Only in rare 
exceptions, like IPHLPAPI.DLL for our SMTP Server for the changss made 
to DNS server discovery lookup starting with 2000, do we have a 
specific dependency.   Maybe a few others, but overall pure WIN32 and 
no advanced IE controls, etc.

> In addition, WPF is a superset of Silverlight....


That is all I needed to know about WPF for now.  I get the picture now. :)

Thank you!

-- 
HLS

Ajay Kalra wrote:

> On Mar 29, 4:45 pm, Hector Santos <sant9...@nospam.gmail.com> wrote:


>> OK, so the bottom line, VS2010 does not add .NET dependency to "pure"
>> MFC applications.
> 
> That has been the case since day one. Regardless of what VS you use,
> MFC app by default will not have any .Net dependency.

Right, but as I had eluded, as a business strategy that will change, 
IMO.   MS has been slowing changing the WIN32 compatibility long term 
process, understandably so.  As we move along, the required components 
  for centralization will be common once again, hence, these 
sub-systems dependencies can be leverage, even possible for MFC.

WPF amd WP7 is the first time where a new platform of development will 
be totally managed under a specific set of GUI development tools and 
sub-system.   .NET will be the next "long term promise" as more and 
more devices include the newer OSes with .NET as natural part of it.
I didn't knew exactly what WPF was. David telling me its based on 
SilverLight totally gives me the picture.

What I was asking was whether  VS2010 at some level has finally 
reached that point where developing for MFC or recompiling an existing 
MFC under VS2010 begins to introduced some of these dependencies.

I think we need to see what happens in July when XP and 2000 is no 
longer supported and all the remaining OSes has the new sub-systems.

-- 
HLS

On Mar 29, 5:36=A0pm, Hector Santos <sant9...@nospam.gmail.com> wrote:

> > That has been the case since day one. Regardless of what VS you use,
> > MFC app by default will not have any .Net dependency.
>
> Right, but as I had eluded, as a business strategy that will change,
> IMO. =A0

That will be foolhardy. MFC is what it is. Thats what differentiates
it from .Net: no dependency on .Net.

If MFC starts to depend upon .Net, it will be the end of MFC. There
will be absolutely no reason to use MFC.

> WPF amd WP7 is the first time where a new platform of development will
> be totally managed under a specific set of GUI development tools and
> sub-system. =A0 .NET will be the next "long term promise" as more and
> more devices include the newer OSes with .NET as natural part of it.
> I didn't knew exactly what WPF was. David telling me its based on
> SilverLight totally gives me the picture.

..Net has been in this position for a long time. WinForms was pure .Net
as well. Nothing new has happened here. Most of the resources from
MSFT will naturally go into the newer technologies. MFC is dated(and
there is nothing wrong in it).

--
Ajay

"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:ea82573e-1729-4c91-86f6-0ac1260ecdd8@g17g2000vba.googlegroups.com...
> .Net has been in this position for a long time. WinForms was pure .Net
> as well. Nothing new has happened here. Most of the resources from
> MSFT will naturally go into the newer technologies. MFC is dated(and
> there is nothing wrong in it).
>

The point I believe Hector is making is that Windows desktop has always 
allowed both native and .NET apps to co-exist, but the newer Windows 
platforms such as cross-platform browser and Windows Phone, which both use 
Silverlight, only allow managed development.  And it's not inconceivable 
that future Windows desktop will allow only managed apps as well, with 
native apps being run in a VM or other legacy hosting container.

The point is, if native development is the only trick in your bag, you are 
not going to be well positioned to develop Windows in the future.  MS is 
slowly making essential capabilities managed-only.

-- David
 

Thanks David. :)

David Ching wrote:

> "Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
> news:ea82573e-1729-4c91-86f6-0ac1260ecdd8@g17g2000vba.googlegroups.com...
>> .Net has been in this position for a long time. WinForms was pure .Net
>> as well. Nothing new has happened here. Most of the resources from
>> MSFT will naturally go into the newer technologies. MFC is dated(and
>> there is nothing wrong in it).
>>
> 
> The point I believe Hector is making is that Windows desktop has always 
> allowed both native and .NET apps to co-exist, but the newer Windows 
> platforms such as cross-platform browser and Windows Phone, which both 
> use Silverlight, only allow managed development.  And it's not 
> inconceivable that future Windows desktop will allow only managed apps 
> as well, with native apps being run in a VM or other legacy hosting 
> container.
> 
> The point is, if native development is the only trick in your bag, you 
> are not going to be well positioned to develop Windows in the future.  
> MS is slowly making essential capabilities managed-only.
> 
> -- David
> 
> 



-- 
HLS

On Mar 29, 7:24=A0pm, "David Ching" <d...@remove-this.dcsoft.com> wrote:
> "Ajay Kalra" <ajayka...@yahoo.com> wrote in message
>
> The point is, if native development is the only trick in your bag, you ar=
e
> not going to be well positioned to develop Windows in the future. =A0MS i=
s
> slowly making essential capabilities managed-only.

I have forgotten what native development is. It seems odd but I hope I
dont ever have to do that for GUI development. For server side work,
unmanaged is OK.

--
Ajay


>
> -- David

One of the things Microsoft discovered is that native code is NOT going to go away. That's
why we are getting enhanced support in new versions of MFC, constantly improved native
mode compiler, etc.  So they have realized that the managed world is NOT going to supplant
native code for a lot of applications. 

And nobody has mentioned "managed C++".
				joe

On Mon, 29 Mar 2010 16:24:48 -0700, "David Ching" <dc@remove-this.dcsoft.com> wrote:

>"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
>news:ea82573e-1729-4c91-86f6-0ac1260ecdd8@g17g2000vba.googlegroups.com...
>> .Net has been in this position for a long time. WinForms was pure .Net
>> as well. Nothing new has happened here. Most of the resources from
>> MSFT will naturally go into the newer technologies. MFC is dated(and
>> there is nothing wrong in it).
>>
>
>The point I believe Hector is making is that Windows desktop has always 
>allowed both native and .NET apps to co-exist, but the newer Windows 
>platforms such as cross-platform browser and Windows Phone, which both use 
>Silverlight, only allow managed development.  And it's not inconceivable 
>that future Windows desktop will allow only managed apps as well, with 
>native apps being run in a VM or other legacy hosting container.
>
>The point is, if native development is the only trick in your bag, you are 
>not going to be well positioned to develop Windows in the future.  MS is 
>slowly making essential capabilities managed-only.
>
>-- David
> 
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

"Joseph M. Newcomer" <newcomer@flounder.com> ha scritto nel messaggio 
news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd@4ax.com...

> One of the things Microsoft discovered is that native code is NOT going to 
> go away.

That's true. When you have a big code base of native C++ code, it makes more 
sense to maintain and evolve it, than migrating to .NET.
Moreover, C++ has a big advantage of being multiplatform and there is a rich 
ecosystem of open-source C++ libraries available.

And there are things that are better done in C++ than in C#. For example: 
shell extensions (which are COM based).
And even if last version of .NET (.NET 4) seems to allow side-by-side 
loading of different CLRs in the same process, it seems to me inefficient to 
inject the .NET runtime in a process (probably adding +20MB per process) to 
write a shell extension in managed code.


>That's
> why we are getting enhanced support in new versions of MFC,

As already written, if you have an existing C++/MFC app working, it can be 
wiser to maintain it and evolve it, than rewriting from scratch in WPF.
But, if you want to start a new app project today, what would you use? MFC 
or WPF? (Or probably just HTML/CSS/JavaScript...? Or maybe Adobe AIR?) Hard 
question!

Microsoft kind of gave an answer: in 1998 VS6 (great) IDE was built using 
MFC. I recall a tip-of-the-day that read something like this: "We used it 
before you: VC6 is written in MFC".
In 2010, VS2010 IDE is written in WPF.

And, as David pointed out, new mobile devices (which should represent a 
growing market) use managed GUI technologies like Silverlight.


> constantly improved native
> mode compiler, etc.

Yes, both the C++ compiler and the libraries have been being improved since 
VC6.


> And nobody has mentioned "managed C++".

I think "Managed C++" is deprecated (it was since VS2005, IIRC).
With VS2005 they introduced C++/CLI. However, I think that it is good only 
to build bridges between native code and managed code, e.g. to wrap some 
native code libraries and expose them to C#.

Giovanni

 

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd@4ax.com...
> One of the things Microsoft discovered is that native code is NOT going to 
> go away. That's
> why we are getting enhanced support in new versions of MFC, constantly 
> improved native
> mode compiler, etc.  So they have realized that the managed world is NOT 
> going to supplant
> native code for a lot of applications.
>
> And nobody has mentioned "managed C++".
> joe
>

Did I say native code was going away?  Clearly, it's not.

What I said is:  "if native development is the only trick in your bag, you 
are not going to be well positioned to develop Windows in the future." 
Clearly, that is true as well.

For the past three years, it's been very difficult for me to find Win32/MFC 
jobs here in the Bay Area.  Mostly all the job ads for Windows client want 
at least some .NET experience, and most of them are interested ONLY in .NET. 
C++ is still used for cross platform or embedded, but then we are not 
talking about Windows.  And it's not just me.  I have former colleagues who 
have been programming MFC (and MFC only) for the last decade who are now 
having difficulty being attractive in the job market.

Conversely, from the hiring side, one of my current gigs is at an extremely 
large and well known global nework company.  They hired me as a C# engineer 
and even though I suggested writing their app in C++, they expressly did not 
want that for fear they would not be able to hire capable people to maintain 
it, as "MFC programmers are dying out."  So it's a cycle that spells the 
doom of MFC.

It's funny that the lip service MS pays to MFC with "enhanced support in new 
versions of MFC" is not improving the job market at all.  Well, duh.  I look 
back at our debates on what is the proper prefix of user defined windows 
messages - UWM_, WM_, or whatever.  Then I think, how quaint it is to be 
using Windows messages as a communication mechanism in the first place! 
Qt's signals and slots, and .NET delegates are so simple and powerful in 
comparison.

-- David
 

On Mar 30, 7:37=A0am, "David Ching" <d...@remove-this.dcsoft.com> wrote:

> For the past three years, it's been very difficult for me to find Win32/M=
FC
> jobs here in the Bay Area. =A0Mostly all the job ads for Windows client w=
ant
> at least some .NET experience, and most of them are interested ONLY in .N=
ET.
> C++ is still used for cross platform or embedded, but then we are not
> talking about Windows. =A0And it's not just me. =A0I have former colleagu=
es who
> have been programming MFC (and MFC only) for the last decade who are now
> having difficulty being attractive in the job market.

This has been my experience as well. When we hire for GUI, we only
look for .Net. (C++ isnt even looked at). I havent seen a MFC job
opening in years.It has been nothing but .Net for a long while.

--
Ajay

I just worked on another complete .NET application and since it was very 
file system intensive I had to resort to pInvoking all sorts of Win32 
functions since the .NET System.IO implementation can't support file paths 
longer than 260 chars.  Sure, Windows supports it,  Win32 supports it, but I 
guess the .NET architects thought they didn't need to.   So far I haven't 
been able to do any C# programming without calling on Win32 functions 
directly.

I don't find the GUI editor to be that much better either.  I do like how 
some things, like font settings, are settable in the properties, but other 
than some conveniences like that, I don't see the big deal.

Tom

"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:644c9093-eec0-4e02-bc0d-01202e021824@x12g2000yqx.googlegroups.com...
> On Mar 29, 7:24 pm, "David Ching" <d...@remove-this.dcsoft.com> wrote:
>> "Ajay Kalra" <ajayka...@yahoo.com> wrote in message
>>
>> The point is, if native development is the only trick in your bag, you 
>> are
>> not going to be well positioned to develop Windows in the future.  MS is
>> slowly making essential capabilities managed-only.
>
> I have forgotten what native development is. It seems odd but I hope I
> dont ever have to do that for GUI development. For server side work,
> unmanaged is OK.
>
> --
> Ajay
>
>
>>
>> -- David
> 

I think they also discovered that C++ remains popular in spite of all the of 
rhetoric to the contrary.

Tom

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message 
news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd@4ax.com...
> One of the things Microsoft discovered is that native code is NOT going to 
> go away. That's
> why we are getting enhanced support in new versions of MFC, constantly 
> improved native
> mode compiler, etc.  So they have realized that the managed world is NOT 
> going to supplant
> native code for a lot of applications.
>
> And nobody has mentioned "managed C++".
> joe
>
 

Hi David,

I fully agree with you.  Any good programmer these days can live in several 
program paradigms.  I often jump between 3 during the same day.

I also agree that MFC is becoming more cob-web covered as time goes on. 
There is some improvement in 2010 with ClassWizard, but ...

Tom


"David Ching" <dc@remove-this.dcsoft.com> wrote in message 
news:u0UYR1$zKHA.2436@TK2MSFTNGP04.phx.gbl...
>
> Did I say native code was going away?  Clearly, it's not.
>
> What I said is:  "if native development is the only trick in your bag, you 
> are not going to be well positioned to develop Windows in the future." 
> Clearly, that is true as well.
>
> For the past three years, it's been very difficult for me to find 
> Win32/MFC jobs here in the Bay Area.  Mostly all the job ads for Windows 
> client want at least some .NET experience, and most of them are interested 
> ONLY in .NET. C++ is still used for cross platform or embedded, but then 
> we are not talking about Windows.  And it's not just me.  I have former 
> colleagues who have been programming MFC (and MFC only) for the last 
> decade who are now having difficulty being attractive in the job market.
>
> Conversely, from the hiring side, one of my current gigs is at an 
> extremely large and well known global nework company.  They hired me as a 
> C# engineer and even though I suggested writing their app in C++, they 
> expressly did not want that for fear they would not be able to hire 
> capable people to maintain it, as "MFC programmers are dying out."  So 
> it's a cycle that spells the doom of MFC.
>
> It's funny that the lip service MS pays to MFC with "enhanced support in 
> new versions of MFC" is not improving the job market at all.  Well, duh. 
> I look back at our debates on what is the proper prefix of user defined 
> windows messages - UWM_, WM_, or whatever.  Then I think, how quaint it is 
> to be using Windows messages as a communication mechanism in the first 
> place! Qt's signals and slots, and .NET delegates are so simple and 
> powerful in comparison.
>
> -- David
>
> 

On Mar 30, 1:42=A0pm, "Tom Serface" <t...@camaswood.com> wrote:
> I just worked on another complete .NET application and since it was very
> file system intensive I had to resort to pInvoking all sorts of Win32
> functions since the .NET System.IO implementation can't support file path=
s
> longer than 260 chars. =A0Sure, Windows supports it, =A0Win32 supports it=
, but I
> guess the .NET architects thought they didn't need to. =A0 So far I haven=
't
> been able to do any C# programming without calling on Win32 functions
> directly.
>
> I don't find the GUI editor to be that much better either. =A0I do like h=
ow
> some things, like font settings, are settable in the properties, but othe=
r
> than some conveniences like that, I don't see the big deal.
>


I have been doing GUI development with .Net for 4+ years. Number of
times I had to resort to Pinvoke: 0. I am sure there are cases which
are valid. I also dont consider this as a major weakness. Its not
something which is done every day.

I have no idea about editor. Thats the same for both, managed and
unmanaged and is a non issue. What matters is .Net framework. .Net
development is light years ahead of what MFC/Win32 is(even today). No
comparison. What I find odd is that this needs to be even talked
about.

--
Ajay

On Mar 30, 7:42=A0pm, "Tom Serface" <t...@camaswood.com> wrote:
> I just worked on another complete .NET application and since it was very
> file system intensive I had to resort to pInvoking all sorts of Win32
> functions since the .NET System.IO implementation can't support file path=
s
> longer than 260 chars.

Bloody hell, as a Brit would say! Out of curiosity, and if you don't
mind, what's the problem!? (You can point me to the offending IL if
that's easiest).

Goran.

> In 2010, VS2010 IDE is written in WPF.

Not the whole thing, but most of the main Windows, and the code editor.



> And, as David pointed out, new mobile devices (which should represent a 
> growing market) use managed GUI technologies like Silverlight.

As a result we will have not Opera, no Firefox, and possible no Flash on
the new mobile devices (unless MS decides to make some exceptions).




-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D4C18BC787B7MihaiN@207.46.248.16...
>
> As a result we will have not Opera, no Firefox, and possible no Flash on
> the new mobile devices (unless MS decides to make some exceptions).
>

Opera and Firefox are no great loss if the built-in browser is decent.  For 
example, on Blackberry, the built-in browser does not do Javascript and is 
entirely inadequate.  As for Flash, it does seem it is getting frozen out, 
first on iPad, now on Win Phone.  Perhaps Adobe will get into the smartphone 
business to promote Flash!  :-O

-- David 

Goran wrote:

> On Mar 30, 7:42 pm, "Tom Serface" <t...@camaswood.com> wrote:
>> I just worked on another complete .NET application and since it was very
>> file system intensive I had to resort to pInvoking all sorts of Win32
>> functions since the .NET System.IO implementation can't support file paths
>> longer than 260 chars.
> 
> Bloody hell, as a Brit would say! Out of curiosity, and if you don't
> mind, what's the problem!? (You can point me to the offending IL if
> that's easiest).
> 
> Goran.


When I first read him say this, I suspected maybe its a unicode vs 
mbcs thing.

-- 
HLS

+Ajay Kalra wrote:

> On Mar 30, 7:37 am, "David Ching" <d...@remove-this.dcsoft.com> wrote:
> 
>> For the past three years, it's been very difficult for me to find Win32/MFC
>> jobs here in the Bay Area.  Mostly all the job ads for Windows client want
>> at least some .NET experience, and most of them are interested ONLY in .NET.
>> C++ is still used for cross platform or embedded, but then we are not
>> talking about Windows.  And it's not just me.  I have former colleagues who
>> have been programming MFC (and MFC only) for the last decade who are now
>> having difficulty being attractive in the job market.
> 
> This has been my experience as well. When we hire for GUI, we only
> look for .Net. (C++ isnt even looked at). I havent seen a MFC job
> opening in years.It has been nothing but .Net for a long while.


Ok, I am going to write this long message once to get in my thoughts 
here over the whole subjective issue.  It all highly subjective and 
personal and what/which direction you go or where you are at is 
subject to your history or position in all this.

It really all depends on where you are looking.  There are plenty of 
definitely MFC, C/C++ jobs availability.   But keep in mind, these 
tend to demand more salary, more systems level experience.

What you are really seeing, in general, not specifics, is requirements 
for a broad knowledge of various technologies, because it is pretty 
broad.  I personally can not afford just hiring a .NET person unless 
he has a sound general broad understanding of basic MFC, C++. So while 
I might hire him to take him to the next level, he needs to be able to 
solve problems where necessary and be able to understand (not be 
confused) when speaking MFC.

..NET GUI works because of the hardware and OS caching speed 
advancements in speed which allows for dealing with a p-code 
environment, but if you have faster needs or parts, or basically lower 
overhead needs, then you have to be more tuned with these methods or 
at least have someone (the more experience honcho) on board that will 
provide the system related tools and apis for you.

Thats one of the issues we have in committing to .NET languages.  We 
have already have a huge investment C/C++, MFC and in additional 
libraries, methods, classes, API, a good bit of it designed for speed, 
low overhead.  This was a very important part in the lower cost 
development behind reusability.

But that is also the purpose of the higher level IDE gui environment.

The nice thing about .NET is that its very rich and it does cover a 
good bit of these needs with the .NET libraries.

However, not in all cases.  For example, for us, many of our 
applications have large data handling requirements, i.e, electronic 
mail, conference mail, group ware, file uploads, downloads libraries, 
etc.

Much of this is handled with memory file maps. Native MMF system .NET 
library functionally was not added until .NET 4.0.  Sure, you can 
write the pinvoke code it yourself or use the 3rd party classes out 
there for it, I think I even saw one for .NET ported from one for 
VB.Classic.

But overall, it was another reason to not commit to .NET yet because 
there are other things in .NET 4.0 that was desirable.  Its a moving 
target so that doesn't help businesses that need to think about these 
things.

Of course, if you (speaking in general) are dealing with in-house 
products or specific market products with no legacy customer to 
support, then you have all the luxury in the world to use the latest 
and greatest without impediments. Unless you have a specific design 
reason to develop the fastest code possible, have no issues on what is 
required to be installed on user machines, then using .NET makes 
perfect sense.

The other issue, for us at least, is that we have a multi-device 
requirement.  This is not a design requirement for many developers. We 
have a commercial online hosting system that customers from small to 
large install for their own customer support or public, private 
hosting (intranet) system.  They need may need Dialup and internet 
access using any kind of user device.

Most of our customers started as Dialup only.  By the time the 
internet came around, as early corporate mandates and their own 
customers did not yet demand internet access.

That changes slowly over the years and for our customers all they had 
to do was turn on the internet servers and the entire I/O was 
virtualized.  So what you see and do via dialup is the same via any 
other TCP/IP connection device.  The interface is the same, the 
communications is virtualized.

A good picture of this multi-device design is shown here:

    http://www.winserver.com/public/vimg.wct?src=wcrpcnet7.png

The Yellow Parts is our framework now since 1996  The light yellow and 
green parts are under developed. Once done, any clients can be used, 
at least that is the plan. :)

The problem we have is how to best single source it or:

     What languages do you use to not only create the client GUI
     but to interface in Interactive fashion as oppose to
     client/server fashion?

The key is interactive two way communications or FULL DUPLEX.

The WCGUIAGT server on the backend is our special Java client GUI 
controller.  For the new clients we need something that does it with 
XML and/or JSON which we call the WCRPC bridge.

The question i need to explore is how WPF fits it with this bridge.  I 
believe it does just based that I think its is XML based.  I have not 
studied it yet, but MS might have their own "bridging technology," in 
fact, I am pretty sure their have a protocol here.

I've been in this business a long time, in fact, among the early 
pioneers, the history of this (intelligent frontends) can be crudely 
summarizes:

o Generic Server, TGUI (Text/Graphical User Interface) client

   - Telecommunications products User Interface scripting languages.
     These were trained to watch for server side prompts and display
     client side dialogs, etc.

        Whats your user login id?

     The user does not see this, but a dialog, but the script looks
     for the the whole string or part of it.

     Two problems: script timing misfiresl; text prompts changed.

   - To speed it up, reduce misfirsts and to avoid text prmpt
     change issues, advanced hosting servers uses persistent tags:

      [LOGIN]Enter your user name or id?

     So client scripts just had to be trained to look for [LOGIN].

     Early version of this on a public hosting systems was for
     CompuServ using TapCis and there was one lost fella/friend
     that use trhe Turbo Powers OWL library to write one TGUI
     for CompuServe.

o TGUI Client/Server - Pre HTML

   Special clients now begin to use special servers with
   a persistent tag or Output language to help draw the
   client interface and also have interactive I/O. Early versions
   of this where the Minitel, Prodigy, etc.

   Others such as the vendors at the last ONE BBSCON show, renamed to
   ONE ISOCON trade show, introduced

   - RIP, this was a LANGUAGE of tags to be used on text based
          servers.

         [RIP_LOGINBOX]What is your user name?

     So if you had telecomm program that supported RIP, it will
     display the login box.

   - RoboFX, this uses Windows Graphics and Glyphs designed
     by a 17 yrs old.

   - GoldXpress (Moi!, A layer above our Silver Xpress Mail System)

   Ironically, at this last ONE BBSCON show was the odd excitement
   in the trade show air about this new "technology" that was going
   to rule the world.  No one had a demo or booth, but Vince Cerf
   gave a talk about the "internet" and someone else talk about
   this "HTML" thing.

   I knew (read/heard about it) but it was "academia" and was too
   excited about the RIP.  In fact, our Wildcat! DOS version was the
   first commercial BBS software to support RIP. So when you connect
   to a wildcat! host,  it spits out ANSI/VT100 and RIP escape
   reporting codes and the Telecomm program will detect it. If
   the telecomm didn't support it, then plain old text interface
   was used.

o HTML world

   I don't need to say much here, but by 1994 the MAD RUSH was
   on by establish BBS vendors to:

    - Move to WIndows
    - Compile under 32 bit
    - Support HTML interface and the new device with WEB browsers.

   in 1996, Wildcat! DOS was ported to Wildcat! Interactive Net Server
   (WINSERVER) as the first system that combined the dialup and
   internet world to support:

      - Text mode

      - Native GUI mode with our Wildcat! Navigator frontend, free
        to users

      - Web Interface.

HTML killed RIP, never took off and RIP was pulled from the
text mode interface.

While Javascript and AJAX with HTML offered increases "WEB 2.0" 
designs, people still knew there was a POWER in making the client 
smarter with better GUI and dynamic interactive I/O;

     - Flash, ActiveX, Java client side agents

In short, MS fell behind and .NET and ASP was their efforts here.  But 
ASP is still based on HTML.  Then you have the growth of APPLE and 
Objective-C methods.

2000 was a lost decade for me for all these issues reasons - how do 
what single source this, how do we offer an API that allows customers 
to do this for any device?    Because it was a moving target and we 
already had a solid working solution - getting older day, it was not 
so simple to commit to WINFORM or ASP for anything we need. Microsoft 
decisions for long term strategy for MFC was horrible. They didn't 
think about a good migration approach where I think most of the 
MFC-based applications would look at a sub-system transparent and 
passive convergence of COM and .NET integration.  Just consider that a 
MFC product would have maybe Windows 2003+ user requirements anyway or 
..NET installation for another part of their stock products. Microsoft
should of leverage this better.  That is why I asked about VS2010 and 
MFC.  Rhetorically, did Microsoft say?

       Ok, we forgot about you guys this decade, sorry!
       VS2010 is the new VS98 and MFC IDE support is back
       and better,  but it MAY mean additional distribution
       requirements when you use any of the components
       and controls in your GUI toolbox that are now
       a natural part of the inherent, out of the box
       tool box set.

What I did know and was very wary about it was that the I/O 
server/client communications was XML based.  Just like Mozilla did for 
their stuff, just Adobe did for their Apex stuff, just like everyone 
was heading to with the new XML based GUI designer system.

I didn't installed SilverLight but I also thought it was XML based. I 
just installed it the other day, I gave up arguing and fighting the 
idea that Microsoft really really really wants to make you part of 
their centralized farm network, just like Google and Apple has open 
the door.  In fact, the concern is not just mine.  The US congress is 
finally going to rethink how the 1986 US EPCA provisions written to 
address the then new 1980s Online BBS hosting market is today outdated 
for the centralized and integrated cloud world.

     http://www.nytimes.com/2010/03/31/technology/31privacy.html

WP7 is Microsoft answer to Apple efforts.  Not because they didn't 
know about this, but APPLE, not treated as a monopoly was able to 
change the mindset of the world, with little, short 2 weeks of 
complaining, that its OK to take force 1 way to develop and 100% 
control of what is allowed to run, and do so with a business model to 
charge a ROYALTY for offering an applet on its network.

MS is going to use the same model which was only possible because of 
APPLE.

What isn't know is how developers will react to this.

I personally think its just another cycle.  In our BBS world, the top 
vendors had their own p-code api for 3rd party developers to right 
applications that run on at the server.  We just didn't charge a 
royalty, however, they had to purchase the SDK tool kit, the SDK was 
free, but the tool kit wasn't - a long term issue of whether to start 
giving it away as we lost market share.

Its the old Gillette business model theory:

     Do you give away (small cost) the "razor" and sell, make profit
     on the blades?

Monopolies or better described as Oligopolies, Collusion models, don't 
have to give away the toolkit.  Today, Microsoft charged you for the 
toolkit and had no say on the end-product you wrote with it.  The 
traditional model.

We can also say that developing with WPF is the still the same model, 
but if you target it for WPC7 devices, then its different model.

What will MS do with WP7 business model as the new cellular devices 
move towards (and already became) the new handheld PC, only time will 
tell.

All I can say, for us, 2000 was somewhat of a "lost decade." I started 
worthing with it in 2005, then again in 2008, but didn't commit to it.

Today we can probably say the new era is becoming more feasible again.
WPF is the new way to the the TGUI that began as:

          What is your Login name?

Only faster speeds and offloaded technology SilverLight, today make 
this possible.


-- 
HLS

> Opera and Firefox are no great loss if the built-in browser is decent.

But (historically) the IE mobile was not decent.


Point is: a lot of other potentially nice applications will be left out.
Anything that is C++ and not a toy application (anything with many tens,
if not hundreds of thousands of lines of code).
One needs a very strong incentive to rewrite the whole beast.

So let's recap the story as I see it:
 - force developers to rewrite everything in a programming language
   invented by me, which can't be used for anythign cross-platform
   (Apple: Objective C, MS: C#)
 - no multitasking (both Apple and MS)
 - lock-down the thing and only allow applications to be installed
   they my proprietary app-store (both Apple and MS)

So haw is just copying the strategy applied by the leader
going to topple the leader, with some years handicap already.
What is the differenciating factor?
Why would I do a full rewrite from C++ to C# to work on a new
unproven platform, instead of just rewrite the GUI in Objective C
and run on the platform that is number one?
(you can still use C++ on iPhone and iPad)

Personally, I was waiting for Win Mobile 7 for the freedom to
install what I want. So much for it. Now Android looks better.

Mihai

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D4DAF4E379AMihaiN@207.46.248.16...
>
>> Opera and Firefox are no great loss if the built-in browser is decent.
>
> But (historically) the IE mobile was not decent.
>
>
> Point is: a lot of other potentially nice applications will be left out.
> Anything that is C++ and not a toy application (anything with many tens,
> if not hundreds of thousands of lines of code).
> One needs a very strong incentive to rewrite the whole beast.
>
> So let's recap the story as I see it:
> - force developers to rewrite everything in a programming language
>   invented by me, which can't be used for anythign cross-platform
>   (Apple: Objective C, MS: C#)
> - no multitasking (both Apple and MS)
> - lock-down the thing and only allow applications to be installed
>   they my proprietary app-store (both Apple and MS)
>
> So haw is just copying the strategy applied by the leader
> going to topple the leader, with some years handicap already.
> What is the differenciating factor?
> Why would I do a full rewrite from C++ to C# to work on a new
> unproven platform, instead of just rewrite the GUI in Objective C
> and run on the platform that is number one?
> (you can still use C++ on iPhone and iPad)
>
> Personally, I was waiting for Win Mobile 7 for the freedom to
> install what I want. So much for it. Now Android looks better.
>

Personally, I was staying out of the mobile market because there were too 
many OS's to worry about.  Then Apple came with one OS.  Except they 
required crappy Objective C, which I refuse to program in.  I can't see the 
loss of not being able to port my Win desktop apps (C++) to Win Phone since 
it would be an almost total rewrite anyway for all but the most trivial 
apps, to go from desktop to phone.

Besides, how good do you think an MFC app would look on a platform which has 
Silverlight as the basis for everything?  It would look like a text mode 
terminal compared to GUI.  Not a good way to sell a lot of copies.

Personally, Windows Phone is great for my career.  It allows me to leverage 
my investment into WPF and Silverlight on an emerging platform.  For the 
first time in decades, Microsoft has my back again.

-- David 

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D4DAF4E379AMihaiN@207.46.248.16...
>
>> Opera and Firefox are no great loss if the built-in browser is decent.
>
> But (historically) the IE mobile was not decent.
>
>
> Point is: a lot of other potentially nice applications will be left out.
> Anything that is C++ and not a toy application (anything with many tens,
> if not hundreds of thousands of lines of code).
> One needs a very strong incentive to rewrite the whole beast.
>
> So let's recap the story as I see it:
> - force developers to rewrite everything in a programming language
>   invented by me, which can't be used for anythign cross-platform
>   (Apple: Objective C, MS: C#)
> - no multitasking (both Apple and MS)
> - lock-down the thing and only allow applications to be installed
>   they my proprietary app-store (both Apple and MS)
>
> So haw is just copying the strategy applied by the leader
> going to topple the leader, with some years handicap already.
> What is the differenciating factor?
> Why would I do a full rewrite from C++ to C# to work on a new
> unproven platform, instead of just rewrite the GUI in Objective C
> and run on the platform that is number one?
> (you can still use C++ on iPhone and iPad)
>
> Personally, I was waiting for Win Mobile 7 for the freedom to
> install what I want. So much for it. Now Android looks better.

I have to agree with you.  I was looking  forward to enhancements in Win 
Mobile 6.5 and what I got was a completely different operating system that 
provides some new features but takes away the core things that I use for 
development! While I don't mind learning something new, there *must* be a 
compelling reason for me to do it. With the latest version of Win Mobile, I 
just don't see any justification for learning it.  I'll continue to look 
over the documentation as it is released, but I would rather not be confined 
to writing toy applications for my phone.

I also think that Microsoft made a huge mistake with the UI because the HTC 
Touch-Flo 3D for Windows Mobile 6 was a superior interface when it was 
released a few years ago and I think that the most recent releases are still 
better than the new flagship UI for Windows Mobile 7.

Sad...

-Pete 

"Pete Delgado" <Peter.Delgado@NoSpam.com> wrote in message 
news:#pQbbfb0KHA.364@TK2MSFTNGP02.phx.gbl...
>
> I have to agree with you.  I was looking  forward to enhancements in Win 
> Mobile 6.5 and what I got was a completely different operating system that 
> provides some new features but takes away the core things that I use for 
> development! While I don't mind learning something new, there *must* be a 
> compelling reason for me to do it. With the latest version of Win Mobile, 
> I just don't see any justification for learning it.  I'll continue to look 
> over the documentation as it is released, but I would rather not be 
> confined to writing toy applications for my phone.
>
> I also think that Microsoft made a huge mistake with the UI because the 
> HTC Touch-Flo 3D for Windows Mobile 6 was a superior interface when it was 
> released a few years ago and I think that the most recent releases are 
> still better than the new flagship UI for Windows Mobile 7.
>
> Sad...
>
> -Pete

Hey Pete, this is interesting.  Win Mobile had such a miniscule market share 
that it was not compelling for me, plus Windows never did scale down well to 
those tiny screens.  I think HTC was the best Windows Mobile device, but 
that isn't saying much.  (BTW, I've used a Blackberry all these years, still 
do and was never tempted with Win Mobile.)  So it's surprising to hear that 
there are people here like yourself who actually like it and have invested 
in developing for it.  I would be ticked too if I were in that position, 
seeing as how MS is basically giving you guys the boot and starting over. 
But what choice did they have?  Windows Mobile was never going to achieve 
iPhone proportions and was even losing market share each year.

What kind of apps are you developing and using such that you think Windows 
Phone promotes "toy applications"?  I would not think it promotes toy or not 
toy applications, it gives you great hardware and a great programming 
environment.  Whether you use it to make toy apps or not toy apps is up to 
you.  (And don't say anything with animation in it is a "toy", that's not 
what we're talking about.)

From what I've seen, developing Silverlight apps is way cooler than writing 
Objective C apps, so Microsoft may yet win this race by having better apps 
than iPhone.

-- David
 

> From what I've seen, developing Silverlight apps is way cooler than writing 
> Objective C apps, so Microsoft may yet win this race by having better apps 
> than iPhone.

I agree that C# is better than Objective C.
But let's remember: you are only forced to Objective C for the UI only.
All the core logic can still stay C++.

Applications like KeyPass take great advantage.
Basically I use KeyPass on Win, WinMo, Mac. And it is also available
for iPhone, Linux, Palm, Android, you name it.

This is just an example. But basically if you have a C++ application,
you don't have to throw everything away, just the UI.
And that you must change big time anyway, to make it work nicely
on a small screen and with touch interaction.

Plus, I really resent asking Apple or MS for permission to
install *MY* applications on *MY* device.


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D4DD17848338MihaiN@207.46.248.16...
>
> I agree that C# is better than Objective C.
> But let's remember: you are only forced to Objective C for the UI only.
> All the core logic can still stay C++.
>
> Applications like KeyPass take great advantage.
> Basically I use KeyPass on Win, WinMo, Mac. And it is also available
> for iPhone, Linux, Palm, Android, you name it.
>
> This is just an example. But basically if you have a C++ application,
> you don't have to throw everything away, just the UI.
> And that you must change big time anyway, to make it work nicely
> on a small screen and with touch interaction.
>

Yes, I see the advantage of having a common back end written in C++.  But I 
would guess the majority of iPhone apps are iPhone-only, and the authors are 
perfectly fine with that.  Similar with Win Phone apps, I would think.


> Plus, I really resent asking Apple or MS for permission to
> install *MY* applications on *MY* device.
>

I hadn't realized MS had set the rules for its (now non-existant) store yet. 
Anyway, I agree Apple has too much control and has screwed a minority of the 
developers.  But this is no reason to boycott a device that has such 
potential to make us $.

-- David 

> When I first read him say this, I suspected maybe its a unicode vs
> mbcs thing.

In .Net this issue doesnt exist.

--
Ajay

"David Ching" <dc@remove-this.dcsoft.com> wrote in message 
news:e55u47b0KHA.4832@TK2MSFTNGP04.phx.gbl...
> "Pete Delgado" <Peter.Delgado@NoSpam.com> wrote in message 
> news:#pQbbfb0KHA.364@TK2MSFTNGP02.phx.gbl...

> What kind of apps are you developing and using such that you think Windows 
> Phone promotes "toy applications"?  I would not think it promotes toy or 
> not toy applications, it gives you great hardware and a great programming 
> environment.  Whether you use it to make toy apps or not toy apps is up to 
> you.  (And don't say anything with animation in it is a "toy", that's not 
> what we're talking about.)

I currently have a platform management application that integrates with 
pocket outlook written in native code as well as various utilities and a 
framework for use with pocket outlook. I was getting ready to port an 
application that would integrate with our Teamcenter suite that would allow 
customers to view BOMs on their Windows Mobile devices. While there are some 
tools that can be ported or re-architected to work on the new platform, it 
becomes a lot of work!

While the new phone specs beefs up the hardware, if my applications must be 
managed code, I suspect there will be things that are difficult if not 
impossible to do.

>
> From what I've seen, developing Silverlight apps is way cooler than 
> writing Objective C apps, so Microsoft may yet win this race by having 
> better apps than iPhone.

Cooler does not necessarily equal better!  ;-)

-Pete

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D4DD17848338MihaiN@207.46.248.16...
> Plus, I really resent asking Apple or MS for permission to
> install *MY* applications on *MY* device.

I totally agree with that!

-Pete 

> But I would guess the majority of iPhone apps are iPhone-only,
> and the authors are perfectly fine with that.
> Similar with Win Phone apps, I would think.

This is just a guess.
But there are many applications that have common code.
Just mentioned browsers, and few others.


> Anyway, I agree Apple has too much control and has screwed a minority
> of the 
> developers.  But this is no reason to boycott a device that has such 
> potential to make us $.

It is not only about developers. As a user I want to install whatever
I feel like it. And I don't want Apple to know. Just because.
Not because I do something wrong or illegal, but because it is *my* device.

So yes, for me it is a reason enough to buycott.


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

"Hector Santos" <sant9442@nospam.gmail.com> ha scritto nel messaggio 
news:#a#d02Q0KHA.5512@TK2MSFTNGP06.phx.gbl...

[David]
>>> For the past three years, it's been very difficult for me to find 
>>> Win32/MFC
>>> jobs here in the Bay Area.  Mostly all the job ads for Windows client 
>>> want
>>> at least some .NET experience, and most of them are interested ONLY in 
>>> .NET.
>>> C++ is still used for cross platform or embedded, but then we are not
>>> talking about Windows.  And it's not just me.  I have former colleagues 
>>> who
>>> have been programming MFC (and MFC only) for the last decade who are now
>>> having difficulty being attractive in the job market.
>>

[Ajay]
>> This has been my experience as well. When we hire for GUI, we only
>> look for .Net. (C++ isnt even looked at). I havent seen a MFC job
>> opening in years.It has been nothing but .Net for a long while.

[Hector]
> It really all depends on where you are looking.  There are plenty of 
> definitely MFC, C/C++ jobs availability.   But keep in mind, these tend to 
> demand more salary, more systems level experience.

My impression and experience match with Ajay's and David's ones.
Where are those plenty of MFC jobs?

And it happens sometimes that when you propose to do a project in C++, they 
tend to answer that it is harder to find C++ programmers for maintainance 
work (kind of: "When you go away, who will maintain your code?").

Also, you may find this blog post by Larry Osterman to be interesting:

http://blogs.msdn.com/larryosterman/archive/2009/10/20/looking-for-new-skillz-turning-the-blog-around.aspx

<quote>
Just for giggles, I went looking at the various job listings within 
Microsoft and outside Microsoft (no, I'm not going anywhere, I was just 
curious).  While looking, I realized that I had absolutely no marketable 
skills :).  Nobody seems to be hiring an OS developer these days.
</quote>


> Thats one of the issues we have in committing to .NET languages.  We have 
> already have a huge investment C/C++, MFC and in additional libraries, 
> methods, classes, API, a good bit of it designed for speed, low overhead. 
> This was a very important part in the lower cost development behind 
> reusability.

This is the case of existing C++ codebase to be maintained and evolved; of 
course, in cases like this, it makes more sense to evolve current C++ code, 
than redesigning, rewriting, retesting and redocumenting in .NET :)
I think that big important companies like Microsoft or Adobe that have huge 
C++ codebases tend to maintain and evolve them in C++ (not e.g. rewriting 
Office or Photoshop in C#!).
But what about *new* projects?


Giovanni
 

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D4F51BEAB0FMihaiN@207.46.248.16...
>
>> But I would guess the majority of iPhone apps are iPhone-only,
>> and the authors are perfectly fine with that.
>> Similar with Win Phone apps, I would think.
>
> This is just a guess.
> But there are many applications that have common code.
> Just mentioned browsers, and few others.
>

For a different light on the common code picture:  if you target 
Silverlight, you can deploy on Windows Phone, Mac desktop, Windows desktop, 
which is pretty compelling.


> It is not only about developers. As a user I want to install whatever
> I feel like it. And I don't want Apple to know. Just because.
> Not because I do something wrong or illegal, but because it is *my* 
> device.
>
> So yes, for me it is a reason enough to buycott.
>

Do you know if Microsoft is going to be as strict as Apple is regarding 
this?  I haven't heard one way or the other.

-- David 

> For a different light on the common code picture:  if you target 
> Silverlight, you can deploy on Windows Phone, Mac desktop, Windows desktop, 
> which is pretty compelling.

But compare the number and quality of Silverlight applications out there
vs. the number and quality of C++ applications.
Have you seen any non-toy Silverlight application?
(VS2010 is not Silverlight, it's WPF, and it's only some of the UI,
not the whole thing)


> Do you know if Microsoft is going to be as strict as Apple is regarding 
> this?  I haven't heard one way or the other.

Just rummors about an app-store and that you can't install anything
except thru the app-store. Bad enough.

Nothing about the approval process (and I would not qualify Apple's
approval process as "strict", but more like "random" or "arbitrary"
or "whimsical" :-)

And you know what? No matter how clear the process, I am still against it.
I mean, who's Apple to say "no porn" or "no political stuff"?
Stop security/malware risky programs. Stop illegal stuff? I am not sure.
Apple is not the police, or fbi, or cia, is not part of the law enforcement.
Do that, and it is abuse.


Anyway, in the end I don't care what programming language is used.
I want applications. Many. And I want a good browser. With Flash. And AIR.
And Perl, and PHP, and a web server, and sqlite. And applications that
can scan for wireless networks, and capure network traffic.

Let's remember:
 - Palm wanted to have all the development in JavaScript + HTML + WebOS APIs,
   no native. Now they had to opened up and accept native (with PDK).
 - Apple wanted the same for iPhone, no native. They had to open up.
 - Android wanted the whole thing on top of Java, no native. Now it's the NDK
   (native development kit)

My prediction: Microsoft should open to native code (the sooner, the better),
or the Windows Phone 7 will die.


I am not telling MS or Apple what to do. But if I don't like it, I just
don't buy that thing. This is not buycott. When you buy an Nikon camera
you don't buycott Sony or Kodak. You just buy what you feel is best
for you.


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D4F79416C5C0MihaiN@207.46.248.16...
>
> But compare the number and quality of Silverlight applications out there
> vs. the number and quality of C++ applications.

That's a not a particularly relevant comparison.  How many apps did iPhone 
have when it first appeared?  Now there are 150K.  iPhone apps are written 
with Objective C, same as Mac apps.  I don't know the answer, but how many 
existing Mac apps got easily ported to iPhone?  I would guess not many at 
all.  So I don't see what bearing existing C++ apps have to do with Windows 
Phone.


> Have you seen any non-toy Silverlight application?
> (VS2010 is not Silverlight, it's WPF, and it's only some of the UI,
> not the whole thing)
>

I'm not sure where this thing about "toy" applications comes from.  My best 
guess is whether it involves touching business data or not.  So the iPhone 
app that simulates playing a flute by blowing into the microphone is a toy 
app because it doesn't touch any business data.  Well, if that is the 
criteria, then OK, the "toy" app fits.  But what about the iPhone app that 
reports whether a particular airline flight is late or not.  That looks up 
flight data and reports it.  Flight data is business data, so this is not a 
toy app?  Or is it?

Or is it a toy app because you might use multitouch gestures to control it, 
or it uses animation to effectively show results?  Is that what makes it a 
toy app?

Is this a toy app in your opinion?
http://tv.telerik.com/silverlight/webinar/building-a-real-world-application-with-radcontrols-silverlight-4


> Just rummors about an app-store and that you can't install anything
> except thru the app-store. Bad enough.
>

Well, you definitely will be able to load apps through Visual Studio!  ;)


> And you know what? No matter how clear the process, I am still against it.
> I mean, who's Apple to say "no porn" or "no political stuff"?
> Stop security/malware risky programs. Stop illegal stuff? I am not sure.
> Apple is not the police, or fbi, or cia, is not part of the law 
> enforcement.
> Do that, and it is abuse.
>

It's their store, they can decide what they do and do not want to sell.  But 
I agree they should not prohibit you from installing other apps without the 
store involved.  But if your app is not highlighted on their store, it won't 
meet much success (I mean the kinds of apps that make $250K per month). 
That's what I'm really interested in.


>
> Anyway, in the end I don't care what programming language is used.
> I want applications. Many. And I want a good browser.

Fine, everyone wants these.


> With Flash. And AIR.
> And Perl, and PHP, and a web server, and sqlite.

Well, you were right to exclude programming language as a valid criteria, 
but here are confusing end user functionality with technology with this 
list.  End user doesn't care, and most likely doesn't even know about, these 
technologies, they want what they can provide.

I'm not sure who would run a web server on a phone.  And SQLLite can be 
replaced with SQL Server Compact Edition.  End user doesn't care.


> And applications that
> can scan for wireless networks, and capure network traffic.
>

Nothing prevents these capabilities from being exposed to managed code (or 
native code for that matter).  Whether they are or not is a different 
question.


> Let's remember:
> - Palm wanted to have all the development in JavaScript + HTML + WebOS 
> APIs,
>   no native. Now they had to opened up and accept native (with PDK).
> - Apple wanted the same for iPhone, no native. They had to open up.
> - Android wanted the whole thing on top of Java, no native. Now it's the 
> NDK
>   (native development kit)
>
> My prediction: Microsoft should open to native code (the sooner, the 
> better),
> or the Windows Phone 7 will die.
>

Maybe they will.  If it proves to be that critical.  Windows Phone is an 
interesting experiment in the first managed-only environment and whether it 
will work, and if so, how good is it.


>
> I am not telling MS or Apple what to do. But if I don't like it, I just
> don't buy that thing. This is not buycott. When you buy an Nikon camera
> you don't buycott Sony or Kodak. You just buy what you feel is best
> for you.
>

Of course.


-- David 

> That's a not a particularly relevant comparison.  How many apps did iPhone 
> have when it first appeared?  Now there are 150K.

It is very relevant. Because many of them were ported from the desktop
versions.

> iPhone apps are written 
> with Objective C, same as Mac apps.  I don't know the answer, but how many 
> existing Mac apps got easily ported to iPhone?  I would guess not many at 
> all.

Well, my guess is quite a few.
Btw, you can use C++ on iPhone. Just not for UI.
And you can mix and match without many problems. You can completely reuse
the C or C++ "engine" and fix redo the UI in Objective C (whitch you might
have to do anyway because the interaction is quite different).

In porting something like Firefox, what do you thing is the hard part?
The HTML parsing and rendering engine, or the UI of the browser?


> I'm not sure where this thing about "toy" applications comes from.
For me a "non-toy application" is something that takes many tens of
thousand lines of code (or hundreds of thousands, or millions).
Duck-tapping a data service with some predefined data grid does not
and it is still toy.
That's my definition.
Or put it differently: something a single guy can put together in a
couple of weeks is a toy application. This time estimat ignores the
cute UI animations that can more than tripple the real coding time :-)

By this definition, toy applications are easy to fully rewrite
in Objective C, or C#, or Java, or whatever one dreams.



> Well, you definitely will be able to load apps through Visual Studio!  ;)

Really? I don't care about the emulator.


> I'm not sure who would run a web server on a phone.
There are some crazy people doing that. For instance:
   http://msdn.microsoft.com/en-us/library/ms834461.aspx
:-)
Or this: http://www.chilisoftware.net/CompactWebServer/
Or this: http://handheld.softpedia.com/get/Internet-Utilities/Mobile-Web-
Server-Free-42332.shtml

Or this
  http://www.cam.com/windowsce.html
  http://wmpoweruser.com/?p=4387
  http://www.mochasoft.dk/freeware/ftpd.htm


> Well, you were right to exclude programming language as a valid criteria, 
> but here are confusing end user functionality with technology with this 
> list.  End user doesn't care, and most likely doesn't even know about,
> these technologies, they want what they can provide.

No, there is no confusion. I want Perl or a web server to run on my device!
(not to develop for the device using Perl)
See http://perlce.sourceforge.net/

Any chances someone will rewrite Perl in C# soon?
Take away C/C++, you just killed this (and a lot of other useful stuff)


> Nothing prevents these capabilities from being exposed to managed code (or 
> native code for that matter).  Whether they are or not is a different 
> question.

No, it is not a different question.
We know .NET does not give access to all that's needed, and on desktop
there is a need of pinvoke for a lot of things.
If I can write C/C++, I can use what I want.
If I can only write C#, I am at the mercy of what MS wants to give me.



-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

Anyway, I will stop here.
I do believe that Windows and Microsoft in general benefited greatly
from being developer friendly.
And restricting what developers can do is a bad move, especially
when you are the underdog.

Apple has the army of funboys that will do whatever Steve tells
them is the right thing.
And they would throw away Objective C and rewrite their applications
from scratch in Ruby, if Steve sais that's the next Apple thing.


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D501280016B0MihaiN@207.46.248.16...
>> iPhone apps are written
>> with Objective C, same as Mac apps.  I don't know the answer, but how 
>> many
>> existing Mac apps got easily ported to iPhone?  I would guess not many at
>> all.
>
> Well, my guess is quite a few.
> Btw, you can use C++ on iPhone. Just not for UI.
> And you can mix and match without many problems. You can completely reuse
> the C or C++ "engine" and fix redo the UI in Objective C (whitch you might
> have to do anyway because the interaction is quite different).
>
> In porting something like Firefox, what do you thing is the hard part?
> The HTML parsing and rendering engine, or the UI of the browser?
>

And how many of these "non-toy" apps are being run on a smartphone?  It's a 
different market, the apps need to do different things, so your definition 
of a toy app needs to change.

The HTML parsing and rendering engine has already been written, you just use 
it in your apps.


> For me a "non-toy application" is something that takes many tens of
> thousand lines of code (or hundreds of thousands, or millions).
> Duck-tapping a data service with some predefined data grid does not
> and it is still toy.
> That's my definition.
> Or put it differently: something a single guy can put together in a
> couple of weeks is a toy application. This time estimat ignores the
> cute UI animations that can more than tripple the real coding time :-)
>
> By this definition, toy applications are easy to fully rewrite
> in Objective C, or C#, or Java, or whatever one dreams.
>

I'm sorry, but that's as arrogant as in 1980's the programmers of DEC, VAX, 
IBM Mainframes (or Sun workstations) saying PC's were "toys" ignoring apps 
like VisiCalc and WordStar were being used to get real work done by real 
people.  Of course PC's weren't in the same league as the mainframes but 
neither were they throwaway toys, and you know what?  I have never 
programmed a mainframe in my entire career, and stayed with these "toys" to 
produce useful software for many people.

So if that's your definition, then it isn't a useful one in terms of 
evaluating a smartphone platform like Windows Phone.


>> Well, you definitely will be able to load apps through Visual Studio!  ;)
>
> Really? I don't care about the emulator.
>

You have to be able to transfer your app to the phone in order to debug it!


>> I'm not sure who would run a web server on a phone.
> There are some crazy people doing that. For instance:
>   http://msdn.microsoft.com/en-us/library/ms834461.aspx
> :-)
> Or this: http://www.chilisoftware.net/CompactWebServer/
> Or this: http://handheld.softpedia.com/get/Internet-Utilities/Mobile-Web-
> Server-Free-42332.shtml
>
> Or this
>  http://www.cam.com/windowsce.html
>  http://wmpoweruser.com/?p=4387
>  http://www.mochasoft.dk/freeware/ftpd.htm
>
>
>> Well, you were right to exclude programming language as a valid criteria,
>> but here are confusing end user functionality with technology with this
>> list.  End user doesn't care, and most likely doesn't even know about,
>> these technologies, they want what they can provide.
>
> No, there is no confusion. I want Perl or a web server to run on my 
> device!
> (not to develop for the device using Perl)
> See http://perlce.sourceforge.net/
>
> Any chances someone will rewrite Perl in C# soon?
> Take away C/C++, you just killed this (and a lot of other useful stuff)
>

If you want these types of things, I agree that MS missed the boat for you. 
I just had no idea these were the kinds of things you were using to evaluate 
suitability.  They are completely different than mine.  I was looking for 
great tools to write great mobile apps (which by nature have different 
functionalities AND different presentations, etc.) like what is found on the 
very popular iPhone, and MS appears to have succeeded in doing that.

On top of that, the same app can run cross platform on Mac, and other 
Windows platforms, both on desktop and in a browser.  In 2010, what's not to 
like about that?

This fixation on native things like FTP servers or IP tunneling could be 
useful in the short term, but long term there will be more elegant 
replacements to achieve the same goals, if enough people want those types of 
things.  Similar to how many programmers like me used to evaluate PC 
graphics cards based on how well they showed text in a DOS box because that 
is where we lived, and did not care too much about how pictures looked 
(whereas the rest of the world couldn't care about DOS boxes).  But over 
time, our editors got ported to GUI and then we didn't care about DOS boxes 
anymore.  There will be a time when you won't care about whether you can 
have a FTP server on the device either, if you get easy file transfer some 
other way.

>
>> Nothing prevents these capabilities from being exposed to managed code 
>> (or
>> native code for that matter).  Whether they are or not is a different
>> question.
>
> No, it is not a different question.
> We know .NET does not give access to all that's needed, and on desktop
> there is a need of pinvoke for a lot of things.
> If I can write C/C++, I can use what I want.
> If I can only write C#, I am at the mercy of what MS wants to give me.
>

These things would be useful to me too, but it is not a deal breaker if I 
don't have them.  A deal breaker for me is having to use Objective C 
(iPhone) , or having a puny audience the size of Windows Mobile that even 
then requires massive #ifdef'ing to support all the phones.

I used to think there is no way MS could replace an HWND.  It was simply too 
powerful and too customizable to be replaced.  But since then, browsers and 
Silverlight/WPF don't use HWND's any yet offer an even more elegant API that 
let me do what I want.  I suspect MS may yet come up with something that 
will win you over in the same way.

-- David 

> The HTML parsing and rendering engine has already been written, you just
> use it in your apps.

And if I want something better than the IE engine?


> I'm sorry, but that's as arrogant as in 1980's the programmers of DEC, VAX, 
> IBM Mainframes (or Sun workstations) saying PC's were "toys" ignoring apps 
> like VisiCalc and WordStar were being used to get real work done by real 
> people.

Again, it is about the size of the application, not about real work or not,
or the usefulness of the application.
A unit conversion application is extremely useful, but it is a toy 
application.
I doube VisiCalc was written in a week or had less than 10K lines of code.

If you have such a problem with "toy", then replace it with "small"

--

To all the rest: I am not talking here as a developer, but as a user.
I know what I run on my current WinMo, and I want the same on the future one.

And it will take a very long while for a vpn client :-)
Same for mapping software, or a pdf viewer.

And I want choices. I don't care if there is a browser, or
mapping software out of the box. I want to compare and choose
what I like most.

Being able to use older C/C++ code can give a headstart.
Apple is still complaining that people don't rewrite their stuff in
Objective C for desktop, after so many years.

Apple says "please use my language" while MS says "my way or the hightway"
This might be the final nail in the WinMo saga.


Can things work with C# only? Yes. I am not bashing C# here.
Just the decision to make that the *only* option.

But who knows. Let's wait and see who was right.


-- 
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

"David Ching" <dc@remove-this.dcsoft.com> wrote in message 
news:uRE1mdA1KHA.224@TK2MSFTNGP06.phx.gbl...
>>
>
>>> Well, you definitely will be able to load apps through Visual Studio! 
>>> ;)
>>
>> Really? I don't care about the emulator.
>>
>
> You have to be able to transfer your app to the phone in order to debug 
> it!

You *must* be a registered developer which requires a $99 annual fee at this 
time. In addition, you must comply with the prover agreement.

http://developer.windowsphone.com/Signup-Create-Account.aspx

After you are a registered developer, you can then register and install on 
specific devices without going through Marketplace.

http://social.msdn.microsoft.com/Forums/en-US/windowsphone7series/thread/2892a6f0-ab26-48d6-b63c-e38f62eda3b3


Application Installation

How do I install applications on my device?
Applications will automatically be installed when downloaded from 
MarketPlace.

Can I manually install applications without using the MarketPlace?
No, "side-loading" applications is not permitted.  The only way to get 
released applications on your device is through MarketPlace.

How can I test my application on a device if I can't install it?
As a registered developer, you will be able to register some devices that 
you can directly deploy your application to for testing. It is not necessary 
to publish your application to MarketPlace just to test it.

My application is for my company / specific group of people only, how do I 
distribute the app only to them on MarketPlace?
The MarketPlace does not currently have the ability to provide locked-off 
areas for private applications. Other than a few key exceptions for Mobile 
Operators,  there is no way to gate your application to a specific group of 
people or devices at this time.

"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
news:Xns9D50142225AB8MihaiN@207.46.248.16...
> Anyway, I will stop here.
> I do believe that Windows and Microsoft in general benefited greatly
> from being developer friendly.
> And restricting what developers can do is a bad move, especially
> when you are the underdog.

The $99 annual entry fee combined with the fact that I must share my profits 
(30%) with Microsoft really makes me angry. While Microsoft does add value 
with the Marketplace, I think that the $99 fee combined with a small 
per-unit sales fee should be sufficient.

Looking at the service agreement: 
https://developer.windowsphone.com/resources/en-US/Windows%20Marketplace%20Application%20Provider%20Agreement.pdf

Notice that:

1. You must pay to have your application certified by a Microsoft provider 
which means even more $$
2. Microsoft has no obligation to distribute your app.
3. Microsoft reserves the right to remove your app from Marketplace and 
*disable* previously downloaded copies!

So an individual developer could potentially develop an app that competes 
with a MS product and MS has every legal right to NOT distribute your app. 
They can also "recall" your app and your users can have the app taken away 
from them even after they have purchased it!!!

>
> Apple has the army of funboys that will do whatever Steve tells
> them is the right thing.
> And they would throw away Objective C and rewrite their applications
> from scratch in Ruby, if Steve sais that's the next Apple thing.


Apple has people willing to put up with the Apple's business model. With the 
emergence of Android as a viable development platform, I suspect that 
Microsoft will lose their developer edge and thus some marketshare. 
Certainly there will be a majority of users for who the availability of apps 
and the ability to develop for the device is not a big deal, but for the 
independant software developer this could be the end of Windows Mobile 
development.

-Pete 

Pete D,

If you really feel this way, you should get involved and highlight the 
situation to the FTC and anti-trust organizations.  This needs to get 
nipped at the bud as there is no doubt in my mind, Microsoft is 
testing the waters here to see if they can get away with it under the 
name that Apple and Google has opened this door.   They are not 
monopolies in the product development world - Microsoft is. There are 
all kinds of issues with this.  I don't wish to get started here with 
it but no doubt, if there is no grass root effort to get this stopped 
now, there are going to be an awful lot of sorry people which may be 
when efforts will start - but it might be too late.

Key note to remember, Per license, Apple restricts bypassing of the 
RTE (p-code engine).  It would be the only way Microsoft will be able 
to control these devices with .NET.   That right there will begin to 
border Anti-trust violations concerns by preventing new technology 
that don't require .NET but just the hardware and broadband 
connectivity on these consumer and business devices.

This think reeks AntiTrust issues!

--
HLS



Pete Delgado wrote:

> "Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
> news:Xns9D50142225AB8MihaiN@207.46.248.16...
>> Anyway, I will stop here.
>> I do believe that Windows and Microsoft in general benefited greatly
>> from being developer friendly.
>> And restricting what developers can do is a bad move, especially
>> when you are the underdog.
> 
> The $99 annual entry fee combined with the fact that I must share my profits 
> (30%) with Microsoft really makes me angry. While Microsoft does add value 
> with the Marketplace, I think that the $99 fee combined with a small 
> per-unit sales fee should be sufficient.
> 
> Looking at the service agreement: 
> https://developer.windowsphone.com/resources/en-US/Windows%20Marketplace%20Application%20Provider%20Agreement.pdf
> 
> Notice that:
> 
> 1. You must pay to have your application certified by a Microsoft provider 
> which means even more $$
> 2. Microsoft has no obligation to distribute your app.
> 3. Microsoft reserves the right to remove your app from Marketplace and 
> *disable* previously downloaded copies!
> 
> So an individual developer could potentially develop an app that competes 
> with a MS product and MS has every legal right to NOT distribute your app. 
> They can also "recall" your app and your users can have the app taken away 
> from them even after they have purchased it!!!
> 
>> Apple has the army of funboys that will do whatever Steve tells
>> them is the right thing.
>> And they would throw away Objective C and rewrite their applications
>> from scratch in Ruby, if Steve sais that's the next Apple thing.
> 
> 
> Apple has people willing to put up with the Apple's business model. With the 
> emergence of Android as a viable development platform, I suspect that 
> Microsoft will lose their developer edge and thus some marketshare. 
> Certainly there will be a majority of users for who the availability of apps 
> and the ability to develop for the device is not a big deal, but for the 
> independant software developer this could be the end of Windows Mobile 
> development.
> 
> -Pete 
> 
> 



-- 
HLS

Hey pete, send me your email address, remove the nospam from my address :)

Pete Delgado wrote:

> "Mihai N." <nmihai_year_2000@yahoo.com> wrote in message 
> news:Xns9D50142225AB8MihaiN@207.46.248.16...
>> Anyway, I will stop here.
>> I do believe that Windows and Microsoft in general benefited greatly
>> from being developer friendly.
>> And restricting what developers can do is a bad move, especially
>> when you are the underdog.
> 
> The $99 annual entry fee combined with the fact that I must share my profits 
> (30%) with Microsoft really makes me angry. While Microsoft does add value 
> with the Marketplace, I think that the $99 fee combined with a small 
> per-unit sales fee should be sufficient.
> 
> Looking at the service agreement: 
> https://developer.windowsphone.com/resources/en-US/Windows%20Marketplace%20Application%20Provider%20Agreement.pdf
> 
> Notice that:
> 
> 1. You must pay to have your application certified by a Microsoft provider 
> which means even more $$
> 2. Microsoft has no obligation to distribute your app.
> 3. Microsoft reserves the right to remove your app from Marketplace and 
> *disable* previously downloaded copies!
> 
> So an individual developer could potentially develop an app that competes 
> with a MS product and MS has every legal right to NOT distribute your app. 
> They can also "recall" your app and your users can have the app taken away 
> from them even after they have purchased it!!!
> 
>> Apple has the army of funboys that will do whatever Steve tells
>> them is the right thing.
>> And they would throw away Objective C and rewrite their applications
>> from scratch in Ruby, if Steve sais that's the next Apple thing.
> 
> 
> Apple has people willing to put up with the Apple's business model. With the 
> emergence of Android as a viable development platform, I suspect that 
> Microsoft will lose their developer edge and thus some marketshare. 
> Certainly there will be a majority of users for who the availability of apps 
> and the ability to develop for the device is not a big deal, but for the 
> independant software developer this could be the end of Windows Mobile 
> development.
> 
> -Pete 
> 
> 



-- 
HLS

"Hector Santos" <sant9442@nospam.gmail.com> wrote in message 
news:%23C0QC1bzKHA.5940@TK2MSFTNGP02.phx.gbl...
>
> Can people with VS2010 now tell me about about their experiences and 
> reality?

Also can anyone tell me : does VS2010 allow debugging of mixed (managed and 
unmanaged) 64-bit code on a 64-bit platform?
Currently it seems VS2008 only allows mixed debugging of 32 bit code.  If I 
select "debug unmanaged code" in the configuration panel of a 64-bit app 
solution I get a dialog telling me mixed debugging is not supported on the 
64-bit platform.

Les 

Good question Les!

Les Neilson wrote:

> 
> "Hector Santos" <sant9442@nospam.gmail.com> wrote in message 
> news:%23C0QC1bzKHA.5940@TK2MSFTNGP02.phx.gbl...
>>
>> Can people with VS2010 now tell me about about their experiences and 
>> reality?
> 
> Also can anyone tell me : does VS2010 allow debugging of mixed (managed 
> and unmanaged) 64-bit code on a 64-bit platform?
> Currently it seems VS2008 only allows mixed debugging of 32 bit code.  
> If I select "debug unmanaged code" in the configuration panel of a 
> 64-bit app solution I get a dialog telling me mixed debugging is not 
> supported on the 64-bit platform.
> 
> Les



-- 
HLS

Yes, kinda, licensed from BCG Soft's MFC extension library.

"Hector Santos" <sant9442@nospam.gmail.com> wrote in message 
news:OlVwQU4zKHA.928@TK2MSFTNGP05.phx.gbl...
> David Ching wrote:
>
>> "Hector Santos" <sant9442@nospam.gmail.com> wrote in message 
>> news:Opk8um3zKHA.5940@TK2MSFTNGP02.phx.gbl...
>>> Is it safe to say that if I include and OCX/COM into the MFC package, 
>>> there will be some managed sub-system requirement when its recompiled 
>>> under VS2010?
>>>
>>
>> No, .NET is not required for MFC apps in VS2010.  VS2010 has the 
>> VC6-style ClassWizard, a welcome-back addition.
>
>
> Yes, that excites me.
>
>> It also has Windows 7-oriented enhancements to MFC.  And an MFC ribbon 
>> designer (for the ribbon that debuted in VS2008 Feature Pack).  None of 
>> which make MFC a particularly good productive or modern framework to 
>> develop in this decade, but it's still the best MFC to date.
>
> OK, so the "extra" controls, that is still pure MFC? or OCX/COM?
>
> -- 
> HLS 

"Giovanni Dicanio" <giovanniDOTdicanio@REMOVEMEgmail.com> wrote in message
news:uqMVaV%23zKHA.2512@TK2MSFTNGP05.phx.gbl...
> "Joseph M. Newcomer" <newcomer@flounder.com> ha scritto nel messaggio
> news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd@4ax.com...
> [...]
> > And nobody has mentioned "managed C++".
>
> I think "Managed C++" is deprecated (it was since VS2005, IIRC).
> With VS2005 they introduced C++/CLI. However, I think that it is good only
> to build bridges between native code and managed code, e.g. to wrap some
> native code libraries and expose them to C#.

I use it the other way around.  I have an unmanaged MFC app that I made
C++/CLI so that I could write some new features using System::XML (which may
or may not be later used by a C# app - this avoids some duplicate effort).
The plan is to migrate the entire MFC app to managed.  I have found that MFC
and CLI are getting easier to intermingle.  VS2002/2003 was dang near
impossible.

The only other point is that it has the single worst example of "help" I've ever had the
misfortune to be subjected to!

We can only hope that this will be fixed in the future.  As it is, it is essentially a
joke help system.

It has no index and no table of contents!  At least in the RC version, which is what I'm
using.
					joe

On Sat, 27 Mar 2010 10:53:21 -0400, Hector Santos <sant9442@nospam.gmail.com> wrote:

>I am about to finally *commit* product porting and new development 
>under VS20xx.  Currently have VS2005 and successfully recompiled all 
>our projects and MFC applications. 139 of 150  projects in total where 
>moved over.  But we never felt good to release it as an update.
>
>About VS2010, we definitely going to upgrade to it, and I heard it is 
>the "new VC6 (VS98)" - that excited me.  I am not like going to waste 
>time downloading the RC and go thru any hassles installing it.
>
>Can people with VS2010 now tell me about about their experiences and 
>reality?  Such as:
>
>I didn't like the class wizard in VS2005.  Is it better?
>
>What about controls?  Was the property editor extended to better 
>support extended aspects with controls (less sub-classing requirements))?
>
>One of the reasons I didn't want to commit to VS20xx compile based 
>product packaging and distribution was based of new OS and different 
>flavors of OS SxS and manifest stuff.
>
>The beauty of having a product under VC6 was that it was design purely 
>for WIN32 and never had to worry about the version of windows users 
>had.  That seem to change now.
>
>So I guess, the deeper questions and answers I see is what are the 
>"new got yas," if any?
>
>Thanks
>
>PS:  What is WPF overall? A new GUI foundation? Do you recommend WPF 
>over MFC?
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

"H Brydon" <HBrydon@yahoo.com> wrote in message 
news:e8H3$gW7KHA.3504@TK2MSFTNGP05.phx.gbl...
>
> I use it the other way around.  I have an unmanaged MFC app that I made
> C++/CLI so that I could write some new features using System::XML (which 
> may
> or may not be later used by a C# app - this avoids some duplicate effort).
> The plan is to migrate the entire MFC app to managed.  I have found that 
> MFC
> and CLI are getting easier to intermingle.  VS2002/2003 was dang near
> impossible.
>

In VC2005, C++/CLI was a first class .NET client, same status as VB and C# 
in terms of creating .NET desktop clients.  Subsequently in VC2008 (and now 
in VC2010), MS declared C++/CLI to be focused on interop between native and 
managed, the idea is the UI is managed and written in C#, the C++/CLI 
provides any data from existing C++ libraries.  As such, support for 
creating managed UI from C++/CLI is deprecated, although perhaps calling BCL 
things like System::XML still works.  At any rate, be careful when talking 
about managed UI with C++/CLI.

-- David