Welcome, Guest. Please login or register.

Author Topic: AmigaOS4.1 Update 5 Released  (Read 9637 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline wawrzon

Re: AmigaOS4.1 Update 5 Released
« on: August 17, 2012, 01:33:21 AM »
id rather guess the update should address bad climate of the last two days after trevor leaked the production costs of x1k become unbearable. well, if certain guys like tommysammy consider even stepping down from the platform, it telling. even if aeon and os4 arent a personal union anymore it would be stupid to let the whole ship sink just as effect of collateral damage. or is there still some netbook in sight?

nevertheless nice that the update sports some desktop backgrounds, even if apparently not from djnick. no rounded corners, btw? what concerns including complete workbench3.1 it must have been helluva of development work involved. i hope the subsequent updates will include also the older workbench versions one by one down to 1.2.

btw, those w3d updates, ist that your work, karlos? i guess the individual program setting infrastructure has been backported from alains wazp3d, right? and the sam460 audio driver, is that an updated version in comparison to what the users have been already supplied with?
 

Offline wawrzon

Re: AmigaOS4.1 Update 5 Released
« Reply #1 on: August 17, 2012, 04:13:35 AM »
@karlos: i see, i suspected it since alain introducetd similar mechanism just of late. dunno which is better, but i fear env variables should be used with caution even though it sounds more amiga-like. im not familiar with how do you create them, but they might duplicate or cross interact once there are more applications and also one tends to forget them when something goes wrong. just thoughts. anyway, nice to hear that one of few things worth mention in this update comes from you.
 

Offline wawrzon

Re: AmigaOS4.1 Update 5 Released
« Reply #2 on: August 17, 2012, 10:25:01 AM »
Quote from: Karlos;703925
The env mechanism is fairly simple. Each driver already has it's own directory within ENV:Warp3D in which it stores the global settings for that driver. I extended this by adding subdirectories, where the name of the subdirectory needs to match the name of the executable the setting is for. You add them on an as-needed basis.



i thought so. perhaps this is sthe most efficient way, only different apps may have same executable names which as long as stored in separate directory. of course im rtather painting the devil on the wall as they say in germany, but we had something similar on aros of late. scalos makes the same dumb generic assignment as wanderer does, and this leads to all sorts inexplicable problems with scalos, as result of a too generic assumption on a directory name. just an example.