FAQ

Having problems? See Help for solutions common problems.

What is DeskTop for?

Like the macOS Finder or the Windows File Explorer, DeskTop is an application for navigating and managing files on your ProDOS 8 disks and launching programs. It runs on the Apple IIe, IIc and compatibles.

If you don't need to manage files, or only ever run programs by booting floppy disks or running the amazing Total Replay, it's probably not for you.

Can I run DeskTop off of 5.25" floppies?

Technically yes, but you probably don't want to or need to. See the previous question. If you're not managing files on an 800k or larger ProDOS disk, you probably don't need Apple II DeskTop. 

Also, there is only enough room on a 140k floppy disk for ProDOS and parts of Apple II DeskTop, so you don't get any Desk Accessories. 140k disk images are available in the download packages, but they are really intended as a way to get the files onto your system to copy onto a hard drive.

Is DeskTop available in other languages?

Yes! Click the download link and you will find download packages available for the following languages:

Are there applications for Apple II DeskTop?

Yes and no...

Yes, any ProDOS app is compatible with DeskTop, whether it's AppleWorks, ShrinkIt, or MousePaint.

"But wait!" you say. "I mean GUI applications that run in DeskTop!" 

What does that actually mean? 

The original 128k Macintosh seemed revolutionary. Every application had the same look and feel. You started off in the Finder, and launched MacWrite. When you quit, you were back in the Finder. Then you launched MacPaint, edited a picture, and quit right back to the Finder. It seemed like you never left the desktop GUI provided by the Finder app. But... that was an illusion. Until systems had more memory and the MultiFinder was released several years later, the Finder was completely replaced in memory when another application was run, and reloaded when the other application exited. The experience was seamless because most applications took advantage of the GUI toolkit routines in ROM to present menus, windows, and so on. Sometimes this illusion was broken, such as early versions of MacPaint that didn't honor the desktop pattern, or games that didn't use the GUI.

The Apple II had no GUI toolkit routines in ROM. In 1985, two years after the Apple IIe was released and one year after the Macintosh launched, Apple produced the MouseGraphics ToolKit (MGTK) for the Apple IIe and later machines. This toolkit was loaded into RAM by applications to provide a GUI experience, and was used by DeskTop and a handful of other GUI apps. In theory, there could have been an extensive suite of ProDOS applications for the 8-bit Apple line that used the MGTK to provide a consistent experience. But this did not happen for a variety of reasons. Apple didn't promote MGTK heavily, perhaps because they wanted to encourage development on the new Macintosh platform. Text-mode applications like AppleWorks were already popular, and GUI applications tended to be much slower and consume more memory. And when the Apple IIgs was released in 1986 it attracted both the users and developers who desired a GUI experience for the Apple II line.

To summarize: there is not enough memory in a 128k Apple II for another full application to co-exist with DeskTop, just small accessories, and the ecosystem did not produce GUI applications that would seamlessly swap with DeskTop. That doesn't mean that GUI applications didn't exist, however...

What other "GUI applications" exist for the Apple II?

While practically any Apple application that supported mouse input in text mode, ran in graphics mode, or ran under GEOS or GS/OS might technically qualify, this section will only list applications for 8-bit Apples that provide a menu-driven interface using a bitmapped graphics display and run under ProDOS. Note that most of these use their own GUI code, not MGTK.

Graphics

Word Processing & Desktop Publishing

Spreadsheet

Database

Hypermedia

Telecommunications

Programming

Reference

Education

Entertainment

Hardware

(This section is incomplete. Suggest more!)

* = uses Apple's MouseGraphics ToolKit, just like Apple II DeskTop, so has a very similar look-and-feel

Why use a GUI on the Apple II at all?

It is absolutely the case that a stock Apple II, with no accelerator and only floppy drives, is woefully underpowered for a GUI interface for most operations.

My current Apple II workflow is primarily emulator-based: Virtual ][ on a MacBook Air. I have a handful of curated virtual ProDOS hard disk images (games, apps, etc). When I want to use the "real thing" I copy the image files onto an SD card and boot the real Apple (actually, my Laser 128EX clone!) using a Floppy Emu. Since an emulator can run much faster than actual hardware, a GUI is no slower than a text-based interface to load or run.

Dragging and dropping files is also (at least for me) way faster than navigating menu structures in Copy II Plus.

How does Apple II DeskTop compare to Catalyst and GEOS?

Other GUI environments exist for the 8-bit Apples, including Quark Catalyst, another Mac-styled program launcher; and GEOS, a full blown GUI application environment and OS including productivity applications. How do they compare with Apple II DeskTop?

Some comparisons were published in popular magazines at the time, including:

At a high level:

(This section is incomplete.)

Is there a way to switch applications and keep DeskTop running?

Not really. For most of the 8-bit Apple era, switching programs required rebooting; most programs assumed that they could take total control over the system. It was only in the ProDOS era that a complete reboot was not required when switching programs. DeskTop's approach is to take advantage of a RAMDisk to make restarting very fast. With additions made to v1.2 and later, restarting DeskTop usually takes you right back to where you were, with the same windows open.

On the Apple IIgs the SoftSwitch application lets you snapshot and switch between 8-bit applications.

How can I contribute to the project?

Apple II DeskTop development takes place on the GitHub Project. The goal of the project is to disassemble/reverse-engineer the suite with an eye towards understanding how it functions, fix bugs, and add functionality.

Please read and adhere to the Code of Conduct and read the Guide for Contributing.