All information lies in a public sphere or a private sphere. The private sphere is larger for most folks, smaller for politicians and similar public figures.
Hunting licenses for the publisher should be granted to anyone whose private sphere information is published. This will also tend to improve data security of personal information brokers.
Mmmmmm....icrosoft, perhaps? They have been generous with the campaign contributions...
Microsoft's license package for the WMA formats and CODECs is interesting. A company signing with them would:
1) Pay MSFT royalties, of course 2) Agree to share information on all new products being developed that include the CODECs. 3) Agree not to sue, prosecute, assist or participate in any judicial, administrative or other proceedings of any kind against Microsoft. This effectively grants Microsoft immunity should any of the licensee's IP appear in a future Microsoft product.
This hasn't been too much of an issue with companies planning to just build WMA/MP3 players. Item 3 is not an issue in Japan, since the Japanese Fair Trade Commission demanded this clause be stricken retroactively. (Sony got what they wanted...)
Can you see Apple wanting to turn over prototype hardware and plans for the next release of Mac OS X to Microsoft? How about agreeing to not sue Microsoft should Mr. Softie nick some technology from Apple?
Didn't think so.
Now, imagine the government legislating that Apple must license the WMA CODECs and format from Microsoft to remain in the music business. Welcome to the Land of the Free, comrades...
Simply put, the OS/2 based ATMs didn't run the mission critical software that the Wells Fargo IT department felt was necessary on public access terminals, which is fundamentally what ATMs are. They require applications like Disk Defragmenter, Scandisk, Norton AV, Windows Update and Ad-Aware - none of which are available for the OS/2 platform.
In today's climate of non-stop worms, trojans and viruses, deploying an ATM with no virus removal software would be irresponsible on the part of Wells Fargo.
As someone deeply involved with two of the graphics systems discussed, yes, it's wrong. It would appear to be misinterpreted from marketing literature.
Leo's perception and commentary is more accurate than that of most of the posters on this subject.
The original beastie was drawn by John Lassiter. Maybe folks here have heard of him? PIXAR? Animation?
He did the artwork for the cover of "The Design and Implementation of the 4.3BSD UNIX Operating System", along with a few variations seen elsewhere. Take a look in the flyleaf. (I'm on page X. Heh...)
If there are an infintie number of parallel universes, why aren't there an infinite number of wormholes opening all over the place in our universe?
There just might be.. Oh, not an infinite number, but one of those really, really big numbers, followed by lots and lots of zeros.
Oh, and the wormholes are small. Really small. Mind-bogglingly small. About a Planck length. And they don't go very far. Probably not to another universe.
Wil Shipley is really very unlikely to pull the whole corporate suit gig. At Omni, for a long time the company was in a house that felt more like a really tidy commune than a corporation. (Having a chef come in to prepare chow for the team probably helped.)
The Omni crew was a long way from suitdom. Wil was a big reason for that. Heck, he's one of the few people I'd consider relocating to work for.
Just look at Dell, they are selling brand new Celeron 2.4ghz machines with a monitor for $499.
OK, so I went to the Dell site and picked the cheapest thing in the Home area of the store, the Dimension 3000. I then picked Customize so I could lose the monitor and printer. The included display was a $45 16 inch viewable CRT.
The price is down to 449.10. Time to check out...
Um... Three shipping options, with the cheapest one being $99 for 3-5 day delivery.
The price is now 548.10. 3 month warranty, because I didn't pop for the special support package.
think it was more hardware needing to get to a certian point. It wasn't until about mid 1999 that a card (TNT2) existed that even had the basic 3d capibility to do what would be needed for a user interface.
The idea of using OpenGL to drive the UI was around a few years before that, when the chip designer roadmaps for graphics accelerator development first started showing interesting marking and texturemap capabilities.
Even so, at that level, all you could really do was make a window a big texture stretched on a polygon. Neat, but faily useless.
Not that useless. It allows the window data to be transferred to the framebuffer using texture DMA, such as the AGP path, and it allows the texture combiner to do all those interesting alpha channel tricks.
> What do you mean by "run at the interpreter level"?
He's probably talking about running it atop the virtual machine.
Most of the older IBM boxen ran a virtual machine abstraction, which then ran the desired OS. It was an interesting approach, unless you needed to support a hardware device IBM hadn't allowed for. Then it became painful.
The NeXTSTEP port lived atop the iron. (No, kids, it never shipped. NeXTSTEP 1.0, even!)
Re:This Article is riddled with inaccuracies.
on
NeXTSTEP To Mac OS X
·
· Score: 2, Informative
It's been said that OpenSTEP on PPC hardware was demonstrated to Apple as a proof of concept (man it's hard to find web pages dating back 1996... was it from FirePOWER, the company that was formed with, basically, the haxed out NeXT hardware division? Was it PREP or CHRP? Can't remember.)
No, the Apple demos were mostly done using a couple Toshiba laptops, running the OPENSTEP for x86 port. We resurrected a NeXTTIME port specifically to demonstrate multimedia support, and ran several Quicktime movies on the laptop at the same time. This was a fun demo to assemble.
All I could find for now is this: link [roughlydrafted.com].
That refers to the old NeXT RISC workstation project. That started life as a RISC workstation built around the 88110, and later moved to using an adapter card in the processor socket to try other architectures. One such adapter used an early 601 processor, and managed to boot a NeXTSTEP 3.0 kernel.
This is far from being a port, and never ran Apple's PPC ABI. It never shipped, and was not maintained, as it was a lab experiment.
Re:This Article is riddled with inaccuracies.
on
NeXTSTEP To Mac OS X
·
· Score: 2, Interesting
Don't teach Grandpa how to suck eggs. It just makes him cranky.
NeXT had ported NeXTSTEP to Power Mac hardware well before they were acquired and is what tilted the balance. That and the fact that Gassé wanted 400 million for BeOS, wich was nowhere near as complete as NeXTSTEP was at the time.
The price tag and lesser capabilities of BeOS were a big factor, as was the demonstrated portability of OPENSTEP. At the time, OPENSTEP 4 was running on a variety of architectures, but Power PC wasn't one of them.
Display PDF: read up, bob: some intro info here
Gee, thanks. Notice that they refer to a PDF drawing model. That's basically PostScript vector drawing, without the PostScript language and non-drawing operators. We call that Quartz.
Display PDF is a rendering engine that displays PDF. What Quartz does is raster graphical commands (actually, the same calls that Cocoa had for Display PostScript, what was eventually dubbed CoreGraphics and then, as a whole, Quartz 2D), plus bells and whistles for OpenGL acceleration (further enhanced with Quartz Extreme) to build up these images and pass-em on to the underlying PDF rasteriser.
Um. No. This inaccurately implies all rendering passes through a PDF form. In normal usage, this is done only for printing, using the PDF form as a spooling format.
What Quartz does is present a set of functions which render into a context. That context may be targeted to produce on-screen drawing, such as what Cocoa does, or may be a CGBitmapContext to generate off-screen rasters, or a PDF context to produce a PDF output stream. Additional context types exist to support specialized tasks. The actual API is often referred to as the "Quartz 2D" API in developer documentation. These functions implement a drawing modelsimilar to the drawing model beneath PDF.
Quartz also provides a PDF interpreter which calls the same Quartz APIs to generate window content (Preview.app), bitmap output via a CGBitmapContext, or other output forms.
The PDF output capability and the PDF rendering pass are primarily used by the Mac OS X printing system, which uses the PDF form as a spooling format.
Quartz window contexts transparently accelerate operations based on hardware capabilities. Quartz Extreme is one good example of this, accelerating the Quartz Compositor back end at the heart of the window system. This functionality was added in Mac OS X 10.2.
Re:This Article is riddled with inaccuracies.
on
NeXTSTEP To Mac OS X
·
· Score: 2, Informative
1) The port to Apple hardware was already done by NeXT before Apple acquired it. They merely completed the drivers, added AppleTalk, ADB and a couple of other software layers to complement the immediate needs.
This turns out not to be the case. The first Apple PPC machines didn't show up until after the merger. The nearest thing we had in late 1996 at NeXT was a NeXT RISC Worktstation prototype with the 88110 processors replaced by a daughter card packed with programmable parts and a 601. (Yay! Jeff and Ali rocked!)
I spent a happy fun Christmas break diddling a GCC compiler to spiff code generation for the NeXT RISC ABI and the 601, so I could get Display PostScript to compile and run.
2) in favor of free technologies like Quartz Now. They rewrote Display PostScript as Display PDF. THEN added Quartz on top, wich is something they've developed for this specific purpose. It wasn't free. They made it. And it's hosted on top of Display PDF.
Display PDF? I don't think so, MouseR. Quartz is a marketing name for the graphics rendering technology used. A PDF interpreter can be hosted on top of this technology, and by establishing what's called a "PDF context", the calls to the Quartz API can generate PDF data.
There is no Display PDF. Really.
The rendering technology is all home-grown, though. This avoids the unpleasant experience of having one's products at the mercy of another company that may not have one's best interests in mind...
The original NeXT Cube, and the various NeXTStation products all did double-buffering of windows by default. Now the Cube and monochrome NeXTStation used only 2 bits per pixel, which helped, but consider the NeXTStation Color:
16 bit per pixel color with alpha channel 1120 x 832 pixel display 25 MHz 68040 processor 16 Mbytes of memory
Double-buffered windows, compositing in the Display PostScript drawing engine, color correction, and a clever dithering scheme to improve color quality. It's still pretty snappy by today's standards, especially when porked out with a huge 64 Mbytes of memory. Woo hoo!
The Microsoft WMA license contains some interesting items that might give Apple pause.
The licensee is required to submit products using WMA to Microsoft for certification prior to being able to ship the product. New iPod product with WMA? Microsoft gets to see it first, before it ships. iTunes with WMA playback shipping in a new OS? Microsoft gets to see it first, before it ships. New computer or other product with WMA playback? Microsoft gets to see it first.
Oh, and one more thing...
There is a clause in the license which bars licensees from any legal action against Microsoft over patent, copyright, or other intellectual property violations. (Microsoft has had to pull this clause in Japan, where it turns out to be illegal, but it's quite legal in the US.)
So, if Apple were to license WMA under the current terms, they'd be giving Microsoft early access and approval over new products, and would be unable to litigate if some technology from those products happened to somehow appear in a Microsoft product.
I'm just surprised that nobody thought of doing it sooner.
Fundamentally the GPU is just a massively parallel processor for operating on streams of data. That the data happens to be graphics data such as pixel or vertex arrays is almost incidental.
Back in the Stone Age, around 1984, we had the Pixar Image Computer with its' CHAP processors[1], long instruction word heavily pipelined processors designed to crunch streams of pixels. Some numerical routines for integer and fixed point math were available, painfully hand-coded in CHAP-Assembler
From time to time. someone would try to do general numeric processing with this monster. Eventually a floating point math package and C compiler with parallel programming extensions was put together for the machine[2], and general purpose programs were written to take advantage of the CGAP GPU.
The first program? "hello.c" naturally! A parallelized ray tracer was ported. The tracer used the SIMD capabilities and floating point package to to run the math primitive processing (normal calculations and whatnot) in parallel, and divided the raytracing of different scanlines across multiple CHAPs, demonstrating both a computing cluster and fully programmable GPU use at the same time.
The numerical processing capabilities were exploited for a number of commercial products, almost incidental to the use of the Image Computer to produce rendered images. Often buffers of fixed or floating point data would be computed or consumed incidental to the primary graphics task. I don't think anyone thought it was particularly special. We were just using the fastest compute engine in a system to do needed work.
1. Adam Levinthal , Thomas Porter, Chap - a SIMD graphics processor, Proceedings of the 11th annual conference on Computer graphics and interactive techniques, p.77-82, January 1984
2. Adam Levinthal, Pat Hanrahan, Mike Paquette, and Jim Lawson. Parallel Computers for Graphics Applications. Proceedings of the Second International Conference on Architectural Support for Programming Languages and Operating Systems, pages 193--198, 1987.
Letting the app take care of its own window borders is a bad idea as well. This is one of the worst parts in M$ Windows - once an app hangs, there is no way of closing or minimizing a window or simply of getting it out of the way. It's way better to have this handled by a separate process.
Annoying, isn't it? The trick here is not to let the apps draw to the visible frame buffer, which requires all this visible region locking, but instead to have the app draw to a buffer (in off-screen VRAM or main memory, addressable by the window system). The window system is then responsible for placing the content on-screen.
So, how does that help? The app always has a place to draw, and the separate window system process always has control over moving the bits onto the display. This means that a window manager can always order the window out, or move the window aside, without the cooperation of the application. In one implementation, the draggable areas used to move the window are registered with the window manager, so the app need not even be involved in moving the window.
One of the more interesting possibilities here comes into play when the window system is implemented atop a powerful engine such as OpenGL. In this case, the window buffers can be treated as texture sources and applied using the various texture combiner paths, along with scaling, filtering, and various transforms, all applied after the application has rendered it's content..
This allows the window system to be extended in a variety of ways without changing one line of the application's code. The windows can be minimized quite literally by adjusting the transformation matrix, or by playing with transparency, without the cooperation of the application. One could transform the window contents down to icon size, and composite the content with an iconic badge, producing a minimized icon representing the window, complete with live content, without the cooperation of the application.
The last thing we need is a new design that allows arbitrary user programs to have read/write access to the entire screen (read-only access is bad enough).
Subtle point here. The hardware the apps have access to may not be the screen, but an off-screen surface which the graphics acceleration subsystem (such as OpenGL) can draw into. The window system takes care of getting the bits drawn in the off-screen surface onto the displays.
These surfaces can live in VRAM, or DMA addressable main memory. Lots of tricks can be done here by having the app draw at what is essentially the front end of the display processing pipeline.
Consider for example the GL buffer-as-texture path. Apps draw into a buffer, which when flushed is treated by the window system as a texture to be applied to the app window. The whole GL pipeline can be applied, scaling or warping the texture, altering the geometry the surface is to be applied to, mixing the texture with other texture sources, and so on.
In the Mac OS X window system, there's still clip lists, but they are not visible to the application. The app just draws in it's window buffers.
The clips are needed to handle event routing, as you mention, and to take care of some subtle internal housekeeping, even when Quartz Extreme is in use. Since not all systems or graphics cards can run Quartz Extreme (there are certain specific graphics card capabilities needed) the clipping information is needed for software compositing cases.
Curiously, the Mac OS X window system implements almost the exact design Jim Gosling describes in his paper.
All drawing work is done on the client side, and the window server has nothing to do with fonts, cut/paste support or much other higher level work. The window server simply assembles the drawing buffers to the displays (via hardware or software) and routes events, using hints of the foreground application and the visible window area to manage the task.
A consistent look and feel is derived by providing a consistent set of high level toolkits, residing on a set of lower level drawing frameworks.
Shared libraries make sure the needed code is readily available and resident in memory. Font are cached and vended as shared memory resources using Mach's virtual memory semantics. Drawing buffers also leverage Mach VM semantics.
You get used to it after a while. What I do is basically:
1) Don't carry anything valuable. They'll make you dump everything on a table, which they don't watch very well. For security staff, they're pretty slack about other people's stuff.
2) Wear cheap, flat 'deck' shoes, like $12 pairs fron a cheap show chain. You may lose them at some point.
3) If you wear a belt, use a cheap flat belt. You may have it torn open at some point.
4) Wear clean underware, with no holes. You may wind up with your pants around your ankles with 20 strangers there, as you try to stand straight, with no belt, and your arms straight out from your sides. (Happened to me at San Diego, in the hole they call Gate 1.)
Expect to be laughed at by the wanker TSA employees. Do not make any remarks or show any expression in response. Remarks about a**holes results in an extra hour or two in a small room while you wait for a cavity search 'specialist'.
It appears that he's just published the public key. That may allow him to ENCRYPT music for play over Airport Express, but it doesn't let him decrypt the stream.
Heck, I put a public key for mail in my.plan and sigs. I don't think that enables anyone to crack my mail. They can SEND me mail, but that's sort of the whole idea, isn't it?
Slashdot Mirror
All information lies in a public sphere or a private sphere. The private sphere is larger for most folks, smaller for politicians and similar public figures.
Hunting licenses for the publisher should be granted to anyone whose private sphere information is published. This will also tend to improve data security of personal information brokers.
Think of it as evolution in action...
Mmmmmm....icrosoft, perhaps? They have been generous with the campaign contributions...
Microsoft's license package for the WMA formats and CODECs is interesting. A company signing with them would:
1) Pay MSFT royalties, of course
2) Agree to share information on all new products being developed that include the CODECs.
3) Agree not to sue, prosecute, assist or participate in any judicial, administrative or other proceedings of any kind against Microsoft. This effectively grants Microsoft immunity should any of the licensee's IP appear in a future Microsoft product.
This hasn't been too much of an issue with companies planning to just build WMA/MP3 players. Item 3 is not an issue in Japan, since the Japanese Fair Trade Commission demanded this clause be stricken retroactively. (Sony got what they wanted...)
Can you see Apple wanting to turn over prototype hardware and plans for the next release of Mac OS X to Microsoft? How about agreeing to not sue Microsoft should Mr. Softie nick some technology from Apple?
Didn't think so.
Now, imagine the government legislating that Apple must license the WMA CODECs and format from Microsoft to remain in the music business. Welcome to the Land of the Free, comrades...
Simply put, the OS/2 based ATMs didn't run the mission critical software that the Wells Fargo IT department felt was necessary on public access terminals, which is fundamentally what ATMs are. They require applications like Disk Defragmenter, Scandisk, Norton AV, Windows Update and Ad-Aware - none of which are available for the OS/2 platform.
:-)
In today's climate of non-stop worms, trojans and viruses, deploying an ATM with no virus removal software would be irresponsible on the part of Wells Fargo.
(With apologies to divisiontwo.com.
As someone deeply involved with two of the graphics systems discussed, yes, it's wrong. It would appear to be misinterpreted from marketing literature.
Leo's perception and commentary is more accurate than that of most of the posters on this subject.
The original beastie was drawn by John Lassiter. Maybe folks here have heard of him? PIXAR? Animation?
He did the artwork for the cover of "The Design and Implementation of the 4.3BSD UNIX Operating System", along with a few variations seen elsewhere. Take a look in the flyleaf. (I'm on page X. Heh...)
Credit where credit is due, and all that...
There just might be.. Oh, not an infinite number, but one of those really, really big numbers, followed by lots and lots of zeros.
Oh, and the wormholes are small. Really small. Mind-bogglingly small. About a Planck length. And they don't go very far. Probably not to another universe.
Wil Shipley is really very unlikely to pull the whole corporate suit gig. At Omni, for a long time the company was in a house that felt more like a really tidy commune than a corporation. (Having a chef come in to prepare chow for the team probably helped.)
The Omni crew was a long way from suitdom. Wil was a big reason for that. Heck, he's one of the few people I'd consider relocating to work for.
OK, so I went to the Dell site and picked the cheapest thing in the Home area of the store, the Dimension 3000. I then picked Customize so I could lose the monitor and printer. The included display was a $45 16 inch viewable CRT.
The price is down to 449.10. Time to check out...
Um... Three shipping options, with the cheapest one being $99 for 3-5 day delivery.
The price is now 548.10. 3 month warranty, because I didn't pop for the special support package.
TANSTAAFL
The idea of using OpenGL to drive the UI was around a few years before that, when the chip designer roadmaps for graphics accelerator development first started showing interesting marking and texturemap capabilities.
Even so, at that level, all you could really do was make a window a big texture stretched on a polygon. Neat, but faily useless.
Not that useless. It allows the window data to be transferred to the framebuffer using texture DMA, such as the AGP path, and it allows the texture combiner to do all those interesting alpha channel tricks.
2D is just 3D with some constants in the matrix. No, really.
I'm looking forward to Volumes 12 through 14. Rumor is that another character takes a bath! I won't reveal the name, as that would spoil the fun.
> What do you mean by "run at the interpreter level"?
He's probably talking about running it atop the virtual machine.
Most of the older IBM boxen ran a virtual machine abstraction, which then ran the desired OS. It was an interesting approach, unless you needed to support a hardware device IBM hadn't allowed for. Then it became painful.
The NeXTSTEP port lived atop the iron. (No, kids, it never shipped. NeXTSTEP 1.0, even!)
No, the Apple demos were mostly done using a couple Toshiba laptops, running the OPENSTEP for x86 port. We resurrected a NeXTTIME port specifically to demonstrate multimedia support, and ran several Quicktime movies on the laptop at the same time. This was a fun demo to assemble.
All I could find for now is this: link [roughlydrafted.com].
That refers to the old NeXT RISC workstation project. That started life as a RISC workstation built around the 88110, and later moved to using an adapter card in the processor socket to try other architectures. One such adapter used an early 601 processor, and managed to boot a NeXTSTEP 3.0 kernel.
This is far from being a port, and never ran Apple's PPC ABI. It never shipped, and was not maintained, as it was a lab experiment.
NeXT had ported NeXTSTEP to Power Mac hardware well before they were acquired and is what tilted the balance. That and the fact that Gassé wanted 400 million for BeOS, wich was nowhere near as complete as NeXTSTEP was at the time.
The price tag and lesser capabilities of BeOS were a big factor, as was the demonstrated portability of OPENSTEP. At the time, OPENSTEP 4 was running on a variety of architectures, but Power PC wasn't one of them.
Display PDF: read up, bob: some intro info here
Gee, thanks. Notice that they refer to a PDF drawing model. That's basically PostScript vector drawing, without the PostScript language and non-drawing operators. We call that Quartz.
Display PDF is a rendering engine that displays PDF. What Quartz does is raster graphical commands (actually, the same calls that Cocoa had for Display PostScript, what was eventually dubbed CoreGraphics and then, as a whole, Quartz 2D), plus bells and whistles for OpenGL acceleration (further enhanced with Quartz Extreme) to build up these images and pass-em on to the underlying PDF rasteriser.
Um. No. This inaccurately implies all rendering passes through a PDF form. In normal usage, this is done only for printing, using the PDF form as a spooling format.
What Quartz does is present a set of functions which render into a context. That context may be targeted to produce on-screen drawing, such as what Cocoa does, or may be a CGBitmapContext to generate off-screen rasters, or a PDF context to produce a PDF output stream. Additional context types exist to support specialized tasks. The actual API is often referred to as the "Quartz 2D" API in developer documentation. These functions implement a drawing modelsimilar to the drawing model beneath PDF.
Quartz also provides a PDF interpreter which calls the same Quartz APIs to generate window content (Preview.app), bitmap output via a CGBitmapContext, or other output forms.
The PDF output capability and the PDF rendering pass are primarily used by the Mac OS X printing system, which uses the PDF form as a spooling format.
Quartz window contexts transparently accelerate operations based on hardware capabilities. Quartz Extreme is one good example of this, accelerating the Quartz Compositor back end at the heart of the window system. This functionality was added in Mac OS X 10.2.
Tiger will be extending GPU use a bit through new functionality such as CoreImage. http://www.apple.com/macosx/tiger/core.html
This turns out not to be the case. The first Apple PPC machines didn't show up until after the merger. The nearest thing we had in late 1996 at NeXT was a NeXT RISC Worktstation prototype with the 88110 processors replaced by a daughter card packed with programmable parts and a 601. (Yay! Jeff and Ali rocked!)
I spent a happy fun Christmas break diddling a GCC compiler to spiff code generation for the NeXT RISC ABI and the 601, so I could get Display PostScript to compile and run.
2) in favor of free technologies like Quartz Now. They rewrote Display PostScript as Display PDF. THEN added Quartz on top, wich is something they've developed for this specific purpose. It wasn't free. They made it. And it's hosted on top of Display PDF.
Display PDF? I don't think so, MouseR. Quartz is a marketing name for the graphics rendering technology used. A PDF interpreter can be hosted on top of this technology, and by establishing what's called a "PDF context", the calls to the Quartz API can generate PDF data.
There is no Display PDF. Really.
The rendering technology is all home-grown, though. This avoids the unpleasant experience of having one's products at the mercy of another company that may not have one's best interests in mind...
The original NeXT Cube, and the various NeXTStation products all did double-buffering of windows by default. Now the Cube and monochrome NeXTStation used only 2 bits per pixel, which helped, but consider the NeXTStation Color:
16 bit per pixel color with alpha channel
1120 x 832 pixel display
25 MHz 68040 processor
16 Mbytes of memory
Double-buffered windows, compositing in the Display PostScript drawing engine, color correction, and a clever dithering scheme to improve color quality. It's still pretty snappy by today's standards, especially when porked out with a huge 64 Mbytes of memory. Woo hoo!
The Microsoft WMA license contains some interesting items that might give Apple pause.
The licensee is required to submit products using WMA to Microsoft for certification prior to being able to ship the product. New iPod product with WMA? Microsoft gets to see it first, before it ships. iTunes with WMA playback shipping in a new OS? Microsoft gets to see it first, before it ships. New computer or other product with WMA playback? Microsoft gets to see it first.
Oh, and one more thing...
There is a clause in the license which bars licensees from any legal action against Microsoft over patent, copyright, or other intellectual property violations. (Microsoft has had to pull this clause in Japan, where it turns out to be illegal, but it's quite legal in the US.)
So, if Apple were to license WMA under the current terms, they'd be giving Microsoft early access and approval over new products, and would be unable to litigate if some technology from those products happened to somehow appear in a Microsoft product.
from a former seawolf (SSN-575) sailor
SUBDEVGRU ONE alumni? I was on the Parche (683) while the Wolf was doing her last few years at Mare Island.
Nice to see some actual facts in the discussion!
Fundamentally the GPU is just a massively parallel processor for operating on streams of data. That the data happens to be graphics data such as pixel or vertex arrays is almost incidental.
Back in the Stone Age, around 1984, we had the Pixar Image Computer with its' CHAP processors[1], long instruction word heavily pipelined processors designed to crunch streams of pixels. Some numerical routines for integer and fixed point math were available, painfully hand-coded in CHAP-Assembler
From time to time. someone would try to do general numeric processing with this monster. Eventually a floating point math package and C compiler with parallel programming extensions was put together for the machine[2], and general purpose programs were written to take advantage of the CGAP GPU.
The first program? "hello.c" naturally! A parallelized ray tracer was ported. The tracer used the SIMD capabilities and floating point package to to run the math primitive processing (normal calculations and whatnot) in parallel, and divided the raytracing of different scanlines across multiple CHAPs, demonstrating both a computing cluster and fully programmable GPU use at the same time.
The numerical processing capabilities were exploited for a number of commercial products, almost incidental to the use of the Image Computer to produce rendered images. Often buffers of fixed or floating point data would be computed or consumed incidental to the primary graphics task. I don't think anyone thought it was particularly special. We were just using the fastest compute engine in a system to do needed work.
1. Adam Levinthal , Thomas Porter, Chap - a SIMD graphics processor, Proceedings of the 11th annual conference on Computer graphics and interactive techniques, p.77-82, January 1984
2. Adam Levinthal, Pat Hanrahan, Mike Paquette, and Jim Lawson. Parallel Computers for Graphics Applications. Proceedings of the Second International Conference on Architectural Support for Programming Languages and Operating Systems, pages 193--198, 1987.
Annoying, isn't it? The trick here is not to let the apps draw to the visible frame buffer, which requires all this visible region locking, but instead to have the app draw to a buffer (in off-screen VRAM or main memory, addressable by the window system). The window system is then responsible for placing the content on-screen.
So, how does that help? The app always has a place to draw, and the separate window system process always has control over moving the bits onto the display. This means that a window manager can always order the window out, or move the window aside, without the cooperation of the application. In one implementation, the draggable areas used to move the window are registered with the window manager, so the app need not even be involved in moving the window.
One of the more interesting possibilities here comes into play when the window system is implemented atop a powerful engine such as OpenGL. In this case, the window buffers can be treated as texture sources and applied using the various texture combiner paths, along with scaling, filtering, and various transforms, all applied after the application has rendered it's content..
This allows the window system to be extended in a variety of ways without changing one line of the application's code. The windows can be minimized quite literally by adjusting the transformation matrix, or by playing with transparency, without the cooperation of the application. One could transform the window contents down to icon size, and composite the content with an iconic badge, producing a minimized icon representing the window, complete with live content, without the cooperation of the application.
Subtle point here. The hardware the apps have access to may not be the screen, but an off-screen surface which the graphics acceleration subsystem (such as OpenGL) can draw into. The window system takes care of getting the bits drawn in the off-screen surface onto the displays.
These surfaces can live in VRAM, or DMA addressable main memory. Lots of tricks can be done here by having the app draw at what is essentially the front end of the display processing pipeline.
Consider for example the GL buffer-as-texture path. Apps draw into a buffer, which when flushed is treated by the window system as a texture to be applied to the app window. The whole GL pipeline can be applied, scaling or warping the texture, altering the geometry the surface is to be applied to, mixing the texture with other texture sources, and so on.
In the Mac OS X window system, there's still clip lists, but they are not visible to the application. The app just draws in it's window buffers.
The clips are needed to handle event routing, as you mention, and to take care of some subtle internal housekeeping, even when Quartz Extreme is in use. Since not all systems or graphics cards can run Quartz Extreme (there are certain specific graphics card capabilities needed) the clipping information is needed for software compositing cases.
Curiously, the Mac OS X window system implements almost the exact design Jim Gosling describes in his paper.
All drawing work is done on the client side, and the window server has nothing to do with fonts, cut/paste support or much other higher level work. The window server simply assembles the drawing buffers to the displays (via hardware or software) and routes events, using hints of the foreground application and the visible window area to manage the task.
A consistent look and feel is derived by providing a consistent set of high level toolkits, residing on a set of lower level drawing frameworks.
Shared libraries make sure the needed code is readily available and resident in memory. Font are cached and vended as shared memory resources using Mach's virtual memory semantics. Drawing buffers also leverage Mach VM semantics.
You get used to it after a while. What I do is basically:
1) Don't carry anything valuable. They'll make you dump everything on a table, which they don't watch very well. For security staff, they're pretty slack about other people's stuff.
2) Wear cheap, flat 'deck' shoes, like $12 pairs fron a cheap show chain. You may lose them at some point.
3) If you wear a belt, use a cheap flat belt. You may have it torn open at some point.
4) Wear clean underware, with no holes. You may wind up with your pants around your ankles with 20 strangers there, as you try to stand straight, with no belt, and your arms straight out from your sides. (Happened to me at San Diego, in the hole they call Gate 1.)
Expect to be laughed at by the wanker TSA employees. Do not make any remarks or show any expression in response. Remarks about a**holes results in an extra hour or two in a small room while you wait for a cavity search 'specialist'.
It appears that he's just published the public key. That may allow him to ENCRYPT music for play over Airport Express, but it doesn't let him decrypt the stream.
.plan and sigs. I don't think that enables anyone to crack my mail. They can SEND me mail, but that's sort of the whole idea, isn't it?
Heck, I put a public key for mail in my