>> Um... Ethernet? :) It seems to be how most people on here
>>synch up, at least...
>
>Yeah, Ethernet over AppleTalk.
>Can you access AppleTalk from Carbon?
Absolutely. From Cocoa, even.
BSD too, for that matter.
******************
Before sending this off, I checked the Carbon docs
extensively... here's the situation.
Carbon supports (through Open Transport):
* TCP, UDP and Raw IP Endpoints;
* TCP/IP Services Provider and TCP/IP Mapper Provider (i.e. DNR protocol);
* DDP endpoints;
* AppleTalk Services Providers and AppleTalk Mappers (i.e. ZIP and
NBP protocols);
* OT/PPP endpoint.
Carbon does *not* support:
* ADSP, ATP, ASP and PAP Endpoints;
* Serial endpoint.
So, to access the Newton over AppleTalk on Ethernet... it
looks like the Carbon app would be able to *see* the Newton, but not
establish a connection to it through AppleTalk. Am I correct in
this? Any OT gurus out there?
Since NIE is available on the NewtonOS 2.x units, would it be
possible to roll a new Docking solution on both ends from scratch,
bypassing the Dock protocol that seems to give everyone fits?
Cocoa has access to the BSD version of AppleTalk through a
couple of package choices you can install, but it's not included in
the default installation. My bad. I used this method for a network
tester I whipped up... I knew I did it, just forgot the extra step.
Apologies.
******************
>> Carbon isn't my strong suit, either, but you can access a
>>legacy serial port through Cocoa, if it's available on the machine.
>>
>> If it's *really* necessary, you can write a direct BSD layer
>>tool to access the port, then wrap that in a GUI through Cocoa quite
>>easily.
>
>Sure. How do I develop that without having to learn?
Sorry, that's just another silly comment.
>Sorry, my software is written for MacOS ToolBox. Porting it to
>Carbon is already an important work. Porting to cocoa is a big work
>which requires to have a MacOS X and considering the market, is it
>really worth it?
It may not be, for you. For *you*, it sounds like Carbon is
your best bet. As I said last time, and Apple has been screaming
from the rooftops for two years now, "If you're porting existing
MacOS apps, use Carbon. If you're starting new development from
scratch, use Cocoa." This is, after all, the entire reason for
Carbon's existence.
Personally, I'd pay good money for a MacOS X synch solution
with Palm Desktop. Carbonized at least, Cocoa is preferred.
Heck, I'd pay so-so money for just a backup solution that's
guaranteed to work under MacOS X. NCU's extreme flakiness is what
brought me to this list in the first place. That's one app I *don't*
expect to see work well... because it doesn't under MacOS 9, and
obviously doesn't follow the normal guidelines there.
>> >Networking & communication is one of the greatest problem of MacOS X,
>> >because of the Unix kernel.
>>
>> Okay, now I'm going to jump into this. This is a *silly*
>>comment. One of the absolute strengths of Darwin (MacOS X's core
>>kernel and Unix layer) is the networking stack. To claim this is a
>>weakness of Unix in general is... well, it's like claiming that the
>>GUI is the weakness of the Mac. (It may not be perfect, but it's
>>still the best out there.)
>
>I mean for Classic/Carbon platform.
>Sure, it you use the Next bs, you have networking.
Um, I'm afraid you're confused on how networking in MacOS X
works... it *all* uses the same networking stacks. Period. Classic,
Carbon, Cocoa, even BSD, they all go through the same exact path
under the hood. They have to. Period. The API used to access it
from each environment may be different, but the mechanism is the
same. That stack happens to be Unix based. That was the cause of a
little bit of furor about 18 months ago when Apple announced they
were dropping STREAMS and going with sockets. STREAMS is the basis
for Open Transport, and is quite a nice system. Sockets are the
traditional Unix way. What Apple did was to place Open Transport
over sockets instead of STREAMS, and then provide a system that gives
much of the plug-in nature of STREAMS, using sockets instead.
(STREAMS is produced by a company called Mentat, and Apple has been
paying Mentat a license fee for every Open Transport copy out
there... this method means no fees.)
Networking is available from *all* the APIs, and user environments.
>> If you can point me to a more robust, stable
>
>NewtonOS on 1 MB machines, 4MB if the -10061 is fixed.
Good one! :)
But seriously, I was talking about desktops, not handhelds.
>>widely-used OS
>>core, please do.
>
>Sorry, that's not an argument.
You're right, it's not, at a technical level... but it sure
as heck helps the OS survive.
>Besides, cooperative multithreading is *not* an innovation. I
>explain part of DOS from stupid cooperative multithreading.
Wow, this is getting confusing. What OS are you talking about?
MacOS up until X: cooperative multitasking.
MacOS X: preemptive multitasking, multithreading, and all the
other current buzzwords.
I believe we were talking about the Unix layer, not MacOS 9, correct?
>> On top of that, 'Unix kernel' is a misnomer. Unix refers to
>>the style of access to the OS more than the actual core anymore.
>>Linux is referred to as a Unix. So is Solaris. So is Darwin. All
>>three have radically different kernels.
>
>But they are all built the same way.
Um, no. Not in the least. Go look up the design docs on
each of the above. None of the three use the same architecture.
Heck, toss in Linux. It's yet another style and design...
>> Darwin's kernel is Mach 3.0, a highly respected clean
>>architecture kernel. The original Mach is newer than the Mac... :)
>
>But based on 1969' technology.
Actually, no. Mach has nothing to do with Unix.
Let me try and explain this...
Mach is the kernel. It's the closest layer to the hardware.
It is the *only* layer that deals directly with the hardware. Any
other code that wants to access hardware must do so *through* Mach.
It was designed in the mid to late 80s by Avie Tevanian, then at
Carnegie Mellon University. At the time, it was a *radical*
rethinking of how an OS should work, and it is a natural fit into an
object-oriented philosophy since the entire thing is based on
messaging... rather like SmallTalk.
Above that sits two environments: BSD (Unix), and Core
Application Services. On top of CAS, in turn, sit Classic, Carbon,
and Cocoa.
'Unix' in this case is just a combination of the user
interface (shells), with the appropriate development tools and
libraries that are common to Unixen.
This is now pretty normal in the Unix world, BTW.
Cocoa/Carbon apps can call processes in the BSD section, but
they don't sit directly on top of it.
So why have the BSD environment?
Two reasons:
1) Power. I love my GUI. I'm a Machead from 1984. But it
can't do everything the best... and that's where a CLI comes in.
They each have their place. As a user, I've preferred MacOS. As a
developer, Unix. Now I have both, *with* a top of the line
development API and environment: Cocoa.
2) Apps. There are *tons* of excellent apps out there for
Unix, particularily in the server and networking arenas, that can now
be ported rather trivially to MacOS X. (I'm assuming CLI apps here -
GUI apps on Unix usually use the X Windowing System from MIT for
their windowing kit, and that isn't included in MacOS X... yet. The
Darwin folk have it up and running, courtesy of game company id's
John Carmack porting XFree86 earlier this year.) Servers and
networking are two areas where the MacOS has traditionally not fared
well... now it can, and on an even footing with the big boys of Unix.
Not too shabby.
Oh heck, just go look at the System Overview on Apple's
developer site:
http://developer.apple.com/techpubs/macosx/System/Documentation/Developer/SystemOverview/SystemOverview.pdf
It's long, but it gives you the entire picture. Also, check
out the Kernel Environment docs for a more detailed look at how Mach
and the other levels communicate and are partitioned:
http://developer.apple.com/techpubs/macosx/System/Documentation/Developer/Kernel/KernelEnvironment.pdf
(Caveat to above explanation - Mach and BSD are actually tied
together a little tighter in MacOS X than they normally are, due to
performance concerns... this doc goes into that in detail. The basic
explanation above still holds for the rough picture however.)
While I'm at it, the Networking Kernel Extensions docs:
http://developer.apple.com/techpubs/macosx/System/Documentation/Developer/Kernel/NKE.pdf
and IOKit docs:
http://developer.apple.com/techpubs/macosx/System/Documentation/Developer/Kernel/IOKitLib/index.html
will give you an idea about a couple of the new mechanisms (robust
ones, I might add, which is a nice change) that replace Extensions.
There are a couple others as well.
>> Unless the app makes low level hardware calls it shouldn't do
>>*anyway* according to Apple's developer guidelines that have been
>>around... well, practically forever... it should run, and run well.
>
>For example anti-viruses, communication programs, they all use low
>level hardware calls, that's well known.
No, they don't. Not any more. Sorry.
For instance, Open Transport is not low level. It's
extremely high level.
What sort of low level hardware calls are you thinking of?
In my mind, low level means you access the ICs on the motherboard
directly and start fiddling bits and tossing assembler at them.
The only apps I can think of that are likely to break are
things like disk partitioning tools, where they bypass the disk
access APIs in an attempt to do their own optimizations.
>> What you have now has a *strong* chance of being compatible.
>
>I am compatible from OS 7 to 9.
And to X in the Classic environment as well, in most cases,
with no code change.
Heck, man, at least *try* it.
>> This reminds me very much of the claims that the move to PPC
>>was going to kill Apple, since there was no way they could possibly
>>make 68K emulation work, and if they did, it wouldn't work well
>>enough to make a difference.
>
>It was much easier that time, since the OS philosophy didn't change.
No, just all the implementation...
>> >And remember that making FAT was easy to do so that we, MacOS
>> >developer, still make FAT programs. But making PPC Carbon/PPC Classic
>> >[CFM]/68k Classic becomes much harder. The 68k market is currently
>> >being abandonned, but the classic non carbon PPC market (i.e. before
>> >OS 8) will be, too.
>>
>> Yup, it will.
>
>And? Many people are still using old macs. They can't afford new
>ones. You don't want to develop for them? Sorry, but most
>developer's market is not Photoshop's.
Agreed, but go back and look at my argument on the shrinking
of that market over the next few years... it *will* happen. There's
no way around it. In two to three years, the balance may have
shifted enough so that you see Cocoa as the proper choice for your
market. And no, I don't think two to three years is too short a
time... the benefits to the user are going to make MacOS X the most
eagerly wanted upgrade ever, IMHO. MacOS 9 migration was a drop in
the bucket compared to this. :) Let's face it, if you had an older
machine running System 7, MacOS 9 didn't offer *that* many reasons to
upgrade. It was a good solid leap, but not compelling. MacOS X will
be, I believe. It has the stability (I think the record so far on my
machine at work is 8 months uptime, and that's only because I had to
move offices...), the power, and the consumer technologies they've
come to expect from Apple. Plus some new goodies. ;)
>Besides, having a Unix kernel means that the OS bowels will be too
>complex for those people. Is it what you want?
Alright, now I'm almost positive you've never used MacOS X.
The Unix layer is *completely* hidden from the user, unless they
decide to go diving into it. Period. This *is* a consumer OS, this
*is* the OS for your grandmother.
Basically, Apple seems to have pulled off the impossible -
they've made Unix user-friendly. The average user will never even
know it's there... except through the lack of hard crashes.
>> If anything, I find Carbon apps to run faster under MacOS X
>>than they do under MacOS 8-9, and I can't tell a difference between
>>Carbon and Classic apps under MacOS 8-9.
>
>I can. Script Editor & Sherlock II takes years to open on my G3 if I
>don't have an enough unfragmented disk.
What about running times vs. launch times? Launch time under
MacOS X may be affected by whether the app is indeed Carbon, or it's
instead Classic and you just think it's Carbon... launching the first
Classic app necessitates launching the Classic environment... which
means booting MacOS 9 on top of MacOS X.
Oh, and if unfragmented diskspace is your problem under MacOS
X, you probably need more RAM. It sounds like you're thrashing the
virtual memory system. It's a lot more robust, but it likes room to
move.
BTW, which OS are we talking about here, MacOS 9, or MacOS X?
Which version of CarbonLib do you have? That *really* makes a
difference under MacOS 9... go grab the 1.1 developer version if you
have to. It's beta, but it makes quite a large difference, and I
haven't found it to be any more crash-prone. The latest *released*
version is only 1.0.4.
>> Ah, now it makes sense. Yeah, I'm bitter about the Newton
>>getting axed too, but the rest of the company still has the best tech
>>out there. :)
>>
>> To bring this back to development and API choices...
>>
>> If you're just starting out, I'd recommend wholeheartedly
>>going with Cocoa in most instances. Your market will be MacOS X
>>only, it's true... but your time to market will be much faster. As
>>in half. It's truly an amazing piece of work, and easily the most
>>advanced API and development suite I've used in the last twenty years
>>of developing.
>
>You should try NewtonOS.
I have. I loved it.
Cocoa is, IMHO, it's desktop equivalent, or the closest thing
we're likely to see without SmallTalk taking over the world. :)
(Which, BTW, Objective-C was based off of... it's much closer to
SmallTalk than C.)
Wait, wait, wait... you programmed for NewtonOS, but won't
move to Cocoa?!? Sorry, this I do *not* understand. You should feel
right at home... a fully dynamic OO system based on prototypes. If
you understand the concepts behind NewtonScript, then you're way
ahead of the folks coming from a C/C++ background. It seems to me
that you'd jump at the chance to do this! Oh well.
>Frankly, we can't do otherwise because they decided to make those
>stupid choices. But this is definitively un-Apple.
>
>Let's take the Anti-virus example again. With PPC, they migrated the
>code to datafork, this introduced another weakness of the
>applications.
Then you'll love the new bundling approach. It's the
data/resource fork idea on steroids, without forcing the underlying
file system to know about forks. It's gorgeous. :)
>If they remove the ability to patch, it will be even more weak.
>Besides, the patch ability is part of the MacOS spirit. People can
>use third party software to change the appearance/interface with
>small hacks. Those developers are the strength of Apple. And as I
>heard it, this is over. Poor choice.
Then you heard wrong. The mechanism has changed, but the
flexibility is still there... in fact, I'd say it's increased, but in
an *intelligent* way.
Patching is powerful.
Patching is also an extremely abusable loophole to screw up
your system. Can you say 'extensions conflict'? Almost impossible
under the new system... and you can 'patch' nearly anything in the
blasted system. Networking, file systems, the UI... you name it,
it's likely patchable.
Also, Objective-C has this nice little thing called 'posing',
where a subclass can stand in for the superclass, system wide. Want
all your windows to have a purple border? Subclass NSWindow, add the
purple border, tell it to pose as NSWindow system-wide. Done. (Oh,
sorry - that's only for all the Cocoa apps... the Carbon and Classic
apps can't play there.)
And that's just the *language* support. :)
In any case, this doesn't really belong on a Newton talk
list, since it now has very little to do with the Newton. I suggest
we take it offline, okay?
-- Jason Smith 353 Sitterson Hall smithja@cs.unc.edu (919) 962-1821 ------------------------------------------------------------------ http://www.cs.unc.edu/~smithja/ *************************************** NewtonTalk brought to you by:EVOTE.COM -- the ESPN of politics on the Internet! All the players, all the news, and the hottest analysis and features (plus 'toons!) anywhere.... visit http://www.evote.com today!
*************************************** Need Subscribe/Unsubscribe info?
Visit the NewtonTalk section at http://www.planetnewton.com
This archive was generated by hypermail 2b29 : Tue Sep 12 2000 - 00:00:07 CDT