"The Ghost In The Machine"
wrote in message
> In comp.os.linux.advocacy, Linonut
> on Wed, 14 May 2008 07:38:52 -0400
>> * Ian Hilliard peremptorily fired off this memo:
>>> A computer system's engineer, who understands that cross platform
>>> development guarantees the best results at the lowest cost, because it
>>> forces cleaner development and provides access to a wider set of tools.
>> Not to mention having to deal with the quantum shifts in Microsoft APIs
>> that come every few years.
> And these are ... ? MoveToEx() is *still* in WinGDI.
> The only APIs I know have shifted are the ones for the
> drivers (I'll admit I don't know the details for those),
> RDO->ADO (I know very little about either), and something
> which I can only identify as a WinInet->WinHTTP transition
> internally, and that only because I happened to notice
> them while poking around hither and yon.
Sure. When an API has been updated like MoveTo() updated to MoveToEx() the
old MoveTo() is still there and works. Enhancing an existing API call while
preserving the existing one is hardly a "quantum shift" in the APIs.
> Or are you referring to .NET? .NET is indeed a quantum
> shift in one respect, but when boiled down to its
> essentialls appears to be little more than the export of an
> intermediate compiler format, one level above machine code
> (anyone who's read what's colloquially called "the dragon
> book", so called because a green dragon is being attacked
> by a knight on the cover, will know about quadruplets,
> code hoisting, and peephole optimization; it was written
> by Aho and Ullman and its proper title is "Principles of
> Compiler Design", but everyone just calls it "the [green]
> dragon book": http://en.wikipedia.org/wiki/Dragon_Book).
..NET is not a "quantum shift in the APIs. No more so than Python or Ruby is
a new shift in APIs. The existing API's are still there and they continue to
work exactly as they did before .NET came around.
..NET is simply a new programming language. It doesn't replace or obsolete
the existing APIs. It's a new language the same as when Ruby and Python came
out they were new languages and weren't meant to be a "quantum shift" from
C, C++ or Perl. Because a new language is released doesn't mean that there
was a "quantum shift" in the existing APIs. We continue to use the native
Win32 API in some of our projects and .NET or no .NET... it all still works
exactly as before.
> Nevertheless, .NET will revolutionize the industry --
> if Microsoft can clear out all of the other "revolutions"
> first. It'll be interesting to see if .NET will suffer the
> same fate as ActiveX, which allowed remote code to walk
> in the front door, settle into the library, and start
> rearchitecting the foyer. (Nowadays, he at least has
> to sign a writ of authenticity first. In Java's case,
> he's shown to the sandbox at the side of the house, and
> only allowed to rearchitect sand castles.)
> I'll also be curious as to what happens to WinFX, which was
> supposed to replace the Win32 muck.
"Replace" or be an "alternate" to? The native Win32 API isn't going
anywhere. There are far, far too many apps (including MS apps) that are
written for the native Win32 API.
** Posted from http://www.teranews.com **