delaneyg@wnre.aecl.ca (Grant Delaney) (05/29/90)
*********************************
Number: 1742 Name: RTC.APW.P1.TXT PART ONE
Address: A2PRO.ERIC Date: 900529
Approximate # of Bytes: 40320
Number of Accesses: 3 Library: 2
Description:
This is the transcript of a Real Time Conference held in the Apple II
Programmers and Developers RoundTable on May 28th, 1990. The featured guest
was Tim Swihart of Apple Computer, Inc. Tim is the product manager of APW
and MPW IIgs, and in this transcript, he discusses the future of APW (among
other things). This is a TXT file that you can read by choosing <L>ist. Or
you can <D>ownload it with XMODEM and read it with your word processor. A
BXY version of this same transcript, that must be processed with ShrinkIt,
is in a nearby file.
Apple II Programmers and Developers RoundTable
==============================================
Real Time Conference Transcript
-------------------------------
Guest : Tim Swihart
: Apple Computer, Inc.
Date : May 28th, 1990
Copyright 1990 GEnie All rights reserved
------------------------------------------------
[Note: this is part one.]
<A2PRO.ERIC> Looks like everyone's here... let's get started. Thanks for
coming, everyone... (and I'm glad I could be here too <grin>). Our guest
this evening is Tim Swihart, the APW and MPW IIgs Product Manager at Apple
Computer, Inc. I guess that involves all of the pieces of MPW IIgs also:
the x-dev compilers, and the IIgs-specific shell commands (REZIIGS,
DUPLICATEIIGS, etc). Tim is here tonight to talk about his products and
to hopefully let us know what's coming up in the future. So, without further
delay, let me turn the floor over to Tim for opening comments.
<TIM.SWIHART> Hi gang. Glad you all could sneak away from the BBQ pits long
enough for this conference. I'll try to keep my answers from being as
verbose as they normally are. :-) Those of you who haven't heard yet,
we're on the verge of shipping the next version of "APW Tools & Interfaces"
(and their MPW IIGS counter part -> MPW IIGS Tools).
This is a replacement/revision to the currently available "Programming
Tools & Interfaces for APW". Aside from shortening the name to something
most folks can remember, we've fixed all the bugs we could find at the time,
given it a "real" manual (instead of the hodge podge manual it had before)
and made it a Class 1 product so it's available for NON-APDA folks as well!
(That effectively cuts its price by twenty bucks)
I'm sure most of you have a whole slew of your own questions, so I'll wrap
this intro up and we can get on with the show. Back to you Eric.
<A2PRO.ERIC> Thanks Tim! Our first question of the night goes to Rio.
<[Rio] M.ARGYROS4> Tim : What's the big deal about MPW ---> And the Mac?
Is it Really Better?
<TIM.SWIHART> "Better" is in the eye of the beholder. MPW IIGS is certainly
"more powerful" due in part to the fact that it lets you harness the 40MHz
Mac IIfx to write IIGS software :-) And due in large part to the greater
resources (engineers, testers, etc) that are working on it. MPW has more
people-hours behind its design and implementation than any native IIGS
development tool.
<[Rio] M.ARGYROS4> And comment the code based ON THE BETA info !! ??
<TIM.SWIHART> Rio, the deciding factor is whether you've created something
"original" or whether you've simply typed in what's in the manual and want
to upload that. You need to be a tad more specific about what you're trying
to do.
<[Rio] M.ARGYROS4> The Pascal GSOS demo is a program and SRC that steps
through all of the Available call's With the Proper( Complete) Syntax...
then I comment The Code and What it does Based on the GSOS Reference Manual's
... Not Word For Word... Just Making Reference to Pages.
<TIM.SWIHART> It sounds "clean", but if you're really concerned, the easiest
thing to do is let us see it before you release it to the world. You can
email it to me (Tim.Swihart) and I'll forward it to the folks that know
best. :-)
<BRYAN.ZAK> Tim, in the new release of APW Tools & Interfaces has Rez been
changed? I don't really want to shell out $50 again if Rez hasn't been
changed.
<TIM.SWIHART> Bryan, the update is only $25 for folks who already bought
"Programming Tools & Interfaces for APW" :-)
<BRYAN.ZAK> ah! I might get it just for the new manual then! Ok, next...
<TIM.SWIHART> I know that several bugs in CLib (which Rez is linked with)
have been fixed and I BELIEVE there are some other MINOR changes as well -
nothing earthshattering, other than the CLIb fixes. The update version
does NOT include the new manual! If it did, the update would cost $50
also. On small products like this, manufacturing costs have to be kept
REAL small or the price takes a hike! I just checked with my local Rez
genius and both CLib and Rez itself were changed since the last release.
MPW is a desktop development environment originally modeled LOOSELY after
UNIX. (very loosely). Like all "good" Mac applications, it's MultiFinder
friendly and can compile in the background, so you can edit (using a second
copy of the shell) other files while compiling in the background. There are
some vague similiarities to Prizm - each window can be used as an "editor"
and to execute SHELL commands. One advantage it has is that the Mac's
screen size is flexible (i.e.: not a fixed number of pixels), so if you have
a two page display, you can see a LOT of source at once!
The next version of MPW was shown publicly for the first time at MacWorld
in April and has some pretty neat features - the most notable are "multi-
paned" windows - each window can have up to 32 "panes" within it. That lets
you see (and edit) up to 32 DIFFERENT parts of your source at once. Pretty
handy for writing the next great IIGS application. :-)
MPW is a fully scriptable environment and it's menus are "changable" on the
fly. You can add menus of your own (at any time) and have the items within
those menus execute commands, scripts, etc. You can also add items to an
existing menu to further customize the shell. You almost needs some time
"hands on" to really appreciate everything it has to offer.
<A2PRO.ERIC> (So true!)
<TIM.SWIHART> It's drawback is that it's a little intimidating to new users.
Developer University offers a couple of classes on MPW alone. :-) It's aimed
at the "industrial strength" end of the spectrum and includes such nice
things as a "smart MAKE" facility (only build the stuff that changed and
anything that depends on it.
Since MPW supports the network, you can connect your IIGS and the Mac to the
same server and have your build script copy the resulting application to the
server where it can be immediately run from the server by the IIGS.
That about sums it up - there's a LOT more, but I think you get the
point. :-)
<BRYAN.ZAK> Sounds like I need an extra $7,00 to develop GS applications :-)
Ok, I'm done (for now).
<[Jeff] J.HOLCOMB1> Tim, are there any other changes or new additions to the
tools in the update?
<TIM.SWIHART> Well, there are lots of changes. Most folks call them "bug
fixes" though. :-) There are no new tools in the set.
<[Jeff] J.HOLCOMB1> Let's talk C. Any chance ya'll might be upgrading your
C compilers to support Ansi or C++ ?
<TIM.SWIHART> (one other point on the new tools) (anybody wondering whether
or not they should get the new version - the answer is YES! re: C, that's
a REAL sticky one! APW C was written for us by a third party, it's not
"fully" our own C. Updating it requires a new contract, negotiations, and
lots of other hassles. Plus, it's not clear whether it would be easier to
start fresh and do it as an ANSI compiler (it's only K&R now) or to try to
update what we have.
We actually have TWO C compilers to think about - the MPW IIGS one and the
APW one. So any decision we make affects both of our C compilers and
could potentially impact ORCA/C (since the Apple label carries quite a
punch). As it stands right now, we don't have a PUBLIC answer to what
we're doing about C for the IIGS.
I will state though that when the new version of ORCA/C (1.1) ships, if it
meets your needs, then go with it! There's nothing wrong with using third
party tools! :-)
<[Jeff] J.HOLCOMB1> Ok, well it doesn't, I find Orca/C to be too slow
compiling. I'm done.
<[ Dave ] A2.DAVE> Tim, could you give us an idea what bug fixes have been
made, and also what documentation os available on the release disk to cover
what is missed with a new manual?
<TIM.SWIHART> Hmm, LinkIIGS had a lot of problems supporting the output of
ORCA/Pascal and ORCA/C. It was NOT the fault of either of those ORCA
products. They both push the OMF to the limits and they caught us looking
the other way. :-( I found a few hard core developers using ORCA around
the world (one of them is in Australia) and they helped us get the kinks out.
MakeLib has been vastly updated - it too had some problems. Duplicate's "-m"
option was taken off and the target file spec is now optional. All of the
C-based tools have a better CLib beneath them. etc.
The "new" manual is simply the old quasi-manual turned into a cohesive
manual. The pages were cleaned up - errors eliminated, the pages are
numbered consecutively, etc. That's part of the reason why the update
version does NOT include the manual - there just isn't enough different
in the new manual to be worth the extra $$ to customers.
Since it does have a complete manual, and it has been fully tested, we were
able to release it as a Class 1 product instead of as a Class 2 product
(where the older package is). That increases the availablity of these tools.
The number of bug fixes alone is worth the update cost!
<[ Dave ] A2.DAVE> Do the new tools support the console driver that we are
supposed to use when APW 2.0 finally arrives?
<TIM.SWIHART> Some of them already support some of the new shell features and
some don't. We expect to have to revise them when the shell is finally done
and we did NOT want to hold back these bug fixes until then. The real problem
here is that the I/O redirection model of the new shell is different from
that of the current shell.
The new shell uses the console driver and the old one uses the text tools.
Ideally, this should be TRANSPARENT to utilities. "Old" tools should still
work under the new shell, when they send stuff to the text tools, it gets
intercepted are re-routed to the console driver. That means a slight hit on
performance, but the new tools should work under the 2.0 shell.
The revision we expect to do would change the I/O redirection model used so
that the tools would then ONLY work under the 2.0 shell (but would use the
console driver instead of being re-routed). At the same time, we would fix
whatever bugs come up along the way.
<[ Dave ] A2.DAVE> Since the 2.0 shell has come up, can we expect to see this
new shell in this calender year?
<TIM.SWIHART> The second part is the shell, editor, assembler, command line
linker (not LinkIIGS), and MacGen. Those of you who looked closely at what
I listed as the Apple part should have recognized that list as the contents
of the "APW Tools & Interfaces" package. (if you didn't scroll back now and
recognize them) :-)
Since the shell wasn't ready last summer and developers NEEDED a way to start
using resources, ExpressLoader, OMf 2.0, etc, I (with some help from the rest
of the team) came up with the idea of putting Apple's part into a new product
("Programming Tools & Interfaces for APW") and shipping them immediately.
That's why the manual for the current version looks a little "hacked" - we
grabbed just the pieces of the APW 2.0 manual that talked about the new
tools. We didn't ship the entire manual because that would drive the
package's price up (more paper = more $$) and because I personally didn't
see any reason to "kill trees" just to document something you couldn't use yet.
Well, time marched on, tons of bugs were fixed in the tools, and sales of this
tools package have been pretty good. We were once again at a cross roads.
The shell/editor/assembler/linker wasn't ready to be released, but our tools
were. After a _LOT_ of thought, I put together a proposal. It was circulated
to ALL of the appropriate folks - DTS, Apple II engineering, the development
tools engineers, tech pubs, evanelism, etc. Their feedback was incorporated
that the proposal was changed to reflect this.
The end result was: The "temporary" product ("Programming Tools & Interfaces
for APW") would become a permanent product. It's manual would be cleaned up
into a complete manual. The bugs would be fixed so that this could be a
Class 1 product and the tools would NOT be put back into the APW 2.0 package-
they would stay separate.
This left APW 2.0 as strictly the shell, editor, assembler, command line
linker (not ZapLink or LinkIIGS), and MacGen.
Further consideration was given to the situation.
APW 2.0 had become simply ORCA 2.0 with an Apple sticker on it. We looked
back in time at the history of APW and saw that it was difficult for us to
update the portions of this product that Apple didn't write (contracts
involved, etc). We also saw that the Byte Works had done a better job of
updating the product, had better distribution (general mail order vs only
APDA), and still people TODAY were buying the Apple version (APW 1.0.2)
instead of ORCA 1.1 (which is newer, lower cost, faster, and has fewer bugs).
We took a bold (and INCREDIBLY DIFFICULT) step.
We decided that the new shell, editor, etc would NOT ship with an Apple
sticker on it. Instead, it would be available only from the Byte Works as
ORCA 2.0.
This was NOT an easy decision!!! Nor does it mean we're giving up on native
tools!
For a long time now, we've been playing a "me too" game when it came to our
development tools. Because APW had the Apple label behind it, customers
would chose it over the newer ORCA 1.1. Once APW 2.0 started shipping, ORCA
2.0 would come out with a different features set. ORCA would have ZapLink,
APW wouldn't. Byte Works had other things they wanted in ORCA 2.0 that we
preferred to have in 2.1 or 2.2 (so we could get 2.0 out the door) or because
we didn't want to finance some of those features.
Since APW is done under contract, we "provide incentives" to make things
happen. That means we'd have to absorb the development cost of features
we didn't want (or didn't want yet) or else live with the confusion of having
two similar products with some different features - which do you get? The
Apple one or the one with more features?
So, we did what we felt had to be done - end the confusion.
Instead, we'll be focusing on IIGS development tool solutions that allow us
to introduce "significant value" to the marketplace. Rez is an excellent
example of that - since last September, Rez has provided a way for IIGS
developers to create and use resources in their apps. It's only been VERY
recently that alternatives to Rez have shown up and still, Rez holds its own
<TIM.SWIHART> among them (such as providing a way to merge multiple resource
forks into one, etc).
<TIM.SWIHART> That pretty much sums up the overview part - this information
was announced outside of Apple for the first time during the recent WorldWide
Developers Conference (May 7-11) and this RTC is the first time it's been
"publicly" announced.
I'm sure this leaves all of you with a ton of questions. Let's get back to
the Q&A so we can tackle them.
<A2PRO.ERIC> Okay!!!! Dave, anything further you wanted to ASK? <grin>
<[ Dave ] A2.DAVE> Thanks Tim, on that note I surrender the floor.
<A2PRO.ERIC> Mark, you're next.
<[Mark] A2.MARK.C> Tim... let me get this straight. Apple is no longer
working on Native development tools for the Apple II. Only Macintosh based
tools or ports thereof like LinkIIGS or Rez/DeRez. Please tell/show me
I'n not correct here!!!
<TIM.SWIHART> Mark - you misread me! We're not doing native development
ENVIRONMENTS! There is a LARGE difference! The newly released "APW Tools
& Interfaces" is part of our continuing commitment to native developers.
Futher native tools will be showing up soon in the form of a MUCH more
powerful version of GSBug and in the form of some tools that we're currently
providing only to partners via the developer CD.
<[Mark] A2.MARK.C> Does that mean you are supporting OTHERS... like, say,
Merlin? Or only ORCA?
<TIM.SWIHART> That drags us right back into the "me too" solutions we're
trying to move away from.
<[Mark] A2.MARK.C> OK... can you tell us anything about any more up and coming
solutions now?
<TIM.SWIHART> Mark - I'm not real hot on talking about some of what we're
looking at for the long term. We're regrouping now and will have more news
coming, when the timing is beter. GSBug willbe our next big release. After
that isn't public yet. :-)
<[Mark] A2.MARK.C> Ok... I'm sure you expected to hear a bit of disappointment
here tonight... (I was one of the regular APW upgraders... since I got CPW
originally... never got ORCA... yet...) Oh well... Thanks, Tim.
<TIM.SWIHART> Mark - I'm disappointed also, this was a VERY hard decision to
make, but if we're really going to move forward, we HAVE to do it.
<[GS Worrier] LAZ> Tim, once in a while a rank amateur, such as myself, sneaks
in here to see what's happening with the pros. It gets real confusing, as
there doesn't seem to be a good way to learn how to use this stuff without
paying some bright lad to tutor us. Are there plans in the works for some
type of bootstrap method of learning to program this bugger?
<TIM.SWIHART> Laz, have you read the "Programmer's Introduction to the Apple
IIGS"? It explains what an event loop is, how the desktop works, how to
support desk accessories, how to create menus, etc. It includes source code
to a complete IIGS application in all three of the most popular IIGS languages
(C, Pascal, and Asm). It sounds like exactly what you're after.
<[Mark] A2.MARK.C> !
<[GS Worrier] LAZ> Nope. I don't know a thing about programming. I barely
know how to spell basic, and haven't cut my teeth on Pascal yet. I know about
the courses offered on here, but some of us can't afford the prices these
things run. Guess I'm just being a bit grumpy. I get lost everytime I look
at a piece of source code.
<[Mark] A2.MARK.C> Not so much a comment as a question... will Programmers
Intro be revised to reflect the changes/power of System 5.0+?
<TIM.SWIHART> Mark - let's tackle that one in a second... Laz - The book
should help you quite a bit, but first you may want to drop by A2U (here on
GEnie) and take one of their intro to programming classes!
<A2PRO.ERIC> It's _free_!
<TIM.SWIHART> Many people in positions just like yours have used A2U as their
ticket to enlightment.
<[GS Worrier] LAZ> Except for the on-line time :)
<TIM.SWIHART> I recommend it.
<TIM.SWIHART> Mark - Gary Little is the one to ask about updating Programmer's
Intro to use resources. He's in charge of all such books and I'm not sure
what's he planning long term. You're much better off asking him.
<A2PRO.ERIC> Laz, anything else you wanted to add?
<[GS Worrier] LAZ> nope. I'm just wishing I understood everything going on.
<[Rio] M.ARGYROS4> Tim : Please Answer Yes or No ... to the Following
Questions... Unless Otherwise SPECIFIED. 1) Can we Expect an Update to
The TExt Edit Tool !
<TIM.SWIHART> Yes.
<[Rio] M.ARGYROS4> 2) When (a Date) ...
<TIM.SWIHART> No date! I do development tools, not System Software.
<[ Matt ] M.DEATHERAGE> !
<A2PRO.ERIC> GA Matt with a comment!
<TIM.SWIHART> I don't have the authority to commit the System Software group
to deadlines like you're asking about.
<[ Matt ] M.DEATHERAGE> There will be more system software, and when it
arrives (which we normally don't pre-announce), it will contain bug fixes
and enhancements, just like always. There will eventually be system
software with new tools and capabilities, also.
<[Rio] M.ARGYROS4> 3) Has There been any Discussion about a System Software
Update!
<A2PRO.ERIC> Tim or Matt...
<TIM.SWIHART> Rio - see Matt Deatherage's last comment. :-)
<[Rio] M.ARGYROS4> OKAY ..
<[Rio] M.ARGYROS4> Tim , How can a developer obtain information about OMF,
Linkers, Compiler's and their Respective formats that Apple chooses to use?
Besides the stuff in The REF's?
<TIM.SWIHART> Let's see... OMF is described in an appendix to the APW manual
and I _think_ it's in the GS/OS volume 2 (not very sure on that one)
<[ Matt ] M.DEATHERAGE> Yup. It's also in the ProDOS 16 Reference, if you
happen to have one.
<TIM.SWIHART> The OMF spec is pretty much all you need. It tells you what
compilers put out and what linkers take in. I've been assured that it is
in GS/OS ref #2. If you're trying to write your own compiler, then the APW
manual is what you're after.
<[Rio] M.ARGYROS4> APW, huh.. I Can get that Thru APDA (Yes/No) How Much?
<TIM.SWIHART> Yes, $100. You can also get it through Developer Tools Express
which simply means you can order APW without joining APDA. You should be able
to find the same info in the ORCA shell manual and it's available mail order
for about $40.
<[Rio] M.ARGYROS4> Tim, Thanks.
<A2PRO.ERIC> Next up, Bryan Pietrzak.
<BRYAN.ZAK> Ok, back to the death of APW...
<TIM.SWIHART> ouch!
<BRYAN.ZAK> What happens to developing on the GS if ByteWorks goes out of
business? I don't like Apple being dependant on a third party.
<TIM.SWIHART> OK, first of all, APW isn't "dead" it's just shipping from The
Byte Works not Apple. The contents/capabilities are still intact. I don't
like being dependant on third parties for our tools either. As a short term
solution, it's ok.
But for a long term solution, using third parties for Apple-labeled tools
doesn't work. APW 2.0 was down to just the third party version and it was no
longer a short term solution.
If the Byte Works "disappeared", we'd have to do something else. Currently, I
don't expect them to vanish. :-)
<BRYAN.ZAK> Why does Apple with all their resources force developers to be
dependant an a small, eratic company like Byteworks. A company that has a
history of blowing release dates. This really slows things down for us. I
can't understand why Apple won't develop a desktop environment.
<TIM.SWIHART> Bryan - Apple's vast resources are split among a LOT of
projects. Should we have pulled an engineer off of the 5.0 development
team to do compilers? Would you trade a Resource Manager for yet another
development environment? In the real world, head count is FINITE and the
number of projects worth doing is infinite.
That measn some things can't be done.
Would yet another development environment really add significant value?
Or would it add confusion?
<[Mark] A2.MARK.C> !
<TIM.SWIHART> Should tool writers suddenly embrace a new environment or would
they stick with what they have?
What about source code compatibility? If we had to do our own native
assembler, it would use the same syntax as the MPW IIGS Assembler, not that
of APW's asm.
Would that truly move the IIGS forward?
<BRYAN.ZAK> Tim, how many employees does ByteWorks have - not many - you mean
Apple couldn't afford 5 programmers for APW 2.0? What good are future OS if I
can't write a program for it efficiently? Let me answer your questions...
If you released a new assembler that was _fast_ and _powerful_ I'd learn its
syntax - period.
I guess to me, it just shows/proves Apple's lack of commitment to the IIgs -
I am _very_ disappointed.
<TIM.SWIHART> First off, APW 2.0 already had OVER 5 engineers, so it's an
issue of 5 MORE that you're really asking. The staffing at Apple is the
reason Apple's part was done before the Byte Works' part. You should
understand that APW is a clone of ORCA, not the other way around. The Byte
Works owns the source code (for all practical purposes), not us.
When changes are needed to the shell/editor/assembler/etc, we negotiate a
contract with them, get it signed off, and get work under way. Along the
way, other things come up that they HAVE to address.
<[A2U Guy] A2.JAY> !
<TIM.SWIHART> Being dependant on a small company was holding us back. In
the short term, it definitely looks like a bad thing. If we're in this for
the LONG term, then there are some ugly things we HAVE to do NOW in order
to last until the future gets here.
This was not a casual decision, it was not made by one person, it was not
an easy thing to do, but it was the only thing to do if we're going to move
forward with IIGS development.
I've known about this for some time, but I still worked hard to get developers
using the tools that ARE available now - i.e.: the Rez tutorial, etc.
I'm sorry you feel this was the wrong decision to make, but there's no way
in the course of an online conference that I can explain all of the background
that went into the decision making process.
<[A2U Guy] A2.JAY> I'm a (new) fan of cross development, but I'd rather see
Apple work on native tools than xdev tools. Seems like the engineers could
have come from the MPW IIgs pool. Stop work on MPW IIgs until you get native
tools where they should be.
<[A2U Guy] A2.JAY> If Shawn Quick can create a complete environment/assembler
in a few months it seems like Apple could do the same. <comment done>
<[andy] SHRINKIT> ! But shawn isn't done, is he?
<[burnt pizza] C.MCKINSEY> Close enough.
<A2PRO.ERIC> Okay.
<BRYAN.ZAK> Ok, Tim, I understand the Apple/Byteworks situation, and I know
your feelings on it (at least I think I do :-) Ok, what _is_ the long term
picture? Is Apple going to do demand that we all use MPW IIgs?
<TIM.SWIHART> MPW IIGS is positioned as an INDUSTRIAL STRENGTH solution! It
is NOT positioned as something ALL IIGS developers are expected to use. (I
haven't seen Shawn's environment SHIP yet) :-)
<[burnt pizza] C.MCKINSEY> (You will at KansasFest)
<[A2U Guy] A2.JAY> (But he's working on it which is more than Apple is
doing.)
<TIM.SWIHART> We will continue to support native development and our native
development tools.
<A2PRO.ERIC> (okay okay, Tim has the floor, guys)
<[ Matt ] M.DEATHERAGE> !
<TIM.SWIHART> Our focus will be on areas where we can add SIGNIFICANT value
to the development community, not just another thing that there are already
a bunch of. Some of the new things we'll be doing will be introduced first
in the MPW IIGS environment (where we can piggyback off of the MPW Team's
efforts) and some of it will ONLY be available in that environment - because
of the amount of effort needed to bring it over.
Some of the future stuff will NEED the MPW shell and the only way to bring
those things over to a native IIGS tool would be to bring over the entire MPW
shell - I'm not convinced that the sheer effort required to do that is the
best use of our resources.
<TIM.SWIHART> I've already told you about some of what's coming in the next
release of MPW. One of the other things they're introducing is an online
help system that covers the complete toolbox and OS - neatly integrated into
the MPW environment. They implemented it in a way that lets me convert it to
support MPW IIGS (toolbox and GS/OS) just as nicely as it supports the Mac.
<[Tyler] A2.TYLER> Why does this sound like the old Apple Push, "BUY A MAC?"
<TIM.SWIHART> Tyler - nice try, but no go. There are high end solutions
that we can bring into existance FASTER by piggybacking off of MPW. There's
nothing wrong with using a Mac to write IIGS software - I like to think of it
as a great use of a Mac. :-)
The solutions I'm talking about are not aimed at the developers who haven't
even bought the Toolbox Reference Manual. We're aiming at the folks that are
trying to do everything they can to reduce their time to market (you may
remember I went into the issue of time to market in the last RTC I did here).
I can go into them again if you want. :-0
<A2PRO.ERIC> Matt, comment?
<[ Matt ] M.DEATHERAGE> Jay:
<[A2U Guy] A2.JAY> Yes?
<[ Matt ] M.DEATHERAGE> You're as up on the rumors/announcements concerning
APW 2.0 as anyone else (outside Apple or ByteWorks, naturally) is so tell
me... what part of APW 2.0 that Apple was doing in-house are we no longer
doing now that Tim has discussed this issue tonight? What were we doing that
we said we're not doing anymore?
<[On Defense] A2.JAY> That's not the point. The point is that Apple has now
stated that Mac tools (even if they are for the IIgs) are more important than
IIgs tools.
<[ Matt ] M.DEATHERAGE> Au contraire, mon frere. That's *precisely* the
point.
<TIM.SWIHART> Jay - whoa. Nobody's assigning "importance" here!
<[On Defense] A2.JAY> You have programmers working on MPW IIgs...but not on
APW. Thatr's assigning importance!
<[ Matt ] M.DEATHERAGE> What we're not doing is putting Apple's label on Byte
Works software which is largely confusing with no benefit. That's what we're
no longer doing.
<TIM.SWIHART> Jay - nonsense. We DO have programmers working on APW tools.
<[On Defense] A2.JAY> Okay, get ByteWorks OUT of the loop...and do your OWN
thing!
<TIM.SWIHART> We've NEVER had programmers working on the shell/editor/
assembler.
<[On Defense] A2.JAY> I can see your point...
<TIM.SWIHART> In fact, the APW versions are usually done by the same engineer
that did the MPW IIGS version.
<[On Defense] A2.JAY> ...but the fact remains that we have to rely on 3rd
party people for a native develkopment environment...and I don't think we
should.
<TIM.SWIHART> By removing APW from the table of offerings for developers,
we're trying to reduce the confusion which stagnates the market.
<[andy] SHRINKIT> ! but we did BEFORE.. what's new about relying on a third
party?
<TIM.SWIHART> Jay - the development environment ALWAYS came from a third
party. It's just going to ship from them now as well.
<[On Defense] A2.JAY> Competition stagnates the market? Variety stagnates the
market? Hmmm... Okay.
<TIM.SWIHART> That's where we hope to end the confusion. Right now, we're
just middlemen helping set what goes into the product and then putting our
sticker on it. Not a lot of value being added if you really look at it.
Jay - you're misreading what I posted. If you total it all up, ORCA is
already ahead, but developers still buy APW.
<[ Matt ] M.DEATHERAGE> ORCA has switch and compress, APW almost doesn't.
<TIM.SWIHART> Dennis - correct. That takes us back to an answer I sent Bryan
several screens ago. If the Byte Works vanished, we would have to have a
different strategy.
<A2PRO.ERIC> Okay... Tim, you still have the floor.
<TIM.SWIHART> One of the BIG reasons we're supporting MPW IIGS for the future
is that we _OWN_ the total environment.
<[On Defense] A2.JAY> Did you write it from scratch?
<TIM.SWIHART> When we want a change, we can make it happen. With a contracted
tool, it's HARD to make changes.
<[On Defense] A2.JAY> Never mind...I'm done. Thanks for the flurry, Tim. =:^)
<TIM.SWIHART> Jay - _I_ didn't. :-) Owning the environment means WE control
its destiny. Trying to control the long term destiny of someone else's
product has not worked. The Byte Works is NOT the only place that using a
third party for the long term has slowed us down. APW C is in essentially
the same predicament.
If I can't reduce the confusion now, I can't focus for the future.
<[ Matt ] M.DEATHERAGE> !
<TIM.SWIHART> Which do you want in the long term - an Apple label on a bunch
of third party tools or something that's REALLY from Apple?
<A2PRO.ERIC> Okay.... Matt, quick comment?
<[ Matt ] M.DEATHERAGE> It's really obvious to Tim and I on the front lines
of developerness (?) that people get confused by APW/ORCA because APW has
Apple's name on it. They assume that there really are underlying reasons
for APW because if ORCA was better, Apple would have published it. Before I
came to Apple, I was REALLY suspicious of ORCA since it claimed to do the
same stuff in 512K, and I thought there had to be compromises. It turns out
only to have been a scriptable linker, which I didn't need anyway. I would
have been better off with ORCA but I wouldn't believe it. Hopefully this
move, painful though it *seems*, will strengthen everyone's position. If
you don't think that needs to happen, just look at Tim who's undoubtedly
nodding his head at all this.
<A2PRO.ERIC> Okay. Thanks Matt. Bryan, you're still up, thank you for being
patient :)
<BRYAN.ZAK> Ok, (last question) bottom line: What is the long term strategy?
Will we see tools/shells written in 65c816 for the GS - NOT THE MAC - I CANNOT
AFFORD A 7,000 dollar environment - I want a GS environment - period.
<TIM.SWIHART> <nod nod nod> Bryan - the entire long term strategy is not
complete. I'm not willing to commit Apple to something that we may or may
not be considering right now. I don't like dodging like that but I have to.
I KNOW the investment in a Mac for cross development is NOT trivial. I also
know that commercial developers CAN recover the investment (and then some)
over the course of their development.
I've stated many times (and will do so again) that we will provide IIGS tools
where we can provide significant value. That applies to both the native and
the cross development environments. The native environment already has an
ANSI C, would adding one with an Apple label really add much value?
<TIM.SWIHART> The MPW IIGS environment has only a K&R C - adding an ANSI C
there would add quite a bit of value (no that's NOT a product annoucement,
it's an example) :-)
As we get closer to delivering new products, or updates to existing ones,
you'll hear more official news.
<BRYAN.ZAK> Ok, I think my point/concern is with ByteWorks, not Apple - I
don't think I can depend on Byteworks to deliver fast compilers on time. (Boy
I hope Mike doesn't see this :-) Ok, I'm done. Thanks Tim.
<TIM.SWIHART> Bryan, The Byte Works just delivered a MUCH faster linker - I
take that as a sign that they know how important the speed issue is and will
address it in the future. The real decision is up to Mike Westerfield of
course.
<A2PRO.ERIC> Okay John, you're up.
<J.W.BAXTER> Comment, then change-of-pace question...I was alarmed when I saw
the BYTEWORKS signature in the first-release of APW... given where we wound up
so far (APW = obsolete ORCA), I think it will turn out that Apple is making the
best of the situation. Now, real tough question, TIm...what did you do during
Life before Apple?
<[Mark] A2.MARK.C> He was an A2Pro Sysop...
<TIM.SWIHART> there's life before Apple? :-)
<A2PRO.ERIC> Wayyyyyyyyyyy back when :)
<TIM.SWIHART> I was the lead avionics test engineer on a research project at
General Dynamics. I also served (for about two years) as a sysop here in A2Pro
(Bill Mensch was my first guest). I also wrote software in my spare time (and
articles) GD taught me how to dodge high speed projectiles (thanks Jay)
:-) I've used just about evry development tool out there. I've had articles
published around the world (Italy). I've written tutorials, shareware, and
freeware. So, I wrote a script that did all the steps to make it easier.
:-)
<J.W.BAXTER> Thanks, Tim...impressive background. Sorry I stepped on that
last comment of yours about Mikes new linker. .a .b ... files were always
one of my peeves with APW.
<A2PRO.ERIC> Dave, you're next.
<[ Dave ] A2.DAVE> Tim, I'd just like to start with a comment. I believe that
the long term success of the GS is tied to a quality native mode environment.
So far, we don't REALLY have it. The little guys make the market keep moving
with Freeware and shareware stuff while waiting on the long term projects. I
know the commercial companies can afford x-dev systems, but the little guys
can't. Please keep this in mind. I also think a lot of little guys get ironed
out? It would be nice to use both and it's currently a mess.
<TIM.SWIHART> Dave - part of the problem of switching between the two is that
ORCA/C supports prototyped functions and procedures (a VERY powerful
feature!!!) and APW C does not. That makes it a REAL pain to move back and
forth between the two. What other specific problems are YOU having in moving
between them?
<[ Dave ] A2.DAVE> Well, for one the libraries are a real pain. I have a
bunch of commands set up to rename and copy things all over the place...
<TIM.SWIHART> Instead of renaming and copying, why not set up two aliases that
simply change the value of prefix 2?
<[ Dave ] A2.DAVE> and currently Tool Box prototyping is still non existant in
Orca so ANSI compatability is not a big pain.
<TIM.SWIHART> then keep the APW C libraries in one folder and the ORCA ones in
the other. The aliases let you quickly toggle between library folders. The
only other problem is that APW C uses Start.Root and ORCA doesn't. That can
be tackled by using real fancy scripting for your MAKE file (not pretty, but
effective)
<[ Dave ] A2.DAVE> Ok, how about the compiler names, they are both the same
with different language numbers.
<TIM.SWIHART> Dave - according to the file type note for Byte Works' C, it
should NOT be named CC. I pointed this out during the beta test phase and
was told it would not change.
<[ Dave ] A2.DAVE> Tell that to Mike. It is.
<TIM.SWIHART> I pointed it out for exactly the reason it bugs you - two
languages with the same name.
<[ Matt ] M.DEATHERAGE> You can install it with a different name and the same
number and it will work just fine.
<[ Dennis ] A2-CENTRAL> !
<[ Matt ] M.DEATHERAGE> I personally have one as CC and one as APWC. No
problems yet.
<TIM.SWIHART> I believe it SHOLD have been called BWC (for Byte Works C).
<[ Dennis ] A2-CENTRAL> (Never mind...what Matt said. That's what I have set
up.)
<TIM.SWIHART> I set mine up as CC and BWC. :-P :-)
<[ Dave ] A2.DAVE> I have OC and AC, but that's not the point. I think if
Apple is giving up the shell, then you should work closely with the third
party to makes sure everything is well integrated. Yes?
<TIM.SWIHART> Dave - I tried working closely with the third party BEFORE the
confusion existed and was ignored. I'm not sure how I could get them to
listen now. I'd love to work more closely with the third parties, but it's
a two-way street. I can't make them work with us and when they choose to
ignore me, I'm not going to break all existing scripts by renaming my products.
If you have any specific ideas, I'm all ears!!!
<[ Dave ] A2.DAVE> Thanks Tim, I appreciate that. I am crying to the wrong
person here, so sorry.
<TIM.SWIHART> (that's part of the confusion we're trying to end - who's
responsible for what) :-)
<A2PRO.ERIC> Mark, you're up now.
<[Mark] A2.MARK.C> Tim... a bit ago you more or less inferred that APW shell,
etc. are being essentially superceded by Orca...
<A2PRO.ERIC> Mark, you're up now.
<[Mark] A2.MARK.C> Tim... a bit ago you more or less inferred that APW
shell, etc. are being essentially superseded by Orca... yet, a little
while ago, you told RIO to buy APW from APDA for $100... in my business,
that's like selling rustproofing on a Corvette (Fiberglass body, remember).
What gives?
<TIM.SWIHART> Mark - APW's manual has some info in it that's not in the ORCA
manuals. He was after that info. I also pointed out that much of the info
he sought IS in the ORCA manual. That left him to decide where he goes for
his info. Does that answer your question?
<[Mark] A2.MARK.C> Yes, but I have another. Also above you started to seem
to imply that if one was serious about programming for any Apple Computer,
including the IIGS, one had better be using MPW and a Mac... Is that the
impression you are really trying to leave?
<TIM.SWIHART> No!!!!!!!!! :-)
<[Mark] A2.MARK.C> Please elucidate.
<TIM.SWIHART> BOTH native and cross development are supported. In the
future, SOME of what we'll be doing that's new will appear FIRST under MPW
IIGS, then under the native shell and some of it will only be available for
MPW IIGS (due to hard requirements for MPW shell-specific things). We're
not "abandoning" native developers (just in case some of you were STILL
wondering).
<TIM.SWIHART> We're positioning ourselves for the future and that requires
some hard decisions in the present.
<[Mark] A2.MARK.C> One more question... will you continue to release
interfaces for Assembly, C AND PASCAL as you have to date in the current
packages with the advent of new Systems... (Personally thinking of TML
Pascal's compat with the interfaces)
<TIM.SWIHART> Not shipping APW as an Apple product was a VERY hard decision
and we had to consider at great length the potential for negative backlash
from the developer community.
Mark - the new APW Tools & Interfaces package includes revised interfaces
for APW C and APW assembler. That should answer your question with deeds as
well as words. :-)
<[Mark] A2.MARK.C> So, you're saying No to Pascal?
<TIM.SWIHART> I've already shipped Pascal interfaces to The Byte Works (they
need some work on them) and should soon be sending TML theirs. (that should
answer your Pascal interface question) :-0
<[Mark] A2.MARK.C> But... if TML's current level of IIGS support continues...
and Byte Works continues to ignore your interfaces... What do we do?
<TIM.SWIHART> Mark - I'm already trying to set up an independant third party
to do the extra work on the Byte Works interfaces for them. If Mike
Westerfield won't ship them, we'll put them in the package that's licensable
for electronic distribution and get them on the nets. :-)
<[Mark] A2.MARK.C> Is it possible to purchase the MPW GS-Pascal interfaces?
B-) THANKS!
<TIM.SWIHART> Mark - the MPW IIGS Pascal interfaces are part of the MPW IIGS
Pascal package. They can however be licensed for electronic distribution
from our software licensing dept. That gives you two ways to get them (three
if the nets license them) :-0
<A2PRO.ERIC> Next up.. Dennis!
<[ Dennis ] A2-CENTRAL> A few questions...first, you implied that APW C may
also revert to the supplier. Any idea if it will be supported (if that's a
correct assumption?)?
<TIM.SWIHART> Dennis - We're NOT planning on turning APW C back over to
MegaMax (the folks that did it for us). As for support for it, we've
rewritten CLib (at least the time critical portions) in Assembly and are
still shaking it out. I'm looking for the "right way" to release it so that
current customers can benefit from the new library (the current library is
a real problem).
As for the compiler itself, it's sort of in limbo right now. We're not
aggressively doing anything other than CLib work because all of our
development tools engineers are pre-occupied with other tool project.
<[ Dennis ] A2-CENTRAL> OK...sorry I misunderstood about it reverting to
Megamax. The next is more an observation than a question: I was at a
science fiction convention this weekend where an Amiga dealer was
_ACTIVELY_ promoting the machine, including trying to woo new developers.
Just as a general question, has Apple (or you specifically) been checking
into competitor's activities while determining strategies for Apple?
<TIM.SWIHART> Dennis - I'm aware of some of what our competitors are up to,
but not everything.
<[ Dennis ] A2-CENTRAL> That's all I have (given that the last question kind
of fizzled :).
<A2PRO.ERIC> Next up... S.Sanders4.
<S.SANDERS4> I am a VERY small developer that would like to program for both
the GS and the Mac. I want to program in either Pascal or C. What is my best
bet? I am currently using TML Pascal v1.50a only for the GS. (It works very
well)
<TIM.SWIHART> Hmmm, you've got two choices here. You can continue to use TML
Pascal 1.5 on your IIGS for the IIGS version or you can move to MPW IIGS
Pascal (since you need a Mac anyways to do the Mac version). :-) For the
Mac version, you can use Think Pascal (from Symantec) or MPW Pascal.
<BRYAN.ZAK> Think is nice
<TIM.SWIHART> There are two other Pascals for the Mac that I know of - TML
Pascal and Borland's Turbo Pascal. Turbo Pascal is WAY overdue for an
update and they're not doing one (as far as I know). TML Pascal runs under
the MPW shell.
<[Mark] A2.MARK.C> Just tell Kahn that Microsoft is coming out with one...
B-)
<TIM.SWIHART> If you're picking a Pascal for use with MPW, I suggest Apple's.
Why? MPW IIGS Pascal was created by merging the front end of MPW Pascal with
a 65816 code generator. That makes MPW Pascal and MPW IIGS Pascal as close
to identical as possible. The combo of MPW Pascal and MPW IIGS Pascal will
let you directly benefit from the parallel/porting examples that one of our
DTS guys is working on.
<TIM.SWIHART> er, I've been corrected...<sigh> The porting/parallel stuff
is in C. But you could convert it to Pascal. :-)
<[Greg] G.BRANCHE1> !
<S.SANDERS4> I have a Mac SE with a 20 Meg HD, can I work with that? Is there
any way I could write one set of code that would compile (seperatly) on both
machines?
<TIM.SWIHART> Anyways, the REAL point is that if you're TRYING to target two
machines, doing it from within ONE environment makes good sense.
<A2PRO.ERIC> Greg, you had a comment?
<[Greg] G.BRANCHE1> Yup
<TIM.SWIHART> The DTS samples are intended to be ONE set of code (using
conditional compiles) that generate both a Mac and a IIGS version of the app.
<[Greg] G.BRANCHE1> Actually, Pascal is probably better for parallel
development, due to its stronger type checking (I can't believe I'm actually
endorsing Pascal) ;-)
<A2PRO.ERIC> Okay, Tim, did you want to add anything?
<TIM.SWIHART> Yes. If at all possible, use one environment (you'll be more
productive in the long run). A Mac SE with a hard drive is "sufficient" to
run MPW if you've got 2 megs of RAM. We urge developers to move to one of
the 020 or 030 machines IF POSSIBLE (not required) because they offer more
"elbow room" for MPW to work in.
<S.SANDERS4> Thanks Very Much.
<BRYAN.ZAK> Ok, will we ever see the equivalent (or close to it) of MPW IIgs
as a native enviroment? Even though it would be a tremendous undertaking.
<TIM.SWIHART> Bryan - I'm not sure. I know that's not the answer you wanted
to hear, but it's the only REALISTIC answer I have right now.
<BRYAN.ZAK> (I expected something like that :-)
<TIM.SWIHART> That's certainly something that's been suggested, but the
value of doing it is what we'd have to look at before agreeing to do it.
We'd also have to look at what we couldn't do as a result of dedicating
those resources.
<BRYAN.ZAK> Ok, Tim, I'm done.
<A2PRO.ERIC> Next up, Jay A. Thanks for waiting.
<[Jay] J.ADELSON1> I'm currently developing a software package in TML Pascal
II, which I'm considering porting to C for certain advantages of C over
Pascal. I've hesitated because I'm concerned that I wouldn't have the
advantages of a resource editor in the C environment. Does APW C contain a
resouce editor? And what sort of resource editor (if so) does it use?
<TIM.SWIHART> Jay - APW C has been shipping since BEFORE resources were a part
of the IIGS's System Software, so it does NOT include a resource editor.
<[Mark] A2.MARK.C> And, of course, let's not forget using GENESYS...
<TIM.SWIHART> The "APW Tools & Interfaces" package includes a resource
compiler that works fine with APW C (in fact, there'
<[Mark] A2.MARK.C> Which you really NEED with TML II as well!!! <sorry>
<TIM.SWIHART> an ongoing tutorial in A2Pro's library showing how to use Rez
and APW C together.
<TIM.SWIHART> AS Mark mentioned, Rez can save your buns with TML Pascal II!!!
I've talked with MANY TML Pascal II users who have lost their entire resource
forks to a crash of TML. If you DeRez (resource decompiler) the resources you
created then you can Rez-urrect them after the crash. :-)
<A2PRO.ERIC> <groan>
<[ Matt ] M.DEATHERAGE> Shoot him now.
<TIM.SWIHART> If you want a better resource creation tool that uses the
desktop, then I suggest you look into GeneSys (from SSSi) and DesignMaster
(from Byte Works)
<[Jay] J.ADELSON1> In a sense, does that mean I can port my TML II resources
to APW C with the tools and utilities?
<TIM.SWIHART> GeneSys is already shipping and info on them can be found by
sending email to SSSi or by visiting their topic in A2Pro. Jay - Yes, you
can bring your resources over in a flash!
<[Jay] J.ADELSON1> :-)
<TIM.SWIHART> DesignMaster info can be had by dropping email to ByteWorks or
by asking in A2Pro.
<[Jay] J.ADELSON1> Well, pointers are giving me a heartache in TML II right
now...so..I'll be converting to C. Thanks Tim.
<[Mark] A2.MARK.C> OK... One last question... since Apple and your
'department', 'section' or whatever it is called is working on all these great
VALUE tools.... When can we look forward to things like SADEgs... or
GS-App (Ala MacAPP...)... etc.?
<BRYAN.ZAK> SADE?
<TIM.SWIHART> For those who aren't sure what Mark's asking about, SADE is
"Symbolic Application Debugging Environment" and it's Apple's source level
debugger for Macs. MacApp is Apple's Object Pascal application class
library. If you don't know OOP, then odds aren't you're not sure what a
class library is either.
There's already a source level debugger available for the IIGS - it's the
ORCA desktop.
<[ Dave ] A2.DAVE> Blech.
<[Mark] A2.MARK.C> Ah... but if the Interfaces are available... IT IS
available for the Mac version of TML... B-)
<TIM.SWIHART> I've had problems using it and I'm sure Mike W's well aware of
them...
<[Mark] A2.MARK.C> (OOP that is...)
<TIM.SWIHART> Which would be better - a brand new version 1.0 source level
debugger or fixing ORCA's desktop one? (it's a rhetorical question)
<[Mark] A2.MARK.C> A BRAND NEW ONE THAT WORKS!!!!!
<A2PRO.ERIC> A brand new one, with Apple's name on it
<[Was wooed] A2.JAY> =:^)
<TIM.SWIHART> AS for OOP class libraries... We'd first have to have a compiler
that supports object oriented programming (OOP) for the IIGS. There are two
main stream (in my opinion) OOP languages right now.
<BRYAN.ZAK> Tim: Does ByteWorks have the necessary resources to do all that
Appple (and us) expect of them?
<TIM.SWIHART> Object Pascal and C++. Object Pascal adds about five keywords
to the std Pascal language and is an easy to learn, but not all-powerful, OOP
language. C++ is an all-powerful language but has two big disadvantages.
First, it's a bear to learn because it has so MANY features (it helps if you
already know C). C++'s second drawback is the speed (or lack of it) in
CFront. CFront translates C++ source into C source which then gets run
through a C compiler. It is possible to have a compiler go from C++
directly to linkable code, but there are drawbacks there also (later)
The output of CFront can be either ANSI C or K&R C or, in the case of MPW
C++, it can be a token stream which gives you about a 10% speed up) CFront
on a Mac II machine is slow - real slow.
The draw back to doing a C++ "compiler" (straight from C++ to linkable code)
is that C++'s language spec is a moving target. There is NO ANSI standard
at present for C++ - we're at the "mercy" of AT&T as to what else gets added
to C++. If you do a true C++ compiler, then you run the risk of being
"broken" by a new feature which just doesn't fit in the architecture of your
compiler - do you then leave it out, losing compatibility, or redo your
compiler?
<TIM.SWIHART> By using CFront, it's easy to stay in step with AT&T (they
create CFront and license it). There are answers to the speed hit of using
CFront, but I don't think you guys are into hearing about it right now.
<[ Matt ] M.DEATHERAGE> Got that right.
<TIM.SWIHART> Before a class library could be done for the IIGS, we'd HAVE
to have either an Object Pascal (weak OOP) or a VERY ROBUST C compiler.
None of the current C compilers for the IIGS can handle the stuff that
CFront spits out. So, the answer is that the basic tools aren't in place to
deliver OOP for the IIGS at this time.
<A2PRO.ERIC> Mark, anything else???
<[ Dave ] A2.DAVE> !
<[Mark] A2.MARK.C> That's all folks!
<A2PRO.ERIC> Dave, quick comment? <grin>
<[ Dave ] A2.DAVE> Did we ever get a real answer on the debugger, or was I
asleep?
<TIM.SWIHART> There is no answer at present. :-(
<A2PRO.ERIC> Tim, closing comments>? :)
<TIM.SWIHART> Thanks for coming everybody and those of you just readin this
stuff in the transcripts for the first time can drop into A2Pro where I'm
sure there will be further discussion of some of the information I presented
here tonight. See you all online or at KansasFest. Tim S.
<A2PRO.ERIC> Thanks for coming Tim! And join us all next week.... for a
great conference with SSSi!
[many thanks to Chet Day, A2.CHET, for editing this transcript "live".]
========================= End of Transcript ==========================
Permission is hereby granted to not-for-profit user groups to reprint
this transcript in its entirety, provided that this notice is included.
To sign up for GEnie, follow these simple steps:
1. With your computer and modem, dial 1-800-638-8369.
2. When you connect, type HHH and hit the RETURN key.
3. The computer will type U#=. You respond with XJM11706,GENIE.
4. Now answer the questions and you will be able to use GEnie the next
working day. Be sure to have a credit card or checking account number
handy when you sign up.
----------------------------------------------------------------------