Quote:

Aslak3 wrote: @cdimauro Quote: [quote]You have so much freedom because of one thing: the Amiga o.s. was broken by design... I'd take issue with this last statement. It did only what it was intended to do, nothing more. Such things as memory protection and priv separation were/are not possible on a 256K 68000 system. It was what it was.

Of course a 68K cannot handle it. But handling the access to o.s. structures in an opaque way was perfectly feasible, for example. The same for not encouraging memory sharing between o.s. and apps, and between apps themselves. Resource tracking was feasible by simply putting a list (LIFO) of allocated resources by a single task. Defining as private the code segments loaded from the hunks is another thing to make it easier paging such memory.

I stop here, but I think you caught the message.
Quote:

Now, to run a system under these SAME limitations, when gigabytes and gigabytes and (say) a thousand times the CPU performance is available.... that's insane.

That's because of bad design decisions which compromise compatibility, and compatibility is very important in such niche market.
Quote:

Quote: You have fragmentation on any filesystem. Even the ones used by any Amiga/-like o.s.. ext2,3,4 and probably other modern filesystems are more or less immune to this problem. OSF/FFS was of course dreadful for this.

Modern filesystems don't defrag by themselves. There can be the o.s. that can run such task in background when the filesystem is not used, for example.

Regarding ext2/3/4, if you have log files in a system which are used by many days, it can take a while, even a lot of seconds, to deleted them, even if their size is much less than a GB. That's because of fragmentation which cannot be prevented by the filesystem.
Quote:

Quote: You can continue if you like. I really like to know what funny thing you'll report or invent. No need to stoke the fire that much....

You're right. I apologize.
Quote:

Quote: The homosexual of the operating systems! Careful. Some people, not me, but others, will take offence at this. You diminish your own arguments with such comments.

It was just a joke... :-/

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: You can do whatever you want because the Amiga o.s. is totally open: all its data structures are public and normal applications can change them You where discouraged to poke and peek this by commodore, they remended you to use the propper set and get functions in Exec and DOS.

I already answer for this, and it's not true. What you reported is regarding the graphic (graphics.library and intuition.library).
Quote:

Quote: You have so much freedom because of one thing: the Amiga o.s. was broken by design.. The only thing broken by design was brains of the developers who did not follow the guidelines.

Correct. And most broken ones were the brains of the developers that have written the guidelines and allowed such dirty things, as I already explained here and on the other thread...
Quote:

http://archive.org/stream/International_Amiga_Developers_Conference_Notes_1993_Commodore/International_Amiga_Developers_Conference_Notes_1993_Commodore_djvu.txt

It's almost all about graphic, as I said on the other thread.
Quote:

Sure they did have many excuses not to, any how AmigaOS is more backwords compatible then most operating system out there.

That's simply because if you try to introduce some modern feature, you break compatibility. That's why it's still backward compatible: you don't add modern things, and you're "fine".

Easy task for maintaining an o.s. almost as is...
Quote:

Try running Windows3.1 applications on Windows8 Try running MacOS6 programs on MacOSX

Try to run an Amiga/-like o.s. and its apps with SMP, memory isolation & protection, resource tracking, and see how well they run.
Quote:

AmigaOS design was good for its time, now updating it to a modern OS, is complicated task, with the few resources thats available.

Of course, and that's because it was bad by design...

An o.s. is not a dogma: it's technical stuff. Otherwise we're talking about religion and fundamentalism...

@cdimauro

"Of course, and that's because it was bad by design..."



It was superior and everybody knows it.
It handled insane amount of stuff far better than any other solution.
It was very future proof in design.

But there are limitations, even when less severe than on those other designs.

Microsoft has rewritten & redesigned their OSs several times since AOS1.3 times.
Same for Apple.

AOS is still using original 1.3 design etc. Time to update the originally superior design.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

Quote:

It was superior and everybody knows it. It handled insane amount of stuff far better than any other solution. It was very future proof in design.

I guess BSD/Unix were more future proof... But it was better than most consumer OS of the time, indeed.

_________________
http://www.warpdesign.fr/

Quote:

CodeSmith wrote: Quote: NutsAboutAmiga wrote: Try running Windows3.1 applications on Windows8 Actually, you probably can unless it's a win16 program and you're running 64 bit windows (and that's a cpu limitation).

For the 16 bit code the virtualization was possible to keep the compatibility, but in practice it doesn't make sense to retain such very old piece of software.
Quote:

Microsoft is obsessed with backwards compatibility, in fact most of the bloat in windows can be blamed on that. To illustrate how far they take it, see this video - it shows windows 1.0 being upgraded, one version at a time, to 8.1. And all the programs still work.

That's because they are using the regular Win16 APIs, but applications hitting the hardware or installing some drivers stopped worked.

But I agree with the general concept: Microsoft have take care of backward compatibility, and largely achieved it.
Quote:

Quote: AmigaOS design was good for its time, now updating it to a modern OS, is complicated task, with the few resources thats available. Engineering is always an exercise in tradeoffs. Back in 1982 when Carl and the rest of the Amiga team were working on the hardware and software, they had a good design that met their requirements, and was easily the best available for a home computer (there were much better designs at the time, but you had to go to IBM or a university lab to see them). Of course amigaos is outdated today - just about every single requirement has changed in the 20 years since cbm went under. A lot of things that are expected today were either unusual or just plain didn't exist when amigaos was being architected, eg if the original 68k had had an MMU I'm sure that the amiga team would have used it to protect OS data structures, rather than asking people not to overwrite them (and being ignored). A lot of the filesystem limitations were because they were designed with floppies in mind - hard disks didn't become commonplace in home computers until the 90s.

I'm not that sure. I think they lacked a proper vision, and have worked like devils to complete the o.s. in time.

Just another example of it is the AllocEntry API: it has put a severe 2GB limit to the address space of the o.s. and the applications, because they decided to use the MSB to signal an error. Since such API normally returns a pointer to list of allocated memory blocks, and that every memory allocation was done using some granularity (I don't remember now if it was 4 byte or 8 bytes the minimum for the Amiga o.s.), such pointer should have had the lower bits always cleared normally. So, the API could have used the LSB to signal an error, without compromising the 4GB address space.

This just another example of the bad design decision that they did and hurt the future of the o.s.. Also the hardware has some bad decisions, to put all the things on the table.

I think that this facts should be accepted as they are, instead of claiming a superiority that, instead, resulted in the enormous limits which are still pending.

Amiga was a wonderful personal computer as all we remember, basically because we (ab)used of it, but scratching the surface and going deeper many bad things and design decisions emerge which are still causing problem.

Quote:

KimmoK wrote: @cdimauro "Of course, and that's because it was bad by design..." It was superior and everybody knows it.

I've exposed specific, technical, questions. You cannot argument with: "everybody knows it was superior".

If there's something wrong of what I said before, you're free to counter-argument and TECHNICALLY show where and how it's wrong.
Quote:

It handled insane amount of stuff far better than any other solution.

Too much generic.
Quote:

It was very future proof in design.

You're completely changing the reality. It's because it was bad by design that its future was and IS crippled.
Quote:

But there are limitations, even when less severe than on those other designs.

Such limitations puts a clear distinction between an hobby/toy o.s. from a mainstream one (NOT as pure market share numbers, but as a solution that can accommodate the needs of the average people; and no, I'm not referring at the quantity of software available, but at the intrinsic o.s. features that let it and its apps run in productive way).
Quote:

Microsoft has rewritten & redesigned their OSs several times since AOS1.3 times. Same for Apple.

See the previous comment: Microsoft ADDED a lot of things, but its APIs are largely backward compatible.

Apple is a different story: it changed the o.s. because MacOS was bad by design as the Amiga one. After that change (from MacOS to MacOS X, to be more clear), the o.s. remained largely backward compatible with its APIs.
Quote:

AOS is still using original 1.3 design etc. Time to update the originally superior design.

With the first sentence you proved why the second one is false: it's because the o.s. had a bad, not a superior, design.

@cdimauro

If you're going to admit that every OS at that time was a bad design, then you might have some credibility. I could spend hours documenting problems I encountered using Mac, MS and Amiga "back when". Short and simple with a couple of personal experiences.... Windows couldn't record digital and open a doc at the same time without crashing, Amiga 1.3 could. Mac couldn't format a floppy and run a terminal program at the same time, Amiga 1.3 could. Not perfect, no contest to modern 2014 standards. But yes, superior among it's peers late 80's, early 90's.... fact.

Comparing classic AOS to the current main stream OS's after 100's of millions of dollars of development and multiple redesigns each has had is just ... well.... silly.

Plaz

Quote:

Plaz wrote: @cdimauro If you're going to admit that every OS at that time was a bad design, then you might have some credibility. I could spend hours documenting problems I encountered using Mac, MS and Amiga "back when". Short and simple with a couple of personal experiences.... Windows couldn't record digital and open a doc at the same time without crashing, Amiga 1.3 could. Mac couldn't format a floppy and run a terminal program at the same time, Amiga 1.3 could. Not perfect, no contest to modern 2014 standards. But yes, superior among it's peers late 80's, early 90's.... fact. Comparing classic AOS to the current main stream OS's after 100's of millions of dollars of development and multiple redesigns each has had is just ... well.... silly. Plaz

+ 1 & common sense to MOST of us

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

@Plaz: I wasn't talking about bugs and/or applications defects, but about design decisions that crippled the future of the o.s.. From this point of view, MacOS was bad by design like the Amiga o.s. was (and in fact, it was completely replaced by Apple with MacOS X), albeit the latter had pre-empitive multitasking.

@cdimauro

The design decisions fit the need, expectations, technical tools and available hardware of the time. It's like saying steam engines were a bad design. No, they were amazing in their time and helped lead us to the modern day as part of the natural evolution of tech.

Now if someone is still trying to stuff a 500hp steam engine in to a 2014 Corvette... yeah we'll agree there. That's quite possibly a BAD design. But saying that AOS was bad in it's day is just not true. Clearly though every OS from 1988 is a poor design by todays standards. (except for dos, really how can you not like dos? )

Plaz

@Plaz

Quote:

Now if someone is still trying to stuff a 500hp steam engine in to a 2014 Corvette... yeah we'll agree there. That's quite possibly a BAD design.

or possibly not

Saab Steam Car

It's been postulated that if we had the metallurgy of the late 20th century in the late 19th century, we'd most likely be driving steam powered cars and even motorcycles, although I suppose we'd most likely call them steambikes.

Crude oil and petroleum would still be industrialised as a great war would be unavoidable in this alternate history, and we would still have invented PVC.

_________________
All the way, with 68k

@tbreeden

Ah the '70's. So many fun "what-ifs" :)

@agami

Sorry, I think I just ran the Dave Haynie thread off topic in to SteamPunk for a second there. lol

Well if my PC is steam powered, I'm running xtgold on dos 5.0. You just can't see through fogged up windows.

Plaz

Quote:

Plaz wrote: @cdimauro The design decisions fit the need, expectations, technical tools and available hardware of the time. It's like saying steam engines were a bad design. No, they were amazing in their time and helped lead us to the modern day as part of the natural evolution of tech. Now if someone is still trying to stuff a 500hp steam engine in to a 2014 Corvette... yeah we'll agree there. That's quite possibly a BAD design. But saying that AOS was bad in it's day is just not true. Clearly though every OS from 1988 is a poor design by todays standards. (except for dos, really how can you not like dos? ) Plaz

I don't know if you are a coder, but from what have you written 'til now you don't look one. I've exposed some technical things here, which talk about specific issues regarding design decisions.

You're justifying them because they were tight to the time when the Amiga o.s. was developed. I'll show you how another o.s., which was clearly inferior to the Amiga one, addressed similar TECHNICAL (I have to highlight it again) DESIGN DECISIONS.

I report some sentences from here: http://www-user.tu-chemnitz.de/~heha/petzold/ch01c.htm

"To illustrate the various techniques of Windows programming, this book has lots of sample programs. These programs are written in C and use the native Windows APIs. I think of this approach as "classical" Windows programming. It is how we wrote programs for Windows 1.0 in 1985, and it remains a valid way of programming for Windows today.
[...]
Generally, the Windows API has remained quite consistent since Windows 1.0. A Windows programmer with experience in Windows 98 would find the source code for a Windows 1.0 program very familiar. One way the API has changed has been in enhancements. Windows 1.0 supported fewer than 450 function calls; today there are thousands.
[...]
The API for the 16-bit versions of Windows (Windows 1.0 through Windows 3.1) is now known as Win16. The API for the 32-bit versions of Windows (Windows 95, Windows 98, and all versions of Windows NT) is now known as Win32. Many function calls remained the same in the transition from Win16 to Win32, but some needed to be enhanced. For example, graphics coordinate points changed from 16-bit values in Win16 to 32-bit values in Win32. Also, some Win16 function calls returned a two-dimensional coordinate point packed in a 32-bit integer. This was not possible in Win32, so new function calls were added that worked in a different way.

All 32-bit versions of Windows support both the Win16 API to ensure compatibility with old applications and the Win32 API to run new applications. Interestingly enough, this works differently in Windows NT than in Windows 95 and Windows 98. In Windows NT, Win16 function calls go through a translation layer and are converted to Win32 function calls that are then processed by the operating system. In Windows 95 and Windows 98, the process is opposite that: Win32 function calls go through a translation layer and are converted to Win16 function calls to be processed by the operating system."

You can find more here: http://www-user.tu-chemnitz.de/~heha/petzold/ since the Windows programming wasn't changed much.

To further show this concept, take a look a this example: http://www.transmissionzero.co.uk/computing/win16-apps-in-c/

Again, I report some sentences:

"To avoid any possible confusion, when we say “Win16” we are referring to the original 16 bit Windows API, where 32 bit addresses are made up of a segment (in real mode) or selector (in protected mode) combined with an offset, and all applications are cooperatively multitasked in a single address space. This API is present from Windows 1.0 to Windows 3.11, and for backwards compatibility reasons is also present from Windows NT 3.1 to current x86 versions of Windows. Windows 95 to Windows ME also support the Win16 API, partly for reasons of backwards compatibility, but also because much of the 32 bit user mode API code on these versions of Windows do little more than call the 16 bit API equivalent to carry out their tasks!"

Pay attention, in both links, to a very interesting thing which is described: how Windows NT and Windows 9x handle the calls to the Win16/32 APIS. NT converts Win16 calls to its internal Win32 calls. 9x converts Win32 function calls to the underling Win16 subsystem.

Why it is / was possible? I report a previous sentence of mine: "handling the access to o.s. structures in an opaque way". This is the key to abstracting the interface between the applications and the o.s.. It's so important that, as you can see, you can even have the o.s. APIs implemented in 16 or 32 bits code, and the 32 or 16 bits calls can be routed to the corresponding 16 or 32-bit versions!

Is it all Magic? No: GOOD DESIGN DECISIONS!

Take a look at the Win16 sample application of the last link, and you'll see that NO O.S. INTERNALS ARE EXPOSED TO THE USER APPLICATIONS: all "important" data structures are exposed and accessible using HANDLES. Sorry for the capitals I used, but it was to better underline the concept.

Was it possible when the Amiga was released? YES: Windows 1.0, a POOR o.s., showed and proved it.

Was it possible with Amiga hardware limits? YES, a PC of the time had a POOR 8086 SLOWLY running due both to the low frequency and the great number of cycles that most instructions required. The MAXIMUM available memory was 640KB (for the very lucky and rich guys that had the chance to get them). An Amiga, instead, had a speed demon 68K running at 7Mhz, and at least 512KB.

Is clear enough now even to non coders? I think so. So, please stop talking about cars: I reported FACTS. TECHNICAL facts about PRECISE arguments. If you want to show that some of them are wrong, you have to counter-argument using, again, TECHNICAL facts on the SAME argument.

Last edited by cdimauro on 28-Aug-2014 at 06:33 AM.

@cdimauro

Summed up nicely as "opaque handles are a good idea".

I have done Win16 (gah) and Win32 (slightly less gah). I do agree with you, but there are some horrors in Windows coding as well. Specifically the AMOUNT of code that has to be written to do simple things. This is why noone writes Win32 directly anymore.

_________________
Blog

Quote:

Aslak3 wrote: @cdimauro Summed up nicely as "opaque handles are a good idea".

Exactly. How many times people like KimmoK dreamed-up about AmigaOS running both 32 and 64-bit applications? With an opaque interface provided by the o.s. it would become possible, like Windows did with Win16 and Win32 applications, and then with Win32 and Win64.

Nowadays it's impossible if you want to get full gain of the 64 bits while running the 32-bit apps as "first-class citizens" on an hypothetic (full / pure) 64-bit o.s.. And you've to resort to an horrible and Amiga o.s.-unnatural dirty hack to get SOME benefits of using the >= 2GB memory...
Quote:

I have done Win16 (gah) and Win32 (slightly less gah). I do agree with you, but there are some horrors in Windows coding as well. Specifically the AMOUNT of code that has to be written to do simple things. This is why noone writes Win32 directly anymore.

The same for me, and I don't how many people liked to directly do Windows programming using the native APIs.

In fact, I'm a Borland fan, and I still appreciate the VCL design, which I used an worked on for a lot of time (with Delphi).

@cdimauro

Quote:

Generally, the Windows API

I do see your angle. But we still have to disagree a bit on what was "bad".
MS developed API's because they were a software company that wanted customers to run their wares on a variety of hardware. API was a necessity for that. Mac and Amiga had a different approach... make a machine that was best at what it did tied more closely to compatible hardware. No need for them to do similar API's. In the end MS won out of course.

Quote:

Is it all Magic? No: GOOD DESIGN DECISIONS!

I won't deny they did work hard to keep backwards compatibility with ever changing hardware. Stability was the price often payed though.

In the grand scheme of things MS had the winning design. Focus on software, let other companies work out compatible hardware. Even foolish CBM started making compatible hardware for the "enemy". CBM couldn't compete on both levels and lost. And as you mention even Mac eventually left the custom hardware behind OSX.

Is an OS closely tied to hardware a bad design? I just can't call it that. Such things have their place. I think it's interesting too that now with all compatible hardware available it has opened the opportunity for so much linux to move in. I was excited back in the day when it looked like Amiga would infuse with QNX. Seemed like a move for the future. Ah well.

As for coding... I started as a coder when binary, asm and pascal were the typical tools. When C was still a shinny new toy I was moving on to a different career path. I later returned briefly to perl and C coding, but except for a few C hobbies I've not coded seriously in years. Doesn't mean we can't have a good discussion on things though. And BTW my last favorite win compiler was also borland.

Plaz

Quote:

Plaz wrote: @cdimauro Quote: Generally, the Windows API I do see your angle. But we still have to disagree a bit on what was "bad". MS developed API's because they were a software company that wanted customers to run their wares on a variety of hardware. API was a necessity for that. Mac and Amiga had a different approach... make a machine that was best at what it did tied more closely to compatible hardware. No need for them to do similar API's. In the end MS won out of course.

APIs is what any o.s. must provide to the applications to let them access its services. Here it isn't a question of hardware variety, but "simply" a matter of design decision. It's all about : "how do I expose my services outside?"

Hardware variety is not relevant, because when Microsoft designed the Windows APIs it was the time of DOS, and PCs had substantially the same hardware, with very few changes regarding the video cards, and that was very easy to handle.

Also AmigaOS4, MorphOS, and AROS proved that it's possible to let an Amiga/-like o.s. run of VERY different hardware, included very different architectures (AROS runs on x86, x64, and ARM).
Quote:

Quote: Is it all Magic? No: GOOD DESIGN DECISIONS! I won't deny they did work hard to keep backwards compatibility with ever changing hardware. Stability was the price often payed though.

It's o.s. abstraction that matter here. You can take a look at many other o.ses, and you'll see that a normal, I can say obvious, thing is to do NOT expose internals but provide opaque interfaces. And in no way let the normal applications access and modify the o.s. structure.
Quote:

In the grand scheme of things MS had the winning design. Focus on software, let other companies work out compatible hardware. Even foolish CBM started making compatible hardware for the "enemy". CBM couldn't compete on both levels and lost. And as you mention even Mac eventually left the custom hardware behind OSX.

Nobody known the future at the time. Even Microsoft, when it released Windows 1.0: the same year of our Amiga 1000 introduction.

Commodore made a lot of other mistakes, which we all know.
Quote:

Is an OS closely tied to hardware a bad design?

See above.
Quote:

I just can't call it that. Such things have their place. I think it's interesting too that now with all compatible hardware available it has opened the opportunity for so much linux to move in. I was excited back in the day when it looked like Amiga would infuse with QNX. Seemed like a move for the future. Ah well.

Honestly I don't like POSIX systems. But it's a question of taste here.
Quote:

As for coding... I started as a coder when binary, asm and pascal were the typical tools. When C was still a shinny new toy I was moving on to a different career path. I later returned briefly to perl and C coding, but except for a few C hobbies I've not coded seriously in years. Doesn't mean we can't have a good discussion on things though. And BTW my last favorite win compiler was also borland. Plaz

Nice.

@cdimauro

Just look at AOS1.x vs MS-DOS & System 1.0 & Windows 1.0.
(unlimitedRAM, HW/devices, multitasking, libraries, speech, done too many comparisons, not wasting time on it any more. Good design also results a lightening fast and flexible system, one of those was.)

And in reality I saw no-one using windows in 1990. Only DOS and 640k RAM on x86. Tells a lot.
(oh those y1995 times...)
In 1996 at work computers started to have win3.11 but still more limited multitasking, RAM, etc etc. Than my miggy OSs...

Last edited by KimmoK on 29-Aug-2014 at 08:17 AM.
Last edited by KimmoK on 29-Aug-2014 at 08:09 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Mikey_C

Couldn't agree more Mikey.

Edit:

Oops, just realised how old this thread is!

Last edited by sicky on 29-Aug-2014 at 01:50 PM.

_________________
SAM 460 with 2GB or RAM, 1000GB HD, 4 port SATA, DVDRW drive and Radeon HD 4650 GFX card.

@KimmoK

Quote:

KimmoK wrote: @cdimauro Just look at AOS1.x vs MS-DOS & System 1.0 & Windows 1.0. (unlimitedRAM, HW/devices, multitasking, libraries, speech, done too many comparisons, not wasting time on it any more. Good design also results a lightening fast and flexible system, one of those was.) And in reality I saw no-one using windows in 1990. Only DOS and 640k RAM on x86. Tells a lot. (oh those y1995 times...) In 1996 at work computers started to have win3.11 but still more limited multitasking, RAM, etc etc. Than my miggy OSs...

Again, you're answering to TECHNICAL questions reporting USER EXPERIENCES. I repeat again: if you think that the TECHNICAL things that I reported are wrong, you are free to counter-argument them with other TECHNICAL facts.

BTW, Windows 3 was an incredible success when it was introduced. So successful that Microsoft decided to regret from the OS/2 project that she was working on with IBM.

I don't know why you continue to talk of things that it's quite evident that you don't know...

Quote:

In 1996 at work computers started to have win3.11 but still more limited multitasking, RAM, etc etc. Than my miggy OSs...

In 1996 computers were packaged with Win95, which had already caught AmigaOS...

Nobody is denying that in 1985, as a consumer OS, AOS was more advanced than Atari/TOS, DOS/Win,.. This doesn't change that today it's a dead end and there are lots of difficulties because of bad (rushed) design decisions.

_________________
http://www.warpdesign.fr/