Welcome, Guest. Please login or register.

Author Topic: The Os 3.1.4 Thread  (Read 239685 times)

Description:

0 Members and 6 Guests are viewing this topic.

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #479 from previous page: July 03, 2019, 07:15:07 AM »
(double-post)
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 hth313

  • Newbie
  • *
  • Join Date: Aug 2018
  • Posts: 20
  • Country: 00
  • Gender: Male
    • Show only replies by hth313
Re: The Os 3.1.4 Thread
« Reply #480 on: July 03, 2019, 08:22:46 AM »
I had no idea Costel maintained Aminet, interesting to know.

Gitlab is nice too and you can also use it on your own server. I used mentioned Github as I am more used to it.

In any case, this reminds me of the product company I worked at a few years back. We developers made a release and then marketing did their stuff. Writing press releases, talking about sports, taking coffee breaks and god knows all they were up to, not always getting the release out the door asap it felt like. We seldom communicated release dates as it was notoriously hard to predict it, we developers slipped in late corrections, had to re-test and marketing had their rituals. It was better when we could hand out nightly builds to customers in need, as we could skip most procedures.

The "funny" part was that marketing did not even want a lot of releases as they could not handle it. We developers had lots of automation, so we could quite easily crank out new releases, but it was a different story in marketing.
 

Offline number6

Re: The Os 3.1.4 Thread
« Reply #481 on: July 03, 2019, 12:44:52 PM »
Github would be even better, you can have releases there too.  ;D
Of course :)

However, since Costel is one of the guys currently maintaining Aminet (the database, I presume), it seems like the natural choice.
http://wiki.aminet.net/Team_Members

But why not both - Aminet could have its own installation of gitlab, with a CI/CD (continuous integration & delivery - exactly what Hyperion are notoriously bad at) prepped and aimed for Amiga developers.

Keep in mind Costel joined Hyperion in May 2015.
The page you quoted is June 2015.
And Amiganews seems to have enough on their hands without having to spread themselves too thin over at Aminet.
Source

#6
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #482 on: July 03, 2019, 02:24:40 PM »
Well, Aminet could need some love too, its "software architecture" (*snigger*) is ancient by today's standards - both the web front-end and the database backend should be distributed around on multiple instances from different hosting sites.
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
 

Online TribbleSmasher

Re: The Os 3.1.4 Thread
« Reply #483 on: July 06, 2019, 10:00:29 AM »
Is the delay caused by the ongoing need to update FAQs, news etc. on Hyperion-Entertainment.com in the background?
When i browse to their Website i often get a 'different' front page displayed, sometimes with 'downloads' or 'FAQ' tabs open on the left side...
 ???
 

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #484 on: July 06, 2019, 07:21:57 PM »
Hello.
Is there a How-to on using the Rom files with a SS Disk Drive on a A1000?
Amiga 2000 Forever :)
Welcome to the Planar System.
 

Offline trekiej

Re: The Os 3.1.4 Thread
« Reply #485 on: July 07, 2019, 08:24:38 PM »
Thanks, I found a very good source with Epsilon's Blog.
Amiga 2000 Forever :)
Welcome to the Planar System.
 

Offline Senex

  • Sr. Member
  • ****
  • Join Date: Nov 2002
  • Posts: 258
    • Show only replies by Senex
    • http://www.amiga-news.de/standard
Re: The Os 3.1.4 Thread
« Reply #486 on: July 07, 2019, 08:27:55 PM »
@number6

De facto Aminet is a one-man job for many years already, with Christoph doing the actual work while Nicolas is providing the server and Costel running a mirror.
 

Offline 10MARC

Re: The Os 3.1.4 Thread
« Reply #487 on: July 08, 2019, 05:53:58 AM »
 ;)
Well, Aminet could need some love too, its "software architecture" (*snigger*) is ancient by today's standards - both the web front-end and the database backend should be distributed around on multiple instances from different hosting sites.

I suspect it is still "ancient" so it continues to work perfect on real Amiga's using things like iBrowse. It is a delight to use on my Amiga4000! I hope they don't change a thing.
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #488 on: July 08, 2019, 06:10:16 AM »
What I was mentioning, has nothing to do with browser support 😛

What I am talking about, is to make the service more robust, getting rid of downtime on the web frontend and avoid "single points of failures". You may have noticed that every now and then the web frontend is unreachable, or is answering "can not connect to database" - that's what should be fixed, using a more "modern" approach.

The service could also be made more amiga friendly with better native tools - UHCTools is great, and I have myself made an Amiga guide frontend to Aminet. This type of frontends could be helped with better APIs to the official database, for example, instead of implementing database and search engines over again, or go nuts parsing HTML output from a service that cannot be relied upon. My favorite interface used to be ADT, the official Aminet Download Tool (which I also somewhat maintained an Amiga version of), but it should be fully re-implemented, as it fails in all kinds of ways today.
« Last Edit: July 08, 2019, 06:28:19 AM by kolla »
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
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #489 on: July 08, 2019, 11:02:42 AM »
...0! Off we go!

 
The following users thanked this post: Tygre

Offline kamelito

Re: The Os 3.1.4 Thread
« Reply #490 on: July 08, 2019, 03:53:07 PM »
Kudos, care to elaborate about "new intution support"?
Thanks
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #491 on: July 08, 2019, 05:57:00 PM »
Sure. Actually, I was going to write about the changes anyhow, so we can start with intuition if this is most interesting for you.

Actually, there is really not much new here. The V45 added off-screen dragging, and for that modified the check for valid window positions and sizes. Interestingly, this check exists twice. Once in the event handler that processes user mouse movements, and another time when moving the window through the MoveWindow() function. The implementation of the latter had a bug - instead of checking whether the right window border would leave the screen when moving the window left, and then disallowing the move, it checked the left window border. Hence, moving windows by programs already stopped the movement pretty early at the left edge of the screen. All other checks were ok.

Then, there is a tiny "preparation change" in OpenScreen() for rtg graphics. The problem P96 and also CGfx have to solve here is to identify the type of bitmap to allocate. That is, whether OpenScreen asks for a RTG bitmap, a true-color bitmap, a high-color bitmap or a native bitmap. Unfortunately, there were no means to provide this information  to the rtg.library, so what P96 did is that it "went fishing" for register contents, and if they looked fine, it assumed that the call was coming from intuition. And if so, P96 goes "fishing for data" on the stack frame, and there finds the view mode of the screen it was supposed to open, and then could allocate the bitmap correctly.

So V45 intuition contains a big kludge to create a "nicely loooking" stack frame for P96.

Needless to say, it cannot stay this way. Actually, this was already clear around ~2001/2002, so back then (remember, already 17 years ago) I extended the interface for AllocBitMap() in P96. If you set a specific flags combination for AllocBitMap() which would be otherwise invalid, its last argument, which is usually the "friend bitmap", becomes a taglist. And on this taglist intuition places now a tag defining the viewmode.

If this first attempt to allocate a proper bitmap fails - and it does by default as the flag combination is invalid under normal circumstances and the graphics.library implementation refuses it - then the old method is used, so compatibility is retained.

Before you ask, I do not know what CGfx would expect here, or how to update the kludge to make CGfx working - or at least move closer to a working cgfx. I don't have access to its sources like I do (and did back then) for P96.

In the future, this "kludge" in intuition may just go away. It is not needed for P96 anymore, and it does not help for CGfx for reasons unclear to me.
 

Offline Dr_Procton

  • Newbie
  • *
  • Join Date: Feb 2017
  • Posts: 16
    • Show only replies by Dr_Procton
Re: The Os 3.1.4 Thread
« Reply #492 on: July 08, 2019, 06:10:46 PM »
Great work Thomas. You and Olaf can really do the magic..
Everyone should appreciate the genuine effort to give us a better 3.1 system.
For my part: Thank you.
 

Online TribbleSmasher

Re: The Os 3.1.4 Thread
« Reply #493 on: July 08, 2019, 07:41:26 PM »
@ Thomas
As the update requires a proper 3.1.4 installation and the disk itself doesn't boot, why is the installer on that disk needed, and therefore also the compression of the most files?
Did the "old" installer not meet the requirements?
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #494 on: July 08, 2019, 07:55:49 PM »
Did the "old" installer not meet the requirements?
Yes, it did. But the reason for including the installer is that the installer itself also received an update. (-:

Actually, not really much of one, but if I find a bug, I fix it. The problem here was that the installer was a bit uncareful in identifying possible target volumes. Instead of sending an ACTION_DISK_INFO right away - which has additional meanings for some handlers - it tests now upfront with ACTION_DISK_INFO whether the target is a file system in first place.

Actually, the story behind this is that the installer crashed if a certain handler was installed in the system. The embarrasing part is that this was one of my own handlers - well, a beta handler that never made it to the public (Clip-Handler, shows the clipboard contents as a file), so probably no harm done. No matter what, a bug is a bug is a bug, and so the installer received an update.