mjohnson@Apple.COM (Mark B. Johnson) (05/09/89)
System Overview
Q: Why is Apple talking about System 7.0?
A: Apple is discussing with developers the core technologies under
development for inclusion with the next major Macintosh System
Software release, System 7.0. Apple's goal in talking about
System 7.0 is to shorten the amount of time necessary to bring a new
generation of powerful application software to Macintosh users.
Q: Why is Apple telling the Press?
A: Apple is informing the press to explain what we're working on in
our labs, why we've chosen the paths that we have and how these
technologies will affect users and developers.
Q: What is Apple's message to users?
A: System 7.0 will extend the user's reach through an expanded set
of capabilities that utilize the same consistent, intuitive techniques
that users already know.
Q: What's in System 7.0?
A: Although the complete feature set of System 7.0 will not be announced
until later this year, the following projects will be a part of
the release:
* Virtual Memory/32-Bit Addressing
* IAC Architecture
* Outline fonts
* New Print Architecture
* Layout Manager
* Database Access Manager
* Finder 7.0
In addition, System 7.0 will integrate 32-Bit QuickDraw (introduced in April)
and the Communications Toolbox (shipping Q3).
Apple is also discussing with developers other projects currently
under development:
* Sound Manager Enhancements
* File System Enhancements
* International Text Support
* Installer 3.0
The complete feature set of System 7.0 will be announced later this year.
Q: When will System 7.0 be made available to customers?
A: Apple will announce customer availability later this year.
Q: What Macintosh computers will be able to run System 7.0?
A: System 7.0 is being designed to run on all Macintosh Plus, SE,
SE/30, II, IICX and IIX computers.
System 7.0 will require two megabytes of RAM.
68030-equipped Macintosh computers and Macintosh II computers with PMMU will
have the additional benefit of Virtual Memory.
Q: Apple says that eventually all Macintosh computers will run System 7.0.
Does that mean that all Macintosh computers will eventually be shipped
with two megabytes of RAM?
A: Not necessarily. Apple is exploring various configurations of RAM,
ROM, processor and hard disk that will support System 7.0.
Q: What does that mean?
A: The total amount of memory that a Macintosh uses for system software
is a combination of RAM and ROM. In general, when more software is put
into ROM, a Macintosh requires less RAM. In addition, for Macintosh
computers with PMMUs, the hard disk can be used to extend RAM with
virtual memory. These technologies provide for many alternative
configurations in the future.
Q: Is Apple announcing System 7.0?
A: No. Apple is making a directional statement to third-party
developers about new technologies that will be included in a
future version of Macintosh System Software.
Q: What are Apple's plans for System 7.0?
A: Apple will move the entire Macintosh product line to System 7.0.
During this transition, Apple will offer both the System 6.0
series and System 7.0 CPU configurations.
Q: How many current applications will be compatible with System 7.0?
A: Application software that conforms to the Inside Macintosh
guidelines will be compatible with System 7.0. As System 7.0 is
still in development, it is impossible to determine which
applications will be 100% compatible. When System 7.0 ships,
Apple plans to make a compatibility report publicly available.
Q: What should customers do to prepare for System 7.0?
A: There is nothing that users need to do now. In making new
purchase decisions, customers should buy the Macintosh configuration
that suits their current needs. Users and businesses that need to
make long range decisions now may want to purchases machines with two
megabytes or more of RAM today.
Q: Why will System 7.0 need two megabytes of RAM?
A: The new features of System 7.0 will require more memory than is
available in a one megabyte system to operate effectively.
Q: Where is the multitasking Macintosh Operating System?
A: The Macintosh operating system has been multitasking since the
introduction of MultiFinder. Many applications take full advantage
of MultiFinder by allowing concurrent printing, recalculating
spreadsheets, sorting databases, and downloading files.
Q: Isn't Apple now putting Macintosh users through an OS/2 experience?
A: Absolutely not. System 7.0 is an extension of today's Macintosh
System Software. Apple is designing System 7.0 to provide for
upwardly compatible applications which is a fundamental part of
the Macintosh System Software strategy. System 7.0 will allow
developers to create even more innovative Macintosh software
and hardware that extends the power of today's Macintosh.
Q: Can a Macintosh II-class machine running Apple's Virtual Memory
operate with 1 megabyte of physical RAM?
A: While this configuration may work, Apple will recommend 2
megabytes of RAM when running System 7.0.
Q: I own a Macintosh II computer with one megabyte of RAM and
I want to upgrade to System 7.0. Should I buy more RAM or an MMU?
A: RAM. The least expensive way to upgrade a one megabyte
Macintosh II to System 7.0 is to add another megabyte of RAM.
Q: Does Apple have plans to add new capabilities to the
System 6.0 series?
A: No. Users of the System 6.0 series can continue to
use their systems. The upgrade path for System 6.0 series
users is System 7.0 with more RAM.
Q: Why not?
A: Apple believes in providing consistency across our products
for our users and developers. This consistency can only be
achieved by focusing on one system software platform.
That platform is System 7.0.
Q: Does this mean that all users need to upgrade to System 7.0?
A: No, users can continue to use the System 6.0 series and their
current applications. System 7.0 and new applications software
will provide many new capabilities that many users will want.
System 7.0 offers users an opportunity to add more functionality to the
Macintosh computers they own today.
Core Technologies for System 7.0
Virtual Memory
Q: What is Virtual Memory?
A: Virtual Memory (VM) extends the user's available memory by
transparently treating the hard disk as additional RAM.
Q: Why is Virtual Memory important?
A: Virtual Memory allows users to run more applications at
once and work with larger amounts of data than they can today.
Q: Will Virtual Memory be compatible with application software?
A: Yes. Virtual Memory is backward compatible with all
applications that adhere to Inside Macintosh.
Q: Which Macintosh computers can use Virtual Memory?
A: Macintosh IIx, IIcx, and SE/30 are ready to use Virtual
Memory--no additional hardware is needed. Macintosh II can
take advantage of Virtual Memory by adding the 68851 PMMU
coprocessor onto the Macintosh II logic board (a socket is
provided on the board for this chip). This coprocessor chip
is on the Apple price list. This is the same co-processor
needed to run A/UX, Apple's version of AT&T's UNIX operating system.
Apple's 68000-based systems--Macintosh Plus and Macintosh SE--cannot
take advantage of the Virtual Memory capability of System 7.0.
Macintosh SE owners have the option of the Macintosh SE/30 logic
board upgrade to gain Virtual Memory capabilities.
Q: Why can't Macintosh Plus and Macintosh SE use Virtual Memory?
A: The 68000 microprocessor used in the Macintosh Plus and
Macintosh SE does not have the memory management hardware
necessary for Virtual Memory. This memory management
capability is one of the primary differences between the 68000 and its
successor chips.
32-Bit Addressing
Q: What is 32-Bit Addressing?
A: 32-Bit Addressing enables the Macintosh to use up to 4
gigabytes of memory. The basic software and hardware of the
Macintosh already supports the 32-Bit Addressing model.
However, Macintosh currently is limited to 8 megabytes of
memory because 32-Bit Addressing is not yet fully implemented
throughout the system.
Q: Why is 32-Bit Addressing important?
A: Macintosh users want more memory for a variety of uses.
Some just want to run more applications under MultiFinder.
Some want to use graphics software that creates multimegabyte
images. Some want to use enormous databases. And some want to
manipulate even larger word processing documents. More memory
has endless uses.
Q: So does the transition to 32-Bit Addressing mean lots of
application incompatibility?
A: No. Applications that conform with 32-Bit Addressing
guidelines ("32-Bit Clean") already run on all Macintosh
computers. These applications will immediately benefit from the
enlarged memory space with System 7.0. Applications that are
not 32-Bit Clean will continue to run under System 7.0 but will
not have the benefit of additional memory space. Apple has been
working with its third-party developers to make sure that all
application software abides by 32-Bit Cleanliness rules.
Q: What Exactly is "32-Bit Clean"?
A: Applications that follow Apple's memory manager guidelines
in Inside Macintosh are 32-Bit Clean. 32-Bit Clean applications
are both upwards and downwards compatible with 24-Bit and 32-Bit
Addressing modes. These guidelines are repeated in Technical Note #212
"The Joy of Being 32-Bit Clean."
Q: What if my existing software is not 32-Bit Clean?
A: Applications that are not 32-Bit Clean continue to run with System 7.0.
Q: Will 32-Bit Addressing become standard?
A: Yes. At some point in the future, Apple will make 32-Bit
Addressing standard on new Macintosh computers.
Q: Since much of system software is in ROM, will I need a new
ROM to get the benefits of 32-Bit Addressing?
A: Apple is researching ways of offering 32-Bit Addressing
to all Macintosh II computers. While an optional ROM upgrade
is not out of the question, other alternatives are being
considered. Apple will keep developers and customers updated
on issues relating to 32-Bit Addressing.
Q: What does 32-Bit Addressing mean for Macintosh Plus
and Macintosh SE?
A: These Macintosh computers cannot get the benefit of 32-Bit
Addressing. 32-Bit Clean and non-32-Bit Clean applications
will continue to run on these computers. Only Macintosh
computers using the 68020 or 68030 microprocessor can have
the benefit of 32-Bit Addressing.
Interapplication Communication Architecture
Q: What is Interapplication Communication Architecture?
A: Interapplication Communication Architecture (IAC) is a
framework for applications to exchange commands and data,
both locally and over networks. IAC consists of several pieces:
* Program-To-Program Communications (PPC)Qa low-level tool
for exchanging data between two programs, either locally
or across networks. PPC provides a unified, consistent
programming interface for both local and network communication.
PPC will be able to deliver messages either Immediate (IPC)
or Store-and-Forward.
* Event Manager PPCQa high-level tool for applications to
exchange commands and data. Event Manager PPC presents a
simple, natural interface to applications.
* AppleEvents(TM)Qan Apple-defined protocol of standard messages
that Applications can send to other applications. Examples
include "Open Document," "Print," "MoveWindow."
* Live Copy/Paste and Link ManagerQLive Copy/Paste gives you
live links between documents. For example, the user can
link a spreadsheet table into a word processing document;
whenever the spreadsheet changes, the word processing document is
automatically updated.
* Clipboard Copy/PasteQa current capability of Macintosh and
is also part of IAC. Macintosh applications universally
support copy and paste between applications via the Clipboard.
Q: What does Live Copy/Paste offer the user?
A: As applications begin to offer Live Copy/Paste, users will
be able to make applications work better together and avoid
repetitive copy and paste. Users can build up libraries of
commonly used objectsQlike graphics or paragraphs of textQand
link them into their documents. When you need to changethe data,
you change every occurrence of that data. And, because Live
Copy/Paste works with AppleShare(R) file servers, you can
easily share data with another person. Imagine linking in the
sales numbers from each of your sales people's spreadsheets.
Your master spreadsheet is always up-to-date.
Q: Does Live Copy/Paste work with existing applications?
A: No. Applications must be revised to take advantage of
Live Copy/Paste. Apple is simplifying the task by providing
extensive user interface guidelines and toolbox support
for Live Copy/Paste.
Apple's outline fonts
Q: What are outline fonts?
A: Outline fonts are mathematical descriptions of characters.
Sharp text at any size on any device can be generated from
outline fonts. Today, the fonts in your Macintosh are called
"bitmap" fonts. These fonts are small collections of pixels
that create the text you see on the screen. With bitmap fonts
the System File can become huge and still not have all the
fonts in all the sizes you might want.
The new Apple fonts are outline fonts.
Q: What are the benefits of outline fonts?
A: Outline fonts provide sharp text at any size on any device.
This means beautiful documents on the screen for multimedia
presentations as well as on the page from any printer. Outline fonts
also simplify the customer experience by creating a single font
standard for the Macintosh computer.
Q: This is confusing. I thought my Macintosh "Style" menu
already had a function for outline fonts.
A: It does, but that is something different. The "Outline"
option in the Style menu actually traces
the character to give it an outlined appearance. It looks like
this. It is simply a graphics trick. However, the new Apple
fonts are called outline fonts because they are based on mathematical
outlines, not bitmaps. These outline fonts are also called spline
fonts or scalable fonts. If you really want to get carried away,
keep in mind that you will be able to "Outline" the outline fonts!
Q: Do Macintosh owners need to buy PostScript fonts anymore?
A: Macintosh owners may want to buy PostScript fonts that
are not yet available in Apple's format. It is important to
remember that today's PostScript fonts, like all of the existing
Macintosh font technology, will still operate normally in the future.
For example, PostScript fonts and bitmaps will remain popular on
1MB Macintosh computers like the Plus and SE. PostScript fonts
may also remain useful in multivendor environments. We expect some
vendors will continue to offer their typefaces in PostScript format
and add the Apple format version of that typeface. However,
the Apple font format will be all most Macintosh owners really need.
Q: How many fonts will be available in the Apple format?
A: Hundreds of fonts will be available within a few months of
first shipment, and thousands soon after. It is impossible to
answer this question precisely. There are two main reasons for
this. First, since Apple's format was designed to be very flexible,
many vendors will be able to automate the conversion of their
existing library to the Apple format. Second, the open format
is available to anyone, so even small players will be
able to create new typefaces. Apple does not have to get
involved in licensing or support. Since there are hundreds
of specialized fonts now available in bitmap formats, these are
all candidates for conversion to outline.
Q: Will Apple be providing fonts in the new format? If so, how many?
A: Apple does not intend to be in the font business, so we will
offer a core set of fonts and then stop. This promotes a healthy
aftermarket for type vendors. The Apple core set will consist
roughly of the fonts Apple ships today with Macintosh computers and
LaserWriter printers, plus a small number of additions. The final
list will be announced later.
Q: Who really needs this technology? After all, LaserWriter NT
and NTX users already enjoy scalable type. Why put it into the Macintosh?
A: Today, the benefits of outline fonts are available from
Apple only through these two LaserWriter models. Now, outline
fonts will enhance the screen display, the ImageWriter II,
the AppleFax Modem, the ImageWriter LQ and the LaserWriter IISC. A
wide range of third-party output devices will also use these
fonts for best possible text quality.
Q: Does this mean that future Apple printers will not support PostScript?
A: No. Keep in mind that the existing Apple printer line
consists of both "intelligent" and "passive" printers. Where we
put the processing power is generally a price/performance decision.
Consequently, future Apple printers will support the new Apple font
format in a variety of ways. Apple is committed to maintaining
excellent system support for PostScript printing. However, our
policy is to not comment specifically on hardware products
under development.
Q: Does this mean that Apple won't be using Display PostScript?
A: Yes. But this should come as no surprise. Apple announced
over a year ago that we will be improving the internal software
of the Macintosh instead of adopting an outside language. This
removes limits from what Apple can do in software while maintaining
excellent backward compatibility. This new font format, like
32-Bit QuickDraw, demonstrates both of these benefits. At the same
time, we are committed to maintaining an excellent interface
to PostScript printers.
New Print Architecture
Q: What is New Print Architecture?
A: The New Print Architecture is designed to extend the printing
capabilities of Macintosh.
Q: What are the advantages of the the New Print Architecture?
A: There are three advantages to the New Print Architecture:
1. New features. Background printing on all printers, increased
performance, support for outline fonts, color/gray scale support,
elimination of document reformatting, and an enhanced user interface
will extend the lead the Macintosh has in printing.
2. A wide variety of new printing devices. Where in the past
it has taken years to support new printers on the Macintosh,
with the New Print Architecture it takes only a few months.
We expect to have more well integrated printers available
on Macintosh than any other computer.
3. Compatible expansion for the future. Expandability is
designed into the new print architecture. With the New Print
Architecture we expect to be able to transparently offer
new features to both the user and application.
Q: How does the New Print Architecture compare to printing in
Presentation Manager?
A: So far there are very few drivers for Presentation Manager.
With Presentation Manager, Microsoft is writing application
independent drivers for the first time. Apple has utilized
four years of experience to develop a new print architecture
that utilizes outline fonts, the Line Layout Manger, 32-Bit QuickDraw,
and other system utilities. With the New Print Architecture
the Macintosh will remain the benchmark printing platform.
Q: Is it true that all of the current printer drivers will
be incompatible with System 7.0?
A: Yes. Apple's New Print Architecture is designed to
make the creation of printer drivers easy.
When System 7.0 ships, Apple will have new printer
drivers to support all Apple output devices.
Q: Who will write replacement drivers for these devices?
A: Apple will work closely with third-party developers to
help in the creation of new printer drivers built around Apple's
New Print Architecture.
Line Layout Manager
Q: What is the Layout Manager?
A: The Layout Manager allows applications to display typographical
quality text.
Q: What are the benefits of using the Layout Manager?
A: Using the Layout Manager, applications can display sophisticated
formats like kerning, ligatures and justification for any text.
For international text systems, like Japanese or Arabic, the Layout
Manager has additional support for composed characters.
Database Access Manager
Q: What is the Database Access Manager?
A: The Database Access Manager is the Macintosh System interface
that allows applications to transparently connect to remote
databases on host computers.
Q: What benefits does this Database Access Manager give to developers?
A: The main benefit is that applications like spreadsheets, desktop
publishing, or graphics programs can now directly access host data
in a standard way regardless of the host computer and database.
Q: How does Apple's approach compare to IBM's OS/2 Extended Edition
or Microsoft's SQL Server products?
A: The Apple Data Access Manager provides standard access to
remote host databases. This is where the bulk of computerized
data is found. In contrast, the IBM product is only a local
database that resides on a single user's machine. The Microsoft
product is a local area network database requiring a dedicated
computer. Both the IBM and Microsoft database extensions are
optional. The Data Access Manager is a standard part of
Macintosh System Software.
Q: What databases does the Database Access Manager support ?
A: ORACLE, Sybase, Ingres, Informix, RDB, Vax-RMS and IBM systems.
Many other databases will be supported in the future.
Finder 7.0
Q: What's new about Finder 7.0?
A: Finder 7.0 improves the Macintosh user interface in three
important ways. First, Finder 7.0 will integrate system functions
that previously had different user interfaces into one consistent,
intuitive interface. Second, we are building in new powerful
features like a quick-find facility, document stationery
templates, aliases that will allow users to organize their
files in multiple ways, and others. Third, Finder 7.0 will
be extensible providing for the integration of new capabilities
like electronic mail and backup in the future.
Q: Will desk accessories continue to run with Finder 7.0?
A: Yes they will. In addition, because applications can now be
installed in the Apple menu like desk accessories, developers
will be able to provide users with better desk accessories. These
new desk accessories will have all the power of applications with
the instant-access features of the original desk accessories.
Q: What's the relationship of Finder to MultiFinder?
A: MultiFinder is a set of operating system capabilities
that give the Macintosh the capability to run multiple applications
concurrently (multitasking). The Finder is the system utility
software that gives Macintosh users control over their desktop.
The Finder is what you use whenever you launch (double-click)
an application, drag a file onto your hard disk, move folders
between windows, etc.
Q: How does the Finder compare to Presentation Manager or Windows?
A: Neither PM or Windows has a Finder. With these systems,
the user sees a graphic display but does not get the intuitive,
direct control over system functions that the Macintosh provides.
For example, in the Macintosh, a user can copy a file from one
disk to another by merely dragging it. In Windows or Presentation
Manager, file copy requires the user to type cryptic file names
into a dialog box and then the system does the copy. This
forces users to remember file names exactly and to remember
arcane name formatting restrictions.
Q: I have a large number of files on high-capacity hard disks.
Will the Finder 7.0 do anything to help manage files better?
A: Finder 7.0 takes advantage of a new system feature called
the Desktop Manager which can handle many more files more quickly.
In addition, the quick-find facility will allow users to access
files more quickly by automatically finding the folder a file
is stored in, opening it on the desktop, and highlighting the
file that the user seeks.
System Software Explorations
Sound Manager Enhancements
Q: What are the improved audio capabilities?
A: The audio improvements represent new functionality in the Sound
Manager including:
* a real-time sequencer
* multiple channels of simultaneous sound
* audio compression/expansion
* integration of MIDI management tools
Q: Why are these improvements so important?
A: The sound enhancements provide the foundation for more and
better audio in current applications as well as a whole new range
of applications with integrated audio capabilities.
File System Enhancements
Q: What's new in the Macintosh File System for system release 7.0?
A: Five enhancementsQFileIDs, Catalog Search, Desktop Manager,
File System Manager and B*tree ManagerQwill make the Macintosh
work smarter for users.
Q: Why are the File System Enhancements important?
A: As applications take advantage of System 7.0 features,
customers will have greater ability to organize their hard
disks and manage those drives more effectively. Applications will be
able to locate documents much more quickly and under a wide range
of search criteria.
Q: How does the Desktop Manager improve performance of
large disks?
A: Currently, desktop information (file icons and comments)
is stored in an invisible Desktop file. Because of the current
implementation, there is a limit of approximately 2,000
entries in the desktop file and, more importantly, performance
becomes sluggish long before the maximum number of entries
is reached. The new Desktop implementation
removes this size restriction and greatly improves
performance in all cases.
Installer 3.0
Q: What is the "one button Installer"?
A: The "one button Installer" is actually version 3.0 of
Apple's installation program. Installer 3.0 offers "one button"
solution to installing system software on Macintosh personal
computers. Installer 3.0 also offers complete control of the
installation process to those users who want to customize their
installation.
MultiFinder
Q: Is MultiFinder a multitasking operating system?
A: Yes. MultiFinder shares the CPU's time among a number of
applications so that a customer can work on a word processing
document while downloading a file or recalculating a spreadsheet.
In technical terms, multitasking is the ability to perform a
number of tasks concurrently. MultiFinder uses a cooperative
scheduling algorithm to run several applications concurrently.
Q: Will there continue to be a distinction between MultiFinder
and single Finder?
A: No. In System 7.0, MultiFinder will always be turned on.
Q: Why will MultiFinder always be on in System 7.0?
A: Many parts of System 7.0 depend on the functionality of
MultiFinder. As a result, MultiFinder will always be turned on.
Q: What is pre-emptive scheduling?
A: Pre-emptive scheduling is a method of allocating CPU time
among several applications that involves temporarily interrupting
each application in turn when that application has used
up its available time.
Q: Why doesn't MultiFinder offer pre-emptive scheduling?
A: Apple choose to focus on other features that we feel
are more important. Apple is looking at offering pre-emptive
scheduling in future releases of Macintosh System Software.
HyperCard
Q: Will HyperCard support System 7.0 features?
A: Future releases of HyperCard will support System 7.0. While
some features are transparently supported, others will necessitate
additional development. For instance, HyperCard will need to
be extended to take advantage of the high-level SQL calls
included in System 7.0. Likewise, support for other features
in the Live Copy/Paste will mean adding additional code. Other
features, like resolution-independent graphics and
Apple's outline fonts, are transparent to HyperCard and
will need no additional work.
Macintosh Communication Toolbox
Q: What is the Communications Toolbox?
A: The Communications Toolbox is a powerful facility that
gives the Macintosh a fundamental capability to communicate
with remote computers, providing users and applications with
consistent and extensible access to terminal emulation, data
connection, and file transfer functions.
Q: Why has Apple developed the Communications Toolbox?
A: Apple is extending the consistency and modularity that
characterize the user-interface Toolbox to the communications
environment. With the Macintosh Communications Toolbox,
Macintosh sets a new standard in empowering users and developers
to take advantage of communications.
Q: When will it be available?
A: The Macintosh Communications Toolbox will be released
to developers during the third quarter of 1989. The
Communications Toolbox will become standard system software
when released as part of System 7.0.
Q: How will users get the Communications Toolbox?
A: Apple is encouraging the third-party developers who
incorporate the Communications Toolbox into their applications
to bundle the Communications Toolbox with their application.
32-Bit QuickDraw and LaserWriter 6.0
Q: What is 32-Bit QuickDraw?
A: QuickDraw is the graphics system software, given away
in every Macintosh, that is responsible for putting objects,
icons, text, and pictures on the Macintosh display. On
68000-based machines, it supports 8 colors. Until recently,
on 68020/030 Macintosh computers, QuickDraw supported up to
256 colors. Today, extensions to QuickDraw, called "32-Bit
QuickDraw," allow QuickDraw to work with the entire range of
visible color, over 16 million colors. There is no longer
any color limitation on color Macintosh computers.
Q: How will the product be distributed?
A: Developers can license 32-Bit QuickDraw and System 6.0.3
from Apple for shipment with their products. In addition,
32-Bit QuickDraw will be distributed to all dealers, user
groups and bulletin boards typically receiving Apple System
Software. 32-Bit QuickDraw will be incorporated into System 7.0.
Q: What markets would want 32-Bit QuickDraw?
A: 32-Bit QuickDraw is especially useful in markets
demanding high-quality color. In publishing and video,
full color is useful for showing realistic images from natural
sources. For presentations, it is helpful for producing
the continuous tone "ramps" from one color to another that
are used in slides. Finally, 24-bits of color make continuous
data easier to visualize for many scientific applications.
As an enabling technology, image visualization can be expected
to open many other new markets.
Q: What are 16-bit, 24-bit and 32-bit color?
A: 16 bits of color can produce very life-like images, 24
bits per pixel is known as "full color" because with 16
million colors available, the eye loses its ability to
distinguish between color incrementally. The additional 8
bits of color that differentiate 24-bit color from 32-bit
color are usually used to store non-color information about
the pixel; for example, one of the bits could be used for
"transparency" information to allow a level of the
background to "show through" the color of a pixel. This is
known as an "alpha" byte.
Q: What is LaserWriter 6.0?
A: LaserWriter 6.0 is a new release of Apple's LaserWriter
driver. Nearly all Macintosh applications use Apple's
graphics system software, QuickDraw, to draw on and off the
screen. The LaserWriter driver translates QuickDraw
instructions into PostScript commands, allowing PostScript
printers (like Apple's LaserWriter printers) to reproduce
what the user sees on the screen at high resolution.
Q: What's new about LaserWriter 6.0? How is it different
from the LaserWriter 5.2 driver that now ships with
LaserWriter printers and System Software?
A: Color printing. LaserWriter 6.0 adds the capability
to translate color QuickDraw images into color PostScript commands.
Any application that supports color QuickDraw now also
supports color printing on color PostScript printers.
Previously, unless an application sent color PostScript directly
to the printer, color printing was not possible on these
printers.
Halftone printing. Users of monochrome PostScript printers
benefit as well. Color images are halftoned by the printer.
Halftoning is a technique that produces dot clusters
of varying size that are perceived as different shades of gray.
The resulting print is much more faithful to the original
image than a high-contrast print composed only of solid black
and white regions.
Faster text printing. The font query mechanism has been
improved substantially in LaserWriter 6.0. It takes less
time for the printer to report its available fonts to the
Macintosh. The result is reduced overall time-to-print,
especially for users who have large font library hard disks
connected to their printer.
32-Bit QuickDraw printing. LaserWriter 6.0 supports output
of images created using 32-Bit QuickDraw. A print of a
32-bit image will show smoother color transitions; in
general, rendering will be more accurate and realistic
than an 8-bit image print.
Extensible menu for page-size choices. The Page Setup
dialog of LaserWriter 6.0 includes the page size choices
US Letter, US Legal, A4 Letter, and B5 Letter. It replaces
the Tabloid choice of previous drivers with an "Other" button.
Clicking this button causes a pop-up menu to appear,
offering the page sizesTabloid, No. 10 Envelope, and
A3. Additional page sizes can be added to this menu by
installing the proper resource. Thus, printer vendors can
ship a driver with their product that includes a page size
specially created for that device. Current color printers
have smaller printable areas than the LaserWriter, and thus
some parts of full-page images are lost when printed on these
devices. Users can now avoid this by selecting a page
size appropriate for their printers.
Q: Will all applications work with LaserWriter 6.0?
A: Apple's testing indicates that most applications will
work fine with LaserWriter 6.0. Most applications use
QuickDraw for printing as well as for screen imaging; these
applications rarely have problems with LaserWriter 6.0.
Other applications do their own conversion of a screen
image to a PostScript page description, and send this
PostScript directly to the printer (bypassing most of the
LaserWriter driver). Some of these applications will not
print as expected with LaserWriter 6.0. There are several
possible effects:
1. Output of a color image is in black and white,
even on a color printer.Many applications that send
their own PostScript to the printer do not send any of the
PostScript required for color printing. It is difficult
for an application to determine whether the printer
is color or not. The options are A) ask the user, or
B) assume a black and white printer. Most applications
do the latter.
2. No output.
A few applications that send their own PostScript rely
on certain variables in the Laser Prep code that is
a part of the LaserWriter driver. Apple has discouraged
this practice, but not with 100% success. The Laser
Prep code has changed in LaserWriter 6.0. Applications
that assume that certain variables are defined will
generate PostScript errors when the user tries to print;
nothing will be printed. The work-around for this is to use
LaserWriter 5.2 until the developer revises the application.
3. Other problems when printing.
Some problems may occur when printing using
"Color/Grayscale" mode, but not with "Black & White" mode.
This is because a few applications assume they will be printing
in black and white. They try to write directly to data
structures that changed when the color capability was
added to the driver. The work around for this is to use
"Black & White" mode when printing until the developer
revises the application.
Q: In the past, new LaserWriter drivers were incompatible
with older drivers. Is this still the case?
A: Yes. LaserWriter 6.0 is not compatible with LaserWriter 5.2.
LaserWriter "wars" can be avoided by ensuring that all users
on a network who share printers have the same version
of the driver installed.
Q: Should every user change to LaserWriter 6.0?
A: No. Those users who meet one of the following
criteria, should use LaserWriter 6.0:
1. Use a color Macintosh (IICX, II, IIX, or SE/30) and
print documents containing color (or grayscale)
2. Use a printer with an attached font library disk
(i.e. have several hundred fonts available)
3. Share a printer, via a network, with any other user
who uses LaserWriter 6.0
Q: How do I get LaserWriter 6.0?
A: LaserWriter 6.0 will be part of Apple's color disk that
will also include 32-Bit QuickDraw. This disk will be
distributed to all Apple authorized dealers. The driver
will also be distributed to electronic bulletin boards,
user groups, APDA, VAR reps, Apple System Engineers, and
reps for National and University Accounts.
LaserWriter 6.0 will be available for licensing to vendors
of color PostScript printers and other third-party developers.
Q: Will LaserWriter 6.0 be included with system software
or LaserWriter II printers?
A: No. LaserWriter 5.2 will continue to ship with both
system software and LaserWriter II printers. When a new
Macintosh is added to an existing network whose users have
LaserWriter 5.2, it will be fully compatible. The network
will need to update to LaserWriter 6.0 only if one or more
users desire its color and font-handling features.
Mark B. Johnson AppleLink: mjohnson
Developer Technical Support domain: mjohnson@Apple.com
Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson
"You gave your life to become the person you are right now. Was it worth it?"
- Richard Bach, _One_rang@cpsin3.cps.msu.edu (Anton Rang) (05/09/89)
Wow. Looks impressive (but now I have to start thinking about an SE => SE/30 upgrade...sigh). One question--in Finder 7.0, what does dragging a disk icon onto another disk icon do? It's always seemed a little non-intuitive that it copies all the files from the source disk, *except* the ones on the desktop.... +---------------------------+------------------------+-------------------+ | Anton Rang (grad student) | "VMS Forever!" | VOTE on | | Michigan State University | rang@cpswh.cps.msu.edu | rec.music.newage! | +---------------------------+------------------------+-------------------+ | Send votes for/against rec.music.newage to "rang@cpswh.cps.msu.edu". | +---------------------------+------------------------+-------------------+
chuq@Apple.COM (Chuq Von Rospach) (05/10/89)
>Wow. Looks impressive (but now I have to start thinking about an >SE => SE/30 upgrade...sigh). Actually, no you don't. One of the nice things about System 7.0 is that it was designed so that the only thing that requires the PMMU or 68030 is the Virtual stuff. Unless you *have* to have virtual memory, you can live quite nicely on an SE... Chuq Von Rospach =|= Editor,OtherRealms =|= Member SFWA/ASFA chuq@apple.com =|= CI$: 73317,635 =|= AppleLink: CHUQ [This is myself speaking. No company can control my thoughts.] Bookends. What a wonderful thought.
jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) (05/10/89)
Thanks, Apple, for posting all this info about System 7.0! I'm really
looking forward to it!
I have two questions, one directed to Apple and one to the net at large?
1) Will support for gray-scaled, anti-aliased fonts be used in System 7.0?
Anti-aliased fonts are fonts in which the edges of the letters are smoothed
by gray pixels. There's not a sharp transition from white pixel to black
pixel. The fonts look fuzzier, but they're VASTLY more readable and
easier on the eyes (see Stewart Brand's _The Media Lab_ for a reference).
With 32-bit QD and outline font technology already in System 7.0, adding
shaded fonts wouldn't be all that hard, and it would add one HELL of a
lot of value for people that do a lot of text editing... so how about
it, Apple?
2) What's the cheapest '030 or '551 upgrade I can get for my Mac II? And
is there anyone else out there who's really, really interested in a
Mac II system (2MB, 40MB HD, 2 int. drives, great condition, color
monitor) for ~$4500? If there is, PLEASE let me know (but with all the
recent announcements of IIs for sale, I doubt it...)!
Thanks!
Rob Jellinghaus | "Next time you see a lie being spread or a
jellinghaus-robert@CS.Yale.EDU | bad decision being made out of sheer ignor-
ROBERTJ@{yalecs,yalevm}.BITNET | ance, pause, and think of hypertext."
{everyone}!decvax!yale!robertj | -- K. Eric Drexler, _Engines of Creation_malczews@girtab.usc.edu (Frank Malczewski) (05/10/89)
Two questions for a PMMU-less Mac II-er: 1) Does this mean I can get by without the PMMU with System 7? 2) Does this mean that a System ROM upgrade won't be required for System 7? -- Frank Malczewski (malczews@castor.usc.edu)
jrg@Apple.COM (John R. Galloway) (05/10/89)
Concerning outline fonts: The posting mentioned that this will (among other things) greatly increase the usfulness of NON-postcript printers like the IISC. What about postcript devices? If major vendors are supporting Apples Outline Fonts will it be faster etc. to have a printer that deals with them directly? Is apple going to provide new roms to make the IINT or IINTX know about postcript AND the new outline stuff? apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
steve@violet.berkeley.edu (Steve Goldfield) (05/10/89)
In article <60053@yale-celray.yale.UUCP> jellinghaus-robert@yale.UUCP writes:
#>Thanks, Apple, for posting all this info about System 7.0! I'm really
#>looking forward to it!
#>
#>I have two questions, one directed to Apple and one to the net at large?
#>2) What's the cheapest '030 or '551 upgrade I can get for my Mac II? And
#> is there anyone else out there who's really, really interested in a
#> Mac II system (2MB, 40MB HD, 2 int. drives, great condition, color
#> monitor) for ~$4500? If there is, PLEASE let me know (but with all the
#> recent announcements of IIs for sale, I doubt it...)!
I posted a similar question yesterday and got several responses.
This seems a good opportunity to summarize.
The gist is that right now there is only a developer price. Six
months ago, one Emailer reports it was $350. Another says that
the educational price is $500. The first speculated that it
should settle down at around $200. That gives at least a ballpark
range of $200 to $500. Since the upgrade board to 68030 sells
for upwards of $1,600 it seems like the way to go for virtual
memory in 7.0. One person said that you wouldn't have to have
the PMMU until system version 8.0. Incidentally, the chip upgrade
is just a chip you can plug into your mother board in an existing
socket. The 68030 upgrade is a board which takes up a slot, which
is presumably one reason why it is so much more expensive.
Steve Goldfieldhellerst@husc4.UUCP (Joe Hellerstein,,,) (05/10/89)
I was under the impression that a Mac Plus/SE with 2 meg could have a PMMU added and run the Virtual INIT. Any guesses on the feasibility of this with Sys. 7.0? And if Virtual can do it, why not Apple, hmmm? Joe Hellerstein
lsr@Apple.COM (Larry Rosenstein) (05/10/89)
In article <2903@cps3xx.UUCP> rang@cpsin3.cps.msu.edu (Anton Rang) writes: > dragging a disk icon onto another disk icon do? It's always seemed a > little non-intuitive that it copies all the files from the source > disk, *except* the ones on the desktop.... (This always seemed like a bug to me :-) I don't know for sure, but it is likely that this will be fixed. Both the desktop and the trash will be implemented as special directories in System 7.0. This not only fixes anomalies such as these, but gives applications a way to put things in those places (when needed -- you should do this only at the user's request). Also, the trash is not emptied automatically by the Finder; the user must use the Empty Trash command. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.COM (Larry Rosenstein) (05/10/89)
In article <30381@apple.Apple.COM> jrg@Apple.COM (John R. Galloway) writes: > increase the usfulness of NON-postcript printers like the IISC. What about > postcript devices? According to the press release on AppleLink, Adobe has announced that it will provide a utility that converts Apple fonts to Adobe Postscript format. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.COM (Larry Rosenstein) (05/10/89)
In article <3832@nunki.usc.edu> malczews@girtab.usc.edu (Frank Malczewski) writes: > 1) Does this mean I can get by without the PMMU with System 7? > > 2) Does this mean that a System ROM upgrade won't be required for System 7? Yes and yes. If you don't have a PMMU, then you can't turn on virtual memory. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
cep@apple.com (Christopher Pettus) (05/11/89)
In article <1791@husc6.harvard.edu> hellerst@husc4.UUCP (Joe Hellerstein,,,) writes: > I was under the impression that a Mac Plus/SE with 2 meg could have > a PMMU added and run the Virtual INIT. Only machines based on a 68020 or 68030 can use a PMMU. Thus, some sort of (compatible) accelerator card would be required. -- Christopher Pettus | "Brahma said: Well, after hearing Network Systems Development | ten thousand explanations, a fool Apple Computer, Inc. | is no wiser. But an intelligent cep@apple.com {nsc, sun}!apple!cep | man needs only two thousand five AppleLink: PETTUS.C | hundred." -- The Mahabharata
earleh@eleazar.dartmouth.edu (Earle R. Horton) (05/11/89)
>Q: Is it true that all of the current printer drivers will > be incompatible with System 7.0? >A: Yes. Apple's New Print Architecture is designed to > make the creation of printer drivers easy. > The present generation Print Manager has only one problem regarding the creation of printer drivers: You can't get documentation unless you have the Promotional Edition of Inside Macintosh. Does this mean that IM VI will have a chapter on "Creating a Printer Driver for your non-Apple Printer?" > When System 7.0 ships, Apple will have new printer > drivers to support all Apple output devices. > >Q: Who will write replacement drivers for these devices? >A: Apple will work closely with third-party developers to > help in the creation of new printer drivers built around Apple's > New Print Architecture. Which third-party developers? Is this going to be public information, or will you have to be someone special to get it? Does this actually mean that Apple is turning over a new leaf in its policy of printer driver documentation? I would like to believe so, but recent history causes me to be skeptical. Earle R. Horton Graduate Student. Programmer. God to my cats.
norman@a.cs.okstate.edu (Norman Graham) (05/11/89)
Just thought I'd get my questions in early! ;-)
1) How will the users of Postscript printers be affected by
outline fonts? Does Apple (or Adobe) plan to release
outline fonts that correspond to the postscript fonts
resident in the LWII or will we be stuck with bitmap
screen fonts? If we do get said fonts, will the Macintosh's
fonts or the LW's fonts be used for printing? In general
how do the new outline fonts work with a postscript printer?
(OK... so that was more than one question :-)
2) Will the virtual memory scheme offer memory protection for
multiple processes running under multifinder, or do all
processes share the same virtual address space (like the
current system)?
+Norm
--
Norman Graham Oklahoma State University
Internet: norman@a.cs.okstate.edu Computing and Information Sciences
UUCP: {cbosgd, rutgers} 219 Mathematical Sciences Building
!okstate!norman Stillwater, OK 74078-0599stores@unix.SRI.COM (Matt Mora) (05/11/89)
In article <1752@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <2903@cps3xx.UUCP> rang@cpsin3.cps.msu.edu (Anton Rang) writes: >> dragging a disk icon onto another disk icon do? It's always seemed a >> little non-intuitive that it copies all the files from the source >> disk, *except* the ones on the desktop.... > >(This always seemed like a bug to me :-) I alwaysed liked that feature. If you want to copy all the contents of one disk to another but don't want to copy a certian file/folder, you move that file to the desktop. Makes perfect sence to me. Otherwize you would copy the whole disk and then have to throw away the file/folder (like the system) that you don't want on the newly copied disk. That would be a waste of time. Now I agree that there should be a warning in the copy dialog that says "File on the desktop will not be copied." or something like that. -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
simon@alberta.uucp (Simon Tortike) (05/11/89)
The word `protection' does not appear once in the two articles posted by Apple. Does this mean that system 7.0 will not have memory protection? We sloppy scientific programmers need this crash barrier so that corrupted system files do not need to be replaced every few weeks. ------------------- Simon Tortike, Department of Mining, Metallurgical and Petroleum Engineering, The University of Alberta, Edmonton, AB, CANADA T6G 2G6. simon@alberta.uucp || simon@cs.UAlberta.CA || Tel. +1 403 492-3338
lsr@Apple.COM (Larry Rosenstein) (05/12/89)
In article <4666@okstate.UUCP> norman@a.cs.okstate.edu (Norman Graham) writes: > 1) How will the users of Postscript printers be affected by > outline fonts? Does Apple (or Adobe) plan to release > outline fonts that correspond to the postscript fonts To quote from the press release: "Adobe System, Inc. today announced that it will provide a utility that converts Apple fonts to the Adobe Postscript format. This announcement assures Macintosh customers that Apple's fonts can be printed on all Macintosh devices, including Postscript printers." System 7.0 still supports bitmap fonts, and font developers can choose to use bitmaps at small sizes. I don't know what will be done to provide outline fonts for existing Postscript fonts. > 2) Will the virtual memory scheme offer memory protection for > multiple processes running under multifinder, or do all All processes share the same address space. This question was asked at the Developer's Conference, and the reply said that offering protection between application heaps would be only part of the job, since low memory and the system heap is still shared between all applications. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
hpoppe@bierstadt.ucar.edu (Herb Poppe) (05/12/89)
In article <30353@apple.Apple.COM> mjohnson@Apple.COM (Mark B. Johnson) writes: >Q: Will HyperCard support System 7.0 features? >A: Future releases of HyperCard will support System 7.0. While > some features are transparently supported, others will necessitate > additional development. For instance, HyperCard will need to > be extended to take advantage of the high-level SQL calls > included in System 7.0. Likewise, support for other features > in the Live Copy/Paste will mean adding additional code. Other > features, like resolution-independent graphics and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Apple's outline fonts, are transparent to HyperCard and > will need no additional work. Whoa back Buck! This is the only place in Mark's two postings that I recall seeing resolution-independent graphics mentioned. I assume this means more than just the outline fonts. For example, I hope this means I can draw a one inch line on a 72dpi screen, save the file, play back the file on a 100dpi screen and see a line that measures one inch. If this is so, I'm curious as to how bitmaps would be handled. Changing the subject: how, when and where will Apple make detailed technical information available on all of the currently announced new features of System 7.0? Will there be a draft IM V6? When will it be available? How can those of us on the Internet get it? (Please don't tell us that APDA will be the only source -- System 7.0 will have been released a year before APDA ships the first draft copy.) Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP
mjohnson@Apple.COM (Mark B. Johnson) (05/12/89)
In article <3218@ncar.ucar.edu> hpoppe@bierstadt.UCAR.EDU (Herb Poppe) writes: > >Changing the subject: how, when and where will Apple make detailed technical >information available on all of the currently announced new features of >System 7.0? Will there be a draft IM V6? When will it be available? >How can those of us on the Internet get it? (Please don't >tell us that APDA will be the only source -- System 7.0 will have been >released a year before APDA ships the first draft copy.) > At the moment, all Partners and Certified developers are getting the most complete technical documentation which is available. Since these are more directional notes than firm technical documentation, they are not yet available to anyone outside of this group. Further discussion in these groups will probably be the best source of information. I don't think Apple will be releasing these notes to the general public anytime soon since the information contained within is constantly CHANGING. System 7.0 is a work in progress... Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_
mjohnson@Apple.COM (Mark B. Johnson) (05/12/89)
In article <13436@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > The present generation Print Manager has only one problem >regarding the creation of printer drivers: You can't get documentation >unless you have the Promotional Edition of Inside Macintosh. Does >this mean that IM VI will have a chapter on "Creating a Printer Driver >for your non-Apple Printer?" > There is going to be a Writing a Printer Driver development kit. The reason Apple hasn't documented these things in the past is because anyone who had done this in the past would now break. Now that the printing architecture is being completely rewritten, you can expect a different reaction from Apple when you want to write a printer driver... Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_
ra_robert@gsbacd.uchicago.edu (05/12/89)
First, I'd like to thank Mark Johnson (mjohnson@Apple.COM) for posting the original System 7.0 releases _the morning of the announcement_. We on the net probably heard them as soon as the developers there did. I, for one, am very impressed. One question: hpoppe@bierstadt.UCAR.EDU (Herb Poppe) wrote asking about resolution-independent graphics in 7.0 (which was mentioned offhand in one of the press releases). Is this in fact limited now only to outline fonts, with the rest to come later? I assume from the silence that this is no-comment territory, destined for System 8.0, but if it can be answered, I'd be interested. Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine ------ MOFO knows!
lange@lanai.cs.ucla.edu (Trent Lange) (05/12/89)
In article <1787@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: > >System 7.0 still supports bitmap fonts, and font developers can choose to >use bitmaps at small sizes. I don't know what will be done to provide >outline fonts for existing Postscript fonts. > >Larry Rosenstein, Apple Computer, Inc. >Object Specialist Will bitmap fonts be the standard way for drawing "normal-size" fonts (eg 9, 10, 12)? It seems to me that the mathematical calculations for drawing an outline font would take much longer than simply dumping a bitmap. Or is part of 7.0's larger recommended heap size going to be used for temporarily storing the bitmaps calculated by the outline, so the calculations only have to be done once per font*size*character/session? Trent Lange P.S. I'm sure I'm speaking for most when I say how much I appreciate Apple's giving these kinds of advance technical notices, and for "official" Apple people like you answering our questions. ********************************************************************** * "UCLA: The fourth best country in the Olympics" * **********************************************************************
yeung@reed.UUCP (Woodrow Yeung) (05/12/89)
Will a 512Ke with 2Mb of RAM still be supported? Woody Yeung yeung@reed
keith@Apple.COM (Keith Rollin) (05/12/89)
In article <23868@shemp.CS.UCLA.EDU> lange@cs.ucla.edu (Trent Lange) writes: > >Will bitmap fonts be the standard way for drawing "normal-size" fonts >(eg 9, 10, 12)? It seems to me that the mathematical calculations >for drawing an outline font would take much longer than simply dumping >a bitmap. Or is part of 7.0's larger recommended heap size going to >be used for temporarily storing the bitmaps calculated by the outline, >so the calculations only have to be done once per font*size*character/session? > 'Tis true. The bitmaps are cached whenever they are used. Also, the outline algorithms are *VERY* fast, so that you shouldn't notice much of a speed difference anyway. Finally, there is standard QuickDraw overhead (internally buffering the text before displaying it to the screen, clipping, adding stylistic variations, etc.) which should even things out. ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
macak@lakesys.UUCP (James Macak) (05/12/89)
In article <1754@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <3832@nunki.usc.edu> malczews@girtab.usc.edu (Frank Malczewski) >writes: >> 1) Does this mean I can get by without the PMMU with System 7? >> 2) Does this mean that a System ROM upgrade won't be required for System >7? >Yes and yes. If you don't have a PMMU, then you can't turn on virtual >memory. >Larry Rosenstein, Apple Computer, Inc. >Object Specialist >Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr >AppleLink: Rosenstein1 I hope I'm not accused of wasting net bandwith doing this, but perhaps it's time to offer a note of thanks to guys from Apple like Larry Rosenstein who are active on the net. Sorry that I don't recall the other Apple employees who also contribute, as this "thanks" also applies to you. Larry (et al), your input and sharing of information is truly very helpful and useful to many of us net Mac users out here. Having this sort of indirect link to Apple is a most informative line of communication that we all appreciate, though this is not often expressed. Thanks again for your time and effort... ALL of you folks at Apple who contribute here. Please continue to "hang around." Jim -- Jim Macak <lakesys!macak@csd1.milw.wisc.edu>
mfi@beach.cis.ufl.edu (Mark Interrante) (05/12/89)
In article <23868@shemp.CS.UCLA.EDU> lange@cs.ucla.edu (Trent Lange) writes: >In article <1787@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >> >>System 7.0 still supports bitmap fonts, and font developers can choose to >>use bitmaps at small sizes. I don't know what will be done to provide >>outline fonts for existing Postscript fonts. >Will bitmap fonts be the standard way for drawing "normal-size" fonts >(eg 9, 10, 12)? It seems to me that the mathematical calculations >for drawing an outline font would take much longer than simply dumping >a bitmap. Or is part of 7.0's larger recommended heap size going to >be used for temporarily storing the bitmaps calculated by the outline, >so the calculations only have to be done once per font*size*character/session? I seems to make sense that a caching scheme for the bitmap version of fonts is in order. Something like what is done on laser printers. ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "X is just raster-op on wheels" - Bill Joy, January 1987
brian@cbw1.UUCP (Brian Cuthie) (05/12/89)
This is beginning to smell a lot like another case of Apple sticking it to us (ala LISA 2, Apple III etc.) Would someone from Apple please comment on whether new ROMs will be available for the IINT and IINTX to support the new outline fonts ? I just bought a LaserWriter IINT and I'm going to be really irked (to put it mildly) if my MegaBuck printer is obsoleted six months after I buy it. When the Mac first came out, I went the whole developer route. I bought a (the just then anounced) LISA 2/10, printer and the necessary software for about $7,000 (developer prices!). Then, less than a year later, Apple had discontinued the LISA and dumped them on Sears who was selling them for $1900!!! I was not able to get more than $2500 for mine. I lost $4500 in ONE YEAR ! I swore I would never, ever, own another Apple product. It has taken me more than five years to break this oath. Screw me once; shame on you. Screw me twice; shame on me. I sure hope I'm not about to get screwed the second time. BTW: Just think about all those lucky Apple III owners... -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umbc.edu
mfi@beach.cis.ufl.edu (Mark Interrante) (05/12/89)
Are the following *features* going to be fixed in sys7.0? 1. When the finder is run it moves the hard disk and the finder to fixed locations on the screen. I have wanted to move such icons to the bottom of the screen instead of the sides. 2. Will the OS have font menus display in the real font (ala suitcaseII)? ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "X is just raster-op on wheels" - Bill Joy, January 1987
lsr@Apple.COM (Larry Rosenstein) (05/13/89)
In article <23868@shemp.CS.UCLA.EDU> lange@lanai.cs.ucla.edu (Trent Lange) writes: > Will bitmap fonts be the standard way for drawing "normal-size" fonts > (eg 9, 10, 12)? It seems to me that the mathematical calculations This issue is not so much the time to convert outlines to bitmaps (since that is very fast). It is a question of which mechanism ends up with the best results and how much time the font designer wants to spend adding font instructions. One of the people working on the outline fonts here was able to add instructions (hints) to get good looking 9 point screen fonts. But the time involved in getting the fonts to look good increases greatly as you deal with smaller point sizes. Font vendors might find it easier to distribute 9 point bitmap fonts than spend the time tuning their outline fonts. 10 and 12 point fonts are not as difficult to tune, but still may look better as bitmaps. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
res12@snoopy.UMD.EDU (Matthew T. Russotto) (05/13/89)
In article <153@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: > [flames about Apple III, Lisa, and possibly obselete Lasewriter NT] Relax-- some Apple.people have already said that there will be a utility to convert Apple outline fonts to Postscript fonts. There are far, far better things to flame Apple for than that... LIKE THE FACT THAT MY MAC II WAS THE ONLY 68020 MACHINE APPLE PRODUCED, AND NOW I HAVE TO PAY $$$ TO GET VIRTUAL MEMORY!!!! (oops. Flame off) -- #include <signature.sig> -- DISCLAIMER: Not only does the University not share my opinions, they don't want me sharing my opinions. "This 'Pnews', what does it do?" Matthew T. Russotto res12@snoopy.umd.edu (this semester only)
holland@m2.csc.ti.com (Fred Hollander) (05/13/89)
In article <1787@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >"Adobe System, Inc. today announced that it will provide a utility that >converts Apple fonts to the Adobe Postscript format. This announcement >assures Macintosh customers that Apple's fonts can be printed on all >Macintosh devices, including Postscript printers." I thought I heard it the other way around - that Adobe and anyone else that sells fonts would come up with a converter from their format to Apple's outline format so we could generate screen fonts. It would surely be a major disadvantage to choose a Postscript font if it meant reverting back to the old-style bitmap font for the screen. Fred Hollander Computer Science Center Texas Instruments, Inc. hollander@ti.com The above statements are my own and not representative of Texas Instruments.
tim@hoptoad.uucp (Tim Maroney) (05/13/89)
In article <1787@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >> Will the virtual memory scheme offer memory protection for >> multiple processes running under multifinder, or do all > >All processes share the same address space. This question was asked at >the Developer's Conference, and the reply said that offering protection >between application heaps would be only part of the job, since low memory >and the system heap is still shared between all applications. That's true. Unfortunately, it seems to indicate that memory protection in System 7.0 will still leave developers in the highly unfortunate position of being able to crash the system with application software bugs. The probability will be reduced but not eliminated, if I'm reading you correctly, Larry. Since low-memory globals are not being eliminated and the system heap is not being made read-only to applications, then one program can still crash either the OS software or other applications. Double plus ungood. I'd prefer that Apple just go ahead and break the programs that ignore the guidelines on low memory and the system heap, rather than leave us all floundering about having to reboot the system constantly during early development. Oh well, I thought I was going to have to wait for 8.0 for this anyway.... -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "What's the ugliest part of your body? Some say your nose, some say your toes, But I think it's your mind." -- Frank Zappa
tim@hoptoad.uucp (Tim Maroney) (05/13/89)
In article <30518@apple.Apple.COM> mjohnson@Apple.COM (Mark B. Johnson) writes: >There is going to be a Writing a Printer Driver development kit. The reason >Apple hasn't documented these things in the past is because anyone who had >done this in the past would now break. Now that the printing architecture >is being completely rewritten, you can expect a different reaction from >Apple when you want to write a printer driver... Which is great, of course. My only concern is, are you saying that existing printer drivers will break under System 7.0? There are some fifty-plus products using nonstandard printer drivers on the market at present, and more in the pipeline (including my current client's product). Again, this would be double-plus ungood to do. An Apple employee told me not two weeks ago that the inner printing architecture would not be changing in any big way for exactly this reason; this was a week before the System 7.0 news flashes. Could someone clarify the situation with regard to backwards compatibility? Thanks! -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Disclaimers are for running-dog lackeys of the bourgeoisie; free-thinking members of the proletariat such as myself have their own opinions, and do not need to express those of their oppressive capitalistic employers! Nyah!" -- James Heath
labc-3dc@e260-2d.berkeley.edu (Andy McFadden) (05/13/89)
In article <8905120211.aa03708@SMOKE.BRL.MIL> KMILES@CC.USU.EDU ("Kurt Miles, VAX Consultant") writes: >Sorry if I seem out of line, but I don't really care about the nut and bolts >gory details of how a mac works under version 6.0 vs. 7.0. Very few of us do, but sending this to comp.sys.apple (info-apple) doesn't help any. The Mac traffic is being cross-posted from comp.sys.mac (info-mac) and comp.sys.mac.programmer, so you have to send to those groups to stop the flood of posts. >Kurt Miles : ..... remember, sometimes the DRAGON wins! -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden labc-3dc@widow.berkeley.edu
jsm@Apple.COM (Jeff Miller) (05/13/89)
In article <7267@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Which is great, of course. My only concern is, are you saying that >existing printer drivers will break under System 7.0? There are some My understanding is that current applications will not break, but current printer drivers will. However, as was pointed out at the conference, not only will the writing of third party print drivers be supported but the development time should be greatly reduced. I believe they gave times in hours and days (rather than months and years). I think the Printshop mentioned an in-house record of developing a prototype driver for the new architecture of 30 minutes (yes, minutes). Of course, your mileage may vary. Jeff Miller Macintosh Toolbox Group (<- note: *not* the Printshop, so I may be wrong)
lsr@Apple.COM (Larry Rosenstein) (05/13/89)
In article <7266@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > software bugs. The probability will be reduced but not eliminated, if > I'm reading you correctly, Larry. Since low-memory globals are not I wasn't clear about this. I don't think the probability will change at all under 7.0. There is one large address space (up to 14 megabytes) and everything lives there. There is no protection at all. The comment about low memory was simply repreating what was stated at the Developer's Conference. If protection was done between application heaps (which it isn't), it would only be a red herring since the system heap and low memory is shared. The thought was that it was better to come up with a total solution in some future system, rather than give users a false sense of confidence. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
earleh@eleazar.dartmouth.edu (Earle R. Horton) (05/13/89)
In article <7266@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: [Discussion of System 7.0 non-elimination of writable lowmem globals.] >or other applications. Double plus ungood. I'd prefer that Apple just >go ahead and break the programs that ignore the guidelines on low >memory and the system heap, rather than leave us all floundering about >having to reboot the system constantly during early development. Any Macintosh application written in a high-level language, using library glue derived from Apple's, and making calls to the Memory Manager will break when Apple makes low memory a protected area. A side effect of using Apple glue to call a Memory Manager routine is to have the glue store a result code in the word at decimal 544. Note that the programmer, along with the marketer of the development system used, is completely innocent of intent to write to low memory. The Memory Manager glue is only an example, too. There are many, many explicit stores to lowmem in Apple glue. If Apple ever does implement a protection scheme that covers lowmem and the System heap (which I also think is a good idea, don't get me wrong) then they will have to distribute library glue which is compatible with it, and allow time for some large percentage of existing Macintosh programs to be recompiled, relinked, and reshipped to customers. Still want them to do it now? "People forget how fast you did a job, but they remember how well you did it." Salada Tag Lines
jb10320@uxa.cso.uiuc.edu (Jawaid Bazyar) (05/13/89)
I'm sure this has been mentioned before, but PLEASE! edit your Newsgroups line to remove comp.sys.apple from the System 7.0 discussions. Thank you... =============================================================================== jawaid bazyar "The history of the world is the history of jb10320@uxa.cso.uiuc.edu the warfare between secret societies." Junior/Computer Engineering @ - Ishmael Reed, Mumbo-Jumbo Univ. of Illinois ===============================================================================
han@Apple.COM (Byron Han, wyl E. coyote ) (05/14/89)
In article <30581@apple.Apple.COM> jsm@Apple.COM (Jeff Miller) writes: >In article <7267@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>Which is great, of course. My only concern is, are you saying that >>existing printer drivers will break under System 7.0? There are some > >My understanding is that current applications will not break, but current >printer drivers will. It was stated at the developers conference that applications that directly diddle with the print record will break or might break. +-----------------------------------------------------------------------------+ | Disclaimer: Apple has no connection with my postings. | +-----------------------------------------------------------------------------+ Byron Han, Communications Architect At Apple, we change the world everyday. Apple Computer, Inc. ----------------------------------------- 20525 Mariani Ave, MS27Y Internet: han@apple.COM Cupertino, CA 95014 UUCP:{sun,voder,nsc,decwrl}!apple!han ------------------------------------ GENIE:BYRONHAN CompuServe:72167,1664 ATTnet: 408-974-6450 Applelink:HAN1 HAN1@applelink.apple.COM -------------------------------------------------------------------------------
day@grand.UUCP (Dave Yost) (05/14/89)
In article <1752@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >Both the desktop and the trash will be implemented as special directories >in System 7.0. Also, the trash is not emptied automatically by the Finder; >the user must use the Empty Trash command. I would hope that the user would also have the option of setting trash emptying behavior so that files in the trash are automatically purged when needed in FIFO order (and not before). With this behavior in place, I would also love it if when I trash "HD:x:y:z" it would be renamed to "HD:trash:HD:x:y:z". Now I would have a true FIFO trash, and it would be possible to ask things like whether there exists a trashed file corresponding to some file on the system. --dave yost
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (05/14/89)
In article <7266@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Since low-memory globals are not >being eliminated and the system heap is not being made read-only to >applications, then one program can still crash either the OS software >or other applications. Double plus ungood. I'd prefer that Apple just >go ahead and break the programs that ignore the guidelines on low >memory and the system heap, rather than leave us all floundering about >having to reboot the system constantly during early development. > >Oh well, I thought I was going to have to wait for 8.0 for this anyway.... >-- >Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim Actually, the right thing to do here is have the relevant places start out as read only, and have them become read/write when it is necessary, such as the first time page 0 is written (for a few select pages) and have things like inserting trap handlers cause traps and run in priviledged mode so they can replicate the handler pages apropriately. It shouldn't be hard to make all of this relatively transparent to high-level languages. The problem would be with assembly code, which has traditionallya ssumed the right to touch anything. Jon
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (05/14/89)
In article <13472@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > Any Macintosh application written in a high-level language, using >library glue derived from Apple's, and making calls to the Memory >Manager will break when Apple makes low memory a protected area. A >side effect of using Apple glue to call a Memory Manager routine is to >have the glue store a result code in the word at decimal 544. Making page 0 shared whould largely solve the problem without introducing significant incompatibilities. One might even think about making page 0 be a virtual page. Jon
chuq@Apple.COM (Chuq Von Rospach) (05/14/89)
>Will a 512Ke with 2Mb of RAM still be supported?
The 512Ke is not supported by System 6.0.*, because it requires the extended
PRAM and 1Meg of memory, and because Apple doesn't support third party
emmory upgrades.
System 6.0.3 works just fine (except for Sound, which is fixed with the
Xpram init) on an upgraded 512Ke -- it better, since that's what I'm typing
on right now. But it isn't supported. Will System 7.0 work on one of these
machines? We won't know until some adventurous soul tries it and sees. But
it won't be an official configuration.
Chuq Von Rospach =|= Editor,OtherRealms =|= Member SFWA/ASFA
chuq@apple.com =|= CI$: 73317,635 =|= AppleLink: CHUQ
[This is myself speaking. No company can control my thoughts.]
Bookends. What a wonderful thought.lange@lanai.cs.ucla.edu (Trent Lange) (05/14/89)
In article <30544@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > > [Assures that drawing outline fonts will be as fast as drawing > the current bitmapped fonts] > >------------------------------------------------------------------------------ >Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support The outline fonts sound great and, to me anyways, are the second most important feature of 7.0 (next to virtual memory). However, the fact that text rotation will not be handled yet is very disturbing. Text rotation is, of course, very important for graphics. And then there's wrapping text into curves... It seems like Apple is going to a lot of trouble to build features in Quickdraw that are already handled by Display Postscript, and taking a a *long* time to do it. Why does Apple insist on re-inventing the wheel? Adobe can't be charging *that* much for Postscript. (If they are simply charging too much, then they would seem to be shooting themselves in the foot). So why doesn't Apple, like NeXT, use Display Postscript? Trent Lange ********************************************************************** * "UCLA: The fourth best country in the Olympics" * **********************************************************************
keith@Apple.COM (Keith Rollin) (05/14/89)
In article <23908@shemp.CS.UCLA.EDU> lange@cs.ucla.edu (Trent Lange) writes: > >It seems like Apple is going to a lot of trouble to build features in >Quickdraw that are already handled by Display Postscript, and taking a >a *long* time to do it. > >Why does Apple insist on re-inventing the wheel? Adobe can't be charging >*that* much for Postscript. (If they are simply charging too much, then >they would seem to be shooting themselves in the foot). > >So why doesn't Apple, like NeXT, use Display Postscript? Ever take a look at the price difference between a LaserWriter IINT and IISC? Says here that that the SRP for an NT is $4999, as opposed to $2799 for the SC. Almost all of that large difference is because of liscensing Postscript and PFS, the PostScript File System, and putting in the hardware to support it. With Apple's outline fonts, you can get that quality on an SC without paying for the extras. Also take into account that things like Adobe's new Type Manager will cost $$$ (although I haven't really seen this mentioned, but I can't see them giving it away for free), and that our System software doesn't need to cost you a dime (unless you want manuals...). Perhaps Adobe *IS* shooting themselves in the foot. I don't know. All I know is what I see on the price sheet. If anyone really knows for sure, feel free to correct me. On the other hand, they do seem to be doing pretty well for themselves... ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (05/15/89)
In article <23908@shemp.CS.UCLA.EDU> lange@cs.ucla.edu (Trent Lange) writes: >In article <30544@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: -> [Assures that drawing outline fonts will be as fast as drawing -> the current bitmapped fonts] The claimed speed (size and font not specified) is O(100 chars/sec) for rendering initially. After that, it's just bitblt time if there is enough cache. >The outline fonts sound great and, to me anyways, are the second most >important feature of 7.0 (next to virtual memory). However, the fact >that text rotation will not be handled yet is very disturbing... On the other hand, the hooks seem to be there. Apple's font definition is the first I have seen in which the hints work EVEN WHEN ROTATED! That was a great insight, and should lead to great rendering. The Print Manager has promised (more or less) to support rotated text at the initial release [well, they said they are trying "real hard" to get it out]. > [other stuff about Postscript] >So why doesn't Apple, like NeXT, use Display Postscript? Why doesn't Adobe change to Apple's format. It may be better. Marc Kaufman (kaufman@polya.stanford.edu)
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (05/15/89)
In article <23908@shemp.CS.UCLA.EDU> lange@cs.ucla.edu (Trent Lange) writes: >It seems like Apple is going to a lot of trouble to build features in >Quickdraw that are already handled by Display Postscript, and taking a >a *long* time to do it. >Why does Apple insist on re-inventing the wheel? Adobe can't be charging >*that* much for Postscript. (If they are simply charging too much, then >they would seem to be shooting themselves in the foot). >So why doesn't Apple, like NeXT, use Display Postscript? Apple doesn't use DP because they abhor being dependent on "foreign" technology. PostScript they keep because they needed a page-description language for the LW when it came out, they didn't have time to write one themselves, and now they've helped (significantly) to establish it as the standard page description language. However, as I understand it, Apple is very reticent in letting their system software (which as you can tell from the lawsuits, they guard and defend like gold) be dependent on outside technology. Another of the issues involved is that if Apple were to use DP, the Mac's performance would suffer significantly (I've heard DP mentioned as the big MIPS-eater in the Next, and a key reason for Mathematica running faster on the 16MHz Mac II than on the 25MHz cube). QuickDraw, on the other hand, has been extensively optimized for the Mac hardware; Apple has people that know the QuickDraw code very well, and can have them optimize and expand on software they know instead of having to have them figure out how to optimize DP for the Mac. Besides, using DP would probably break a lot of software, and it would open a whole new can of worms with people attempting to clone the Mac (since the basic display stechnology behind the interface is not Apple's anyhmore, but Adobe). Ugly, ugly, ugly as far as Apple's concerned. It might not necessarily be the best for the user (although I think their decision *is* the way to go), but it is the best decision for them as a company, and that's where it's at. Like people have said before, (with smileys) 4.5 MIPS out of the 5 in the NeXT get swallowed by DP :-) >Trent Lange -Ivan Cavero Belaunde "An MIT surveyor once found the gates of Hell He looked the devil in the eye and said "You're looking well," The devil looked right back at him, and said "Why visit me - You've been through Hell already; you went to MIT!"" -The MIT Engineers' Drinking Song EMail: captkidd@athena.mit.edu USnail: 407 Memorial Dr. Cambridge, MA 02139 Phone: (617) 621-0312
FTWILSON@pucc.Princeton.EDU (Frederick Todd Wilson) (05/15/89)
In article <30660@apple.Apple.COM>, keith@Apple.COM (Keith Rollin) writes: >In article <23908@shemp.CS.UCLA.EDU> lange@cs.ucla.edu (Trent Lange) writes: >Apple's outline fonts, you can get that quality on an SC without paying for the >extras. > >correct me. > >On the other hand, they do seem to be doing pretty well for themselves... >------------------------------------------------------------------------------ >Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support Just let me get this straight, once and for all. I've read all the System 7 stuff out there just like I'm supposed to, and the stuff about the outline fonts seems to boil down to something Apple hasn't actually said: with outline fonts you'll be able to get current LaserWriter IINT/NTX print quality out of a IISC. Is this right? F. Todd Wilson "My opintions are my own. Who else would want 'em anyway?!"
casseres@apple.com (David Casseres) (05/16/89)
In article <8321@pucc.Princeton.EDU> FTWILSON@pucc.Princeton.EDU (Frederick Todd Wilson) writes: > Just let me get this straight, once and for all. I've read all the System 7 > stuff out there just like I'm supposed to, and the stuff about the outline > fonts seems to boil down to something Apple hasn't actually said: with > outline fonts you'll be able to get current LaserWriter IINT/NTX print > quality out of a IISC. Is this right? Well, I'm no longer involved in printing at Apple, but note that even today, the IISC gives slightly better than PostScript quality as long as you stick to the few fonts and sizes that are supported. The new outline font stuff is specifically aimed at supporting ALL sizes, and there will be a lot of fonts in the new format. But also notice that there's more to PostScript than font rendering. There's splines, and arbitrary rotation, and so forth. The new printing stuff addresses some of these areas, such as halftoning, but not all. David Casseres Exclaimer: Wow!
parent@apple.com (Sean Parent) (05/16/89)
In article <7267@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Which is great, of course. My only concern is, are you saying that > existing printer drivers will break under System 7.0? There are some > fifty-plus products using nonstandard printer drivers on the market at > present, and more in the pipeline (including my current client's > product). All existing printing drivers will stop working under 7.0. You will not even be able to choose these devices in the new chooser. We are working hard to ensure that most 3rd party drivers are revved to the new architecture either before or shortly after we ship 7.0. Under the new architecture developing a driver is much simpler (yes, the in-house record is 30min). One of the resons for this is that an old driver would not be able to handle a call from a new application using the new call set. There is a compatibility box layered onto the new drivers so that exsiting applications can talk to them. Sean Parent PrintShop Engineer AppleLink: PARENT Standard Disclaimers Apply
amanda@intercon.UUCP (Amanda Walker) (05/16/89)
In article <8321@pucc.Princeton.EDU>, FTWILSON@pucc.Princeton.EDU (Frederick Todd Wilson) writes: > Just let me get this straight, once and for all. I've read all the System 7 > stuff out there just like I'm supposed to, and the stuff about the outline > fonts seems to boil down to something Apple hasn't actually said: with > outline fonts you'll be able to get current LaserWriter IINT/NTX print > quality out of a IISC. Is this right? Exactly. In fact, I have it on good authority that a IISC being driven by a II or IIx is actually *faster* than a IINT... Also, it makes printers like the HP Deskjet or LaserJet II *much* more attractive. -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation
tim@hoptoad.uucp (Tim Maroney) (05/17/89)
In article <7266@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >or other applications. Double plus ungood. I'd prefer that Apple just >go ahead and break the programs that ignore the guidelines on low >memory and the system heap, rather than leave us all floundering about >having to reboot the system constantly during early development. In article <13472@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > Any Macintosh application written in a high-level language, using >library glue derived from Apple's, and making calls to the Memory >Manager will break when Apple makes low memory a protected area. A >side effect of using Apple glue to call a Memory Manager routine is to >have the glue store a result code in the word at decimal 544. Note >that the programmer, along with the marketer of the development system >used, is completely innocent of intent to write to low memory. The >Memory Manager glue is only an example, too. There are many, many >explicit stores to lowmem in Apple glue. And all of these low memory locations can be trapped by the MMU and handled transparently to the application. > If Apple ever does implement a protection scheme that covers >lowmem and the System heap (which I also think is a good idea, don't >get me wrong) then they will have to distribute library glue which is >compatible with it, and allow time for some large percentage of >existing Macintosh programs to be recompiled, relinked, and reshipped >to customers. I don't see why. There are a number of different ways that an MMU can be set up to provide compatibility with the most common low memory globals, without the current memory copying on context switch overhead. > Still want them to do it now? Absolutely. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "This signature is not to be quoted." -- Erland Sommarskog
newbery@rata.vuw.ac.nz (Michael Newbery) (05/17/89)
In article <1752@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >[] Also, the trash is not emptied automatically >by the Finder; the user must use the Empty Trash command. What, never? Not even on Restart or Shutdown? Or when ejecting a disk from which files have been deleted? -- Michael Newbery <NEWBERY@rs1.vuw.ac.nz> (...!uunet!vuwcomp!newbery)
newbery@rata.vuw.ac.nz (Michael Newbery) (05/17/89)
* Will outline fonts cache generated bitmaps as PostScript does? * Will you be able to specify 'hand tweaked' bitmaps for small point sizes, i.e., preload the cache? -- Michael Newbery<NEWBERY@rs1.vuw.ac.nz> (...!uunet!vuwcomp!newbery)
phil@Apple.COM (Phil Ronzone) (05/18/89)
In article <7321@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >And all of these low memory locations can be trapped by the MMU and handled >transparently to the application. Well, that is not economical. When we launched a version of Lode Runner under A/UX, guess who was watching the clock ticks rather than using an A-line trap? (A/UX normally updates the ticks much less frequently). Nice thing about it was Lode Runner ran about 5x slower, so I could win. You can now set an environment variable, and A/UX will issue signals to update the clock ticks lowmem much faster -- except now that process is taking a lot of signals. Point is -- a lot of looking at the low memory globals CAN be caught, but would (could) be very expensive in cycles. +-----------------------------------------------------------------------------+ |Philip K. Ronzone, Apple Computer, 10440 Bubb Rd, MS 58A, Cupertino, CA 95014| |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft,...}!apple!phil | +-----------------------------------------+-----------------------------------+ | All "IMHOs" disclaimed and copyrighted. | Self defense is a human right ... | +-----------------------------------------+-----------------------------------+
perry@key.COM (Peter Kiehtreiber) (05/18/89)
In article <30935@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes: > In article <7321@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >And all of these low memory locations can be trapped by the MMU and handled > >transparently to the application. > Well, that is not economical. When we launched a version of Lode Runner > under A/UX, guess who was watching the clock ticks rather than using an > A-line trap? (A/UX normally updates the ticks much less frequently). After watching this line of discussion for a while, I can't keep still any longer. Could somebody please explain to me WHY all the applications in a Mac with PMMU have to share their low-memory globals? Why not give each one a copy? (That's what the 2nd 'M' in PMMU is for, right? 'Mapping'?) As for the system heap now, that's a more difficult problem. A possible solution would be to split it into a 'clean' and a 'dirty' part; then share the 'clean' (i.e., readonly) part and copy the 'dirty' part for each application. Wastes some memory, but it's VIRTUAL memory now! Besides, even if the entire system heap needs to be copied for each application, I'd be quite willing to pay that price for protecting my applications from each other (and from my own stupidity :-). That leaves thingies like drivers that must muck around with the system's data. But those critters can trash any operating system (ask any UNIX victim). Puzzled and slightly confused mind wants to know. Flames by mail, real information on the net, how's that sound? Thanks in advance -- perry -- ------------------------------------------------------------------------ Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** ...!pacbell!key!perry
dplatt@coherent.com (Dave Platt) (05/18/89)
In article <811@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: > After watching this line of discussion for a while, I can't keep still > any longer. Could somebody please explain to me WHY all the applications > in a Mac with PMMU have to share their low-memory globals? Why not give > each one a copy? (That's what the 2nd 'M' in PMMU is for, right? 'Mapping'?) True... you can do this, _if_ it's possible for the kernel of the system (the portion running in supervisor state, or whatever the equivalent is) to keep things consistent in the face of N different copies of the low-memory globals. Having multiple, individual-application copies of some of these globals isn't a conceptual problem. In particular, globals that reflect the state of only the application owning them (i.e., globals that are local... if that makes sense) can be cloned safely. CurApName, for example, isn't a problem. However... globals that _truly_ reflect the state of the overall machine may present a different problem. For example, globals such as the pointers to the heads of important system queues should not (must not!) be allowed to diverge between applications... otherwise, the truly system-global information can get badly out of sync between different applications. SOMEbody has to keep these straight, or things will go seriously wrong! If Apple thought far enough ahead,'way back in the 128k toaster days, to place all of the application-specific globals in one set of pages, and all of the truly-globals in another, then this may not be a big problem. I'd be surprised if the current low-memory layout were partitioned anywhere near this cleanly, though. MultiFinder is clearly handling part of this problem already, when it "juggles" certain low-memory globals back and forth during context switches. It would have to do so differently if applications had their globals distinguished by the PMMU. And I'm not sure _how_ it could safely and certainly handle changes in the non-application-specific globals. > As for the system heap now, that's a more difficult problem. A possible > solution would be to split it into a 'clean' and a 'dirty' part; then share > the 'clean' (i.e., readonly) part and copy the 'dirty' part for each > application. Wastes some memory, but it's VIRTUAL memory now! Besides, even if > the entire system heap needs to be copied for each application, I'd be quite > willing to pay that price for protecting my applications from each other > (and from my own stupidity :-). Yes, that's distinctly more of a problem. And it may be worse than you think. Consider what happens if your application loads a resource from the System file (say, a FONT), and the memory manager is forced to compact the system heap in order to free up a large-enough contiguous block. CRUNCH! The compaction may move, purge, or coalesce blocks all over the System heap in one swell foop. All of a sudden, the entire heap is potentially dirty! To make matters a bit worse, you can't simply protect the System heap against modification by application code running in user-state. You must also protect it against modification by code in the OS itself that's performing tasks on behalf of the user! For instance, there's really no difference between the user storing blindly into the middle of the heap, and the user calling FSRead to read several hundred bytes into a buffer that's allocated in the System heap... either of these events can trash the universe. In order to prevent kernel-trashing-the-heap conditions, you must either add code to _every_ OS & toolbox routing that manipulates user-specified memory (checking the specified pointers for safety), or protect the System heap itself against modification _by_the_OS_, and then (when a store-violation occurs) decide whether the specified change to the heap is "valid". Both of these approaches are expensive in time and/or in programming effort, and they're tricky to get right. I suspect that you'd rapidly reach the point at which every application would have a completely separate copy of the System heap. This isn't too terrible a problem if you have virtual memory and a fast enough disk, but it does eliminate one of the major advantages of the MultiFinder approach (only one copy of any particular System resource is in physical memory at any one time). Every seen a small computer go into paging-death? It's not a pretty sight :-{. > That leaves thingies like drivers that must muck around with the system's > data. But those critters can trash any operating system (ask any UNIX victim). Yep. The Mac OS has more of these little critters, though... VBL tasks in the System heap, I/O endaction routines, and so forth. It's going to be interesting (to say the least!) to see how these sorts of features can either be replaced by safe alternatives, or sufficiently isolated from the guts of the system that they don't crash more than one application at a time. -- Dave Platt FIDONET: Dave Platt on 1:204/444 VOICE: (415) 493-8805 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
suitti@haddock.ima.isc.com (Stephen Uitti) (05/18/89)
>I would hope that the user would also have the option >of setting trash emptying behavior so that files in >the trash are automatically purged when needed in FIFO >order (and not before). > >With this behavior in place, I would also love it >if when I trash "HD:x:y:z" it would be renamed to >"HD:trash:HD:x:y:z". Now I would have a true FIFO trash, >and it would be possible to ask things like whether >there exists a trashed file corresponding to some file >on the system. I had several starter files, call them "WordStart". There were copies in several folders. When i deleted the second one, the finder complained that i already had one. "HD:trash:HD:WordStart" already existed. I'd just as soon that it didn't create "HD:trash:HD:x:y:WordStart", but instead keep a flat directory space and use a renaming convention such as "HD:trash:x.y.WordStart", then when the second "WordStart" in that folder was deleted, name it "HD:trash:x.y.WordStart#2", or somesuch. Of course, there will be another system for dealing with path+filenames that are longer than will fit into a filename. If space could be found for the original path and file name, then a user friendly "undelete" could be made available (renaming the file to the original folder). Who knows, maybe capslock option command shift control "Empty Trash" already does this for selected trash files. One might have to read the manual. Stephen.
amanda@intercon.UUCP (Amanda Walker) (05/18/89)
In article <811@key.COM>, perry@key.COM (Peter Kiehtreiber) writes: > After watching this line of discussion for a while, I can't keep still > any longer. Could somebody please explain to me WHY all the applications > in a Mac with PMMU have to share their low-memory globals? I think Phil's point was that a number of applications use low memory globals to monitor real-time status (such as the tick count), and it gets pretty uneconomical to have to update this all the time. That's why all of the compatibility guidelines for a while have said "USE TRAPS" in big letters. It's a lot simpler for everyone to only retrieve the status when it's asked for, rather than trying to continually update the process image... -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation -- "You don't have to take my word for it--I'll convince you!" --Gurshuran Sidhu
tim@hoptoad.uucp (Tim Maroney) (05/19/89)
In article <7321@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >And all of these low memory locations can be trapped by the MMU and handled >transparently to the application. In article <30935@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes: >Well, that is not economical. When we launched a version of Lode Runner >under A/UX, guess who was watching the clock ticks rather than using an >A-line trap? (A/UX normally updates the ticks much less frequently). Interestingly, when I was talking by e-mail with an Apple employee last year about all the compatibility problems with 6.0, he told me that Lode Runner was an example that proved that perfectly conforming applications could be written. Guess that's now out the window. Anyway, I agree that this is a problem with Ticks. However, most low memory globals, and especially the error storage globals that were under discussion, are not going to have to be accessed that often and certainly don't need to be updated by the system every sixtieth of a second. The clock globals are in a rather unique position. Other globals are far more economical. >You can now set an environment variable, and A/UX will issue signals to update >the clock ticks lowmem much faster -- except now that process is taking a lot >of signals. Also, I don't know that this is neccessarily the most economical way to do this. If you page fault on access to the page containing Ticks, then the page fault handler can fill it in for the software without actually updating a real page anywhere. You do this once per access, so it may turn out to be just as slow, but I'd like to see some benchmarks. >Point is -- a lot of looking at the low memory globals CAN be caught, but >would (could) be very expensive in cycles. Some, definitely. But, say, ResErr and PrintErr? I don't think so. I don't think the clock globals accurately reflect the virtual economics of most of the low memory globals. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Those Mayas were sacrificing not only pagan children, but baptized Christian children, for crying out loud! And they were carrying out those sacrifices, those barbarities, with great savagery, without giving the victims the benefit of the humane types of death that the European Church accorded even to heretics and witches during that century, such as burning at the stake." -- Matthew Rosenblatt, rec.arts.books
kent@lloyd.camex.uucp (Kent Borg) (05/19/89)
In article <1838@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >I don't think the probability will change at all under 7.0. There is one >large address space (up to 14 megabytes) and everything lives there. >There is no protection at all. The virtual address map comes in two sizes. 14 meg for 24-bit addressing, and some 2-ish number of gigabytes for 32-bit addressing--at least that's what Apple said last week. A gripe (sorry): There seems to be a very big duration-gap between the memory we can ask for before we ever start running (in our SIZE resource we should be frugal) and the MultiFinder temp memory which we might discover once running, but are not supposed to keep when calling WaitNextEvent (yes, I know we can mark it as purgable and take our chances...). Is there a way we can check whether there is scads of unused memory floating around which we could use to make the user happier? Can you tell us more about the properties of MultiFinder temp memory? Why should we not keep it for long periods? When will it get purged if marked purgable? (BTW: I like that it is now real memory manager memory.) What about this kludge: When the application finds itself running it checks whether it has lots of memory available. If it does it plays with it's own SIZE resource and launches itself again--then sets its SIZE back down? Pretty bad, huh? We need a better way to parcel out the available memory... Just thought of another question: Can an alias for an application have a SIZE resource? And another thing: When the 7.0 Finder discovers that my 4 meg. Plus at home (I wish) does not have enough room for a 10 meg application, will it ask me how much memory to use instead of just asking whether sucking up everything is alright? Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
g549863254ea@deneb.ucdavis.edu (0040;0000006816;0;581;142;) (05/19/89)
What will the status of 3rd party NuBus Memory boards be under system 7.0? Will the National Semiconductor NuBus boards be available to 32 bit clean Mac OS applications? How about 24 bit? Can one use 8 Meg NuBus and 1 Meg motherboard RAM as 9 Meg real RAM?
phil@Apple.COM (Phil Ronzone) (05/19/89)
In article <7356@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <30935@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes: >>Well, that is not economical. When we launched a version of Lode Runner >>under A/UX, guess who was watching the clock ticks rather than using an >>A-line trap? (A/UX normally updates the ticks much less frequently). > >Interestingly, when I was talking by e-mail with an Apple employee last >year about all the compatibility problems with 6.0, he told me that >Lode Runner was an example that proved that perfectly conforming >applications could be written. Guess that's now out the window. I correct myself. A/UX had the bug, not Lode Runner. (it still ran slow enough for me to get many many points ... :-) ). We fixed A/UX. Anyway, other postings may the right points about why it is BAD to look at low memory globals. +-----------------------------------------------------------------------------+ |Philip K. Ronzone, Apple Computer, 10440 Bubb Rd, MS 58A, Cupertino, CA 95014| |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft,...}!apple!phil | +-----------------------------------------+-----------------------------------+ | All "IMHOs" disclaimed and copyrighted. | Self defense is a human right ... | +-----------------------------------------+-----------------------------------+
tim@hoptoad.uucp (Tim Maroney) (05/20/89)
In article <811@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: >After watching this line of discussion for a while, I can't keep still >any longer. Could somebody please explain to me WHY all the applications >in a Mac with PMMU have to share their low-memory globals? Why not give >each one a copy? (That's what the 2nd 'M' in PMMU is for, right? 'Mapping'?) I believe that's what myself and others have been proposing. The only problem with it is that, if you'll look at the old Apple pages on low memory globals by location (don't ask me for copies, I only have it on paper) you'll see that system-invariant and application-switched globals are mixed up on the same pages of memory. Either all the low-memory globals need to be made "unreal" (that is, they are filled in for software by a special page fault handler), which is ugly, or some of them will have to be decommissioned, causing some compatibility problems. I support the latter. >As for the system heap now, that's a more difficult problem. A possible >solution would be to split it into a 'clean' and a 'dirty' part; then share >the 'clean' (i.e., readonly) part and copy the 'dirty' part for each >application. Wastes some memory, but it's VIRTUAL memory now! Besides, even if >the entire system heap needs to be copied for each application, I'd be quite >willing to pay that price for protecting my applications from each other >(and from my own stupidity :-). There's very little reason for most applications to mess about with the system heap except in read-only mode. Those others can be given some special flag to allow them to do it. An updater utility to set the flag would be under 20K, could readily be distributed over networks and by hand, and would not count as a real upgrade cycle. (However, I'm about as sure as sure can be that most applications will have to do a real upgrade with 7.0, just as they did with 6.0.) >That leaves thingies like drivers that must muck around with the system's >data. But those critters can trash any operating system (ask any UNIX victim). Yeah, too bad. Maybe some future Mac OS will figure out a way to prevent this, at least in RAM. Of course, any software that can diddle hardware registers and take over at interrupt time has incredible powers of destruction, so it'll never be really safe. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim These are not my opinions, those of my ex-employers, my old schools, my relatives, my friends, or really any rational person whatsoever.
tim@hoptoad.uucp (Tim Maroney) (05/21/89)
In article <25141@coherent.com> dplatt@coherent.com (Dave Platt) writes: [Accurate and thoughtful comments on low memory globals deleted.] >Consider what happens if your application loads a resource from >the System file (say, a FONT), and the memory manager is forced to >compact the system heap in order to free up a large-enough contiguous >block. CRUNCH! The compaction may move, purge, or coalesce blocks all >over the System heap in one swell foop. All of a sudden, the entire >heap is potentially dirty! No, that's not the application writing to the system heap. That's the OS writing to the system heap. OS code is always going to have the theoretical potential to screw up this kind of thing; it's Apple's responsibility to try to make the code so clean that it almost never does. And usually, they do pretty well at this. I understand much more of the OS is being written in high-level languages these days, which is a further aid to reliability. Routines like GetResource in the OS ought to run in supervisor mode and have read-write system heap access. It's applications that should have read-only access to the system heap, running in user mode. The situation you describe only dirties the heap as much as the OS can do (roughly epsilon), not as much as the application software can do (roughly aleph-null). And it works perfectly well with the application in read-only mode. >To make matters a bit worse, you can't simply protect the System heap >against modification by application code running in user-state. You >must also protect it against modification by code in the OS itself >that's performing tasks on behalf of the user! For instance, there's >really no difference between the user storing blindly into the middle of >the heap, and the user calling FSRead to read several hundred bytes into >a buffer that's allocated in the System heap... either of these events >can trash the universe. That's true. Fortunately, there is a long tradition of kernel code checking its buffers and sizes in memory protected environments. In UNIX implementations, this is often done using a special (and fairly slow) block move routine that copies from kernel to user space. It checks each address written to make sure the user process it's working on behalf of is allowed to write into that address. >In order to prevent kernel-trashing-the-heap conditions, you must either >add code to _every_ OS & toolbox routing that manipulates user-specified >memory (checking the specified pointers for safety), or protect the >System heap itself against modification _by_the_OS_, and then (when a >store-violation occurs) decide whether the specified change to the heap >is "valid". Both of these approaches are expensive in time and/or in >programming effort, and they're tricky to get right. I don't think there are all that many places where user buffers need to be checked in the Mac OS. I think the former approach is clearly the way to go; the latter might work, but it would be a mess. Context sensitive special page fault handlers -- yecch. However, a compromise solution might work. Memory permissions could be raised for some system calls but not for others. For instance, BlockMove can only correctly be used to copy from the caller's space to the caller's space, so it can run with its caller's protection. Most status calls that return something into a pointer variable may need to read system space, but won't need to be able to write it, so they can be set up without any expanded write protections. There is complexity, but the problem is soluble given Apple's huge resources in Mac programming expertise. But they have to decide to do it first! >I suspect that you'd rapidly reach the point at which every application >would have a completely separate copy of the System heap. This isn't >too terrible a problem if you have virtual memory and a fast enough >disk, but it does eliminate one of the major advantages of the >MultiFinder approach (only one copy of any particular System resource is >in physical memory at any one time). I don't see why there would need to be multiple system heaps. One more note: According to a reliable source, A/UX is only sort of 32-bit clean. It changes into 24-bit mode before calling the ROMs, which, claims of various people aside, are *not* now 32-bit clean. The source is an experienced A/UX hacker who has disassembled some of its internals, and who will remain nameless for that reason. This fact about the non-32-bit-clean ROMs is acknowledged twice in the Developer Conference Q&A, albeit obliquely, and confirmed by sources within Apple. I deeply resent being flamed for pointing out the truth, especially the documented truth. Re-read the questions and answers on 32-bit mode before flaming again. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Prisons are built with stones of Law, Brothels with bricks of Religion." - Blake, "The Marriage of Heaven and Hell"
DN5@PSUVM.BITNET (05/22/89)
Question:
Sean Parent (from Apple) claimed all currently existing print drivers would
fail under 7.0. This is very reasonable, and I expected this. My question
is, on an AppleTalk network, with different size Macs (1 Meg vs. 5 Meg),
connected to the same LaserWriters, will they ALL have to upgrade to the
new system 7.0, or will some provision be made for using system 6.xx and
system 7.0 on the same network.
If we can't use different systems (with the different LaserWriter drivers)
effectively, then this cuts me out of system 7.0 (with my Mac II), because
most of the rest of the Macs are 1 Meg with no upgrade plans in the near
future.
D. Jay Newman (Jay, etc...)
DN5 at PSUVM.BITNETjln@accuvax.nwu.edu (John Norstad) (05/23/89)
In article <89142.094457DN5@PSUVM> DN5@PSUVM.BITNET writes: >on an AppleTalk network, with different size Macs (1 Meg vs. 5 Meg), >connected to the same LaserWriters, will they ALL have to upgrade to the >new system 7.0, or will some provision be made for using system 6.xx and >system 7.0 on the same network. We were assured at the Developer's conference that mixed 6.xx and 7.0 networks would work fine without the dreaded "LaserWars." However, LaserWriter 5.2 and 6.0 are incompatible. John Norstad Academic Computing and Network Services Northwestern University Bitnet: jln@nuacc Internet: jln@acns.nwu.edu AppleLink: a0173 CompuServe: 76666,573
tim@hoptoad.uucp (Tim Maroney) (05/24/89)
In article <89142.094457DN5@PSUVM> DN5@PSUVM.BITNET writes: >Sean Parent (from Apple) claimed all currently existing print drivers would >fail under 7.0. This is very reasonable, and I expected this. Yes, I think all of us programmers have been hoping for a Print Manager rewrite ever since the first time we read the chapter. I'm very glad that they've done it, or are doing it. I hope it really is as easy as they say to write a new driver for 7.0, though; otherwise, a lot of us are going to be up the proverbial creek, myself included. There didn't seem to be any specific pre-documentation of the new format in the conference notebooks I browsed, and I wonder when some more detailed information will be available. >My question >is, on an AppleTalk network, with different size Macs (1 Meg vs. 5 Meg), >connected to the same LaserWriters, will they ALL have to upgrade to the >new system 7.0, or will some provision be made for using system 6.xx and >system 7.0 on the same network. According to the information Apple released, 6.0 and 7.0 LaserWriter drivers will be able to share printers with no hassles. However, concerning your upgrade plans, I've been quoted prices as low as $130 for one-megabyte SIMMs, and prices are continuing to drop. By the time System 7.0 is released (first quarter 1990, perhaps?) it ought to be quite cost effective to upgrade your one megabyte computers. >If we can't use different systems (with the different LaserWriter drivers) >effectively, then this cuts me out of system 7.0 (with my Mac II), because >most of the rest of the Macs are 1 Meg with no upgrade plans in the near >future. You're in luck.... -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "What's bad? What's the use of turning? In Hell I'll be there a-burning! Meanwhile, think of what I'm earning! All on account of my name." - Bill Sykes, "Oliver"
alexis@ccnysci.UUCP (Alexis Rosen) (05/24/89)
I've been watching this discussion for a while, but nobody seems to have
come up with this, so...
The arguments about why we can't have complete memory protection are fairly
convincing (disgusting perhaps, but convincing). This doesn't address why we
can't have preemptive multitasking, but there are surely other good reasons
for this lack. I would like something much simpler- so simple that it would
probably take hours, or a few days at most, for someone doing OS work at Apple,
but so integrally liked to the OS that it would probably be impossible for
anyone else to do.
Why can't we have a little program that takes a chunk of memory and boots a
new Mac inside of this memory? In fact, you could probably boot System 6.0
on this virtual Mac, but I won't push things. (You could probably also run it
in 24-bit mode while leaving the rest in 32-bit mode.) This would solve all of
the compatability problems with one stroke.
Actually there are a few gotchas, but I don't see them as major problems. The
primary difficulty that I can see is that the disk drive may be altered by
one virtual Mac and the other would get confused. But since Apple has their
personal AppleShare code nearly done, they could simply install the appropriate
External File System in the new virtual Mac so that it would think its disk
was being shared. This way any alterations to the disk would be dealt with
properly.
To be honest, I'm surprised that Connetix hasn't offered multiple "virtual
Macs" as a feature of their product already.
---
Alexis Rosen
alexis@ccnysci.{uucp,bitnet}
alexis@rascal.ics.utexas.edu (last resort)phil@Apple.COM (Phil Ronzone) (05/25/89)
In article <2086@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: >Why can't we have a little program that takes a chunk of memory and boots a >new Mac inside of this memory? In fact, you could probably boot System 6.0 >on this virtual Mac, but I won't push things. (You could probably also run it >in 24-bit mode while leaving the rest in 32-bit mode.) This would solve all of >the compatability problems with one stroke. Well, in way you have that when you use A/UX. Some questions that arise when this is done: Do you have a sophisticated enough virtual memory manager? Assuming this is pre-emptive (no?) how do you control access to non-rentrant toolbox code? And so on ... Rick Daly can tell you more gory details ... +-----------------------------------------------------------------------------+ |Philip K. Ronzone, Apple Computer, 10440 Bubb Rd, MS 58A, Cupertino, CA 95014| |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft,...}!apple!phil | +-----------------------------------------+-----------------------------------+ | All "IMHOs" disclaimed and copyrighted. | Self defense is a human right ... | +-----------------------------------------+-----------------------------------+
boone@oce.orst.edu (Jeff Boone) (05/25/89)
In article <1856@internal.Apple.COM> casseres@apple.com (David Casseres) writes: >In article <8321@pucc.Princeton.EDU> FTWILSON@pucc.Princeton.EDU >(Frederick Todd Wilson) writes: >> Just let me get this straight, once and for all. I've read all the >System 7 >> stuff out there just like I'm supposed to, and the stuff about the >outline >> fonts seems to boil down to something Apple hasn't actually said: with >> outline fonts you'll be able to get current LaserWriter IINT/NTX print >> quality out of a IISC. Is this right? > >Well, I'm no longer involved in printing at Apple, but note that even >today, the IISC gives slightly better than PostScript quality as long as >you stick to the few fonts and sizes that are supported. The new outline >font stuff is specifically aimed at supporting ALL sizes, and there will >be a lot of fonts in the new format. But also notice that there's more to >PostScript than font rendering. There's splines, and arbitrary rotation, >and so forth. The new printing stuff addresses some of these areas, such >as halftoning, but not all. > >David Casseres This all sounds great for text, but what about graphic artists who use software like Adobe Illustrator? I have a friend who makes his living with a Mac and Illustrator. He "proofs" his work on the LaserWriter, then when he has it to his satisfaction, he takes it to the print shop and has it output on the Linotronic (which speaks only postscript). If Apple dumps Postscript altogether, I think they will be forcing alot of graphic designers/publishers into an alternative platform (NeXT) which would be very unfortunate. ---------------- Jeff Boone boone@oce.orst.edu College of Oceanography, Oregon State University "My opinions" From: boone@oce.orst.edu (Jeff Boone) Path: boone@oce.orst.edu Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: Re: System 7.0 Q & A Expires: References: Sender: Reply-To: boone@oce.orst.edu (Jeff Boone) Followup-To: Distribution: world Organization: College of Oceanography, Oregon State Univ., Corvallis, Or. Keywords: In article <1856@internal.Apple.COM> casseres@apple.com (David Casseres) writes: >In article <8321@pucc.Princeton.EDU> FTWILSON@pucc.Princeton.EDU >(Frederick Todd Wilson) writes: >> Just let me get this straight, once and for all. I've read all the >System 7 >> stuff out there just like I'm supposed to, and the stuff about the >outline >> fonts seems to boil down to something Apple hasn't actually said: with >> outline fonts you'll be able to get current LaserWriter IINT/NTX print >> quality out of a IISC. Is this right? > >Well, I'm no longer involved in printing at Apple, but note that even >today, the IISC gives slightly better than PostScript quality as long as >you stick to the few fonts and sizes that are supported. The new outline >font stuff is specifically aimed at supporting ALL sizes, and there will >be a lot of fonts in the new format. But also notice that there's more to >PostScript than font rendering. There's splines, and arbitrary rotation, >and so forth. The new printing stuff addresses some of these areas, such >as halftoning, but not all. > >David Casseres This all sounds great for text, but what about graphic artists who use software like Adobe Illustrator? I have a friend who makes his living with a Mac and Illustrator. He "proofs" his work on the LaserWriter, then when he has it to his satisfaction, he takes it to the print shop and has it output on the Linotronic (which speaks only postscript). If Apple dumps Postscript altogether, I think they will be forcing alot of graphic designers/publishers into an alternative platform (NeXT) which would be very unfortunate. ---------------- Jeff Boone boone@oce.orst.edu College of Oceanography, Oregon State University "My opinions"
casseres@apple.com (David Casseres) (05/26/89)
In article <10802@orstcs.CS.ORST.EDU> boone@oce.orst.edu (Jeff Boone) writes: > In article <1856@internal.Apple.COM> casseres@apple.com (David Casseres) writes: > >In article <8321@pucc.Princeton.EDU> FTWILSON@pucc.Princeton.EDU > >(Frederick Todd Wilson) writes: > >> ... something Apple hasn't actually said: with > >> outline fonts you'll be able to get current LaserWriter IINT/NTX print > >> quality out of a IISC. Is this right? > > > >Well, I'm no longer involved in printing at Apple, but note that even > >today, the IISC gives slightly better than PostScript quality as long as > >you stick to the few fonts and sizes that are supported. The new outline > >font stuff is specifically aimed at supporting ALL sizes, and there will > >be a lot of fonts in the new format. But also notice that there's more to > >PostScript than font rendering. There's splines, and arbitrary rotation, > >and so forth. The new printing stuff addresses some of these areas, such > >as halftoning, but not all. > This all sounds great for text, but what about graphic artists who > use software like Adobe Illustrator? I have a friend who makes his > living with a Mac and Illustrator. He "proofs" his work on the > LaserWriter, then when he has it to his satisfaction, he takes it > to the print shop and has it output on the Linotronic (which speaks > only postscript). You're quite right. QuickDraw is still QuickDraw, and does not have the same graphics capabilities as PostScript. > If Apple dumps Postscript altogether, I think they will be forcing > alot of graphic designers/publishers into an alternative platform > (NeXT) which would be very unfortunate. Indeed it would, which is why Apple said at the developers' conference that it will continue to support PostScript. Apple is NOT dumping PostScript, by any stretch of the imagination. David Casseres Exclaimer: Wow!
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/26/89)
In article <10802@orstcs.CS.ORST.EDU> boone@oce.orst.edu (Jeff Boone) writes: >This all sounds great for text, but what about graphic artists who >use software like Adobe Illustrator? I have a friend who makes his >living with a Mac and Illustrator. He "proofs" his work on the >LaserWriter, then when he has it to his satisfaction, he takes it >to the print shop and has it output on the Linotronic (which speaks >only postscript). > >If Apple dumps Postscript altogether, I think they will be forcing >alot of graphic designers/publishers into an alternative platform >(NeXT) which would be very unfortunate. Apple has stated that they intend to maintain support for PostScript in their product line. Since PostScript is on the whole more versatile for certain types of graphic effects than QuickDraw, I think that this will not be likely in the near future. So don't worry about Apple dumping PostScript. Their current innovations with outline fonts and the like are, I think, intended mainly to bring some of the benefits of PostScript to the non-PostScript user, rather than to force QuickDraw into the low-level printing process in cases where it isn't now. -- Mark Wilkins
ech@pegasus.ATT.COM (Edward C Horvath) (05/27/89)
In article <10802@orstcs.CS.ORST.EDU> boone@oce.orst.edu (Jeff Boone) writes: >If Apple dumps Postscript altogether, I think they will be forcing >alot of graphic designers/publishers into an alternative platform >(NeXT) which would be very unfortunate. From article <1328@jarthur.Claremont.EDU>, by wilkins@jarthur.Claremont.EDU (Mark Wilkins): > Apple has stated that they intend to maintain support for PostScript in > their product line...Their current innovations > with outline fonts and the like are, I think, intended mainly to bring some > of the benefits of PostScript to the non-PostScript user, rather than to > force QuickDraw into the low-level printing process in cases where it isn't > now. To add additional support to this view, note that the new print architecture includes three standard rendering packages: QD->raster, QD->vector, and QD->PostScript. The second is new, the last writes "generic" (i.e. not LaserWriter-dependent) PostScript (The bit about LW-indep may or may not be in the conference proceedings: it was the verbal response to my direct question at the printing session). Perhaps more to the point, Adobe has agreed to provide a converter for Apple-to-Adobe font translation, so the graphic designer will have more options, not fewer, along with superior on-screen rendering. Presumably Linotronic, if they haven't agreed to already, will also accept Apple outline fonts (I don't remember). Given the large amount of Mac-draft and Lino-final DTP out there, I'd be surprised if they didn't... =Ned Horvath=