Consequences of the AmigaOS 3.1 source code "leak", one year after?

[Christian Johansson]

Nope, they did not fix anything, they made the camera not work at all with Windows 10 - not work as in.. no software would find any camera, despite it being there the device list, and according to Windows, working.

Ok, Windows 10 was not release by then, so i only tried it in Win7 and probably Win8.

[slaapliedje]

You mean a company like Red Hat ?

Red Hat definitely keeps their customers happy.  On the other hand, Microsoft are successful by a lot of strong arming of OEMs and generally shady, cut throat deals.  Granted Atari and Commodore were far too concerned with each other to open their eyes up in time to notice that the IBM compatibles were sweeping in to take over.

[Thorham]

And no, that's exactly what you *cannot* do. The consequences are that your program will be taken down

You can do what ever the hell you want, and depending on what you're doing, no one might ever find out that you based your work on someone else's work.

[slaapliedje]

Okay, no one has really come out and said it... but.. does it actually compile?

I seem to recall when it was leaked that people were having a hard time getting it to compile  anything, and that sources were missing.  But then it was long enough ago that I could be remembering something else.

Can you compile it with gcc?

[Pat the Cat]

Okay, no one has really come out and said it... but.. does it actually compile?

I seem to recall when it was leaked that people were having a hard time getting it to compile  anything, and that sources were missing.  But then it was long enough ago that I could be remembering something else.

Can you compile it with gcc?

How can anyone say "Yes" without making it blatantly obvious that they have tried to do so?

Bear in mind, it isn't designed to produce directly executable code exactly like other programs. It's designed to run from a ROM chip, at startup.

Also, I really don't know which compiler it was designed for. Probably Lattice, but that is a guess.

[EugeneNine]

My experience with HP printers specifically and printers in general is  that if they are supported in CUPS, they WILL work a lot better under  Linux than under Windows.  Windows has always had a really crap printing  system.  I mean it's just absolutely terrible.

I recall having  to do some weird voodoo to get my mother's printer to even work after it  randomly stopped printing.  All with install drivers, make sure it's  not plugged in, plug it in when it tells you, oh wait, it didn't detect,  okay unplug, reboot, remove drivers, reboot again, install drivers,  plug in printer.. oh is going to work?  Nope, try again...

Ohh, the whole plug it in, unplug it, plug it in again thing is because USB is crap in windows too.

This is a network printer though.

But I've setup other printers in Windows too and its still too much work in Windows compared to Linux.

So I mentioned earlier that software changes affecting you are not just an issue in open source but also close source.
Many years ago I tested Office 2010 in my company and they asked for feedback so I took the time and wrote up all my issues and then rolled back to 2007 and a couple weeks later got an e-mail claiming all the issues I reported didn't exist as both my helpdesk and Microsoft had thoroughly tested office 2010.  When SP1 for Office 2012 was released I found all of my reported issues in it as fixes.  So I have to at least give them credit for fixing those even though they denied they existed.  I still have a couple old KB numbers that haven't been fixed.

[bison]

Yes. Amongst the other "dragon territories", as such as "which init system do I use today", "which X11 replacement system do you prefer" and "how do I configure my printer with cups".

CUPS was the end of printer configuration, at least for me.  Since CUPS it's been a matter of 1) plug in the cable, 2) press CTRL-P, and 3) click the "Print" button.  Maybe I'm just lucky with printers, although previous experience with copiers would not indicate this.

[olsen]

Okay, no one has really come out and said it... but.. does it actually compile?

I seem to recall when it was leaked that people were having a hard time getting it to compile  anything, and that sources were missing.

Building the code is difficult, as most of it requires an Amiga-native compiler/assembler to create something that fits on the disk/into the ROM and does what it's supposed to. On top of that, hardly any two components of the operating system are built in the same manner, using the same set of makefiles and scripts.

Tinkering with the code is more like archaeology, when what you do involves sifting through layers of dust, ashes and earth before you can even begin to reconstruct the organization and systems as they were when they were still functional.

Can you compile it with gcc?

Not really.

[kamelito]

@Olsen
Isn't it simpler in the long run to just backport AmigaOS 4.1 for Classic 68k Amiga without PPC?
It will surely be slower but as HW and Software simulation/emulation go faster in the long term it will be fast enough I guess and one code base is better than 2.

Kamelito

[olsen]

@Olsen
Isn't it simpler in the long run to just backport AmigaOS 4.1 for Classic 68k Amiga without PPC?
It will surely be slower but as HW and Software simulation/emulation go faster in the long term it will be fast enough I guess and one code base is better than 2.

Kamelito

I don't believe that this would be the easier option, even in the long run.

The "threshold" when backporting code from AmigaOS4 to AmigaOS 3.x could still be accomplished with reasonable effort (time and manpower) was crossed in about 8-9 years ago. Ever since then new data structures and APIs have been added to AmigaOS4 which significantly increase the difficulties of backporting code.

This happened at Commodore, too, when Kickstart/Workbench 2.x was under development. The toolbox became larger (double the ROM space, double the leverage afforded to software developers), and it became more and more difficult for Commodore to provide the same tools to developers who wanted to use them both in 1.x and 2.x applications.

There weren't many such tools (I remember "amigaguide.library" and the Installer), and there were some 3rd party solutions such as a disk-loaded "gadtools.library". But inside the operating system, the new APIs and data structures created more tightly-coupled code, saving ROM space and allowing for more robust code to be written.

Backporting such code at some point means porting practically everything, because you cannot always conveniently resolve the new interdependencies. Even if you tried, you'd run into practical problems for a hypothetical AmigaOS4 for 68k: AmigaOS4 is designed for a platform with much more RAM. As these things go (Moore's law, etc.) it also requires a more powerful CPU to run smoothly than a 68k platform could deliver (unless you consider emulation a target platform that makes good business sense). Finally, that complex port would have to be tested as well, which is no small challenge to begin with.

[kolla]

How can anyone say "Yes" without making it blatantly obvious that they have tried to do so?

Clearly someone managed to compile parts of it at least, the parts that you can find in BB3+4, the parts with major version string ... 42

To build the whole thing is not what people are interested in either, each person has his/her point of "itch" that has been bothering them.

[wawrzon]

I don't believe that this would be the easier option, even in the long run.

The "threshold" when backporting code from AmigaOS4 to AmigaOS 3.x could still be accomplished with reasonable effort (time and manpower) was crossed in about 8-9 years ago. Ever since then new data structures and APIs have been added to AmigaOS4 which significantly increase the difficulties of backporting code.

This happened at Commodore, too, when Kickstart/Workbench 2.x was under development. The toolbox became larger (double the ROM space, double the leverage afforded to software developers), and it became more and more difficult for Commodore to provide the same tools to developers who wanted to use them both in 1.x and 2.x applications.

There weren't many such tools (I remember "amigaguide.library" and the Installer), and there were some 3rd party solutions such as a disk-loaded "gadtools.library". But inside the operating system, the new APIs and data structures created more tightly-coupled code, saving ROM space and allowing for more robust code to be written.

Backporting such code at some point means porting practically everything, because you cannot always conveniently resolve the new interdependencies. Even if you tried, you'd run into practical problems for a hypothetical AmigaOS4 for 68k: AmigaOS4 is designed for a platform with much more RAM. As these things go (Moore's law, etc.) it also requires a more powerful CPU to run smoothly than a 68k platform could deliver (unless you consider emulation a target platform that makes good business sense). Finally, that complex port would have to be tested as well, which is no small challenge to begin with.

in one sentence: os4 as a whole has become incompatible with amiga. which is actually the case for what i know. there is apparently less hassle to backport a good deal of aros software to genuine amiga system, not only because it guards the original concepts, it actually runs on 68k, because things like necessary functions are still register parametrized, library interface is interchangeable, hook syntax is apparently the same like the original one and last but not least aros has in comparison to the features it offers a reasonable memory footprint, comparable to original kickstarts.

what an irony..

[Pat the Cat]

Clearly someone managed to compile parts of it at least, the parts that you can find in BB3+4, the parts with major version string ... 42

To build the whole thing is not what people are interested in either, each person has his/her point of "itch" that has been bothering them.

Kolla, I haven't ever looked at the source code of an operating system written in C. C isn't one of my primary coding languages. I can adjust a C program's data, stuff like getting an Arduino system running. That isn't the same as an operating system.

Both the leaked 3.0 (?) and 4 partially or completely rewritten in C, but certain parts of the leaked source must be derived from the BCPL ancestor, TripOS, that was ported to the Amiga. And really, no one has ever attempted a full translation of AmigaDOS, into hand coded assembler. For any kind of Amiga hardware. At least that I'm aware of.

Bits of the operating system can be coded in assembler, and ideally, an OS evolves tailored to the hardware available.

It's amazing how like AmigaDOS TripOS is. Because TriPOS is still in use, networked distros that cost money, by a lot of British insurance companies.

Here's a very short overview, with regard to similarities like drivers and libraries. Parts of the leak might well date from a much earlier BCPL ancestor. That isn't true of AmigaOS V4 and later. That's all been redone, which is probably partly WHY V4+ is so greedy on 68K machines for resources.

https://en.wikipedia.org/wiki/TRIPOS

Anyway, I haven't looked at the code. Lattice is mentioned in a lot of publicly available Commodore works, and I bought a few, so it's reasonable to assume that was the dev tool used to put the leak together in the first place, V3.0 was a CBM software and firmware release. Isn't that right? I don't know.

Unless, perhaps, it isn't genuine in all respects. That's one possibility, with an internet dissemated file.

[guest11527]

Both the leaked 3.0 (?) and 4 partially or completely rewritten in C, but certain parts of the leaked source must be derived from the BCPL ancestor, TripOS, that was ported to the Amiga.

The development path of AmigaOs is somewhat convoluted. AmigaOs used to be a mixture between assembler in its core parts, C and BCPL. In 2.0, the BCPL parts were replaced by C, though most of the replacments came into living by the "arp" (Amiga Replacement Project) project of the "software distillery". Thus, many of the commands in C: are reworked versions of the arp commands, and not directly ported from BCPL.

And really, no one has ever attempted a full translation of AmigaDOS, into hand coded assembler. For any kind of Amiga hardware. At least that I'm aware of.

AmigaOs is already hard to maintain as of today. Translating it into assembler makes it even harder to maintain, and harder to upgrade. Not a good deal if you ask me. Assembler code might be quick, streamlined efficient, but also bug-ridden, and "not yet quite ready, sorry."

It's amazing how like AmigaDOS TripOS is. Because TriPOS is still in use, networked distros that cost money, by a lot of British insurance companies.

AmigaDos is historically almost completely Tripos. If you look at Tripos basics, it seems even likely that some of the exec components were derived from or inspired by Tripos. Exec devices and the device interface looks very much like the device interface of Tripos.

Parts of the leak might well date from a much earlier BCPL ancestor.

Not much of the original Tripos interface were left in AmigaOs 2.0 and later. It's only a thin compatibility layer that remained. AmigaOs 1.3 still had the Tripos loader (aka "LoadSeg") in dos.library, along with the GloVec constructor used by all the BCPL commands in C:. Tripos libraries are substationally different from amiga libraries, and the "OpenLibrary" function is there actually part of the loader ("LoadSeg"), and not the responsibility of the program itself as we have it today. That is, 1.3. LoadSeg() had the ability to open libraries for the code.

This stuff still worked with the 1.3 Tripos "dos.library", though was removed for 2.0. You find more details on this in Ralph Babel's "Guru Book".

The bad part is that this magic actually only works for the dos.library as the calling convention required for library linking through LoadSeg() is different from the usual calling convention.

That isn't true of AmigaOS V4 and later. That's all been redone, which is probably partly WHY V4+ is so greedy on 68K machines for resources.

Not really. Tripos was already gone in 2.0 except for a couple of assembler stubs for compaibility.

Lattice is mentioned in a lot of publicly available Commodore works, and I bought a few, so it's reasonable to assume that was the dev tool used to put the leak together in the first place,

AmigaOs is based on three compilers, based on the development time of the components. Lattice C 5 for many legacy components. Newer components were compiled with SAS/C, and some of the old code was ported to SAS. Intuition is a bit special as it required the Greenhill compiler, as only component. 1.3 was Lattice and BCPL.

V3.0 was a CBM software and firmware release. Isn't that right? I don't know.

Lattice C 5 came from Lattice, not CBM. The SAS institute bought it later on and released version 6 as SAS/C.

[Pat the Cat]

The development path of AmigaOs is somewhat convoluted.

AmigaOs is already hard to maintain as of today. Translating it into  assembler makes it even harder to maintain, and harder to upgrade. Not a  good deal if you ask me. Assembler code might be quick, streamlined  efficient, but also bug-ridden, and "not yet quite ready, sorry."

Well yes, translating all of the code into assembler will take quite  some time. But, key components can be translated one at a time and  tested for compatility. I take your point about exec, the only part you  can't really mess with a lot without breaking something somewhere is  exec and intuition. That has to be present at the turnkey stage, ie,  burnt into a ROM, or sideways ROM mapped in a 32 bit Amiga.

Lattice C 5 came from Lattice, not CBM. The SAS institute bought it later on and released version 6 as SAS/C.

Didn't know that, like I said, C isn't my thing. Yeah, I recall  arp.library being a seperate component. I guess the whole history is  different exec's and family sets of Workbench and KS resources being  used, some shunted in, some shunted out.

I just find it fascinating that you can recode bits of it and shunt  different versions of libraries and devices into and out of a system by  copying files and reboot. With differing levels of success for getting  things working, it would seem. Or load a different module device or  library to replace the one started with from the KS ROM.

Oh yeah, Thomas, respect for looking at the 68040 library. I played with  one once, reviewed it as a current draining, hot beast, but I didn't  click that the 68040.llibrary was eating memory as it ran. I put it down  to hardware issues, not a software problem in the 68040.library. Then  again, I only had it a couple days. Not like I really had much time to  check. Respect for sorting that issue out.

EDIT:  I think I get the point about dos.library really calling the tunes as  far as smartly using the right library without the end user being aware of it. But, it seems to me that rather  than the program choosing the library for WB2 and later, it's more a  case of the programmer chooses roughly what will be used, and the end  user has to find and slot in the best fit of device and library and maybe handler for their system and  application, if the one they are using doesn't do the job properly. That was always true, very few people ever bothered with loadseg. I didnt. I haven't looked at Ralph Babels book, seems he is upset at an early public release in English so just sticks with the German for the current release. Ignorant? Well, I'm a bit busy right now, will try to catch up later on an 800 page technical document written in German.

[kolla]

Kolla, I haven't ever looked at the source code of an operating system written in C. C isn't one of my primary coding languages. I can adjust a C program's data, stuff like getting an Arduino system running. That isn't the same as an operating system.

Er... ok?

Both the leaked 3.0 (?) and 4 partially or completely rewritten in C, but certain parts of the leaked source must be derived from the BCPL ancestor, TripOS, that was ported to the Amiga. And really, no one has ever attempted a full translation of AmigaDOS, into hand coded assembler. For any kind of Amiga hardware. At least that I'm aware of.

Bits of the operating system can be coded in assembler, and ideally, an OS evolves tailored to the hardware available.

It's amazing how like AmigaDOS TripOS is. Because TriPOS is still in use, networked distros that cost money, by a lot of British insurance companies.

Here's a very short overview, with regard to similarities like drivers and libraries. Parts of the leak might well date from a much earlier BCPL ancestor. That isn't true of AmigaOS V4 and later. That's all been redone, which is probably partly WHY V4+ is so greedy on 68K machines for resources.

https://en.wikipedia.org/wiki/TRIPOS

Anyway, I haven't looked at the code. Lattice is mentioned in a lot of publicly available Commodore works, and I bought a few, so it's reasonable to assume that was the dev tool used to put the leak together in the first place, V3.0 was a CBM software and firmware release. Isn't that right? I don't know.

Unless, perhaps, it isn't genuine in all respects. That's one possibility, with an internet dissemated file.

I don't understand - why are you talking about OS4?
(And why do you write so much that is not at all relevant here?!)

Maybe you do not know the AmigaOS version string conventions? OS 3.0 was largely "version 39", as in most binaries in OS 3.0 had major version 39. In OS 3.1, these were bumped to 40 and maybe a few 41. In the OS 3.1 leaked sources, there are a few things that have developed further, to version 42.

This has _nothing_ to do with OS4.