Re: Adobe abandons the "grace period" for recent CS2 buyers

In article <35lr33p3qjgaljfv65aonnk99rfht6k31c@xxxxxxx>,
PC Guy <pcguy@xxxxxxxxxxx> wrote:

On Sun, 06 May 2007 02:13:24 GMT, Alan Baker <alangbaker@xxxxxxxxx>
wrote:

In article <3fup33pods10tm8u3css7cdmu947a2rgbg@xxxxxxx>,
PC Guy <pcguy@xxxxxxxxxxx> wrote:

On Sat, 05 May 2007 21:29:32 GMT, Alan Baker <alangbaker@xxxxxxxxx>
wrote:

In article <r8tp335su4o2n6ukl03rd7fak7p7rgrfho@xxxxxxx>,
PC Guy <pcguy@xxxxxxxxxxx> wrote:

On Sat, 05 May 2007 17:05:02 -0400, ZnU <znu@xxxxxxxxxxxx> wrote:

In article <qprp33529u5fbo74h21sltou8r23qbbub9@xxxxxxx>,
PC Guy <pcguy@xxxxxxxxxxx> wrote:

On Sat, 05 May 2007 16:38:55 -0400, ZnU <znu@xxxxxxxxxxxx> wrote:

In article <13qp33p14lhrkhn8vh69maeasiajejclj8@xxxxxxx>,
PC Guy <pcguy@xxxxxxxxxxx> wrote:

On Sat, 05 May 2007 16:08:51 -0400, ZnU <znu@xxxxxxxxxxxx> wrote:

In article <59op33164kj94df36qgcbug0f01g4mutl6@xxxxxxx>,
PC Guy <pcguy@xxxxxxxxxxx> wrote:

On Sat, 05 May 2007 15:44:35 -0400, ZnU <znu@xxxxxxxxxxxx>
wrote:

My guess is this is because they're using Adobe's
cross-platform
toolkit, and that toolkit doesn't have path-independent
mechanisms
for
locating resources, because it's a lowest-common-denominator
toolkit
that also has to work on Windows, which is heavily
path-dependent.
In
other words, it's virtually certain that the fact that
Adobe's
apps
break when moved on the Mac is actually a result of the poor
design
of
Windows.

So the take away from this is that the Macintosh is not
immune,
contrary to what the Mactards have been saying all along.

Nobody ever said the Mac made it impossible for poorly written
third-party apps to break themselves.

Sure they do. Everytime they blame Windows for these poorly
written
third-party apps that break themselves on the Windows platform.

As I explained in my previous post, apps that break when moved in
Windows are not considered poorly written by the standards of the
platform.

Yet you Mactards act as if they are poorly written.

You're very confused. *You* are the one who's arguing path dependancy
is
simply a matter of poorly designed apps.

I am making no such arguments one way or the other. Just pointing out
the Mactard are in error when they blame Windows because of the
choices made by application developers.

What other choice could they make?

They could write their applications self contained too.

How would that choice be supported by the OS's services?

Application calls OS APIs to perform tasks. Do you really need help
with this? Oh sorry, I didn't realize until just now that I was
talking to Alan Baker.

Yesssssss, PC Guy. Very good. Applications call OS APIs to perform tasks.

I had no idea you're understanding of the subject was so limited that
I'd have to spell it out in full, but I now will.

Apparently it's much better than yours.

What OS APIs in Windows facilitate the creation of self-contained
applications?

There are no "self-contained application" APIs. Perhaps it best not to
speak about what you do not know.

Not on Windows there aren't.


Mac OS X has a whole set of OS facilities relating to
providing third-party developers the ability to do this. So what's
Windows got.


On the Mac, it is. On Windows, it's not, because apps are *supposed
to*
work
that way.
This is a design flaw in Windows.

See, here it is again. A Mactard blaming Windows to choices made by
third party developers.

Nope. It's people blaming Windows for not providing developers with the
services necessary for them to make a better choice.

What necessary services are missing?

Automatic version control of shared libraries, for one.

OS X provides this? I don't think so.

So far, there's been very little evidence of you ever thinking, I agree.

But I can help you with your ignorance, anyway...

<http://arstechnica.com/reviews/2q00/macos-x-dp4/macos-x-dp4-2.html>

"As mentioned earlier, all of this clever resource management doesn't
help if the particular shared library you use ends up containing an
incompatible version of the functions you need. We've all seen this
happen, for example, when an impolite installer overwrites an existing
shared library with an older (or newer!) version of that library that
breaks applications that used the previously installed version. Or
worse, the newly installed library may present the same functional
interface (allowing it to be successfully linked) but behave in a subtly
different manner. Bugs like this are among the most difficult to track
down.

Frameworks solve this problem by encapsulating one or more versions of a
shared library in structured directories. Framework versioning is split
by the concept of Major and Minor versions. A new Major version is
required when making a change to a library that renders it incompatible
with applications that work with older versions. Examples of
incompatible changes that require a new Major version are: removing or
renaming a function, adding or reordering instance variables, or adding
functions in languages like C++. (Functions can be added in more dynamic
languages like Objective C without causing any incompatibility.)
Each Minor version of a library remains compatible with all other Minor
versions within the same Major version. Minor version changes include
bug fixes, performance enhancements that do not affect functional
structure, and the addition of methods (except in C++), classes, and
structures.

Traditionally, Major versions have been named with a single capital
letters of the alphabet, but they may be any string that is also a valid
directory name: "2.0", "Two", and so on. Major versions of a shared
library file are stored in their own directories within the Framework.
When an application is compiled, the path to the Major version of each
Framework is stored within the executable. When an app needs a function
defined in a Framework during execution, it searches for the required
version of that Framework, checking the path stored during compile time
first, and then traversing a standard search path if that fails. The
standard locations for Frameworks include:

/System/Library/Frameworks - Frameworks included with the
operating system.
~/Library/Frameworks - Frameworks that are only used by a single
user.
/Local/Library/Frameworks - Frameworks used by all users of a
particular machine.
/Network/Library/Frameworks - Frameworks used across a network.
(This type of search path should look familiar to those of you who read
the DP3 article.)

Since each Framework can contain more than one Major version of a shared
library, upgrading a Framework to a new Major version does not break old
applications; the older versions of the library are still contained
within their respective Major version subdirectories inside the
Framework Bundle."

Now, as I noted, I don't know that you can think, but you have to be
able to *read*, so I'll pull out a few sentences for you just in case.


"Frameworks solve this problem by encapsulating one or more versions of
a shared library in structured directories."

"Since each Framework can contain more than one Major version of a
shared library, upgrading a Framework to a new Major version does not
break old applications; the older versions of the library are still
contained within their respective Major version subdirectories inside
the Framework Bundle."

--
"The iPhone doesn't have a speaker phone" -- "I checked very carefully" --
"I checked Apple's web pages" -- Edwin on the iPhone and how he missed
the demo of the iPhone speakerphone.
.

Relevant Pages

  • shared objects
    ... I have some problems getting around with shared libraries under linux. ... harder to write/use/bla than it was under windows: ...
    (comp.os.linux.development.apps)
  • Re: shared objects
    ... I have some problems getting around with shared libraries under linux. ... harder to write/use/bla than it was under windows: ...
    (comp.os.linux.development.apps)
  • Re: [9fans] Install from CD fails
    ... debating putting shared libraries into a system. ... Before X windows, 10% of programs were from the library. ... below) space savings with X windows. ...
    (comp.os.plan9)
  • Re: [9fans] Install from CD fails
    ... System designers have a responsibility to help the rest of the ... debating putting shared libraries into a system. ... Before X windows, 10% of programs were from the library. ...
    (comp.os.plan9)
  • Re: Can MS listen to customers?
    ... IE is comprised of a set of libraries that other applications use. ... a HUGE portion of even a minimal install of Windows (or even in ... For Windows, Notepad, Paint, IE, OE, msconfig, Wordpad, Hearts, NT ...
    (microsoft.public.windowsxp.general)