The Os 3.1.4 Thread

[Tygre]

Hi Thomas and all!

I probably come late but I wanted to thank all people involved in working on 3.1.4! It is an amazing feat to have succeeded in reworking, recompiling, modernizing, improving a code base that has been around for such a long time You all deserve big thanks and our (my at leat!) admiration for doing this job! It must have been similar to monks doing mediaeval illumination ("Un travail de moine" in French...)

Congrats and thank you!

Pulling windows out of screens is a feature of intuition v45 which will be available for all customers of 3.1.4 as an optional component for installation. Unfortunately, it is only optional because it does not work with cybergraphics.

Unfortunately, CGfx depends on compiler-specific register- and memory allocation of the compiled intuitition v40 code beyond our knowledge, and intuition v40 is the only component which was built with the Greenhill compiler. Unfortunately, the compiler is no longer available, and even if it would, we would not know how to integrate it into the built-system, so we cannot reproduce what Cgfx requires.

We reached out to Frank Mariak asking for insight, and offered an internal interface in intuition v45 for CGfx to reproduce (with some assembly stubs potentially) its requirements. Even some first contact was established successfully, this went unfortunately nowhere.

So, at this time, intuition v45 is for native graphics and P96 only, and only as an optional feature. I would have preferred to offer this as a regular part of 3.1.4, but we cannot risk to loose Cgfx customers.

[Tygre]

Hi Thomas!

Let me second what Olaf wrote:

b) Testing! The problem with the printer device was not only that it was legacy code, it was also not tested to the degree necessary. This being said, I'm not fully in line that the printer is my accomplishment. It is to a major degree the result of our beta test group that continued to file bug after bug. In the end, I do not remember how many we had for the printer and the HP drivers.

Very nice! I'm curious if you could tell us more about testing: do you use test frameworks? What test cases exist? Did you inherit test cases or build your own test suites?

Cheers!

[Tygre]

Hi Thomas and Olsen!

Thank you for your answers, very interesting!

The Amiga operating system and all its components matche one of the textbook definitions of legacy code: code for which no automated tests exist. It is not designed to be testable, which makes it very hard to both design effective tests and to deploy a testable version in the same context as it would be in if it were production code and not test code (ROM space is the major limitation here). The operating system source code is a mix of 'C' and assembly code, both of which provide very little leverage to achieve abstraction layers which are much more easily available in object-oriented languages.

If you are used to testing frameworks to make your life easier, you know what you are missing. I did investigate how testing of complex 'C' code is being done, and the sad result seems to be that is an unsolved problem. The testing frameworks I found which apparently catered to the need of automated 'C' code testing seemed to be not much more useful and powerful than the equivalent to planting assert() calls and the occasional printf() in the code (debugging like it's 1983), so I was none the wiser.

As far as I can tell there is no worthwhile test framework for 'C' legacy code, but I'd very much like to be proven wrong on that... So we did not use one on AmigaOS, which is why there are no use cases and no test suite to speak of.

Compatibility testing still worked very much like it did when Commodore was still in business: testing by exercising the features, discovering compatibility issues more or less by chance as well as by methodical exploration.

One exception is the new "Disk Doctor" which I wrote from scratch for Workbench 3.1.4. The code was designed to be testable, and it even includes a damage simulation feature which makes the disk access layer pretend that certain forms of data corruption or read errors exist on the medium. Automated testing involved having Disk Doctor examine and recover data from hundreds of Amiga disk images.

I don't know of a good framework to test C code either, even less so for OS and OS ROM and libraries... Could you explain in more details what you mean about "It is not designed to be testable"? Naively, I would have think that, being a set of libraries (in ROM or software), there could be tests for each and every available data structures and functions provided by these libraries, but I'm certainly missing something here... in particular, when it comes to dynamic stuff, like tasks and processes.

Could you tell us more about the features that you exercised? Do you have a set of programs that you know are "tough" on the OS and "play" with them to test the OS?

Best!

[Tygre]

I don't know of a good framework to test C code either, even less so for OS and OS ROM and libraries... Could you explain in more details what you mean about "It is not designed to be testable"?

He means, you can't easily do test driven development, or have test traceability, which is much easier to do with object oriented code. Plus there's nothing like selenium that could drive the UI automatically to test GUI stuff.

Traceability between functions and tests is of course possible, not more easier/difficult with C than with Java... it all boils down to the code and the framework(s) (if any). So, thanks but I would prefer a direct answer

Best,

[Tygre]

You somehow seem to consider Hyperion as a small or medium sized enterprise

Nonsense, stop putting words in my mouth - I consider them a one-man show, a lawyer, with a plumber and an sql-jockey as sidekicks.

But... it's not like https is magic and maintaining a certificate is wizardry, this is really simple to fix issues, but yet they are incapable. It seems they are only interested to offer support if your problem is related to registering and paying, otherwise it is utter silence.

You read Thomas' and agree with him: Hyperion are a (very) small operation (with possibly little revenue), so why would they spend time on things that do not directly bring money? Especially to help someone who complains without contributing much...

As we say in French: "it's easy to criticize, but hard to act".

[Tygre]

It's not about helping me, it's about helping themselves, about having at least *some* credibility as a *computer software* company that knows what it's doing. This low resource, undermanned and "possibly low revenue" (are you kidding? It's a "negative revenue" company), is still capable of writing a software license that is long, full of quasi-legalese nonsense, still capable of buying Reaction, still capable of fighting legal battles east and west, still capable of threatening people east and west, still capable of stepping all the toes they can and burning all bridges they have had with other Amiga entities, still capable of updating content and do announcements, still capable of pissing people off by attempting to register trademarks which they don't own and tons more. But no resources to take necessary measures to secure the privacy of their own customers, who are the only source of income they have, and for whom they have legal responsibilities.

This contradicts your comment that this is a "one-man show" (your words). So, again, you are just complaining for the sake of complaining.

QED!

[Tygre]

There is no contradiction and you have not demonstrated anything, so a "QED" here is out of place.

QED bis...