Welcome, Guest. Please login or register.

Author Topic: Consequences of the AmigaOS 3.1 source code "leak", one year after?  (Read 36736 times)

Description:

0 Members and 3 Guests are viewing this topic.

Offline Pat the Cat

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #194 from previous page: January 07, 2017, 05:19:55 PM »
Quote from: Thomas Richter;819275

Well, instead they decided to include Arexx. Unlicensed, BTW, as far as I know.

Interesting. I never got feedback from IBM on Rexx. William (Bill?)l Hawes should know, one wasy or the other.
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

guest11527

  • Guest
Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #195 on: January 07, 2017, 05:26:47 PM »
Quote from: Pat the Cat;819278
Interesting. I never got feedback from IBM on Rexx. William (Bill?)l Hawes should know, one wasy or the other.

While Rexx is certainly a language designed by IBM, Bill is in no relation to IBM. ARexx was a re-implementation of Rexx in 68K assembler (urgh!). In the same sense, Basic is not a Microsoft property, even though Microsoft made a lot of money by providing Basic implementations to many platforms (amongst them the C64 and the Amiga.) But other Basics exist, for example the Atari Basic, which is an unrelated implementation by SMI (which became later Oss).

Thus: ARexx != Rexx, except for the language fundamentals, and Bill != IBM.
 

Offline Pat the Cat

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #196 on: January 07, 2017, 05:27:26 PM »
Quote from: Thomas Richter;819277

At least a much cheaper. 1$ per disk as opposed to 0$ per disk is an easy decision to take. However, unlike Basic, ARexx is not a beginnner's language, and it did not include an editor, or a GUI, or support for graphics... nothing like that. It's an entirely different type of product, thus hardly comparable.


This is why they charged for replacement floppy sets, of course. Most people were like "it's a disk, it costs pennies". They did not appreciate that the content was actually valuable and had cost money to develop.

Would it have really been sensible to keep funding a rival OS, purely to keep using the same Basic? I think CBM were smart. They knew alternative Basics would appear, having studied how software chains develop. They also knew that, for serious development of applications, Basic was very very limited.

You have a bleeding edge product. You want to attract developers. You do not include crap development tools with the base machine unless there is no alternative.
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline Pat the Cat

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #197 on: January 07, 2017, 05:33:01 PM »
Quote from: Thomas Richter;819279

Thus: ARexx != Rexx, except for the language fundamentals, and Bill != IBM.

Rexx = IBM. Arexx = Amiga implementation of Rexx. Therefore, to certain degree, Bill has a relationship with an IBM product, in that he developed an Amiga implementation of an IBM product. He didn't do it blindfolded. :)
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline Pat the Cat

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #198 on: January 07, 2017, 05:40:44 PM »
Quote from: Thomas Richter;819275
If you search through the CBM bug database (which you probably don't have), you'll notice that there were at least three versions of AmigaBasic (all from Microsoft, of course). The version 1.2, which was shipped on the Extras disk of Workbench 1.2.

I didn't know they had a bug database. I thought they just had a shredder for that sort of thing. CBM were principally known as a hardware provider. Any issues with software were kept very, very close. Bit like Apple in many respects.

If you weren't a registered developer (and I could not be) then they didn't talk to you. They certainly did not talk to me about jack %&$#?@!%&$#?@!%&$#?@!%&$#?@! that was technical. I had to find everything out from day one pretty much on my own, but at least I could make phone calls without worrying about the cost of that.

Reason I couldn't be a registered developer? Conflict of interests. You cannot sign a Non Disclosure Agreement and yet be a responsible, independent journalist who puts their readers first, last, and always. That was my problem to deal with, and I ended up giving up journalism. I made some cool Amiga toys instead. Now excuse me, I'll start digging them out for y'all.
« Last Edit: January 07, 2017, 05:52:33 PM by Pat the Cat »
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

guest11527

  • Guest
Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #199 on: January 07, 2017, 05:40:55 PM »
Quote from: olsen;819264
If you've read so far, congratulation! As you might have concluded by now, I do not subscribe to the idea that what makes an Amiga what it is would be strongly connected to how close it is to the operating system design or target hardware of AmigaOS 3.1.

Well, I beg to differ. I've a very pragmatic approach to this definition, which is the "duck principle". "If it talks like a duck and it walks like a duck, it is a duck".

The problem with the mentioned changes - as good and well-motivated they really are (Tripos volume and lock handling is a mess, "ACTION_EXAMINE" is a mess) no argument! - is that they cause incompatibilities with existing software (file systems, for example), and hence violate the "duck principle". If I cannot run Amiga software on the machine, it's something, but not Amiga.

Even CBM did great care in the introduction of 2.0 that software would remain working. Even as of 3.1, the 1.2 BCPL command line tools (the stuff in C:, e.g. C:copy) works correctly (well, almost "Ed" is an exception, details follow if needed), as even v40 of dos.library includes a compatibility layer for Tripos.

That is, CBM tried their best to follow the "dug principle". Os4 did not. Different CPU, compatibility not as prime principle.

Unfortunately, legacy software is all what exists on the Amiga, so introducing something incompatible - no matter how good that is - will leave some software behind, and shrinking the already existing software basis is not exactly a good move.

I believe this is the point where Os4, Morphos... got it wrong. The systems tried to establish a new platform, even though the days where you could gain customers through a convincing platform alone were over already. The market changed considerably, and the Os became uninteresting for users.

Very quickly: The "Home computer area" was dead at this time. Amiga is a retro platform these days, and *this* market works differently.
 

guest11527

  • Guest
Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #200 on: January 07, 2017, 05:49:31 PM »
Quote from: Pat the Cat;819282
I didn't know they had a bug database.
CBM had a professional developer program, called CATS. Unfortunately, it costed money to join, and no, I never joined. I just bought the books (RKRMs, AmigaDos manual) and did some reasearch of my own.

Quote from: Pat the Cat;819282
If you weren't a registered developer (and I could not be) then they didn't talk to you. They certainly did not talk to me about jack %&$#?@!%&$#?@!%&$#?@!%&$#?@! that was technical.
Right, and correct. I also wrote letters to CBM, they probably went into the same paper waste as yours. I believe everyone disliked the CBM "management" in all its glory. Customer relations costs money, and CBM was always short of money. Instead, ask developers to *pay* for your platform. I as a hobby developer did not buy into this type of marketing.
 

Offline Pat the Cat

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #201 on: January 07, 2017, 06:04:21 PM »
Quote from: Thomas Richter;819284
CBM had a professional developer program, called CATS. Unfortunately, it costed money to join, and no, I never joined. I just bought the books (RKRMs, AmigaDos manual) and did some reasearch of my own.

Well, at least I called CATS. They kind of had different levels, for different pockets. I never registered either though. Some journalists did register, but you had to go out of the office, couldn't be staff, for that. I saw that as unprofessional and so did the magazine management generally. If you are keeping commercial secrets that you cannot disclose, then you can't have true freedom of expression.

Quote from: Thomas Richter;819284
Right, and correct. I also wrote letters to CBM, they probably went into the same paper waste as yours.

I never wrote to CATS. Never wrote to Commodore. Never had time, I had thousands of other words to write, constantly.

Quote from: Thomas Richter;819284
I believe everyone disliked the CBM "management" in all its glory. Customer relations costs money, and CBM was always short of money. Instead, ask developers to *pay* for your platform. I as a hobby developer did not buy into this type of marketing.

Well, they DID pay on Marketing. They paid Future to have Amiga Format "Get you Started" guides in the boxes. They were a sodding nightmare, in some respects. And I know they paid for that, because that was an out of house commission. But it did ease the journey for noobs. They could start having fun quicker.

Then CBM released the A500+ without even telling us. Gee, thanks guys. Really clever. "Oh, THAT new machine... Yes, we're not doing upgrades for WB2 for earlier Amigas for a couple years yet". In other words, they were going to keep control of the Dev and Release chain, and still not tell anybody how to use the bloody thing properly. Maybe they were too scared to talk at all. I read Dave Hs pieces on the period, and his releases. The prototype AA3000s were going up in smoke and falling apart, and nobody knew why exactly. Lot of conspiracy theories about that one. I think it was just a failed board run on a new production system, but there you go. It might have been intentional sabotage. Who knows?
« Last Edit: January 07, 2017, 06:16:59 PM by Pat the Cat »
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline Pat the Cat

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #202 on: January 07, 2017, 06:33:06 PM »
Quote from: olsen;819264
s.

The dos.library in AmigaOS4 assumes more responsibilities than was the case in previous versions, in which file systems and client software was left to fend for themselves. The old way of doing things required a file system to implement an inane/insane number of operations, accessing crufty data structures according to very underdocumented rules, and this in turn led to stability issues. It was hard to write a robust file system, but poisonously easy to get it subtly wrong with dire consequences, for which it was extremely difficult to figure out what exactly caused them.

So, for example, dos.library now cares about how file change notifications work, how you would change the volume or device list after a medium change. This sounds like the most pedestrian thing to mention, but what goes on under the hood in dos.library V40 (and below) in these areas is a highly complex and error-prone process.

All very true. A classic OS will either work or lock everything up in this respect, and typically non developer systems don't have a hardware "quit" on a program to interrupt the softcrash. Mind you, if everything is talking to each properly, it doesn't happen. But out of control software, unstable software, is an issue with the Classic AmigaOS.

It's an issue with all OS, mind you. :) I hear you are a very nice and helpful Amiga guy who does nice things with networks. You've probably done scads more Amiga, like Thomas. Thank you.
« Last Edit: January 07, 2017, 06:35:31 PM by Pat the Cat »
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline Matt_H

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #203 on: January 07, 2017, 07:07:06 PM »
Quote from: Thomas Richter;819284
CBM had a professional developer program, called CATS. Unfortunately, it costed money to join, and no, I never joined. I just bought the books (RKRMs, AmigaDos manual) and did some reasearch of my own.

...

Customer relations costs money, and CBM was always short of money. Instead, ask developers to *pay* for your platform. I as a hobby developer did not buy into this type of marketing.


Exploring this subject a bit, I'd argue that Commodore's approach to third-party development was much nicer than what Apple and other walled-garden vendors are offering these days.

With Commodore, my take on it is that, essentially, if you could get a functional product you could distribute it as you see fit. If you needed to distribute it with OS components (e.g., 1.3-era products that included Workbench on the program disk) you paid a license. And if you bought into CATS you got phone/email support from a real human, access to various software betas, and a line directly into the development office for the platform. Not being a developer myself I don't have first hand knowledge of this, but from what I've read over the years, registered developers formed mutually beneficial working relationships with their CATS reps and were very happy with the service. And CATS was justifiably proud of the service the provided.

Nowadays, with Apple and co., everything is "free" but the vendor controls your distribution channels. They take a cut of your profits and they can lock you out entirely for some perceived slight against them. I can hardly imagine an iOS developer having a productive conversation with someone inside Apple, let alone Apple taking the development community's concerns seriously or inviting them to suggest product improvements.

With the size and scale of software development in the larger industry today, I don't know whether something like CATS would be logistically possible for a modern vendor, but I think that CATS was a very important option to have available back in the day, and that it's a big part of why the Amiga has survived as long as it has.
 

Offline kolla

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #204 on: January 07, 2017, 07:20:19 PM »
Quote from: Pat the Cat;819281
Rexx = IBM. Arexx = Amiga implementation of Rexx. Therefore, to certain degree, Bill has a relationship with an IBM product, in that he developed an Amiga implementation of an IBM product. He didn't do it blindfolded. :)


A friend of mine wrote Regina, the free implementation of REXX, he too, has no relations to IBM. You see, REXX is a _language_, anyone can implement interpreter for it.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #205 on: January 07, 2017, 07:23:13 PM »
Quote from: olsen;819269
The NFS client software which was part of AS225 was used to connect the Amigas of the developers to the NFS servers which would contain the operating system source code and the material archived/maintained by CATS.


Do you have information on how AS225 from CBM became I-Net225 from Interworks? And can you confirm that it should be able to connect to Internet (albeit IPv4) using SANA-II ethernet device even today? :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline olsenTopic starter

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #206 on: January 08, 2017, 10:12:08 AM »
Quote from: kolla;819292
Do you have information on how AS225 from CBM became I-Net225 from Interworks?

Part of it may have been licensed/acquired/etc. from Commodore. The authors of "I-Net 225" (Michael B. Smith & Jim Cooper) were part of the networking group at Commodore, who developed the original "A225", "Envoy", "AS225", etc. Commodore (of course!) disbanded the group.

It's possible that both "I-Net 225" and "Envoy" became commercial products because Commodore just didn't see any sense in that Internet thing, local networks, etc.

Commodore certainly lacked the in-house resources to make anything out of the code base, so maybe (I'm speculating) the networking group members were permitted to keep their work and commercialize it.

The "ReadMe" file on the "I-Net 225" installation disk acknowledges the origin of parts of the package.

I quote:

Parts of the "I-Net 225" package were based on a TCP/IP package released by
Commodore Business Machines, Inc.  The original Commodore package (AS225)
was

   Copyright © 1990-1993 Commodore Business Machines, Inc.

End of quote.

I was part of the team which created the "Amiga Surfer" package at Amiga Technologies GmbH back in the winter of 1995/1996. It was built around the Amiga Internet application software available at the time, which included "I-Net 225" and, for example, Oliver Wagner's early "Voyager" browser (bless him). We didn't realize how far ahead of its time this project was when it was under development.

My part of the work concerned the dial-up connection to the Internet, which would use the infrastructure IBM had set up for OS/2. You first had to sign up for an IBM account, and then the access information would be written out as configuration files for "I-Net 225" to use. I wrote the program which sets up the modem, the serial device driver, and which performs the IBM account setup.

Once the configuration files were in place, you could go online by launching the "StartInet" program, if I remember correctly.

Quote
And can you confirm that it should be able to connect to Internet (albeit IPv4) using SANA-II ethernet device even today? :)
Yes. I personally used "I-Net 225" to connect my work machine (an Amiga 3000 UX) to a different Amiga 3000 running NetBSD, with both using "Ariadne" Ethernet cards, back in 1997/1998. I did not connect this setup to the Internet because back then this required a dial-up link, rather than the much more convenient DSL gateway router setups we use today. Had a gateway router been available to connect to the Internet back then, changing the default route to use that router would have easily allowed the "I-Net 225" setup to access the Internet.

The version of "I-Net 225" which I knew did not support DHCP (or BOOTP/RARP), which means that you have to edit/create certain configuration files, knowing exactly which information to enter into them. That's a challenge all by itself.

Setting up the network, however, works differently in "I-Net 225" than in "AmiTCP" or "Miami". Configuration files are stored in "S:", and in "ENV:". The documentation explains how all the pieces need to be set up, it's just that it requires a lot of prior knowledge to put it all together.

In so many words: "I-Net 225" is much harder to set up than the Amiga TCP/IP stacks we use today, but it does get the job done, eventually, if you see it through. "I-Net 225" was the only part of the "Amiga Surfer" package which gave us no trouble at all, and that's saying something.

One more thing: the "I-Net 225" API is different from the one used by "AmiTCP" (and "Miami", "Roadshow", etc.). Back in the early days, application software would support both the "AS225R2"/"I-Net 225" API and the "AmiTCP" API, but nowadays it's unlikely that anything but the "AmiTCP" will be supported. So even if you managed to set up "I-Net 225" correctly, you might be restricted to use the shell commands and applications which ship with "I-Net 225".
« Last Edit: January 08, 2017, 10:18:54 AM by olsen »
 

Offline kolla

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #207 on: January 08, 2017, 02:17:52 PM »
@olsen
Thank you for extensive reply, as usual!

My first ethernet card was the I-Card PCMCIA card, also from Interworks (an slightly different incarnation of http://www.bigbookofamigahardware.com/bboah/product.aspx?id=923). We were a handful of students who bought them in a bulk order from IAM for our A1200s at the univ computer club, where we had direct access to Internet, and everyone using public addresses.

We had one minor problem with those cards on the A1200 - the common reset issue. Then we had one major problem with them, they would sometimes lock up the machine and _flood_ the ethernet with packages, essentially DOSing the LAN and making life miserable for everyone on it. We tried all the TCP stacks that were available in hopes of getting those cards to work more reliable, but in the end, after disassembling and debugging the SANA-II driver itself, there was no question what was at fault.

We contacted both IAM and Interworks about our issues, but it never resulted in any improvements. Our work-around was to break up our LAN into smaller segments, and have one just for the Amiga computers, so any berserk I-Card would just affect the other Amiga systems. Later on came the open driver for the NE2000 PCMCIA cards, and we threw the I-Cards in the bin. Life became much easier :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Pat the Cat

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #208 on: January 09, 2017, 12:55:37 AM »
Quote from: kolla;819291
A friend of mine wrote Regina, the free implementation of REXX, he too, has no relations to IBM. You see, REXX is a _language_, anyone can implement interpreter for it.

Sure. And if you do that for the WRONG operating system, and release it for sale, IBM will sue your arse off.

Just because Rexx has public versions, doesn't make all of Rexx open source and free to develop for, on any platform.

Try making and selling a product that uses HPGL. Hewlett Packard will have a few things to say, like "cease and desist or pay us lots of money". You can develop such a product, use it, give it away, no problems. Try selling it, different story. Not a smart thing to do.
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline kolla

Re: Consequences of the AmigaOS 3.1 source code "leak", one year after?
« Reply #209 on: January 09, 2017, 03:15:14 AM »
Quote from: Pat the Cat;819343
Sure. And if you do that for the WRONG operating system, and release it for sale, IBM will sue your arse off.


No, you are wrong.

Quote
Just because Rexx has public versions, doesn't make all of Rexx open source and free to develop for, on any platform.


Rexx is an ANSI standard (X3.274), and Regina is an open source implementation of a Rexx interpreter, since 1992 (and it isn't even the only one):

http://regina-rexx.sourceforge.net
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS