I will help you out. I'm sure it's going to be a huge improvement over Windows 8.

Shachar

Just to add pedanticity (pedanticness?) to the discussion....

You forgot Windows 95 OSR2 and Windows 98SE, both technically OS versions of their own.

Shachar

Menus on the Amiga were bound to the screen, not the window. You are probably remembering a full-window.

Shachar

You can keep your ancient 1.3 books. I have the shining new 2.04 manuals in one of my unpacked boxes here (or maybe it is in storage, next to my actual Amiga?)

Shachar

The original Amiga 500, including the early Kickstart 1.3 ones, would actually completely turn off the LED. If you don't believe me, you are welcome to visit me. I still have my original machine in (more or less) working order.

You are correct that later models would not turn it off completely, but rather only dim it. I only remembered that fact after I hit Send, and thought no one will be anal enough to demand a clarification.

In other words, the hardware does not support it.

That is one point I am not as sure about. It goes against what I remember, but I might be wrong on that point. However:

Do provide links. Please. I failed to find them, and my black 2.04 books are buried in some box from my latest moving day (if I had not thrown them out).

Shachar

You misremember. The Copper code to change display modes took several scan-lines to run. Having a window with different display mode was impossible. You could, and did, have a UI construct called a "screen", which had its own display mode. You could drag a screen down and see another screen behind it.

AFAIK, none of those utilized SKIP. They were all based on WAIT and MOVE. If you know differently, please provide further details.

I don't think so. I am, however, fairly sure you mis-remember.

Shachar

You got a partial answer. If "SKIP" was ever used, I'm interested to know by whom. I only know of a single example, which was EXTREMELY special case.

The commands:
MOVE: move immediate value into copper register. These included such actions as where in memory the video memory was (i.e. - where to fetch the picture from), what is the palette, video resolution, where on screen the video fetch starts and where it ends and many others.
WAIT: wait for the screen update to reach a certain point. There was a mask argument which allowed you to have don't cares on some of the bits.

These two was how most of the programs worked. From simply displaying a static image (the memory fetch registers had to be reset each frame), through "copper waves" (things like telling the hardware to start displaying the image in a different timing each line, so that a straight in memory was a wave on screen), to what matfud erroneously called "display HAM in a window" (it took several scan lines for the copper to completely replace the display mode, so you couldn't display two modes side by side, but you could display them one above the other). It also allowed "virtual sprites" by reusing the same 8 hardware display sprites for different things in the same frame, so long as they were not in the same line.

The third command, skip, had the same arguments as WAIT. Instead of waiting, however, it skipped the next command if the condition was not met. Add to that copper registers that restarted the copper program if written to, and the fact you could load two start addresses and switch between them, and you get the ability to perform a loop.

Back in 1994 there was a Mac "emulator" called A-Max. It was not really an emulator. It loaded Mac ROMs into the ram, patch some hardware related entry points so that it would work on the Amiga, load a copper instruction that caused the Amiga display to act like a Mac black & white display, and simply executed the ROMs. As a result, a 7.2Mhz Amiga 500 ran programs written for the 8Mhz Mac at 120% speed.

One (rather minor) problem they had was that while the display content was showing correct colors, the Amiga was hard-coded to use color 0 for the overscan. As a result, the overscan, black on the Mac, was white on A-Max. Around 1993 I figured a way to resolve this, using the SKIP command and the loop method mentioned above. I assumed that if I figured it, it was obvious, and didn't do anything with it. Around a year or two later, A-Max released a version which had text similar to the following:
Thank you (don't remember the name) for providing us with a method to give a black overscan without writing a huge copper program. As thanks, we've given him a free version of A-Max.

Which caused me to kick myself no ends, and never assume my ideas aren't innovative.

As far as I know, there was no other use for the skip command (which might explain why the A-Max guys never thought about it themselves).

Shachar

And then Commodore went on to (half inherit, half design) the Amiga. Maybe "cobbled together" is too harsh for it, but still. Floppy controller that can decide, per track, whether to work in MFM or RLL (but not read a single sector, mind you), more DMA channels than the CPU can handle, and a display processor with a built-in three commands machine language (one of which was only ever used by one application ever) to change display resolution mid-monitor.

I loved it, but the Amiga gave the impression that it was designed by engineers that couldn't make up their mind on what choice to make, so they created hardware that would offload all decisions to software.

One last anecdote. Many have heard of the famous "Guru meditation". What only Amiga users know is that you knew one was coming because the power led would blink three times. Yes, the power led was software controlled, making the Amiga the first ever computer that could play dead.

Shachar

Plus the character gave off a distinct "Elton John" air (or is it just me?)

Shachar

Yes, but that's not the whole story (sorry about the pun).

Douglas Adams once said that every new medium he adapts to is a rewrite for him. He, quite deliberately, did not repeat the same story in a different medium, but rather wrote a new story loosely based on the same plot and characters.

Some of the differences between the movie and other adaptations were clearly not a dictation of the medium, but rather an artistic decision. Two random examples: in other portrayals Zaphod's heads were side by side and the heart of gold, at least in the books, was shaped like a sneaker shoe. The only reasons to change those are artistic, not medium related.

Yes, when you adapt a story to a new medium it was never told in before, changes are inevitable. To me, the best case scenario is that someone who understands and loves the original story embraces this fact, and tries to recreate a new story that captures as much as possible that was good in the original.

In fact, those movies which do try to capture the original books as accurately as possible are those I enjoy less. When I see them, I've either already read the book, or it is a few clicks away. By all means, give me a different story in the movie.

Shachar

According to that logic, if I own an apartment, and I rent it out to you, I can video and audio record its interior.

It doesn't work that way, and that's a good thing. When you are driving a car, you have a reasonable expectation that you are not being watched and recorded all the time.

The country I live in (Israel) is strictly a "one party" country. Recording the inside of a car is, however, a case where none of the parties to the conversation are aware of the recording. It wouldn't pass here either.

Shachar

A while back my wife had to go to Jeruslaem on the same day George W. Bush was visiting there. I let her know she was going to spend the day sitting in stand-still traffic.

Turns out, I was wrong. So many people assumed the same thing that nobody travelled to/from the city that day. The roads, when not blocked, were empty.

Shachar

So how did the court case end?

Shachar

Yeah, I heard that claim before. Aside from the Novel Wordperfect stink, that is just not so.

What people fail to consider when saying this is that, even if it were still true (and I don't think it is), it is immaterial. Wine does not need to, and does not do so, implement every one of Windows' APIs. It just needs to implement those APIs that programs are actually using.

MS cannot change interfaces to existing APIs. That will break application compatibility (without which, MS has no monopoly). They can add new functionality all they want. Until applications start using them (i.e. - after release), they are immaterial to Wine.

Also, you simply assumed everything else I said was the same. Linux interfaces in BSD are not subject to the same rules, and yet they did very little to drive adoption of BSD based OSes.

It all boils down to this. If you want to run Windows apps, you are going to do so on Windows. If you want to run Linux apps, you are going to do so on Linux. If you want to run Android apps, you are going to do so on Android. Every so often, you will want 90% from your native OS, and the support for those extra 10% would be great. It is not, however, something that drives large scale market shifts.

Shachar

P.S.
Judge Jackson's finding of facts had everything to do with IE integration, some to do with Java embrace and extend, and nothing at all to do with private APIs.

Actually, Wine does a surprisingly good job on a surprisingly large number of applications.

But also, and I cannot stress this enough, whoosh. In your haste to spew unfounded ridicule, you completely missed the sarcasm.

Shachar