Print

[blusnowkitty]

I've seen in Office System 3 that there's an option to install device drivers in Preferences. It comes with a few printer drivers, and there's an option to insert a disk and install a new driver. Was there ever a driver development kit for Office System, or would you just have used the normal Workshop? Can Office System even talk to anything that isn't a disk drive or a printer?

[stepleton]

There is a fairly extensive manual for device driver authors, including full source code for a device driver (for a disk, if I remember right). I don't know if a standard install of the Workshop would have the files that would allow you to compile the source code, though.

The Priam drive includes a built-in tape drive, so it seems probable to me that there's driver support for that (unless the tape drive operates independently of the computer somehow).

I assume that when Apple folks were designing the driver framework, they were probably thinking about supporting things like the AppleNet card as well. I've never heard of an AppleNet driver for the Lisa OS, though.

[blusnowkitty]

Thanks for that, this will prove useful.

Something else I've noticed in reading this document and some early software documentation on Bitsavers is the presence of an underlying "Operating System" that, seemingly, the Office System builds upon. Am I correct in thinking that perhaps the Office System runs in much the same way that UNIX/Linux + X11 and Windows NT work - in that, there is an underlying kernel with its own native API that you don't necessarily interface with, but rather the graphical environment on top? Sort of like how the Windows NT kernel has a native kernel-mode NTAPI, but you really should use the user-mode Win32 API.

Interestingly the early software documents also state that the Operating System loads the SHELL file, which can be deleted and replaced at will. I wonder if that's how the Lisa development team were able to so quickly go from a text-based environment to a graphical one in Busy Being Born.

Come to think of it, I wonder if this is what the Workshop is - access to the underlying Operating System, but with a graphical shell loaded in on-demand...

[rayarachelian]

Thanks for that, this will prove useful.

Something else I've noticed in reading this document and some early software documentation on Bitsavers is the presence of an underlying "Operating System" that, seemingly, the Office System builds upon. Am I correct in thinking that perhaps the Office System runs in much the same way that UNIX/Linux + X11 and Windows NT work - in that, there is an underlying kernel with its own native API that you don't necessarily interface with, but rather the graphical environment on top? Sort of like how the Windows NT kernel has a native kernel-mode NTAPI, but you really should use the user-mode Win32 API.

Interestingly the early software documents also state that the Operating System loads the SHELL file, which can be deleted and replaced at will. I wonder if that's how the Lisa development team were able to so quickly go from a text-based environment to a graphical one in Busy Being Born.

Come to think of it, I wonder if this is what the Workshop is - access to the underlying Operating System, but with a graphical shell loaded in on-demand...

That's exactly what it is, I just wish it was less... lame. There's an "EXEC" command language for it also. Not quite a shell script language. More like expect, but, um... lamer. It's too bad it's not more like an IDE. If you install LPW on top of LOS, you can use the Environments window to switch between the two.

[patrick]

That's exactly what it is, I just wish it was less... lame. There's an "EXEC" command language for it also. Not quite a shell script language. More like expect, but, um... lamer. It's too bad it's not more like an IDE. If you install LPW on top of LOS, you can use the Environments window to switch between the two.

Three. There was a tutorial called LisaGuide that came with its own shell. In the Environments window you can chose between Office System, Workshop and LisaGuide.

[stepleton]

I'm not so sure what's lame about all of this stuff 

I think the term "shell" may be part of the issue---it leads people to expect something like /bin/bash . It's just the program that the OS starts when it boots, is all.

The shell files concept is very similar to .system files in ProDOS (and maybe SOS if I understand correctly). Unix kernels may not be much different either---after all, their "shell" is traditionally init(8 ), although booting with init=/bin/whatever_you_want is an option on many systems if you prefer a different root process. Lately, most Linux distributions have changed the "shell" to systemd(1), which is either a good thing or not depending on your outlook. But you could boot Linux into a custom program if you felt like it, and though I don't know for certain, I suspect this is basically what Android phones do.

Anyway, it is correct that the Office System is a shell, and so is the Workshop. The Workshop's shell presents a text-based menu interface that resembles the UCSD p-System interface very closely, and this shell can also run the exec files that Ray mentioned. That said, there's nothing stopping someone from writing a different shell that looked and worked much like bash or PowerShell... well, except for memory usage perhaps (cf. PDF page 16 of the Workshop User's Guide). There's also nothing to prevent someone from writing any other kind of standalone program in the Workshop and renaming it to SHELL.Whatever and having that be a shell listed in the Environments window --- even if it does something useless like compute the Mandelbrot set over and over again.

More info about Lisa OS process structure starting from PDF page 69 of the OS reference manual.

Both the exec file system and the Workshop menu interface seem to be part of the StdUnit library (see reference manual PDF page 312 on), which makes some sense because they work with each other. I don't think the OS requires that your program to use StdUnit, however, and if you were writing your own shell from scratch, you'd probably be abandoning those features/conveniences, since I expect they depend rather heavily on functionality built into the Workshop shell itself. (Same for the ProgComm library also mentioned in the reference manual.)



I feel like I should take a second to defend the exec file system, which is wonky but not lame in my opinion; I think it's rather powerful! It's a rather elaborate Pascal-like scripting language with flow control, subroutines (as separate files), string manipulation, and file I/O! It actually surprises me a little bit how much it can automate the Workshop interface. See chapter 9 of the User's Guide.


Regarding:

Interestingly the early software documents also state that the Operating System loads the SHELL file, which can be deleted and replaced at will. I wonder if that's how the Lisa development team were able to so quickly go from a text-based environment to a graphical one in Busy Being Born.

I think this is probably not the case. Development of the OS and I think (but am not sure) some of the foundations and apps for the Office System took place in the Monitor, an earlier operating environment that resembled the p-System even more closely. In the Monitor, the menu interface was much more intrinsic to the kernel, if my reading of the source code on bitsavers is not mistaken. The Monitor was a pretty low-overhead operating system, much like DOS in many respects, with no memory protection and (I think) only marginal support for running more than one program at once. So, if you were developing an application that needed to draw graphics, there was nothing stopping you from having it write to the framebuffer in RAM. In fact, there is at least one Lisa graphical environment that does exactly this: Lisa Smalltalk-80! You start it up in the Monitor and it basically takes over the whole computer. I'm not sure you can even quit it.


On that note, one thing I'm not so sure of are the details of when and how programs running the Lisa OS secure access to the video memory. Details of this are surely buried deep in things like the QuickDraw libraries and other Office System libraries perhaps. There isn't really the concept of "user space" and "kernel space" in the Lisa OS like there is in Unix, I don't think, but there are some kinds of memory protection, and I'm not sure of their nature. Deciding what part of the stack should do the drawing and how that element should be commanded was a design choice that different vendors approached differently---here is a workshop proceedings where people are comparing their choices in a pre-X Unix world (scroll down to the bottom for figures). I'm not sure what the Lisa engineers chose.

Since it's the Lisa, I assume that they selected the most complicated option that would fit within the system's overall constraints.

(PS: Do click around in that workshop proceedings---it's a fascinating time capsule and features a few well-known names in attendance. You'll see mentioned here and there some people describing interest in Apple's contributions to the art, but this is a very Unixey crowd indeed!)

(PPS: for people who do read it---I've been enjoying exploring a Whitechapel MG-1... it's running right now, here in the same room as my Lisas )

[stepleton]

I'm also reminded how one of the reasons we Linux geeks made fun of NT back in the day is because it had its graphics run in kernel space, or something, and that meant that it was easier for something Not Serious to crash the computer. Even today the issue of where the graphics go isn't fully settled, and probably won't ever be...

[rayarachelian]

I mean it's lame in the "Those who do not understand Unix are condemned to reinvent it, poorly." sense.

I fully understand that the shell is the first thing the kernel runs and about init. It's not lame because of that.

It's lame because it's not a proper scripting language, and has no interactive repl. It's a menu system on to which a hack of an exec language has been bolted on to. Basically, stapling extra legs on a dog to make an octopus.

And while the rest of the Lisa has a GUI, this isn't a graphical IDE, so it's basically the worst of all worlds, and it isn't self consistent. Some of its commands are hidden from the menu but documented in the exec  documentation.

The ones that are part of the menu, like "p" for pascal, "a" for assemble, "g" for generate code are single letter commands, typically with curly braces after to write a comment. So pretty much everyone used P{ascal}file where the P was the thing that actually invoked the compiler, but the {ascal} was a comment - so people had to write comments around to make it prettier as a workaround.

For the commands that aren't part of the menu you have prefix with a $ - sure you have have flow logic like if else, and you can call other exec files, but it's really ugly.

And sure, it does have variables like %1 to %9. I mean... ok they're called "parameters" and sure you can do some operations on them like UPPERCASE, but it's very limited.

I mean, DOS batch scripts are more self consistent and more capable than this thing. And I'll refrain from comparing how bad it is compared to sh or ksh, or even perl - and yes, it's possible to write clean well structured, readable perl, just as it's easy to write line noise perl.

And even the menu system is inconsistent. To copy files, compile, link, or power off, or reboot you use this menu system, but to eject a floppy you have to use the GUI text editor. wtf? And that system manager vs file manager in the top level menu? what manager? it's all part of the same binary, there's no separate executable on disk for those. There's no actual "manager" there.
And speaking of the editor, when you launch it it asks you for a file name, which you have to type in. But if you create a new one and save it, it gives you a model dialog file browser or something like that. It's also inconistant.

I can't speak to the rest of LPW, I'd guess it's a proper compiler/linker toolset, though it does use intermediate code generation which isn't ideal, but that's ok.

The rest of LOS is far better designed and self-consistent. This thing is not properly designed, it's been slapped together from multiple schools of thought, and then more features have been accreted on to it with no thought to redesign/refactor it to make it consistent.

MPW at least was a lot better designed and is a lot more consistent.

This could have been a lot better. These guys saw Smalltalk at Xerox, and Tesler should have asked them to build a full IDE here rather than borrowing piece meal from uscd pascal. I don't think Turbo Pascal existed before LPW was built, but something like that would have been 100x better.

Sure the end user was free to write their own shell, hopefully do a better job, but the point is that it should have shipped with a better shell to begin with and a better scripting language.

[stepleton]

Eh, I don't think it's that bad. To each their own.

Some points: the FILE-MGR being a separate manager is at least a callback to the Monitor, where it was a separate program, and also the p-System before that, which had the "Filer". (It might be a separate program in the Workshop, too---that is, a separate .OBJ file, the same way the compiler and the linker are, among others. Not sure.) It makes sense for there to be some consistency between the Monitor and the Workshop, I think: the Lisa team had probably got pretty used to their toolchain by then, and why switch horses midstream.

Perhaps more importantly: in 1982-'83, I expect things that look like the p-System would have been familiar to large parts of Apple's developer userbase and others. Apple had been shipping the extremely similar Apple Pascal on the ][ since 1979 (it was one of the reasons for the Language Card), and the real pSystem was one of the OS options for the IBM PC (alongside CP/M 86 and one other that I can't remember right now). So going with something that looks like a major market offering isn't a bad idea if you've just gotta ship.

Tesler could have asked for a fancier IDE, but I'm guessing the dev support team was also busy building the ToolKit once they got the Workshop out the door, and I wouldn't be surprised if their attention couldn't be divided. The ToolKit is a rather elaborate system and maybe would have seemed a higher priority for people trying to rebuild what they did or saw at PARC. This is all just a guess though. Certainly there is a lot of new design in the ToolKit, and you can tell when comparing it to something like the Unix GUI offerings around the same time, which are much more rudimentary.

You can eject a floppy from the file manager using the U{nmount } option. I actually didn't know you could do it from the Editor...

You can have variables and parameters in EXEC files that have more interesting names than %n. PDF page 167 has the details.

The $ prefix is the main thing I think is "wonky", but the good news is that you can choose whether to use it to prefix internal language lines or the menu-system commands --- either way is acceptable

I think EXEC was (literally) more than adequate for the intended purpose. Could it have been better? Sure, but I think it gets the job done, and it doesn't really take much wrestling for it to do that, especially if you are already comfortable with Pascal syntax. The entire Workshop 1.0 installer is in EXEC; so is the utility that publishes your QuickPort app to the Office System. Neither are trivial programs. I guess I don't see the Workshop or EXEC as missed opportunities from a product success perspective---there are probably other things I'll tackle first if I ever get the chance to play Larry Tesler Simulator '82. (You win if Lisa survives as a product until 1996, in which case the I/O board COPS year date limit is the boss level.)

[rayarachelian]

Yes, you're right in that "it's not that bad," and also that this was the state of the art at the time, and that they were used to it and so they accepted it, but that's also playing apologist for the bad decisions made.

It could have been a lot better compared to how well designed and polished the LOS desktop and tools are, and certainly when compared to the smalltalk env in the Alto, i.e.: https://www.youtube.com/watch?v=uknEhXyZgsg back in 1976. Comparatively, MPW did it better, but that rewrite should have been to LPW instead. Maybe it was just a matter of time, but the Lisa's ran out, as more focus went to the Mac.