Amiga OS 3.1 Source code leaked yesterday

[Hercules]

Originally Posted by Minuous

@absence:

Unfortunately AROS is much too far behind recent versions of AmigaOS, and that gap is only widening. Also its performance leaves much to be desired.

Their are a limited number of developers on the Aros project, the other goals are met by philosophies of what others would like to see and bounties. Of course it shall always be behind modern day operating systems, but those whom put their money where their mouth is to push the bounties for a new feature is to be employed. Compared to AmigaOS is has come on leaps and bounds. The only thing it lacks when compared to AmigaOS is memory protection. Sadly we won't see that under AmigaOS or Aros anytime soon based on how the OS is designed.

[masteripper]

Originally Posted by redblade

I think I remember reading that you needed Green Hills C compiler to compile Intuition because it was designed with 16 bit ints not 32 bit.

I want to make it clear...I am curious if the code is correct in the concept that "if" - as described in the hypothetical scenario that you land in a fully configured environment (Green Hills C compiler would be there ...np on this) - everything "else" is there the code would compile and produce the final product... "auxiliary" - although critical - "byproducts" are not counted in.

[gulliver]

Nope, parts are missing and the build is broken as it is.

[Thomas Richter]

Originally Posted by redblade

I think I remember reading that you needed Green Hills C compiler to compile Intuition because it was designed with 16 bit ints not 32 bit.

Not exactly. It's not the int size that makes intuition special, it is the calling syntax. Greenhill C passes short structures (smaller than 4 bytes) in registers instead of copying them, and in some places of the original intuition code, this was made use of.

However, this was all fixed already before 3.1.4 started, and today the Os is fully buildable from scratch by means of vamos. Actually, the vamos branch on my github page was used to build 3.1.4. Just by a "make". It took a while to get it there, but it is nowadays not really much of a problem to run a hosted built of the Os such that in the end you get the kickstart ROM images and the workbench disks out of it.

[Thomas Richter]

Originally Posted by gulliver

Nope, parts are missing and the build is broken as it is.

The 3.1 built, yes, but not the 3.1.4 built. This was all part of the problem getting the Os into a compilable shape again.

[Minuous]

Originally Posted by Hercules

Compared to AmigaOS is has come on leaps and bounds. The only thing it lacks when compared to AmigaOS is memory protection.

That's not correct; it is missing a great deal of functionality. Eg. the entire ReAction GUI subsystem, and most other AmigaOS improvements of the last 20+ years.

[kamelito]

@Minous,
I didn't knew AmigaOS 3.1.x has been in development for 20+ years

[masteripper]

Originally Posted by Minuous

That's not correct; it is missing a great deal of functionality. Eg. the entire ReAction GUI subsystem, and most other AmigaOS improvements of the last 20+ years.

Sorry again for asking but I am a bit confused over the answers that you all kindly provide...as the question is not what the "leak" could include but -assuming - you have all the tools that you start compiling Kickstart --> presto a file what ever extension ready for the flash programmer, start compiling Workbench --> presto a set of files...
You put the flashed Kickstart to a suitable Rom...a hypothetical Amiga that carries all the functionality in hardware level ...boots showing the animation to insert a disk or whatever...you insert the disks... workbench starts booting...it doesn't matter if its completely stripped out of extra functionality...I am assuming only the bare minimum...even booting to Amiga Shell would be considered sufficient.
TIA and sorry for the bother

[Thomas Richter]

Originally Posted by masteripper

Sorry again for asking but I am a bit confused over the answers that you all kindly provide...as the question is not what the "leak" could include but -assuming - you have all the tools that you start compiling Kickstart --> presto a file what ever extension ready for the flash programmer, start compiling Workbench --> presto a set of files...

As already said, you cannot build from this leak, it doesn't compile. Intuition is one problem, graphics is another, and the build system yet another. For 3.1.4, it took about 6 months to get a working built system, and only because there was already some work done on intuition to allow it to build on SAS/C instead of Greenhill C.

[masteripper]

Originally Posted by Thomas Richter

As already said, you cannot build from this leak, it doesn't compile. Intuition is one problem, graphics is another, and the build system yet another. For 3.1.4, it took about 6 months to get a working built system, and only because there was already some work done on intuition to allow it to build on SAS/C instead of Greenhill C.

Maybe I am not 100% clear.
Suppose it was some other application for example completely in C++.
Besides all the issues described would there be missing .cpp/.h ?

[jotd]

sources are just useful to know how this is done. Rebuild is another story, except when the companies took the hassle to try to reproduce the build from scratch on an empty machine.

[masteripper]

Originally Posted by jotd

sources are just useful to know how this is done.

this is exactly what I am asking.....is the source complete ?
Now whatever special conditions must be met in order to get it producing "meaningful" result is another story

[Matt_H]

Originally Posted by masteripper

this is exactly what I am asking.....is the source complete ?
Now whatever special conditions must be met in order to get it producing "meaningful" result is another story

Part of the reason this is, for all practical purposes, unusable is that this isn't an archive of a source repo. It's a partial dump of one of Commodore's fileservers that happens to include (most of?) the v40 code. There are references throughout to directories/files that aren't included in the .tar file. The build environment is one of those missing things; I don't know/don't understand what's missing in terms of code.

[masteripper]

Originally Posted by Matt_H

There are references throughout to directories/files that aren't included in the .tar file..

This is exactly what I am asking...
If for example

#include "/monitor.h"

and monitor.h is missing then its incomplete..

[redblade]

Originally Posted by Thomas Richter

Not exactly. It's not the int size that makes intuition special, it is the calling syntax. Greenhill C passes short structures (smaller than 4 bytes) in registers instead of copying them, and in some places of the original intuition code, this was made use of.

So when I disassemble a C binary and I see all the values get put on stack, then jump to the routine which copies from stack to the registers, then calls the function.

Greenhill C just loads direct to the function registers ?? That would save A LOT of code. I think they used to charge over $1,000 for their C compiler, now I can't find the price on the website.

Originally Posted by Thomas Richter

However, this was all fixed already before 3.1.4 started, and today the Os is fully buildable from scratch by means of vamos. Actually, the vamos branch on my github page was used to build 3.1.4. Just by a "make". It took a while to get it there, but it is nowadays not really much of a problem to run a hosted built of the Os such that in the end you get the kickstart ROM images and the workbench disks out of it.

Thanks will look into it

[Thomas Richter]

Originally Posted by redblade

So when I disassemble a C binary and I see all the values get put on stack, then jump to the routine which copies from stack to the registers, then calls the function.

Greenhill C just loads direct to the function registers ?? That would save A LOT of code. I think they used to charge over $1,000 for their C compiler, now I can't find the price on the website.

Sorry, I was imprecise. Greenhill C uses a stack-based calling syntax, and thus requires the typical register ping-pong. However, consider you have something like:

struct Point {
 WORD x,y;
}

then Greenhill C can "alias" this structure to a LONG (as it is 32 bits in size). Thus, instead of passing a LONG, one can also pass a "struct Point" instead. Since this is/was all K&R C, and arguments were passed on the stack anyhow, this worked silently without the compiler complaining. The "fake LONG" is/was then taken apart in some call-paths and casted back to a struct.


ANSI C cannot cast an integral type to a struct - it can only cast a pointer to an integral to a pointer to a struct. Thus, from today's perspective, this was quite dirty code that depended on pecularities of the Greenhill compiler.


This was all changed for 3.1.4 - there is no longer a register ping-poing necessary as SAS/C can take register parameters directly, and the code was cleaned up (not by me) to compilable by SAS/C. Thus, calls reach the code directly, and within intuition, the SAS/C registerized parameters are used.



The only place where we have additional ping-poing is where automatic stack extension is performed. OpenScreen/Window functions, mostly, and the autorequester functions.

[jotd]

AlexH also told me that CDTV ROM sources aren't in the package (example: cdtv.device)

[alexh]

Originally Posted by jotd

AlexH also told me that CDTV ROM sources aren't in the package (example: cdtv.device)

Yes the CDTV directory/branch is not in this "leak".

There is stuff in the cdgs directory (CD32) but even if you use RCS and "check-out" the earliest version you can see it is not the code for CDTV v2.07 or v2.30. (Despite some of the earliest files having a version number of 2.3)

It's better than nothing I guess. It is a great shame because it would have accelerated the debug of why cdstrap, cdtv.device and cdfs.library didn't work with 32-bit FastRAM installed. But that is now all understood.

The AmigaOS 3.1.4/3.2 guys intimated that this "leak" is not the only AmigaOS source code available to them and that they have the CDTV source code preserved... somewhere....

[Matt_H]

Originally Posted by alexh

Yes the CDTV directory/branch is not in this "leak".
The AmigaOS 3.1.4/3.2 guys intimated that this "leak" is not the only AmigaOS source code available to them and that they have the CDTV source code preserved... somewhere....

If I had to guess, I’d say that this archive was made by a Commodore employee a few weeks before the bankruptcy. Over the years it probably changed hands a couple of times and was converted from tape to .tar (probably by someone who didn’t know what exactly they had) and released out to the net.

Presumably the “official” Commodore server backup tapes were turned over to Escom in 1995. The chain of custody for the OS4 and OS3.1.4+ code probably originates with those tapes. Remember a few years ago there was an animation released showing code commits dating back to the 1.x era? That animation couldn’t have been created without access to a more complete backup.

[Jope]

Originally Posted by Matt_H

Remember a few years ago there was an animation released showing code commits dating back to the 1.x era? That animation couldn’t have been created without access to a more complete backup.

Is this still available somewhere?