Re: Cryptogram Comment
From: Daniel James (wastebasket_at_nospam.aaisp.org)
Date: 06/19/04
- Next message: Tom St Denis: "Re: Cryptogram Comment"
- Previous message: Daniel James: "Re: Cryptogram Comment"
- In reply to: Tom St Denis: "Re: Cryptogram Comment"
- Next in thread: Tom St Denis: "Re: Cryptogram Comment"
- Reply: Tom St Denis: "Re: Cryptogram Comment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 19 Jun 2004 13:58:38 +0100
In article
news:<iMBAc.324020$Ar.31119@twister01.bloor.is.net.cable.rogers.com>,
Tom St Denis wrote:
> > MFC was originally an abtraction tool so that people could write
> > one application and compile it for both 16-bit and 32-bit
> > Windows. It's
>
> You could already do that. The Win16 and Win32 APIs were so
> similar that porting an application to Win32 [what Win95/98/ME/XP
> are essentially] was a matter of recompiling and minor source
> changes at best.
This is a bit off-topic here, but since you ask...
I disagree. There is similarity between Win16 and Win32, yes (well, of
course, there would be), but porting Win16 C code to Win32 is a bit
more than just recompiling ... What MFC did was to provide a single
API that compiled correctly for both 16-bit and 32-bit targets. In
some cases 16-bit MFC provided application code that emulated Win32
APIs not present in Win16, making continued parallel development for
the two platforms much easier than it might have been.
MFC is far from perfect and could have been much better, but it did
solve a real problem and it did do so fairly succesfully. It's
certainly not an example of MS inventing a technology for its own
sake. There are many examples of that that you could have chosen, but
you happen to have picked on something that isn't one.
> > also a fairly functional C++ wrapper around the Windows API
> > that does make coding quite a lot easier than in the bare Win32
> > API.
[snip]
> I don't know about that. With just C and MSVC you can
> drag-and-drop design GUIs, code the callbacks and have nice
> flashy pretty gui applications. MFC doesn't help that.
Strange thing to claim! MSVC is a pretty poor example of a
drag-and-drop GUI design tool - compared with, say, Borland's C++
builder (or the glade tools, or wxWidgets and its designers, or ...).
MFC *does* make it easier to write code with MSVC. The MFC libraries
hide a lot of the complexity of a bare C WinAPI application so the
applications programmer has less to write (and Wizards that will write
some of it for him). MFC apps don't have to register their own window
classes, don't have to provide their own message loops, don't have
humungous switch statements for processing different types of
messages, ...
There's nothing MFC makes possible that isn't possible with the bare
Win32 API, but there's a lot that it makes considerably easier.
> > C# and .NET are MS's response to Sun preventing them from using
> > Java.
>
> Response as in "look we can do it too!" That's marketing not
> engineering.
No, response as in "We have a ton of application logic that we've
developed in MS Java using COM heavily, and now Sun won't let us build
COM into Java any more - we'd better come up with a Java-like language
quickly or throw all that work away". It's an engineering solution to
a marketing problem that is not of MS's making.
> C# and .NET [and .ASP and .whateversnext] won't enable you to
> write an application any easier than before.
No, it enables you to write certain kinds of application as easily as
before, where the alternative was not to be able to write such an
application so easily because Sun had pulled the plug on MS Java.
I'm a C++ programmer, and I occasionally have to use Java -- though I
don't particularly like Java (for a number of good technical reasons).
I think C# manages to avoid a number of Java's shortcomings, but I
don't feel remotely tempted to use it for anything. It doesn't do
anything that C++ doesn't do better.
I'm not trying to persuade you that MS are Good Guys, just that not
everything they do is necessarily a bad thing done for their own
ulterior motives ... and that Sun can be Bad Guys too (but I expect
you knew that).
> > ... I'd say MS had a (moral if not legal) duty *to those third
> > parties* to offer the fix to all users, including pirates.
>
> Well then you would be for SP2 disabling pirated WinXP installs?
> I mean that would stop them from running an unpatched OS.
>
> Why should they take the stance of making a pirated install better?
The object here is to reduce the number of copies of XP in the world
that have the security failings that make them susceptible to
virus/worm infection -- for the benefit of all users, not just the
users of those XP systems.
If the SP disabled pirate installs pirates wouldn't apply it, and so
their machines would continue to be a danger to the rest of us. So,
no, that wouldn't stop them running an unpatched OS.
I'm not suggesting that MS should make pirated copies of XP "better"
for the users of those systems - just that they should enable those
users to patch the systems so that they aren't causing a nuisance to
to other honest people who've never pirated a thing in their lives.
Others have put this better than I ...
Cheers,
Daniel.
- Next message: Tom St Denis: "Re: Cryptogram Comment"
- Previous message: Daniel James: "Re: Cryptogram Comment"
- In reply to: Tom St Denis: "Re: Cryptogram Comment"
- Next in thread: Tom St Denis: "Re: Cryptogram Comment"
- Reply: Tom St Denis: "Re: Cryptogram Comment"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
