Dual monitor for Macbook
 

I'm a recent mac convert, and I'm looking through system preferences and noticing that macbook doesn't seem to support dual monitor (ie. my external monitor displays something different than my internal display). This is something XP seems to do pretty well. Can anyone tell me if this is possible, or if there's a hack out there for this. Thanks.

The MacBook supports it. It's just that you don't see the option unless the second monitor is hooked up. Then you see a Mirror option, and if you turn that off, it goes into Extended Desktop mode where you can spread out. Also if there is a double rectangle icon on your F7 key, that is a shortcut for mirror/extended mode with the second monitor.

Thanks Styrafome. Much appreciated.

Here are Apple's instructions:

http://docs.info.apple.com/article.html?artnum=86286

But the original post isn't about running with the lid closed.

Oops. My mistake. CJS737, the Mac has had superior multi-monitor support since the 1980's. Windows only added it with XP.

In the late 90s, I remember seeing an unattended NT machine set up in a conspicuous location at one of Unilever's offices, with two monitors attached. I knew it was NT because the NT splash screen was spread accross both monitors. I remember laughing at it because it was obvious that some one had spent some time on it, and when they did get it working they wanted everyone to see it. :D

Mean while, the first Mac I'd ever seen with dual monitors was a Mac II in 1988. I easily did it with my IIci in 1989. ;)

We had a Mac SE running System 6 with dual monitors in 1988. An aftermarket card was added to the PDS slot to provide a port for the external monitor, but the OS directly recognized and supported it. Had a full page portrait display to do the newspaper, with the little 9-inch built-in monitor used for PageMaker's palettes.

PCs were running MS DOS on amber or green text-only screens. And didn't have mice yet.

Hilarious. Making the OS think two monitors is one monitor, instead of true multiple-monitor support. That's all Parallels does when you turn on multiple monitor support. You can only stretch a single window across two screens, and it's lame.

Yes, the Mac had it very early on. My first laptop, an Apple PowerBook 160, had exceedingly advanced monitor support for a laptop in its day (1992?). It supported extended desktop running the external monitor at 256 colors, 15 years ago. It was some time before PC laptops were capable of that. And you wanted to use an external monitor with a PowerBook 160, because the internal screen was a ghosty passive-matrix grayscale LCD.

That's because the Mac was designed from the beginning with 32 bits in mind. The first Mac OS was 24 bit, but developers were warned to write 32 bit clean code from the start.

When you think about it, the PC never had a chance to add multiple monitors until sometime after Win 95 at the earliest, which still had a ton of 16 bit code. How could a 16 bit OS handle dual monitors when it could really only deal with data in 64KB chunks? Even a black & white display at 640x480 would require at least 38400 bytes, or more than half of 64KB.

It's amusing that we're going on 14 years in the future, and MS once again is struggling with the transition into a larger memory space with multiple versions of the OS needed to run 32 or 64 bit.

I don't think it's the bits that allows multi-monitor support. It was the fact that Apple, in the Mac, built in abstraction layers between application code and hardware. In the case of graphics, it was QuickDraw. That's the reason the Mac could manage multiple monitors and single monitors of multiple sizes. On Windows and DOS machines, apps drew directly into the frame buffer.

Yes, but even Quickdraw needed to be 32 bit to handle color. ;) How you would write 16 bit software to deal with 32 bit window drawing software, I don't know. Neither, apparently, did Microsoft. :D


Edit: I don't want to imply that dual monitor support would have been impossible for 16 bit systems. Obviously, if you can span VPC running DOS or Windows across two monitors on a Mac, it could have been done. It's just that it wouldn't have been easy and it never would have worked as well as a 32 bit system.

Yes, but we're not talking about color. We're talking about support for multiple monitors. And there is no reason that 16 bit code can't handle multiple monitors. The reason was that Microsoft didn't abstract their screen drawing code until late in Windows development.

True they didn't, but why would they try when most of their code was 16 bit? It was just plain easier to wait until after they got to 32. That, and they were still selling the idea that the Mac was just a gui and real business applications didn't need graphical interfaces. :rolleyes:

What difference does it make whether the code was 16 bit or 32 bit? 16 bit code would still allow for a screen size of 65,536 pixels x 65.536 pixels.

Are you suggesting that they didn't put multiple monitor support into GDI because they were busy with more important work? Still, how would we ever know the rationale?

No matter how many bits are used in the operating system, you can use any number of bytes that you choose to store information about each pixel. The number of bits use in an operating system is a non-issue.

The real issue is the amount of video RAM.

To directly store state information about a screen of size 1024 x 768 (just to pick an example screen size), in just black and white (2 possible states per pixel) you need 1024 x 768 = 786432 bits or 98,304 bytes.

To directly store state information about a screen of size 1024 x 768 in 32 bit color, you need 1024 x 768 x 32 = 25,165,824 bits or 3,145,728 bytes.

Of course, it's more complex than that in OS X because there's an abstraction layer that calculates things like the transparency of windows automatically for you.

Trevor

16 bits only allows for 65536 bytes, which is 524,288 pixels in black & white, with zero overhead. At 640x480, you're using 307,200 pixels, or more than half of the 524,288. It could be done, but not elegantly, and the problem gets worse when you add color (8-bit color puts you at 307,200KB - far beyond 16 bit), higher resolutions than 640x480, and overhead.

I think it was partly that they felt they had more important things to do, but mainly, 16 bit software was a sizable impediment.

In modern systems, I agree, and especially for driving a monitor. But the OS still needs to know something about the data going to the displays, especially when you've got more than one.

That's true. But the early Intel chips had 20 bit address busses, so they could address 1MB. Bill Gates decided that application could use the bottom 640K and the rest is history...

Yeah, Bill Gates: a great visionary! :D

The early computers that used the system processor and memory for display were most definitely limited by the processor's address bus, but most anything since '83 used video cards with their own video processors and video memory. Of course, the computer still needed to maintain the data that the screen was to hold and early PCs were limited to a very small video buffer (A limit defined by IBM; Not Bill), this didn't prevent enterprising engineers from developing high resolution display cards and displays exceeding the 64K limit by using paged buffers on the card itself. I had a CAD/CAM system in '84 that used multi-color vector graphics on a very high resolution display on a PC running DOS.

What gave the Mac the advantage for multiple displays was in fact Quickdraw. From the very beginning, Quickdraw defined the screen as an X:Y map from -32768 to 32767 defining the upper left corner of the visible screen at 0:0. Adding displays simply required that at least one point of the new displays edge was adjacent to an edge point of the previous. That and no fixed location for the screen buffer. Color was always a feature in Quickdraw but wasn't implemented on the display until the Mac II.

Yes, they were limited in their speed by the processor's address bus. They were not limited in their screen resolution, though. Screen resolution is not dependent on how many bits a computer's operating system, or processor, or memory uses. These are unrelated variables.

Trevor

Vector graphics require a lot less system RAM than even a black and white image.

Again, I'm not saying it wouldn't have been possible to do, it's just that getting the software that works with the card, the application, and DOS to all squeeze a portion of themselves into the same 64 KB to work together while dealing with images was already difficult, and as time went on and applications got larger, it got harder. Trying to do it and manage more than one monitor would have made things even worse.

My memories of the 80s and computers all include bumping into memory limits. Even my IIci, which I bought with 8MB of RAM, needed more. ;)

As I said, with video cards, the 64KB limit could easily overcome. The primary problem at the time was clock speed. A larger display required a lot more resources/clock cycles. Vector graphics overcame the speed issue for a highly complex design.

The IIci (I had one too!) was the first color Mac with built-in video. It used the 32bit processor and system memory for the built-in display. I very quickly learned that a video card sped everything up.

Or let you add a second monitor! With 8MB of RAM, the speed difference didn't seem to be as great as people claimed at the time, but I never bothered to measure.

I remember being annoyed by that integrated video, just like some current MacBook owners are. There was less free RAM than on my old IIcx. I forgot if I got the boss to upgrade the RAM. One day we went over to this guy's desk because he had like FIVE megabytes of RAM in his Mac and was running all these programs at the same time. :eek:

If this web site had been around in those days, someone would have posted the tip that if you want to speed up screen redraw on one of those Macs, you put the monitor into 1-bit (Black and White) display mode.