Prev: MDI App: start 2 DocTemplates in CMyApp::InitInstance
Next: How To: CStatubar panel Right-align text
From: David Ching on 31 Mar 2010 11:48
"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message
> 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
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
From: Hector Santos on 31 Mar 2010 12:41
> On Mar 30, 7:42 pm, "Tom Serface" <t...(a)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).
When I first read him say this, I suspected maybe its a unicode vs
From: David Ching on 31 Mar 2010 14:28
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
> I agree. I feel culturally displaced because I don't know WPF. But I
> have difficulty
> justifying it because my customer base is purely C/C++ based. But I
> really think I should
> be learning it.
> I am kept sufficiently busy with C/C++ work that I don't have spare time
> to learn WPF. I
> keep feeling this is going to come back and bite me soon.
> Sadly, these myths persist. My clients don't want C# because they have no
> in-house people
> to maintain the code (having ONLY C/C++/MFC experts)
It's always hard to predict paradigm shifts and react in a timely fashion.
It seems your steady work with C/C++ coupled with your eye on retirement
makes sticking with MFC until its logical conclusion a good choice for you.
OTOH, with the good books on WPF coming out now, the "barrier to entry" is
coming lower, so you might want to start reading about it for your own
edification, and it might turn into some gigs in the future, who knows.
From: Hector Santos on 31 Mar 2010 16:06
+Ajay Kalra wrote:
> On Mar 30, 7:37 am, "David Ching" <d...(a)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,
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
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
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
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:
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
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
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
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
[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
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
- Web Interface.
HTML killed RIP, never took off and RIP was pulled from the
text mode interface.
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
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.
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
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
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
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
From: Mihai N. on 1 Apr 2010 04:04
> 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.