Amiga OS

[darklife]

Did it use window buffering? Besides the hardware, why was it so fast?
Maybe most the techniqes could be applied to a PC based OS. My Amiga 500 with a 7Mhz (not 70, or 700) could play more than one movie at the same time with almost no slowdowns. Sound was still fine, and GUI fully interactive. Full screen mpeg movies wouldn't even slow it down using many colors and 30fps.
The hardware was good, but I'm sure the OS had something to do with it.
It could do all of this with 1Meg of memory! Not 1Gig lol.
On the other side, why is Windows XP so slow. Just bad code or is it really the hardware?

[Solar]

Did it use window buffering?

Yes, optionally. (You could select smart or simple refresh.)

Besides the hardware, why was it so fast?

The AmigaOS was designed without MMU support. Upon loading from disk, an executable was relocated to a physical address - no virtual / physical translation necessary.

Since there is no memory protection, sending a message is a matter of passing a 32bit pointer, no matter how large the message.

And the AmigaOS GUI didn't try to do too many things at once. See below.

Maybe most the techniqes could be applied to a PC based OS.

They could, but at the expense of memory protection. And I doubt the advantages would be so large on a CPU that has been built with MMU in mind from the very beginning.

On the other side, why is Windows XP so slow. Just bad code or is it really the hardware?

No, it's definitely not the hardware - QNX shows how much you can squeeze out of a custom IA32. The problem with Windows is its rotten messaging system.

Add to this that the Windows GUI tries to do so many things. Even if a window is not active, it still gets all the mouse-over events passed through. AFAIK, AmigaOS never did that kind of stuff, but focussed on the active window alone.

[Tim]

Windows messaging is fine. Windows is slow because it's simply doing a lot more.

Compare NT 4, Windows 2000 and Windows XP. NT 4 is amazingly fast on modern hardware. XP is usable. NT 4 is relatively small (a couple of hundred MBytes). XP is well over a gigabyte. They all have the same core, and the same design, but the difference is that XP has far more features than NT 4, yet few have been taken out.

(On the other hand, Microsoft do have a schedule for removing unused features from their operating systems. Note that between 2000 and XP, they removed NetBIOS, OS/2 and Posix support, among other things. And IA-64 versions have had 16-bit support removed.)

[Pype.Clicker]

my hints on "Why is Window Slow" are:
- Win3.x was cooperative multitasking, which means the slowest process slows down the whole system
- The FAT filesystem suxx ... which means virtually no windows 9x can be good (as even the .
- The other windows are huuuuge, which means they hardly fit in the processor cache and the cache misses induce severe performance penalty. The fact that QNX fits on a floppy reinforces me that way
- MS marketting service is trying hard to sell "Futurist OSes" -- which should be understood as "an OS which requires hardware which is not yet available"

[Brian_Provinciano]

In my opinion, Microsoft takes advantage of the 99% of computer users who are just plain ignorant, and by having menu shadows, gradients, bloated themes, and all the other visual crap that slows down perfomance, those people will buy it. If it looks the same but runs 500% better, most people won't buy it, because most people go by how it looks visually. Of course, GNOME and KDE in the RedHat 7 distros GUIs are slower than XP on my PC with all the fancy crap enabled. It's only 800mhz, but I'm not going to buy a new one. Instead of wasting my money on a new PC to run the newest software, I try to just stick to the versions that were released when the PC was new... runs way faster

Microsoft should start from scratch like MacOS X, and then just have an emulator, like MacOS X for the old stuff. They REALLY REALLY need to start from scratch, which an entirely new design. They need to think outside the WM_MESSAGE box, they need to build it from SCRATCH!

[Solar]

Really, dudes. It's not merry guessing that the Windows messaging scheme is broken.

Under load, a Windows application needs ages to get the hint and redraw its window. (Or the OS if the window is buffered, I really don't care.) If you click a button, it takes more than a second before the button reacts visibly. If you clicked it a second time in this phase, you get double postings (or some other duplicate effect). And that's only the GUI stuff.

If my informations are correct, Microsoft never fundamentally revised their messaging since Windows 2.x.

[Brian_Provinciano]

As a matter of fact, Windows 1.0 executables will still run under WindowsXP. All you need to do is open them up in a hex editor and change the Windows version to 3.0 in the header. Funny enough, the same is true for 2.0 exes of course. Making us all wonder why Microsoft just plain wouldn't allow backward compatibility? So everyone would need to purchase new versions of Word and such?? Hmm...

On a minor note, some control positions are slightly off in Win32, but not usually, a very minor thing. Likely due to the system metrics or something. Other than that, they run perfectly fine.

[darklife]

As a matter of fact, Windows 1.0 executables will still run under WindowsXP.

That says it all right there ;D
Imagin if Microsoft made Amiga OS and it was designed the same but in the "Microsoft way". It would be horrible! So much for playing mpegs on my old Amiga 500 7MHz system lol. Well I could laugh all I want about this but the truth is that Microsoft could never make something as good as the Amiga OS. They may be good at creating pretty eye candy, but when it comes down to it, we would have Amigas that run such a slow OS that you would need a 800 MHz Motorola processor to run something equivelent to Amiga OS 1.2 lol.
Still, I'll take Linux over Amiga OS any day. I just miss my old A3000 with WB 3.1, 60MHz processor. Those were the days.

[mr. xsism]

this is a good string. So far i got this:
-IPC/messaging should be small in size and frequency
-GUI should use smart buffers(dirty rect theory)
-GUI themeing should be simple with less details
-when possible, don't change DPLs

i would enver NOt use MMU. Virri would have a hay day. GUIs can still have great looking themes without a 40 piece theme. Heck, if you'd use color themeing instead of image themeing it would be awesome.

That last point isn't as obvious, but is understood as such. This canbe difficult to do because drivers need to communicate with user progs and if you keep user progs and drivers in one DPL it can create security flaws. Agreed?

We ought to look back at how OSes worked when they HAD to operate with 640K. I can't imagine how they did it? First thing that comes to mind is assembly and byte code. Most of us use C and the nuts of the bunch use C++. No matter how we look at it both languages are bloated compared to assembly. One thing i am doing to reduce size in C is not 4KB aligning the segments. I see no use in doing that. Should i not remove alignment?

hmm, phun phun phun.
mr. xsism

[Solar]

-IPC/messaging should be small in size and frequency

Hehe. ;D Note that AmigaOS was efficient, but not infrequent. The exec kernel basically fullfills the definition of a microkernel.

-when possible, don't change DPLs

That, together with the "infrequent IPC", targets a monolithic kernel approach.

I would never NOT use MMU.

And today, you would be right in that decision. Back in the early 80'ies, that was a price decision - MMUs were extra chips <=> extra costs, while today they are integral part of every desktop CPU.

Back then, the Amiga designers decided that memory protection can never be perfect (correct), and that the additional effort and cost (in both $ and speed) was not worth it.

And if all Amiga programmers would have heeded the API docs regarding memory management, you could even retrofit memory protection. But as always, people assumed that "if it works, it is correct". :-\

GUIs can still have great looking themes without a 40 piece theme. Heck, if you'd use color themeing instead of image themeing it would be awesome.

Personally, I oppose per-application themeing / skinning. If every app looks and feels different, I have to "learn" every individual application. Most modern GUI approaches aim at softening the borders between applications to generate one homogenous user interface. Per-application skinning is the absolute opposite of that.

That last point isn't as obvious, but is understood as such. This canbe difficult to do because drivers need to communicate with user progs and if you keep user progs and drivers in one DPL it can create security flaws. Agreed?

Absolutely. (AmigaOS had drivers and apps in different protection levels, BTW.)

We ought to look back at how OSes worked when they HAD to operate with 640K. I can't imagine how they did it? First thing that comes to mind is assembly and byte code. Most of us use C and the nuts of the bunch use C++. No matter how we look at it both languages are bloated compared to assembly.

I disagree, at least in part. I claim that you would be hard-pressed to generate hand-written ASM code that beats compiled C code of comparable quality. This is due to the complexity of modern CPU's, their pipelines etc.

I also doubt that you could squeeze even one order of magnitude in size out of hand-written ASM compared to compiled C. But you buy all sorts of troubles, like maintainability and the headache when the next CPU generation has different requirements on alignments, parallelism etc.

One thing i am doing to reduce size in C is not 4KB aligning the segments. I see no use in doing that. Should i not remove alignment?

Segments are aligned to faciliate paging. If you don't page, you don't have to align (to 4 KB).

[mr. xsism]

but i do use paging, but the kernel is ment to be a singular core of code. The core does so many things and then the plugins do the rest. I don't see any use in K alignment within kernel segments themselves, but instead in the entire kernel image itself only.


thanks for your comments solar

[Tim]

The 4KB alignment is to make protection work. At the very least, you need to keep .text and .bss/.data separate, because protection is per page. In general you want all sections to be page-aligned in memory, if the image format supports arbitrary sections and permissions.

The waste incurred by page alignment really isn't big -- max 4095 bytes per section. Some formats (PE, and, I believe, ELF) support different alignments on disk and in memory, so you can align to 512 bytes on disk and to 4096 bytes in memory.