Letters - A Written Adventure (First Prototype) Mac OS
Letters - A Written Adventure (First Prototype) Mac OS
- Letters - A Written Adventure (first Prototype) Mac Os X
- Letters - A Written Adventure (first Prototype) Mac Os Download
- Letters - A Written Adventure (first Prototype) Mac Os X
To make sure the converted City name is injected into the database, lowercased and first letter capitalized, then you would need to use JavaScript before you send it over to server side. CSS simply styles, but the actual data would remain pre-styled. Letters - a written adventure Letters is a fun word puzzle game about friendship, growing up and finding your place in life. Follow Sarah, a shy girl from Switzerland, by moving through her pen pal letters and chat messages. Use the power of words to solve riddles, interact with her friends and decide who she will grow up to be. This is the universal binary Mac OS X version of Fire Line, that.should. run on all most recent Mac systems. I have not tested it myself (because I don’t have a Mac), but I’m going put my trust in the Unity 3D project compiler and builder (at least this time, don’t ask about all the Mono Develop related script compilation crashes). During the winter of 1985, Sculley dropped all plans to license the Mac OS, only one year after he sent Chuck Berger to drum up support for the plan. Macintosh sales were collapsing. Apple had originally forecasted that it would sell 50,000 Macs a month during 1985, but the real figure was closer to 20,000.
2 Years ago11 Feb 2019 7:48 pm by Dog Cow
Apple had already been bitten by the cloners: unscrupulous companies who duplicated the Apple II motherboard and its ROM and sold unauthorized copies. Steve Jobs wasn't going to let that happen again with Macintosh. Per his orders, a small icon which read 'Stolen from Apple Computer' was embedded in the ROM. Unlike the Apple II, whose commented 6502 ROM source was printed in its reference manuals, the Macintosh ROM source was a closely-guarded secret. Thus the Macintosh ROM remains one of the most mysterious aspects of the machine.
But as Sherlock Holmes famously said in The Adventure of the Dancing Men, 'What one man can invent another can discover.' With this adage in mind, let us begin on a voyage of discovery into the Macintosh 64K ROM with MacsBug.
Where is the ROM Located?
This is a question with two answers. If you are asking where is the ROM physically located? the answer is in two chips on the motherboard, labelled ROM HI and ROM LOW, respectively. The 64 kilobytes of data in ROM is split in half between these two chips. The 'HI' chip holds the high-byte of each address in ROM, while the 'LOW' chip holds the low-byte.
To visualize what half means in this case, imagine a book with 64 pages. You take a pair of scissors and cut each page in half vertically. So you have the left half of 64 pages, and the right half of 64 pages. Call the left half 'HI' and the right half 'LOW', and now you have the equivalent of how the Mac ROM is divided.
The HI ROM is Apple part number 342-0220-B while the LOW ROM is 342-0221-B There was an earlier revision of the ROM, with suffix -A. This ROM has a slightly different Sony disk driver which is only compatible with early model Sony OA-D34V 400K disk drives. The -B ROM revision is compatible with both early and later model Sony drives.
The Mac has two ROM chips located near the 68000 microprocessor
Notice one big difference between these two chips and the other 49 on the motherboard: the two ROM chips are the only ones socketed. All other chips are soldered to the motherboard. Macintosh was designed with a future ROM upgrade in mind. The original Macintosh ROM is only 64K in size, but the motherboard has 16 address lines for the ROM sockets, granting a maximum capacity for 128K of ROM.
Where is the ROM logically located?
Now here is the second answer to the question. Where is the ROM logically located within the 68000 CPU's address space? The 68000 has a 24-bit address space meaning there are 16,777,215 memory locations, or 16 MB. This address space is divided into quarters, meaning that 4 MB of space is reserved for ROM.
ROM is mapped into memory starting at address $400000 (decimal 4,194,304). It's physically impossible for there to be 4 MB of ROM (without modifying the logic board), so the 64K ROM ends up being repeated several times. The last byte of ROM is at location $40FFFF. Accessing the next location, $410000, brings you back to the beginning of ROM, and it continues on, wrapping around a dozen or more times.
The ROM's base address is stored in global variable ROMBase which is stored in low-memory at $2AE. Assembly language programmers should use ROMBase to determine the ROM's location. The wrapping around effect described previously is merely trivia and should not be used in any code you write for Macintosh.
At the very earliest stages of system startup, the Mac ROM is also located at address 0. This location allows the 68000 CPU to access some hard-coded vectors, stored in ROM, that it needs for initialization. The Synertek SY6522 VIA vOverlay bit is used only during system startup to cause the ROM to appear at the bottom of memory. After the RAM is tested, the overlay bit is cleared, placing RAM starting at location 0 as usual and ROM at $400000.
What is in the ROM?
ROM is the Macintosh's permanent read-only memory and contains information and instructions that give the Mac its look, feel, and personality. While your data on disk may change and contents of RAM be altered, Apple Computer personally guarantees that the ROM will never change while your Macintosh is running.
There are about 480 routines in ROM, which can be divided into 3 main groups:
- Operating System
- User Interface Toolbox
- QuickDraw
Each of these groups consumes roughly 1/3 of the 64K of ROM. The majority of the Mac's Operating System is in fact stored in ROM, not on your startup disk. The System file merely contains resources for localization, keyboard mapping, desk accessories and fonts, some icons, and other resources that customize the way the Mac works. The Operating System in ROM contains the Memory Manager, Segment Loader, File Manager, Device Manager, Disk Driver, Serial Drivers, Vertical Retrace Manager, among others. These are all low-level routines that don't have any impact on the Mac's user interface.
Now the User Interface Toolbox in ROM gives the Mac its windows, menus, and icons interface! Within the Toolbox are found the Font Manager, Event Manager, Window Manager, Control Manager, Menu Manager, TextEdit, Dialog Manager, Scrap Manager, and so on. These managers control how the user interface works, but not what it looks like. As you may know, there are several types of windows. You can have a window with a black, rounded title bar, or a window with no scroll bars, or a window with no close box. The appearance of each type of window is stored in a
WDEF resource in your System file on disk. WDEF stands for Window Definition, and it's these definition routines that determine how the windows, menus, controls (such as scroll bars), and so on look.Using a WDEF resource that draws round windows in the Finder
The Window Manager in ROM does not assume rectangular windows. Its routines will move, close, resize, and redraw any window of any arbitrary shape. For example, it's possible to have round windows, or a window with a hole in it that shows part of the desktop. You can have menus with an icon next to each item. You can have custom controls beyond just radio buttons and scroll bars, such as an analog clock face, or a three-way toggle switch in your application. You could have circular scroll bars to work with your circular windows! These definition routines are all stored as resources on disk, not in ROM, precisely so they can be customized and changed.
The final block of code in ROM is QuickDraw, the patented graphics package for Apple Lisa and Macintosh, written single-handedly by Bill Atkinson. QuickDraw is about 40,000 lines of assembly source code, and is identical on Lisa and Macintosh. It is used to draw everything you see on screen: windows, icons, fonts, shapes, patterns, and so on. It is also used in the Print Manager to reproduce on paper an identical copy of what you see on screen.
Using MacsBug to Disassemble ROM
Now let's use MacsBug, the Macintosh debugger, to disassemble and explore the ROM. If you don't have MacsBug on your startup disk, refer to the MacsBug article on where to get it and how to install it. Among other places, MacsBug can be found on MDS Disk 2.
You should also have the Programmer's switch installed on the left side of your Mac to access MacsBug. In a pinch, you can use the round end of a paperclip to push the Interrupt button, but it's not an ideal solution, as you could hit the Reset button by mistake!
Once you have everything installed, boot your Mac, and at the Finder desktop, press the Interrupt button to enter MacsBug.
First, let's verify ROMBase. We will use MacsBug's DM (display memory) command. Type:
| Code: |
| DM 2AE |
After you press Return, you should see:
| Code: |
| >DM 2AE 0002AE 0040 0000 0000 0B00 |
There will be more to this line after 0B00, but we only care about the first 4 bytes which read $00400000. That's the location of the ROM.
Now let's examine the first 16 bytes of ROM. Type:
| Code: |
| DM @2AE |
This MacsBug command uses @ to make location 2AE a pointer.
You should see the following:
| Code: |
| 400000 28BA 4E50 0040 002A 0069 6000 0038 6000 |
At the far right will be the ASCII interpretation, but it's gibberish. Let's begin by dissecting these first 16 bytes of ROM.
The first 4 bytes $28BA4E50 is the ROM checksum. The next 4 bytes tell the 68000 where its program counter (PC) should initially point after reset. $40002A is the address of the BootStart routine in ROM. We'll explore this routine next.
The following two bytes, $0069 is the ROM version number. In decimal this is 105. $69 corresponds to 6.9 which was the final developmental version number of the Mac ROM. When the ROM was frozen in September 1983, it was called to ROM 7.0. The point is that version numbers $69, 105, 6.9, and 7.0 all refer to the same ROM version: the final release of the original 64K ROM.
The 128K ROM, used in the Macintosh 512Ke and Mac Plus, is version number $0075, or 117 in decimal.
After the 2-byte verion number, the remaining 6 bytes are 68000 instructions. These instructions begin at $40000A. Let's switch to using MacsBug's IL command to disassemble the machine code.
Type:
| Code: |
| IL @2AE+A |
At $40002A, shown with the red arrow in the screenshot above, is the entry point for BootStart. BootStart begins by checking location $F80000 for signature bytes $AA55. This was a hook for debugging hardware or software used in early Macintosh development. If the debugger wasn't found, then execution branches to $400044 to initialize the 68000 status register, address register A5, and continue with the rest of the startup procedures.
A future Mac 512K Blog article will explore the Mac's startup procedures in depth.
Tracing the Trap Dispatcher
Whenever an application or desk accessory wants to use a Macintosh Toolbox routine, it uses a 2-byte trap number to refer to the particular routine. The Trap Dispatcher in ROM looks up this number and calls the appropriate subroutine, which may be located in ROM or RAM. Andy Hertzfeld wrote the Trap Dispatcher, beginning in July 1982.
Here are a few common Toolbox routines and their corresponding trap numbers:
- AddResMenu - A94D
- DrawString - A884
- GetNewDialog - A97C
- InitCursor - A850
- Open - A000
- PackBits - A8CF
To the 68000 CPU, Macintosh Toolbox and Operating System traps look like a special set of instructions. The CPU recognizes, or traps these instructions, and hands them off to the Macintosh Trap Dispatcher for further processing.
The Trap Dispatcher, located in ROM, refers to a table of all possible code numbers with corresponding subroutine locations for each. To save space, the original 64K ROM has only one table to hold both Toolbox and Operating System traps. This table is kept in ROM, in a compressed format. When you startup the Mac, the table is copied into RAM at location $400 so that it may be patched to fix ROM bugs or add new traps.
There is room for only 512 trap entries, and each entry is 2 bytes long, making 1024 bytes total. The 128K ROM in the Mac Plus and 512Ke maintains separate tables for Operating System and Toolbox traps which allows for many more traps.
Let's trace and disassemble the Trap Dispatcher to learn more about how it works!
At the Finder desktop, press the Interrupt switch to enter MacsBug. Type
| Code: |
| AB LAUNCH |
MacsBug should appear immediately and show:
| Code: |
| MACTRAP A9F2 LAUNCH |
| Code: |
| DM DFF1FF |
You are now in the Trap Dispatcher, at its entry point $401018. But how did we get here? The Motorola 68000 CPU stores the location for all A-line traps in low-memory location $28. This vector is one of several for the various errors and exceptions which the 68000 must handle. The Macintosh designers decided to route just about all of the possible exceptions, except for A-line instructions for Toolbox traps, through a central Error Manager. This is the same Error Manager that shows the infamous bomb dialog.
If you type
| Code: |
| DM 28 |
Type
| Code: |
| IL PC |
Type S, then continue pressing Return to step through the Trap Dispatcher and see it in action. You will see that the trap code for Launch, A9F2, is copied from the stack into register D2. The code in D2 is then compared against #$A800. If the trap code is less than A800, it's an Operating System trap. Otherwise it's a Toolbox trap. The two traps are handled slightly differently when it comes to saving and restoring registers.
Launch happens to be a Toolbox trap used to run an application. The Trap Dispatcher computes an index into the dispatch table by first chopping off bits 9 thru 15 to yield an index number from 0 to 511. As mentioned earlier, the trap dispatch table only holds 512 entries. $A9F2 becomes $1F2. Each entry in the table is 2 bytes long, so D2 is doubled by adding it to itself, resulting in $3E4.
The address of the dispatch table, $400 is loaded into A2, and will be used as a base address to find the trap location in the table. The next instruction adds this base address $400 to D2, checks the value in the table, and saves the result, $2609 in D2.
You can verify this operation yourself by typing
| Code: |
| DM 400+3E4 |
Next, this value from the trap dispatch table is also doubled, again by adding D2 to itself, which yields $4C12. This value is an offset from a base address. But from which base address? The trap dispatch table can point to either ROM or RAM. Bit 15 of this offset is a flag: if set, the trap is in RAM; if clear, the trap is in ROM.
In this case, the high-bit is clear in $4C12 meaning that this is a ROM offset. The BCS instruction which tested for the high-bit will not branch. The next instruction will add ROMBase, stored in $2AE, to our offset in D2. ROMBase, as shown earlier in this article, is typically $400000.
At last we have computed the subroutine location for Launch. It is $400000 + $4C12 = $404C12. The next few instructions in the Trap Dispatcher push this address on the stack and then 'fake' an RTS to transfer control to the Launch subroutine in ROM. Apple II users will recognize this programming technique was also used in the Apple II Monitor.
If you have been following along thus far, pressing Return to step through each instruction in the Trap Dispatcher, you should have reached the RTS at $401042. After you press Return, you will see that you are at $404C12. Type
| Code: |
| WH PC |
The Trap Dispatcher has successfully done its job, and we have arrived at the Launch subroutine.
Disassembling a ROM routine
After learning how the Trap Dispatcher works, let's disassemble a ROM subroutine. We could continue using MacsBug's step command to trace through Launch, but let's look at another one instead so we have more opportunity for learning. There is a trap that will allow an application to specify a function that should be called when the Memory Manager needs to allocate more blocks of memory, called SetGrowZone. Let's disassemble this trap.
First we need to know the trap number. Appendix C of Inside Macintosh volume III has a table of trap names to numbers. SetGrowZone is on page III-222. Its number is A04B.
Now we can apply the same transformations as in the Trap Dispatcher. A04B is less than A800, so this is an Operating System trap. For OS traps, bit 8 is a flag to save/restore register A0. After checking this flag, bit 8 is cleared. Clear bits 8 thru 15 to get $4B. Double it to make $96. This is an offset within the trap dispatch table.
Recall that the trap dispatch table begins at $400, so add $400 to $96 to get $496. Type
| Code: |
| DM 496 |
Aha! Because this trap offset is pointing to a RAM location, we know that its address was patched by the System file.
RAMBase is stored at low memory global $2B2. Type
| Code: |
| DM 2B2 |
Due to the limits of a 15-bit offset, RAM patches can only be located within the first 64K of RAM. This limitation is no hardship for a Mac 128K, but it is something to be aware of for the Mac 512K. For this reason, RAM patches are typically loaded into the System Heap, which usually begins at $B00.
If an application patches a trap, it is possible for the patched code, stored in the application heap, to be beyond the 15-bit offset range.
Let's disassemble SetGrowZone by typing
| Code: |
| IL 26B2 |
This subroutine is very short, only four instructions, which makes it good for an example.
This subroutine takes a single argument in register A0, the address to a grow zone procedure. The address of the current heap zone record is loaded from low memory global TheZone at address $118. The grow zone procedure is stored within this record. The subroutine returns a result code in D0, which is always 0 for success, before returning to the caller with RTS.
Letters - A Written Adventure (first Prototype) Mac Os X
This routine is so simple; why was it patched in the first place? Let's compare with the original in ROM. SetGrowZone is located at $402C3C. If you disassemble it, you'll see that the only effective difference is the offset in the heap zone record used to store the grow zone procedure. In ROM, it's $10. The patched version was $2C.Why the change in offset? I'll leave that as an exercise for the reader, with a note that Inside Macintosh, page II-23 for the Memory Manager has a warning not to store directly into the gzProc field, and instead use the InitZone or SetGrowZone procedures. Within the heap zone record, gzProc is offset $10, while $2C points to sparePtr.
Stolen from Apple Computer!
Andy Hertzfeld did a good job of telling the story behind this icon, hidden in the ROM of every Macintosh, in his Folklore blog. The idea was Steve Jobs'. Susan Kare drew an icon showing a face behind jail bars, while Steve Capps wrote a routine to compress the icon and make it difficult to detect.
All that was necessary was to use MacsBug to execute a hidden subroutine to decompress and display this little icon on the screen.
screenshot from Andy Hertzfeld's Folklore blog
This icon was later simplified to remove the jail bars, and is just 24 pixels tall instead of the usual 32. The subroutine to display the icon is located at $40AD26 while the icon data is located just beyond, at $40AD40. The icon is 96 bytes long, un-encoded bitmap. Steve Jasik, author of the MacNosy disassembler, was among the first to discover this hidden icon in 1985. An identical icon exists in a prototype Twiggy Mac ROM from mid-1983, suggesting that the jailbar icon antedates it by some months.
In MacsBug, type
| Code: |
| G 40AD26 |
Stolen from Apple Computer! This is the most well-known icon, but a different one lurks in ROM too
Better ROM Disassembly
If you're interested in a better tool for ROM disassembly, try MacNosy by Steve Jasik, the original power-user's disassembler. It has far more tools than MacsBug, and will convert numbers and offsets to symbolic names and equates.
At the tail end of ROM, $40FFF8 are two sets of initials. The first is RHS for Rony H. Sebok. The second is WDA for William D. Atkinson. Enter DM 40FFF8 in MacsBug to see these initials. Earlier or later versions of the Mac ROM may have more initials.
That's all for this Mac 512K Blog article! Join me next time as I experiment with an Micro Asanté Print LocalTalk bridge to connect a Mac 512K to an Ethernet network.
| The Mac 512K Blog wrote: |
| This blog chronicles the Macintosh 512K and my projects with it. We will test software, fix hardware, program it, hack it, and generally take the 512K Macintosh to its limits. Do leave any feedback you may have, either to my email dog_cow@macgui.com or by posting a comment to this article. |
« MacIP: TCP/IP Stack for Mac 128K and 512K • Micro Asanté Print LocalTalk to Ethernet Bridge »
Microsoft was deeply involved in the development of the Macintosh. Microsoft had been the first outside developer to get a Macintosh prototype. The prototype was promptly nicknamed SAND (Steve’s Amazing New Device) by Bill Gates and Charles Simonyi.
Microsoft developed productivity software that the Macintosh desperately needed to make the Macintosh a contender in corporate markets.
License This
After the public unveiling of the Macintosh, Bill Gates personally wrote John Sculley, urging him to license the software and ROMs to outside manufacturers so that the Macintosh would become the new standard in personal computing. (This was two years after Microsoft began development of Interface Manager, which was renamed Windows shortly before release.)
The proposal, dated June 25, 1985, was soundly rejected by Jean-Louis Gassée, who was given control of the Macintosh and Lisa after Steve Jobs had been stripped of management responsibilities. Gassée reasoned that the Macintosh was so vastly superior to the existing PC graphical environments that Apple would never face any serious competition and would be able to rely on profit-rich hardware sales (with margins over 55% until the early 90s).
Besides protecting profits, Gassée was probably a little distrustful of Microsoft’s motives. It was in Microsoft’s interest to maintain the IBM PC standard for as long as possible, since Microsoft controlled most of the operating system market and most of the developer’s tools market. In Gassée’s mind, the proposal could have been an attempt to sabotage the Macintosh.
In later interviews, however, Bill Gates points out that Microsoft made a lot more money selling a Mac user a copy of Word and MultiPlan (the predecessor of Excel) than selling an OEM DOS license, so a Macintosh standard would have benefited both companies in the long term.
Despite Gassée’s objections to the plan, Sculley believed that it could help Apple establish the Macintosh as the personal computer standard, supplanting the IBM PC and MS-DOS.
Letters - A Written Adventure (first Prototype) Mac Os Download
Sculley had Dan Eilers, one of his aides, prepare a list of possible licensing deals. The list of suggestions included selling entire system boards to manufacturers, porting the Macintosh software to the IBM PC and selling the software to consumers, partnering with a workstation vendor, and others.
Salivating Over the Mac OS
Armed with a list of proposals, Sculley sent a vice president, Chuck Berger, to travel the nation talking to possible Macintosh licensees. Interest was astounding. Eilers and Gates had both suggested consumer electronics companies with no presence in the US computer market, but Berger found that even large, well established companies were interested in licensing the Macintosh. Apollo, DEC, and Wang all gave Berger letters of intent.
By far the most promising prospect was AT&T. The company was so interested in bundling the Macintosh software on its Unix workstations that CEO Bob Allen personally contacted John Sculley.
Apple was poised to license the Macintosh software to several major manufacturers and get the Macintosh standard firmly established in the business market, but Gassée would have none of it. He became more and more adamant in his opposition to the plan. He wouldn’t have any other company cannibalize Apple’s Macintosh sales, even if it meant establishing an industrywide standard.
Forget It
During the winter of 1985, Sculley dropped all plans to license the Mac OS, only one year after he sent Chuck Berger to drum up support for the plan.
Macintosh sales were collapsing. Apple had originally forecasted that it would sell 50,000 Macs a month during 1985, but the real figure was closer to 20,000.
With Macintosh sales tanking and no licensee in sight, Gates pressed ahead with Windows. On November 15, 1985, in the midst of the COMDEX trade show, Gates revealed Windows to a lukewarm response.
There were already other companies with far more impressive environments than Windows. Digital Research GEM mimicked the Mac interface almost perfectly – and had color to boot. VisiCorp VisiOn had a built-in office suite. Tandy DeskMate was bundled on every PC compatible Radio Shack (then one of the largest cloners) sold.
Windows 1.0 ‘No Threat’
Microsoft Windows 1.0 had a tiled interface; windows couldn’t overlap each other. Instead, users could move windows around like a jigsaw puzzle.
Windows 1.0 with its tile interface (rescaled from 640 x 350 EGA display)
When a user only needed one app at a time, he or she could zoom it to take up the entire display. Apps could also be minimized to the “desktop”, a dock running along the bottom of the screen.
When Gassée saw Windows 1.0, he dismissed the software as no threat.
But when Sculley saw the software, he was enraged. Microsoft had been provided early prototypes of the Macintosh and some source code to help optimize Word and MultiPlan. Now Windows had a menu bar almost identical to Apple’s. Windows even had a Special menu, containing disk operations. Other elements were strikingly similar. Windows came bundled with Write and Paint, both mimicking Apple’s MacPaint and MacWrite.
Sculley couldn’t allow Microsoft, a company that had only $25 million in sales in 1983 (compared to Apple’s revenues well over $1 billion) to so flagrantly rip off the Mac, even if Word and MultiPlan accounted for two-thirds of all Macintosh software sales.
He dispatched an Apple lawyer, Jack Brown, to Microsoft’s headquarters to threaten Bill Gates with a lawsuit for violation of Apple’s copyrights on the Macintosh.
Toe to Toe
Gates was incensed. Development of Windows had begun before the Macintosh was even demonstrated to Microsoft. Besides, Microsoft had licensed GUI elements from Xerox, including a desktop-style interface used on the Xerox 8010, the commercial version of the Alto. (Apple had also licensed the GUI from Xerox for $100 million in Apple stock.)
Bill Gates supposedly called Sculley personally and told him that if Apple was going to sue Microsoft, “I want to know it, because we’ll stop development on all Mac products. I hope we can find a way to settle this thing. The Mac is important to us and to our sales.”
Gates and Microsoft’s chief counsel, Bill Neukom, flew down to Cupertino, and he met with Sculley in the boardroom one-on-one.
Sculley couldn’t leave the meeting without some sort of concession from Microsoft, and Gates wanted Apple’s cooperation in the nascent (and highly profitable) Microsoft Office.
Both men wanted to avoid a drawn out lawsuit. Gates was gearing up for the wildly successful Microsoft IPO, and Sculley was still trying to popularize the Macintosh.
Ultimately, Sculley agreed to license the Macintosh’s “visual displays” to Microsoft to use in software derived from Windows 1.0, and Microsoft agreed to continue developing its Mac products and promised not to release Excel (a feature-rich replacement for MultiPlan) for any other platform for two years.
Sculley had Al Eisenstat, Apple’s chief counsel, draw up a contract, and the two men signed on November, 22 1985, exactly one week after Windows 1.0 was released.
After the contract was signed, Sculley implemented a major reorganization that structured the company more like a traditional corporation with accountable executives. Pie in the sky projects like BigMac, a project to create an Apple workstation running a Unix-Macintosh hybrid, were canned. Sales began to improve in 1986, and by 1987 Apple’s net income had doubled over 1985. Sculley was being lauded in the press for his turnaround at Apple and was being considered a possible successor to Kodak’s struggling CEO.
Windows 1.0 Fails to Open Market
Meanwhile, the first version of Windows failed to catch on. The only major application written for Windows 1.01 (the first version available to the public) was Aldus PageMaker. PageMaker was actually bundled with a runtime version of Windows, since almost no PC user owned Windows.
That began to change with the release of Windows 2.0 on November, 1 1987.
Windows 2.0 with overlapping windows (reduced from 640 x 480)
Windows 2.0 was a huge improvement over version 1.0, and Sculley recognized it. The new version offered overlapping windows, multitasking, and a limited object oriented environment (through a rudimentary version of OLE).
Besides the new features, Windows 2.0 actually had programs for it. During the press conference, Microsoft revealed that it had finished developing Microsoft Word for Windows and Microsoft Excel for Windows, and that outside companies including Aldus, Corel, and Microtek were all working on Windows 2.0-compatible programs.
Sculley was shocked at how much Windows 2.0 resembled the Macintosh, and he believed this to be a breach of contract. Sculley, along with most of the Apple legal team, believed that the November 1985 agreement gave Microsoft permission to use Macintosh displays in Windows 1.x, but not in any later versions.
Letters - A Written Adventure (first Prototype) Mac Os X
Talk to the Judge
Without warning, Apple filed suit against Microsoft in federal court on March 17, 1988 for violating Apple’s copyrights on the “visual displays” of the Macintosh. (Apple also filed suit against HP for its NewWave environment that ran on top of Windows 2.0.)
Apple’s suit included 189 contested visual displays that Apple believed violated its copyright.
Microsoft countersued, but it failed to stem the bad publicity. Windows’ development community was terrified that any court ordered changes to the software would render their products incompatible and make Windows undesirable to consumers. Borland’s CEO said it was like “waking up and finding out that your partner might have AIDS.”
Fortunately for Windows developers, Judge W. Schwarzer ruled on July 25, 1989, that 179 of the 189 disputed displays were covered by the existing license, and most of the other ten were not violations of Apple’s copyright due to the merger doctrine (the merger doctrine stipulates that ideas cannot be copyrighted). In the case of Apple vs. Microsoft, many of the displays Apple contested were ideas and could not be protected by copyright.
The lawsuit was decided in Microsoft’s favor on August 24, 1993.
Strained Relationship
The lawsuit single-handedly tainted Microsoft-Apple relations until 1997, when Microsoft pumped $100 million into Apple.
The 1985 agreement hurt Sculley almost as much as the judgment did. Mac users everywhere were shocked that the Apple CEO would give Microsoft unfettered access to the Macintosh interface in exchange for Excel and Word.
Apple appealed the ruling and made it all the way to the Supreme Court, which declined to hear the case.
Further Reading
- MultiPlan, Wikipedia
- Apple Confidential 2.0, Owen W Linzmayer
- COMDEX, Wikipedia
- GEM, Wikipedia
- VisiOn, Wikipedia
- DeskMate, Wikipedia
- Adobe PageMaker (originally Aldus PageMaker), Wikipedia
- OLE (Object Linking and Embedding), Wikipedia
- HP NewWave, Wikipedia
- Merger doctrine, Wikipedia
- Apple Computer, Inc. v. Microsoft Corp., Wikipedia
Keywords: #applevsmicrosoft #microsoftguilawsuit #windowsguilawsuit
Short link: http://goo.gl/qUV7RM
searchword: applevsmicrosoft
Images adapted from ToastyTech.
Letters - A Written Adventure (First Prototype) Mac OS