Quartz = Psychopathic Chipmunks
Dan Johnson
http://www.vzavenue.net/~danieljohnson/
One of the articles is on Quartz, and it is highly favorable to
Apple. So now I feel all dirty. I will therefore hold forth
on how we can tell that Quartz was designed by
psychopathic chipmunks, and then I will feel better.
Your patience is appreciated.
It's really the Cocoa API that has the chipmunks'
pawmarks all over it. They managed to take what
was broken about QuickDraw and make it even
more broken.
Cocoa keeps most of what it knows about what
you draw as global state. For instance, if you want to
draw a red shape, you set the current color like this:
NSColor.redColor().set();
Cocoa puts "red" into an global data structure.
QuickDraw was the same way, but in QuickDraw
the data structure wasn't so invisible. It was called
a GrafPort, and you created it. The only thing that
was really global as a pointer indicating which
GrafPort was in use.
In Cocoa, the graphics state is just sort of out there
somewhere. This would be less of a problem if the
documentation was written with that in mind, but
in fact the docs are written about the classes you
can see. These classes, like NSColor, have methods
that affect the global state. It's quite a challenge to
find methods to do this, as they can be on virtually
any class. At least with QuickDraw there was a place
where all the functions that affected the current port
were listed.
But this design could be the work of ordinary, sane
chipmunks. To understand why these furry programmers
have to be kept in tiny straightjackets, you need to
look at NSColor.
You probably think that it is a color. Shows what you
know.
It only thinks its a color. It's really a brush. That is, it's
an object that describes how to fill the interior of a shape.
NSColor.redColor() is one that says to fill things in with
solid red.
But there are also "image colors" which fill space with
a texture. They are also NSColor objects.
NSColor has methods to fetch the red, green, and blue
components of the "color". They fail if called on an "image
color". Because that's not a color. It's an NSColor. And
it wouldn't do to think that NSColor represented a color.
Except it does represent a color. It is the only class
that does. It just sometimes represents other, non-color
things too.
It's not like this "design" buys you anything. Java2D
has colors that you can use to fill space in the same
way. But it doesn't use the same class for textures-
there's a separate class, and they share a common
interface.
There. Now I feel better.
Heywood Mogroot
> I've starting putting my thoughts on MacOS X on my web page:
>
> http://www.vzavenue.net/~danieljohnson/
>
> One of the articles is on Quartz, and it is highly favorable to
> Apple. So now I feel all dirty. I will therefore hold forth
> on how we can tell that Quartz was designed by
> psychopathic chipmunks, and then I will feel better.
I enjoyed your writings on the site above.
My internal cognitive mapping of MS vs. -x- is Redmond being the
Imperium of Star Wars Ep 4.
MS is and has been at the height of its powers, a relatively
efficient, technically astute organization with virtually unlimited
resources, able and willing to execute any strategy to increase its
grip on PC technology.
Its competitors strike me as ragtag bands in suede vests getting their
asses handed to them in all setpiece battles that they commit to.
If MS had a vision of the future that were at all attractive I'd be
less of a Mac apologist; but as things stand now I'm comfortable with
the progress Apple, with its miniscule R&D budget, is making in my
areas of interest (3D, networking, sound, unicode, programming
languages).
But I do fear for the future.... MS plans to increase R&D spending
from 4.3B to 5.2B;
http://www.siliconvalley.com/mld/siliconvalley/business/companies/3737266.htm
this 0.9B yearly increase alone would fund 2 years of Apple R&D, which
has been steadily decreasing over the past year:
http://biz.yahoo.com/fin/l/a/aapl.html
Mitigating this is that the Apple leadership suite is very attuned to
the criticisms of its major ISV's; apparently if you're on SJ's
'trusted advisor' list you've got a pretty straight shot at affecting
Apple strategy and spending, unlike the bad days when the executive
suite didn't know a shared library from C.
> It's not like this "design" buys you anything. Java2D
> has colors that you can use to fill space in the same
> way. But it doesn't use the same class for textures-
> there's a separate class, and they share a common
> interface.
>
> There. Now I feel better.
As for AppKit, it's not really a 'modern' API. Essentially developed
1987-1992, ported to various platforms 1992-1997, and tinkered with
1997-now.
Now that major internal development is moving away from Carbon to
AppKit, expect correspondingly major modernizations to AppKit in the
future.
Whether this will actually increase its real utility remains to be
seen; the presence of MAX_OS_VERSION_ALLOWED #defines in the 10.2
AppKit headers is not a comforting sight to this observer.
But as a fellow PBG4 owner, I certainly wish I could quit my dayjob
and develop for this beast fulltime. It's such a nice chunk of
technology.
=Heywood=
[delete .com]
> "Dan Johnson" <daniel...@vzavenue.net> wrote in message
news:<uo995mi...@news.supernews.com>...
> > I've starting putting my thoughts on MacOS X on my web page:
> >
> > http://www.vzavenue.net/~danieljohnson/
> >
> 1987-1992, ported to various platforms 1992-1997, and tinkered with
> 1997-now.
>
NeXTSTEP achieved hardware independence in 1993 with the Intel release. But
the transition to OpenStep was designed to make "Cocoa" not only independent
of hardware, but independent of the operating system. Hence, "Cocoa" was
working on Windows NT by 1994.
Since all that modularity has been shelved while Apple focuses on its niche
as integrated systems builder, one wonders if it can be made good use of.
To my knowledge, it is the most modular of any API in existence, which gives
it top ranking on my "modernity" scale. In the move to OS X, the AppKit was
made thread safe, a major modernization. The Java access to the AppKit was
a "modernization" though perhaps mainly to suit the winds of fashion.
So, what other "modernizations" could the AppKit benefit from?
-- Lee
--
`You have learned that they were told, "Love your neighbour, hate your
enemy." But what I tell you is this: Love your enemies.'
======================================================================
Lee Altenberg, Ph.D.
E-mail: spam AT dynamics DOTT org
======================================================================
John C. Randolph
Dan Johnson wrote:
>
> I've starting putting my thoughts on MacOS X on my web page:
>
> http://www.vzavenue.net/~danieljohnson/
>
> One of the articles is on Quartz, and it is highly favorable to
> Apple. So now I feel all dirty. I will therefore hold forth
> on how we can tell that Quartz was designed by
> psychopathic chipmunks, and then I will feel better.
Quartz was designed by people with a great deal more knowledge in the
field of 2D graphics than you and I will collectively acquire in our
respective careers in computer science.
> Your patience is appreciated.
Your ignorance is not.
> It's really the Cocoa API that has the chipmunks'
> pawmarks all over it. They managed to take what
> was broken about QuickDraw and make it even
> more broken.
>
> Cocoa keeps most of what it knows about what
> you draw as global state. For instance, if you want to
> draw a red shape, you set the current color like this:
>
> NSColor.redColor().set();
>
> Cocoa puts "red" into an global data structure.
Umm, NO. It sets the current color of the currently-focused drawing
context to red.
In Cocoa, you'll do most of your drawing in the -drawRect: method. When
-drawRect: is invoked, the framework has already switched to the
window's drawing context, and set the clipping path and coordinate space
such that you won't color outside the NSView in which you're drawing.
> QuickDraw was the same way, but in QuickDraw
> the data structure wasn't so invisible. It was called
> a GrafPort, and you created it. The only thing that
> was really global as a pointer indicating which
> GrafPort was in use.
>
> In Cocoa, the graphics state is just sort of out there
> somewhere.
It's not that hard to get to:
id graphicsContext = [NSGraphicsContext currentContext];
> This would be less of a problem if the
> documentation was written with that in mind, but
> in fact the docs are written about the classes you
> can see. These classes, like NSColor, have methods
> that affect the global state.
You seem to be confused on this point. Each window is a world unto
itself (a device, to put it in Postscript terms), and what color (or
coordinate space, etc) you set in one view doesn't affect any other
drawing in your app.
>It's quite a challenge to
> find methods to do this, as they can be on virtually
> any class.
Start here:
file://localhost/Developer/Documentation/Cocoa/TasksAndConcepts/ProgrammingTopics/DrawBasic/index.html
and here:
file://localhost/Developer/Documentation/Cocoa/TasksAndConcepts/ProgrammingTopics/DrawColor/index.html
Better yet, start by reading Aaron Hillegass's or Garfinkel & Mahoney's books.
> At least with QuickDraw there was a place
> where all the functions that affected the current port
> were listed.
>
> But this design could be the work of ordinary, sane
> chipmunks. To understand why these furry programmers
> have to be kept in tiny straightjackets, you need to
> look at NSColor.
>
> You probably think that it is a color. Shows what you
> know.
>
> It only thinks its a color. It's really a brush. That is, it's
> an object that describes how to fill the interior of a shape.
> NSColor.redColor() is one that says to fill things in with
> solid red.
>
> But there are also "image colors" which fill space with
> a texture. They are also NSColor objects.
>
> NSColor has methods to fetch the red, green, and blue
> components of the "color". They fail if called on an "image
> color". Because that's not a color. It's an NSColor. And
> it wouldn't do to think that NSColor represented a color.
You certainly should know when you set a color, what kind of a color it
is. If it's a color provided by the user through the color panel, you
can find out what kind of color it is by sending it a -colorSpaceName
message.
>
> Except it does represent a color. It is the only class
> that does. It just sometimes represents other, non-color
> things too.
>
> It's not like this "design" buys you anything. Java2D
> has colors that you can use to fill space in the same
> way. But it doesn't use the same class for textures-
> there's a separate class, and they share a common
> interface.
>
> There. Now I feel better.
You'd rather vent your spleen than RTFM?
-jcr
Dan Johnson
news:dd5de929.02091...@posting.google.com...
> "Dan Johnson" <daniel...@vzavenue.net> wrote in message
news:<uo995mi...@news.supernews.com>...
> > I've starting putting my thoughts on MacOS X on my web page:
> >
> > http://www.vzavenue.net/~danieljohnson/
> >
> > One of the articles is on Quartz, and it is highly favorable to
> > Apple. So now I feel all dirty. I will therefore hold forth
> > on how we can tell that Quartz was designed by
> > psychopathic chipmunks, and then I will feel better.
>
> I enjoyed your writings on the site above.
Yay! A visitor! :D
Thank you.
> My internal cognitive mapping of MS vs. -x- is Redmond being the
> Imperium of Star Wars Ep 4.
>
> MS is and has been at the height of its powers, a relatively
> efficient, technically astute organization with virtually unlimited
> resources, able and willing to execute any strategy to increase its
> grip on PC technology.
>
> Its competitors strike me as ragtag bands in suede vests getting their
> asses handed to them in all setpiece battles that they commit to.
I think there is some truth to this. Though the Galactic
Empire had a wrinkly guy who could shoot lightning
bolts out of his fingers, and I don't think Bill Gates can do
that.
They are certanly prepared to build the computational
equivalent of the Death Star. They can't make their
competitors expire just by gesturing in their direction,
however.
> If MS had a vision of the future that were at all attractive I'd be
> less of a Mac apologist; but as things stand now I'm comfortable with
> the progress Apple, with its miniscule R&D budget, is making in my
> areas of interest (3D, networking, sound, unicode, programming
> languages).
MS has visions sometimes, but maybe you do not find
them attractive. :D
> But I do fear for the future.... MS plans to increase R&D spending
> from 4.3B to 5.2B;
>
>
http://www.siliconvalley.com/mld/siliconvalley/business/companies/3737266.ht
m
>
> this 0.9B yearly increase alone would fund 2 years of Apple R&D, which
> has been steadily decreasing over the past year:
>
> http://biz.yahoo.com/fin/l/a/aapl.html
Microsoft expends a lot of effort on R&D, but R&D
isn't vision either.
It can support such visions as MS has, but I don't
think it will amount to all that much for GDI+,
because there's no vision behind that. The problem is
that while they may come up with cool new graphics
technologies, if MS doesn't see what the technologies
are supposed to be for, they won't be able to sell
their developers on it.
> Mitigating this is that the Apple leadership suite is very attuned to
> the criticisms of its major ISV's; apparently if you're on SJ's
> 'trusted advisor' list you've got a pretty straight shot at affecting
> Apple strategy and spending, unlike the bad days when the executive
> suite didn't know a shared library from C.
That's a good thing, but MS is also very attuned to their
ISVs. I cannot say which is moreso, but historically it
was clearly MS.
> > It's not like this "design" buys you anything. Java2D
> > has colors that you can use to fill space in the same
> > way. But it doesn't use the same class for textures-
> > there's a separate class, and they share a common
> > interface.
> >
> > There. Now I feel better.
>
> As for AppKit, it's not really a 'modern' API. Essentially developed
> 1987-1992, ported to various platforms 1992-1997, and tinkered with
> 1997-now.
Still felt good. Also, there doesn't seem to be any other
high-level API for it. Just Cocoa and that C API.
> Now that major internal development is moving away from Carbon to
> AppKit, expect correspondingly major modernizations to AppKit in the
> future.
That would be nice.
> Whether this will actually increase its real utility remains to be
> seen; the presence of MAX_OS_VERSION_ALLOWED #defines in the 10.2
> AppKit headers is not a comforting sight to this observer.
I do not understand why that would be a problem. API headers
routinely have conditional directives so they can be used with
different versions of the OS. In <Windows.h> the macro
is WINVER. Set this to 0x0400, for instance, and it behaves as
if you were targeting for NT 4. Various headers are omitted,
and so on.
I'd not be surprised to find such a thing in the MacOS X headers.
> But as a fellow PBG4 owner, I certainly wish I could quit my dayjob
> and develop for this beast fulltime. It's such a nice chunk of
> technology.
I do not really feel that way. For one thing, that PowerBook keyboard
is no fun, and while the screen is impressive for a laptop it is still
small.
If I were to develop on a Mac fulltime, I'd want a desktop
Macintosh. :D
Dan Johnson
news:3D858C6F...@idiom.com...
> > One of the articles is on Quartz, and it is highly favorable to
> > Apple. So now I feel all dirty. I will therefore hold forth
> > on how we can tell that Quartz was designed by
> > psychopathic chipmunks, and then I will feel better.
>
> Quartz was designed by people with a great deal more knowledge in the
> field of 2D graphics than you and I will collectively acquire in our
> respective careers in computer science.
Color me intimidated, then.
>
> > Your patience is appreciated.
>
> Your ignorance is not.
I feel your pain.
[snip]
> > Cocoa keeps most of what it knows about what
> > you draw as global state. For instance, if you want to
> > draw a red shape, you set the current color like this:
> >
> > NSColor.redColor().set();
> >
> > Cocoa puts "red" into an global data structure.
>
> Umm, NO. It sets the current color of the currently-focused drawing
> context to red.
That is part of the global data structure to which I was
refering.
> In Cocoa, you'll do most of your drawing in the -drawRect: method. When
> -drawRect: is invoked, the framework has already switched to the
> window's drawing context, and set the clipping path and coordinate space
> such that you won't color outside the NSView in which you're drawing.
Yes, I know. A good thing too, seeing as,
bizzarely, lockFocus is apparently expected to
fail sometimes. "canDraw" is just plain bizzare.
[snip]
> > In Cocoa, the graphics state is just sort of out there
> > somewhere.
>
> It's not that hard to get to:
>
> id graphicsContext = [NSGraphicsContext currentContext];
NSGraphicsContext is next to useless in Cocoa.
You cannot use it as a substitute for the scattered
drawing methods Cocoa does support.
> > This would be less of a problem if the
> > documentation was written with that in mind, but
> > in fact the docs are written about the classes you
> > can see. These classes, like NSColor, have methods
> > that affect the global state.
>
> You seem to be confused on this point. Each window is a world unto
> itself (a device, to put it in Postscript terms), and what color (or
> coordinate space, etc) you set in one view doesn't affect any other
> drawing in your app.
That is sort of true. Each window has a co-ordinate
system of its own, but drawing is done through yet
another co-ordinate system, and things like the current
color are not part of the window (as they are in QuickDraw).
Instead there is a separate data structure that is global
that holds this information. It isn't a simple pointer as
with QuickDraw, either. It is a stack of state descriptions,
though what form those descriptions take invisible.
> >It's quite a challenge to
> > find methods to do this, as they can be on virtually
> > any class.
>
> Start here:
[snip links]
I've been there. The tutorials are very limited. The references
are organized by class, as I said.
> Better yet, start by reading Aaron Hillegass's or Garfinkel & Mahoney's
books.
I may have to do that. But it is a shame Apple's docs
are weak.
[snip]
> > NSColor has methods to fetch the red, green, and blue
> > components of the "color". They fail if called on an "image
> > color". Because that's not a color. It's an NSColor. And
> > it wouldn't do to think that NSColor represented a color.
>
> You certainly should know when you set a color, what kind of a color it
> is.
Near as I can tell, that is the one time you don't need to know
what kind of color it is. All colors support set().
> If it's a color provided by the user through the color panel, you
> can find out what kind of color it is by sending it a -colorSpaceName
> message.
This, from the guys who have "a great deal more knowledge in
the field of 2D graphics than you and I will collectively acquire
in our respective careers in computer science"?
Color me unimpressed again.
> > Except it does represent a color. It is the only class
> > that does. It just sometimes represents other, non-color
> > things too.
> >
> > It's not like this "design" buys you anything. Java2D
> > has colors that you can use to fill space in the same
> > way. But it doesn't use the same class for textures-
> > there's a separate class, and they share a common
> > interface.
> >
> > There. Now I feel better.
>
> You'd rather vent your spleen than RTFM?
I did RTFM. That is how I knew about the stuff
I was complaining about. You don't think I could
come up with something as warped as NSColor
on my own, do you? :D
Dan Johnson
news:Tveh9.9898$kT1....@nwrddc04.gnilink.net...
> > 1987-1992, ported to various platforms 1992-1997, and tinkered with
> > 1997-now.
> >
> Actually, it underwent the biggest reworking going from NeXTSTEP to
> OpenStep. NeXTSTEP achieved hardware independence in 1993 with the
> Intel release. But the transition to OpenStep was designed to make
> "Cocoa" not only independent of hardware, but independent of the
> operating system. Hence, "Cocoa" was working on Windows NT by
> 1994.
>
> Since all that modularity has been shelved while Apple focuses on its
niche
> as integrated systems builder, one wonders if it can be made good use of.
It is not clear to me what "modularity" is involved in being
platform independant. It seems to me that while drivers might
be considered modules, the API would not need to be
modularized on account of that.
> To my knowledge, it is the most modular of any API in existence, which
gives
> it top ranking on my "modernity" scale.
I am not sure this is true. It looks much less modular than,
say, Win32. However, Win32's modularity is widely seen
as a drawback. Lots of separate modules each with its
own API- it increases the learning curve. .NET is notably
less modular in this way. Instead, it is more integrated
(and indeed more like Cocoa in that way).
> In the move to OS X, the AppKit was
> made thread safe, a major modernization.
Apple's documentation says that it is mostly not
thread safe, with specific exceptions. Making
it fully thread safe would be a major modernization,
but it would be very hard and probably hurt
performance more than it is worth.
Still, It could afford to be more threadsafe than it
is. Being able to process events on more than one
thread would be nice on occasion.
> The Java access to the AppKit was
> a "modernization" though perhaps mainly to suit the winds of fashion.
That was not a change to Cocoa at all; it was a bridge
that calls Cocoa on a Java program's behalf.
> So, what other "modernizations" could the AppKit benefit from?
The particular things I brought up were:
It could afford to have a "graphics context" object you could
use to refer directly to the graphics state, rather than having
this be implicit.
It could afford to make a distinction between objects and
values, at least semantically. Using the same exact class to
refer to "ARGB tuple" and "space-filling policy" is really
weird.
Mind, Apple seems to know this, as their low level
C API seems to incorporate these things.
flip
sp...@dynamics.org.com [delete .com] wrote:
> In <dd5de929.02091...@posting.google.com> Heywood Mogroot wrote:
> > "Dan Johnson" <daniel...@vzavenue.net> wrote in message
> news:<uo995mi...@news.supernews.com>...
> > > I've starting putting my thoughts on MacOS X on my web page:
> > >
> > > http://www.vzavenue.net/~danieljohnson/
> > >
> > As for AppKit, it's not really a 'modern' API. Essentially developed
> > 1987-1992, ported to various platforms 1992-1997, and tinkered with
> > 1997-now.
> >
> Actually, it underwent the biggest reworking going from NeXTSTEP to OpenStep.
> NeXTSTEP achieved hardware independence in 1993 with the Intel release. But
> the transition to OpenStep was designed to make "Cocoa" not only independent
> of hardware, but independent of the operating system. Hence, "Cocoa" was
> working on Windows NT by 1994.
>
> Since all that modularity has been shelved while Apple focuses on its niche
> as integrated systems builder, one wonders if it can be made good use of.
> To my knowledge, it is the most modular of any API in existence, which gives
> it top ranking on my "modernity" scale. In the move to OS X, the AppKit was
> made thread safe, a major modernization. The Java access to the AppKit was
> a "modernization" though perhaps mainly to suit the winds of fashion.
>
> So, what other "modernizations" could the AppKit benefit from?
I believe that dropping Cocoa for Windows was a major, major blunder. It
would have given developers one more reason to use Cocoa for app
development.
Heywood Mogroot
> They are certanly prepared to build the computational
> equivalent of the Death Star. They can't make their
> competitors expire just by gesturing in their direction,
> however.
All that MS talk wrt Netscape and 'air supplies' is pretty darn
close...
> > If MS had a vision of the future that were at all attractive I'd be
> > less of a Mac apologist; but as things stand now I'm comfortable with
> > the progress Apple, with its miniscule R&D budget, is making in my
> > areas of interest (3D, networking, sound, unicode, programming
> > languages).
>
> MS has visions sometimes, but maybe you do not find
> them attractive. :D
If I were a MIS/IT shop I'd be a big MS pusher.
> > As for AppKit, it's not really a 'modern' API. Essentially developed
> > 1987-1992, ported to various platforms 1992-1997, and tinkered with
> > 1997-now.
>
> Still felt good. Also, there doesn't seem to be any other
> high-level API for it. Just Cocoa and that C API.
Yes, the C API's were the post-buyout work to bridge AppKit &
Foundation to the traditional Mac programming base.
> > Whether this will actually increase its real utility remains to be
> > seen; the presence of MAX_OS_VERSION_ALLOWED #defines in the 10.2
> > AppKit headers is not a comforting sight to this observer.
>
> I do not understand why that would be a problem. API headers
> routinely have conditional directives so they can be used with
> different versions of the OS. In <Windows.h> the macro
> is WINVER. Set this to 0x0400, for instance, and it behaves as
> if you were targeting for NT 4. Various headers are omitted,
> and so on.
#defines are a hack. While COM with its GUIDs was something of a
syntactical nightmare, objects etc. should support API versioning.
This is a tools issue more than anything else IMV. Everything feels so
stone-age (vs. what a really bag-up job would produce) in the tools
dept.
> > But as a fellow PBG4 owner, I certainly wish I could quit my dayjob
> > and develop for this beast fulltime. It's such a nice chunk of
> > technology.
>
> I do not really feel that way. For one thing, that PowerBook keyboard
> is no fun, and while the screen is impressive for a laptop it is still
> small.
Well, I *do* have a USB hub with Microsoft Natural Elite and mouse,
and an Apple DVI->ADC adapter to my 17" LCD. Close the clamshell and
I'm in nirvana, essentially an 800Mhz G4 cube.
=Heywood=
Dan Johnson
news:<uobd8fq...@news.supernews.com>...
> > They are certanly prepared to build the computational
> > equivalent of the Death Star. They can't make their
> > competitors expire just by gesturing in their direction,
> > however.
>
> All that MS talk wrt Netscape and 'air supplies' is pretty darn
> close...
That's just talk. Netscape got clobbered for not
improving their buggy browswer for so long, given
MS lots of time to catch up, then surpass them.
Arguably, turning IE into components other software
can use might have contributed. Some say it did,
and feel this was dirty pool. It certainly created
dependancies that wouldn't have been there
otherwsie.
But I am not convinced this really mattered. I think
Netscape did more than enough damage to itself,
even without that.
[snip]
> > MS has visions sometimes, but maybe you do not find
> > them attractive. :D
>
> If I were a MIS/IT shop I'd be a big MS pusher.
Yes, you probably would. MS is very good at appealing
to such organizations.
> > > As for AppKit, it's not really a 'modern' API. Essentially developed
> > > 1987-1992, ported to various platforms 1992-1997, and tinkered with
> > > 1997-now.
> >
> > Still felt good. Also, there doesn't seem to be any other
> > high-level API for it. Just Cocoa and that C API.
>
> Yes, the C API's were the post-buyout work to bridge AppKit &
> Foundation to the traditional Mac programming base.
I haven't made much effort to use them, but I have
looked at them.
They are more traditional in design; there are handles
to graphics contexts which hold drawing state. Lots of it-
they hold things like a "current path" to append to, or
to draw to. More state than is typical.
I suspect the design was never intended to be programmed
directly; it 'feels' like it was meant as a substrate on which
to build other graphics APIs.
If Apple is committed to Cocoa, then it makes little
sense to build more than this for Carbon apps,
if they can avoid it.
[snip]
> > I do not understand why that would be a problem. API headers
> > routinely have conditional directives so they can be used with
> > different versions of the OS. In <Windows.h> the macro
> > is WINVER. Set this to 0x0400, for instance, and it behaves as
> > if you were targeting for NT 4. Various headers are omitted,
> > and so on.
>
> #defines are a hack. While COM with its GUIDs was something of a
> syntactical nightmare, objects etc. should support API versioning.
> This is a tools issue more than anything else IMV. Everything feels so
> stone-age (vs. what a really bag-up job would produce) in the tools
> dept.
Hmm. You are talking about two different things. The #defines
are a way to turn off features that were introduced in later
OSes, so you can build for older ones more safely.
COM with its GUIDs was trying to solve the problem Objective-C
solves with selectors. It's a *binary* compatibility problem- how
do two objects communicate even though different versions of
either may be present, and their binary representations might
vary.
[snip]
> > I do not really feel that way. For one thing, that PowerBook keyboard
> > is no fun, and while the screen is impressive for a laptop it is still
> > small.
>
> Well, I *do* have a USB hub with Microsoft Natural Elite and mouse,
> and an Apple DVI->ADC adapter to my 17" LCD. Close the clamshell and
> I'm in nirvana, essentially an 800Mhz G4 cube.
There is that. I could hook my PowerBook to my
PC's monitor, I 'spose. Perhaps I would feel
inspired.
Mike Paquette
> I've starting putting my thoughts on MacOS X on my web page:
>
> http://www.vzavenue.net/~danieljohnson/
>
Nice web site. Good article.
> One of the articles is on Quartz, and it is highly favorable to
> Apple. So now I feel all dirty. I will therefore hold forth
> on how we can tell that Quartz was designed by
> psychopathic chipmunks, and then I will feel better.
Wheee! Does that make me Chip, or Dale, or ???
> It's really the Cocoa API that has the chipmunks'
> pawmarks all over it. They managed to take what
> was broken about QuickDraw and make it even
> more broken.
Oh. THAT isn't Quartz. That's the Cocoa AppKit. Quartz is all that
C API that starts with CG...
I'll leave any further commentary up to the local Cocoa boosters. I'm
feeling all agnostic today.
Heywood Mogroot
> "Heywood Mogroot" <imout...@mac.com> wrote in message
> news:dd5de929.02091...@posting.google.com...
> > "Dan Johnson" <daniel...@vzavenue.net> wrote in message
> news:<uobd8fq...@news.supernews.com>...
> > All that MS talk wrt Netscape and 'air supplies' is pretty darn
> > close...
>
> That's just talk.
No, it was more than talk.
"Our business model works even if all Internet software is free. We
are still selling operating systems. What does Netscape’s
business model look like? Not very good." -- Bill Gates, 1995
> Netscape got clobbered for not
> improving their buggy browswer for so long, given
> MS lots of time to catch up, then surpass them.
That's also true. MS shoulda just let Netscape take itself out of the
game, but Allchin & co. got spooked. We all lost. _Breaking Windows_
is a great book on this.
> Arguably, turning IE into components other software
> can use might have contributed. Some say it did,
> and feel this was dirty pool. It certainly created
> dependancies that wouldn't have been there
> otherwsie.
>
> But I am not convinced this really mattered. I think
> Netscape did more than enough damage to itself,
> even without that.
There were more MS nefariousness beyond spotwelding IE to the desktop:
http://www.courttv.com/trials/microsoft/legaldocs/netcomplain.html
I believe MS has yet to pay the piper (treble damages) for their
misdeeds,
http://www.infowar.com/law/02/law_012302c_j.shtml
but they most certainly shall.
> > the C API's were the post-buyout work to bridge AppKit &
> > Foundation to the traditional Mac programming base.
>
> I haven't made much effort to use them, but I have
> looked at them.
>
> They are more traditional in design; there are handles
> to graphics contexts which hold drawing state. Lots of it-
> they hold things like a "current path" to append to, or
> to draw to. More state than is typical.
>
> I suspect the design was never intended to be programmed
> directly; it 'feels' like it was meant as a substrate on which
> to build other graphics APIs.
and/or wrap the Objective-C stuff for the C world.
> > #defines are a hack. While COM with its GUIDs was something of a
> > syntactical nightmare, objects etc. should support API versioning.
> > This is a tools issue more than anything else IMV. Everything feels so
> > stone-age (vs. what a really bag-up job would produce) in the tools
> > dept.
>
> Hmm. You are talking about two different things. The #defines
> are a way to turn off features that were introduced in later
> OSes, so you can build for older ones more safely.
I hate #defines. They're stone age. Add to the friggin' language,
Apple owns it now.
> COM with its GUIDs was trying to solve the problem Objective-C
> solves with selectors. It's a *binary* compatibility problem- how
> do two objects communicate even though different versions of
> either may be present, and their binary representations might
> vary.
I like the communicative nature of COM -- querying for interfaces. In
my private dreamworld both the 'compile-time' headers and the runtime
are vended by a separate framework process. Your IDE would actually
talk to the framework, none of this textfile processing bs.
That's my idea of a kickass IDE at any rate. When the AppKit headers
are properly encapsulated (no private exposure), then they'll be
halfway modern.
> [snip]
> > > I do not really feel that way. For one thing, that PowerBook keyboard
> > > is no fun, and while the screen is impressive for a laptop it is still
> > > small.
> >
> > Well, I *do* have a USB hub with Microsoft Natural Elite and mouse,
> > and an Apple DVI->ADC adapter to my 17" LCD. Close the clamshell and
> > I'm in nirvana, essentially an 800Mhz G4 cube.
>
> There is that. I could hook my PowerBook to my
> PC's monitor, I 'spose. Perhaps I would feel
> inspired.
If I could send my current Mac setup back in time 10 years, it would
absolutely shock people. My 933Mhz PIII running Win2K, on the
otherhand...
if that's not inspiring, nothing would be...
=Heywood=
John C. Randolph
Dan Johnson wrote:
> > > Cocoa keeps most of what it knows about what
> > > you draw as global state. For instance, if you want to
> > > draw a red shape, you set the current color like this:
> > >
> > > NSColor.redColor().set();
> > >
> > > Cocoa puts "red" into an global data structure.
> >
> > Umm, NO. It sets the current color of the currently-focused drawing
> > context to red.
>
> That is part of the global data structure to which I was
> refering.
It would appear then, that you don't know what "global" means.
-jcr
Dan Johnson
news:396c5556.02091...@posting.google.com...
Thank you.
(Two visitors! It's a record! :D )
> > One of the articles is on Quartz, and it is highly favorable to
> > Apple. So now I feel all dirty. I will therefore hold forth
> > on how we can tell that Quartz was designed by
> > psychopathic chipmunks, and then I will feel better.
>
> Wheee! Does that make me Chip, or Dale, or ???
Freddie and the Chimpunks?
> > It's really the Cocoa API that has the chipmunks'
> > pawmarks all over it. They managed to take what
> > was broken about QuickDraw and make it even
> > more broken.
>
> Oh. THAT isn't Quartz. That's the Cocoa AppKit. Quartz is all that
> C API that starts with CG...
Well, I 'spose so. But it's the only API that accesses
Quartz from Java. It is so wrong to call it a "Quartz API"?
> I'll leave any further commentary up to the local Cocoa boosters. I'm
> feeling all agnostic today.
Oh, well.
Dan Johnson
> > That is part of the global data structure to which I was
> > refering.
>
> It would appear then, that you don't know what "global" means.
I do. Though I 'spose I should say that the drawing
state in Cocoa is "thread static" rather than global;
but it really isn't much a difference.
Dan Johnson
> > > close...
> >
> > That's just talk.
>
> No, it was more than talk.
>
> "Our business model works even if all Internet software is free. We
> are still selling operating systems. What does Netscape’s
> business model look like? Not very good." -- Bill Gates, 1995
Bill is right on this one. They can still make money on
the OS even if all Internet software is free. They can
make money on internet software by making it part
of the OS, which isn't quite the same thing as free,
but MS isn't quibbling.
Microsoft has solved a nagging problem in desktop
software- how can you afford good development tools.
They cost a lot to build, and desktop application programmers
have been very leery of royalties that might pay for this.
They are also relatively few in number, compared to their
users, so if you charge by the seat or something, you need to
set your prices astronomically high.
Microsoft ships the runtime libraries for their tools
as part of their OS, Windows, and OEMs pay for
that on a per-computer basis. That's as good as
royalties, but it doesn't scare of developers. They
can then sell their tools cheap. ($100 for
Visual C# Standard edition is absurdly cheap, if
you include of all the frameworks and runtime
libraries underneath it.)
"Componentizing" IE was supposed to turn it into
one of these runtime libraries. MS would then sell
web authoring tools to developers, and also sell
OSes for both clients and servers to OEMs. Part
of their solution would be in the client OS, part
in the server OS, and part would be sold separately
to developers. But that last was the smallest and
cheapest part, lest the developers be scared away.
This whole business depends on cross-subsidization;
Windows pays for the cheap development tools. Some
see *this* as dirty pool (some people see anything
MS does as dirty pool, for that matter). But I've never
heard anyone articulate a better way to do this.
Netscape's business model seems to have been
to make money on web servers but not web
clients, which is rather weaker than MS's plan to
make money on both. Netscape could not
cope with the server software being free, where
MS just threw *that* into Windows as well
(Oddly, nobody seems to carp about IIS
being bundled. Can't think why- that was a much
more direct blow to Netscape than IE was.)
> > Netscape got clobbered for not
> > improving their buggy browswer for so long, given
> > MS lots of time to catch up, then surpass them.
>
> That's also true. MS shoulda just let Netscape take itself out of the
> game, but Allchin & co. got spooked. We all lost. _Breaking Windows_
> is a great book on this.
I know Allchin & co. got spooked and overreacted;
I also know they managed to miss the real threat
in the bargain. They worried so much about Java on
the client they missed Java on the server, until it
ate their some of their lunch.
I do not, however, see much need to read MS bashing
books. I can get my MS bashing for free, right here. :D
> > Arguably, turning IE into components other software
> > can use might have contributed. Some say it did,
> > and feel this was dirty pool. It certainly created
> > dependancies that wouldn't have been there
> > otherwsie.
> >
> > But I am not convinced this really mattered. I think
> > Netscape did more than enough damage to itself,
> > even without that.
>
> There were more MS nefariousness beyond spotwelding IE to the desktop:
That is not what they did. They tried to turn it into
a development tool. This didn't so much "spot weld" it
to the desktop as "spot weld" it to third party applications
which, the theory was, would use it as a runtime library,
so you'd have to have it to use those apps.
This didn't work all that well. Few apps used it.
> http://www.courttv.com/trials/microsoft/legaldocs/netcomplain.html
Netscape may want to pretend they lost because
MS undercut their pricing, but that's stretching it. Their
browser was also free for most users, in practice.
Yes, not for everyone like Internet Explorer. But
the difference was marginal.
> I believe MS has yet to pay the piper (treble damages) for their
> misdeeds,
>
> http://www.infowar.com/law/02/law_012302c_j.shtml
>
> but they most certainly shall.
Well, that seems unlikely. The appeals court that reviewed
this case did not agree that competition per se was
anti-competitive. They upheld only the verdict that Microsoft
had used exclusionary licensing with OEMs, which is nothing
do to with Netscape. They reversed one of the remaining
verdicts and remanded the other.
So as it stands, it appears that entering into a new
market with a superior product at a lower price
is not necessarily anti-competitive. Though the
appeals court did leave open the possibility that it
might be shown to be so, later.
[snip]
> > I suspect the design was never intended to be programmed
> > directly; it 'feels' like it was meant as a substrate on which
> > to build other graphics APIs.
>
> and/or wrap the Objective-C stuff for the C world.
I do not see it doing that. Where does it do that?
> > > #defines are a hack. While COM with its GUIDs was something of a
> > > syntactical nightmare, objects etc. should support API versioning.
> > > This is a tools issue more than anything else IMV. Everything feels so
> > > stone-age (vs. what a really bag-up job would produce) in the tools
> > > dept.
> >
> > Hmm. You are talking about two different things. The #defines
> > are a way to turn off features that were introduced in later
> > OSes, so you can build for older ones more safely.
>
> I hate #defines. They're stone age. Add to the friggin' language,
> Apple owns it now.
I think Apple is more interested in Java. This is understandable;
Objective-C has not been a very widely, er, appreciated
language.
Mind, the *way* Apple supports Java makes it feel
more like Objective-C than I had expected. But of course
that applies only to the Cocoa API, really.
> > COM with its GUIDs was trying to solve the problem Objective-C
> > solves with selectors. It's a *binary* compatibility problem- how
> > do two objects communicate even though different versions of
> > either may be present, and their binary representations might
> > vary.
>
> I like the communicative nature of COM -- querying for interfaces. In
> my private dreamworld both the 'compile-time' headers and the runtime
> are vended by a separate framework process. Your IDE would actually
> talk to the framework, none of this textfile processing bs.
I am not sure way you want a process. The "new world"
approach to this as seen in Java and .NET puts the required
data into the .exes or .dlls, and your compiler reads it
out of there- not from a process.
But they are coming from the same file as the binary
executable code.
> That's my idea of a kickass IDE at any rate. When the AppKit headers
> are properly encapsulated (no private exposure), then they'll be
> halfway modern.
What do you mean, private exposure?
[snip]
> > There is that. I could hook my PowerBook to my
> > PC's monitor, I 'spose. Perhaps I would feel
> > inspired.
>
> If I could send my current Mac setup back in time 10 years, it would
> absolutely shock people. My 933Mhz PIII running Win2K, on the
> otherhand...
>
> if that's not inspiring, nothing would be...
I do not understand. How would your Mac setup shock people?
While a 933MHz PIII is not very fast by today's standards in 1992
it would have astonished them for its speed, if nothing else.
Heywood Mogroot
> "Heywood Mogroot" <imout...@mac.com> wrote in message
> news:dd5de929.02091...@posting.google.com...
> > > > All that MS talk wrt Netscape and 'air supplies' is pretty darn
> > > > close...
> > >
> > > That's just talk.
> >
> > No, it was more than talk.
> >
> > "Our business model works even if all Internet software is free. We
> > are still selling operating systems. What does Netscape’s
> > business model look like? Not very good." -- Bill Gates, 1995
>
> Bill is right on this one. They can still make money on
> the OS even if all Internet software is free. They can
> make money on internet software by making it part
> of the OS, which isn't quite the same thing as free,
> but MS isn't quibbling.
Only by running facefirst into Clayton Sherman.
> Microsoft ships the runtime libraries for their tools
> as part of their OS, Windows, and OEMs pay for
> that on a per-computer basis. That's as good as
> royalties, but it doesn't scare of developers. They
> can then sell their tools cheap. ($100 for
> Visual C# Standard edition is absurdly cheap, if
> you include of all the frameworks and runtime
> libraries underneath it.)
I don't follow this at all. These 'runtimes' are required by
Microsoft's own programs, too.
and 'professional' VS seats haven't come cheap, IME:
http://shop2.outpost.com/product/3241051
(though one MSDN box can easily serve 10-20 cubicles..)
> "Componentizing" IE was supposed to turn it into
> one of these runtime libraries. MS would then sell
> web authoring tools to developers, and also sell
> OSes for both clients and servers to OEMs. Part
> of their solution would be in the client OS, part
> in the server OS, and part would be sold separately
> to developers. But that last was the smallest and
> cheapest part, lest the developers be scared away.
This is rather incorrect. Silverstein was creating an "Internet
Platform" group. Allchin called a timeout to point out that Win32 was
the one true platform for MS and that was that.
> This whole business depends on cross-subsidization;
> Windows pays for the cheap development tools. Some
> see *this* as dirty pool (some people see anything
> MS does as dirty pool, for that matter). But I've never
> heard anyone articulate a better way to do this.
Windows (and Office) can pay for everything. Right now MS's main
problem is just spending its net income.
> Netscape's business model seems to have been
> to make money on web servers but not web
> clients, which is rather weaker than MS's plan to
> make money on both. Netscape could not
> cope with the server software being free, where
> MS just threw *that* into Windows as well
>
> (Oddly, nobody seems to carp about IIS
> being bundled. Can't think why- that was a much
> more direct blow to Netscape than IE was.)
Netscape's original complaint to Joel Klein in 1996 mentioned IIS
bundling.
http://www.courttv.com/trials/microsoft/legaldocs/netcomplain.html
> I do not, however, see much need to read MS bashing
> books. I can get my MS bashing for free, right here. :D
_Breaking Windows_ isn't a bash book, unlike eg. Wendy Goldman's _The
Microsoft Files_.
> > There were more MS nefariousness beyond spotwelding IE to the desktop:
>
> That is not what they did.
Not *all*, no. But when I first installed WIn98 I was greatly amused
by the inability to trash the e desktop icon. That's when I knew MS
was playing for keeps.
>They tried to turn it into
> a development tool. This didn't so much "spot weld" it
> to the desktop as "spot weld" it to third party applications
> which, the theory was, would use it as a runtime library,
> so you'd have to have it to use those apps.
>
> This didn't work all that well. Few apps used it.
It pissed me off when VC5 was shipped, requiring the IE install, and
its HTML help was greatly inferior to the previous perfectly fine
hyperlink help.
http://groups.google.com/groups?selm=uZfc8TtP8GA.133%40uppssnewspub05.moswest.msn.net&output=gplain
> > http://www.courttv.com/trials/microsoft/legaldocs/netcomplain.html
>
> Netscape may want to pretend they lost because
> MS undercut their pricing, but that's stretching it. Their
> browser was also free for most users, in practice.
Read the link.
> > I believe MS has yet to pay the piper (treble damages) for their
> > misdeeds,
> >
> > http://www.infowar.com/law/02/law_012302c_j.shtml
> >
> > but they most certainly shall.
>
> Well, that seems unlikely. The appeals court that reviewed
> this case did not agree that competition per se was
> anti-competitive. They upheld only the verdict that Microsoft
> had used exclusionary licensing with OEMs, which is nothing
> do to with Netscape. They reversed one of the remaining
> verdicts and remanded the other.
>
> So as it stands, it appears that entering into a new
> market with a superior product at a lower price
> is not necessarily anti-competitive. Though the
> appeals court did leave open the possibility that it
> might be shown to be so, later.
It's ** everything else ** that MS did, quite a long laundry list (cf
Netscape's 1996 complaint) that will bring the piper to Redmond.
> [snip]
> > > I suspect the design was never intended to be programmed
> > > directly; it 'feels' like it was meant as a substrate on which
> > > to build other graphics APIs.
> >
> > and/or wrap the Objective-C stuff for the C world.
>
> I do not see it doing that. Where does it do that?
Everywhere it can. Eg. CFStrings are really NSStrings.
> > I hate #defines. They're stone age. Add to the friggin' language,
> > Apple owns it now.
>
> I think Apple is more interested in Java. This is understandable;
> Objective-C has not been a very widely, er, appreciated
> language.
Java is part of the mix, but Cocoa is Apple's core development
environment.
> > I like the communicative nature of COM -- querying for interfaces. In
> > my private dreamworld both the 'compile-time' headers and the runtime
> > are vended by a separate framework process. Your IDE would actually
> > talk to the framework, none of this textfile processing bs.
>
> I am not sure way you want a process.
Don't see why not. Basically moves a lot of compiler technology
outside the IDE, for use by more kinds of apps. Great idea, I should
patent it.
> > That's my idea of a kickass IDE at any rate. When the AppKit headers
> > are properly encapsulated (no private exposure), then they'll be
> > halfway modern.
>
> What do you mean, private exposure?
all the private crap in the system frameworks. This shouldn't be
exposed -- a large part of the Carbon effort was enforcing opaqueness
of system headers. Now we got to do the same thing to Cocoa. Got I
hate that word.
> [snip]
> > > There is that. I could hook my PowerBook to my
> > > PC's monitor, I 'spose. Perhaps I would feel
> > > inspired.
> >
> > If I could send my current Mac setup back in time 10 years, it would
> > absolutely shock people. My 933Mhz PIII running Win2K, on the
> > otherhand...
> >
> > if that's not inspiring, nothing would be...
>
> I do not understand. How would your Mac setup shock people?
see my very recent "Back to the Future I" post to this ng.
> While a 933MHz PIII is not very fast by today's standards in 1992
> it would have astonished them for its speed, if nothing else.
precisely.
=Heywood=
Dan Johnson
> > the OS even if all Internet software is free. They can
> > make money on internet software by making it part
> > of the OS, which isn't quite the same thing as free,
> > but MS isn't quibbling.
>
> Only by running facefirst into Clayton Sherman.
That is at best debateable.
> > Microsoft ships the runtime libraries for their tools
> > as part of their OS, Windows, and OEMs pay for
> > that on a per-computer basis. That's as good as
> > royalties, but it doesn't scare of developers. They
> > can then sell their tools cheap. ($100 for
> > Visual C# Standard edition is absurdly cheap, if
> > you include of all the frameworks and runtime
> > libraries underneath it.)
>
> I don't follow this at all. These 'runtimes' are required by
> Microsoft's own programs, too.
Yes, they are.
> and 'professional' VS seats haven't come cheap, IME:
>
> http://shop2.outpost.com/product/3241051
>
> (though one MSDN box can easily serve 10-20 cubicles..)
Even the Enterprise Architect version of VS.NET
only cost about $3000, which isn't much as such
thing go. And the low-end stuff is about $100 a
seat.
> > "Componentizing" IE was supposed to turn it into
> > one of these runtime libraries. MS would then sell
> > web authoring tools to developers, and also sell
> > OSes for both clients and servers to OEMs. Part
> > of their solution would be in the client OS, part
> > in the server OS, and part would be sold separately
> > to developers. But that last was the smallest and
> > cheapest part, lest the developers be scared away.
>
> This is rather incorrect. Silverstein was creating an "Internet
> Platform" group. Allchin called a timeout to point out that Win32 was
> the one true platform for MS and that was that.
It isn't incorrect. You shouldn't get hung up on
nomenclature. They rolled IE into Win32, in
essense.
> > This whole business depends on cross-subsidization;
> > Windows pays for the cheap development tools. Some
> > see *this* as dirty pool (some people see anything
> > MS does as dirty pool, for that matter). But I've never
> > heard anyone articulate a better way to do this.
>
> Windows (and Office) can pay for everything. Right now MS's main
> problem is just spending its net income.
Well, I'm not sure I'd put it that way. Their
main problem is maintaining their grip on
their developers, now that they have it.
[snip]
> > (Oddly, nobody seems to carp about IIS
> > being bundled. Can't think why- that was a much
> > more direct blow to Netscape than IE was.)
>
> Netscape's original complaint to Joel Klein in 1996 mentioned IIS
> bundling.
>
> http://www.courttv.com/trials/microsoft/legaldocs/netcomplain.html
Well, okay, I guess Netscape didn't miss that one. But
it sure didn't get much press. I find this odd.
> > I do not, however, see much need to read MS bashing
> > books. I can get my MS bashing for free, right here. :D
>
> _Breaking Windows_ isn't a bash book, unlike eg. Wendy Goldman's _The
> Microsoft Files_.
Uh-huh.
> > > There were more MS nefariousness beyond spotwelding IE to the desktop:
> >
> > That is not what they did.
>
> Not *all*, no. But when I first installed WIn98 I was greatly amused
> by the inability to trash the e desktop icon. That's when I knew MS
> was playing for keeps.
That's just cosmetic. They did far more
serious things than that.
> >They tried to turn it into
> > a development tool. This didn't so much "spot weld" it
> > to the desktop as "spot weld" it to third party applications
> > which, the theory was, would use it as a runtime library,
> > so you'd have to have it to use those apps.
> >
> > This didn't work all that well. Few apps used it.
>
> It pissed me off when VC5 was shipped, requiring the IE install, and
> its HTML help was greatly inferior to the previous perfectly fine
> hyperlink help.
Well, MS was certainly able to have their own apps
use it. But that's not a very large subset of the apps
that are out there.
[snip]
> > > http://www.courttv.com/trials/microsoft/legaldocs/netcomplain.html
> >
> > Netscape may want to pretend they lost because
> > MS undercut their pricing, but that's stretching it. Their
> > browser was also free for most users, in practice.
>
> Read the link.
Oh, please.
[snip]
> > So as it stands, it appears that entering into a new
> > market with a superior product at a lower price
> > is not necessarily anti-competitive. Though the
> > appeals court did leave open the possibility that it
> > might be shown to be so, later.
>
> It's ** everything else ** that MS did, quite a long laundry list (cf
> Netscape's 1996 complaint) that will bring the piper to Redmond.
I do not think so. The mere fact that some people
can make everything MS does sound dirty doesn't
mean mich. You can do that to anybody.
I do not even think the exclusionary licensing is going
to "bring the piper to Redmond"; all that will happen is
that they will be prohibited from doing that anymore,
and it will just mean they charge OEMs slightly more.
But OEMs will still have to ship Windows as long
as developers develop most apps for it.
[snip]
> > > > I suspect the design was never intended to be programmed
> > > > directly; it 'feels' like it was meant as a substrate on which
> > > > to build other graphics APIs.
> > >
> > > and/or wrap the Objective-C stuff for the C world.
> >
> > I do not see it doing that. Where does it do that?
>
> Everywhere it can. Eg. CFStrings are really NSStrings.
Ah. That is a surprise to me.
> > > I hate #defines. They're stone age. Add to the friggin' language,
> > > Apple owns it now.
> >
> > I think Apple is more interested in Java. This is understandable;
> > Objective-C has not been a very widely, er, appreciated
> > language.
>
> Java is part of the mix, but Cocoa is Apple's core development
> environment.
Cocoa is an API, not a language. Apple clearly knows
the difference, even if Sun does not. :D
> > > I like the communicative nature of COM -- querying for interfaces. In
> > > my private dreamworld both the 'compile-time' headers and the runtime
> > > are vended by a separate framework process. Your IDE would actually
> > > talk to the framework, none of this textfile processing bs.
> >
> > I am not sure way you want a process.
>
> Don't see why not. Basically moves a lot of compiler technology
> outside the IDE, for use by more kinds of apps. Great idea, I should
> patent it.
I do not think you'd make a lot of money; it would be
far more simple to put that functionality into share
libraries or the like. Which is what Java and .NET
do, in essense.
> > > That's my idea of a kickass IDE at any rate. When the AppKit headers
> > > are properly encapsulated (no private exposure), then they'll be
> > > halfway modern.
> >
> > What do you mean, private exposure?
>
> all the private crap in the system frameworks. This shouldn't be
> exposed -- a large part of the Carbon effort was enforcing opaqueness
> of system headers. Now we got to do the same thing to Cocoa.
I was not aware the headers were transparent. Of course,
I've been programming in Java, and it appears to me that
the Java .class files your link to aren't transparent in this
way.
So Apple may already have made some progress on
eliminating #defines and transparent headers, with their
Java bridge.
> Got I hate that word.
You no like "Cocoa"?
[snip]
> > > if that's not inspiring, nothing would be...
> >
> > I do not understand. How would your Mac setup shock people?
>
> see my very recent "Back to the Future I" post to this ng.
In summary: it would shock them because you
would have pointed out all the great things your
PowerBook could do, whilst leaving your
PC to gather dust in the backseat of your
DeLorean. :D
Well, maybe not quite that. But most of the
shocking stuff about your Mac is just as
true of a contemporary PC laptop.
> > While a 933MHz PIII is not very fast by today's standards in 1992
> > it would have astonished them for its speed, if nothing else.
>
> precisely.
However, there is quite a lot else that would have
impressed users of Windows 3 computers. :D