@kas1e

yes but we have already talked of it: version string solves a lot of trouble. besides native libs are usually natively maintained, while ports from linux world... who knows. what concerns .libs even bernds fork of ixemul has not caused known problems, contrary to what has been anticipated. while there was a whole bunch of problems with different .so versions under owb, iirc, which led to statically linked versions in the end.

Quote:

The same as win32 with supporting of : QT, Gtk, cygwin, .so (as well) also enforced to linux philosophy. Common ,, the more support of different stuff on the OS - the better for users. I want to see also QT, Grk, WxWidgets and all possible ports to our os as well. And its no mean any linux phylosophy. Everyone feel free to make "amiga only" apps. The only problem is : where those programmers who will write firefox from scratch, all those video editors, and so on ?

no, i agree, even though doubling systems with same/similar functionality doubles the amount of problems, its nice to support as many standards as possible. i only fear the enforcement of .so philosophy leads os4 to become a linux derivate with no visible advantages against it, but rather limitations. i think an amiga inspired system must do both, support variety of foreign standards but maintain own philosophy (or call it identity that distinguish it from others), whatever it would be. think of it like in political therms being a patriot but not nationalist, chauvinist or xenophobe.

Last edited by wawa on 01-Jul-2011 at 11:47 AM.
Last edited by wawa on 01-Jul-2011 at 11:45 AM.
Last edited by wawa on 01-Jul-2011 at 11:43 AM.

@thread

Good article. Thanks.

I hope we will get future information how to convert a libraries functions into a fully OOP code using classes in C++ program.

Why .so ? Just change library system into object like format with proper vesioning and subversion.

Amiga always used PURE code. are .so files pure ?

.so are inneficient, they dont load just functions it require and also do they share resources ?

Use MD5 ?

We need an easy to create library/object system.

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@wawa

Quote:

yes but we have already talked of it: version string solves a lot of trouble.

Of course. I think it should be very easy to implement , just by adding small version string at end of file, and small part of code to handle it to the .sobj/elf handler. I think they will do it soon or later (better soon of course).

Quote:

besides native libs are usually natively maintained, while ports from linux world... who knows. what concerns .libs even bernds fork of ixemul has not caused known problems, contrary to what has been anticipated. while there was a whole bunch of problems with different .so versions under owb, iirc, which led to statically linked versions in the end.

Sure, its all was for first getting too "cool" by some programmers. Like some "dream from the heaven is come", and everyone start to use sobjes where is need and no need. But its just problems of programmers, who not think about what and for what they do, and what will have users in end.

In other words, all that fuzz about "how bad to have .so support on aos4", can be rephrased to "why some programmers use sobjs where is not necessary". Its up to programmers to make their progs, ports and so on. If they do something bad, its their bad choice.

I personally from very begining trying to use only static builds for everything, just because i , as user know, how un-interesting to worry about any 3d party libs/sobjs. And if programm still want some libs as necessary (or sobjs), i always put necessary libs to the PROGDIR: libs or to PROGDIR:sobjs (from where programm will get it).

Anyway, version-string are must.

Last edited by kas1e on 01-Jul-2011 at 11:48 AM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@thread

if we can make universal shared objects, then maybe ANY application can use another applications object file.

For example a PAINT package may be able to use another apps objects -

IF its is identified as a PAINT/DRAW object

IF its in correct format to use

IF its correct version

If each Amiga application was created to know about other applications, they could communicate to each other their perpose and features.

The application could then say, yes I also am a paint package - do you want my functions or share them - here is how I like them and this is what I can do ...

send request
jobto PaintProgram
requestFunction Drawbox
width=100 height=100 colour=15
texture 15%
effect 12
applystyle 45
sendrequest anotherpaintprogram export image to PSD format end
end

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@kas1e

lol. best thing is to have .so and not to use it. ;P

@Nibunnoichi
Quote:

"DLL hell" was practically introduced on Amiga by MUI and nobody seemed to complain, so what?

This was the argument a Frieden brother used against MUI in that memorable MUI vs Reaction thread on amigans.net.

And yet, something worse on this matter (no control, no proper versioning, ...) was introduced in OS4. Why the change of heart?

But it's good there's now a warning about the mis-use of these not-so-shared objects.

As said somewhere previously, i would personally only use shared objects as plugins local to an application, at most (like quake does, for instance). And never ever rely on some random 3rd party shared object (especially considering they're often incarnations of libraries that change API every now and then).

[edit] smoothed some edges for the soft minds.

Last edited by Fab on 04-Jul-2011 at 12:50 PM.
Last edited by Fab on 01-Jul-2011 at 12:32 PM.

@wawa

Quote:

i only fear the enforcement of .so philosophy leads os4 to become a linux derivate with no visible advantages against it, but rather limitations.

Fair enough, neither I would want AmigaOS to turn into a Linux-ish system. But I just don't see that happening. Most OS4 programmers keep using shared libraries if they can, or linking against static libs. Shared objects are mainly used to make ports run - rarely in original OS4 software. If AmigaOS was really turning into Linux, the tendency would be different.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@wawa
Quote:

lol. best thing is to have .so and not to use it. ;P

Haha :)) But in general you right, with small differene : best think use .so if you really need it (plugins , heavy-heavy ports (as qt) ) and stuff. Just as Fab say now. I just dunno why everyone start to think that sobjs its some "dream from heaven". Maybe because SDK trying to use by default sobjs, and not .a .. Dunno.

@all
If anyone in interest, i write one more artile about sobjs on aos4 with a bit more real-life look, check this out

Last edited by kas1e on 01-Jul-2011 at 12:55 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

wow! you ARE fast!

@all:
thanks for interesting discussion, not least, since i had to formulate my doubts, now i feel i understand the situation a little better.

@Fab

Quote:

Fab wrote: @Nibunnoichi Quote: "DLL hell" was practically introduced on Amiga by MUI and nobody seemed to complain, so what? This was the argument a Frieden brother used against MUI in that memorable MUI vs Reaction thread on another site.

I don't know to what you're referring to, i've never read it... i'm not saying that .so (or Reaction for that matter) are good and MUI is bad, i'm just noting that it isn't a new-never-seen-before problem yet people are suddenly complaining about only one of its incarnations.
I remember when - during "classic days" - i had to crawl endlessly to find the right version of the right classes, often conflicting between different apps. It's not even true that native things are always better supported: i've sometimes experienced frustration searching MUI classes just to find that they were hosted on a no-more-existent geocities site for example.
I'm just reporting my own experience (i.e. various MUI versions < 4), I don't know how the current situation with MUI is, i'm quite sure it's better controlled and maintained now that it's a fundamental part of your OS; i don't know, you sure are more knowleadgable than me on this topic.

Quote:

But it's good they warn about the mis-use of these not-so-shared objects, at last.

I find that article to be well balanced because it talks about the shortcomings too and it's not "condemning" those who avoid using .so ...i believe it's good to give more possibilities and let the developer choose what he prefers.

_________________
Proud Amigan since 1987
Owner of various Commodore and a SAM440ep\OS4.1FE
See them on http://retro.furinkan.org/

@kas1e

Nice

Last edited by samo79 on 01-Jul-2011 at 02:09 PM.

_________________
BACK FOR THE FUTURE

http://www.betatesting.it/backforthefuture

Sam440ep Flex 800 Mhz 1 GB Ram + AmigaOS 4.1 Update 6
AmigaOne XE G3 800 Mhz - 640 MB Ram - Radeon 9200 SE + AmigaOS 4.1 Update 6

@wawa
Quote:

lol. best thing is to have .so and not to use it. ;P

Exactly. :) Just like on MorphOS. :P Anyway, the mistake IMO was not to introduce .so-s in general, to let an application load shared objects, which is good, but to make the whole thing appear as a system-wide solution, and encourage people to build apps on it.

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

@thread

Update 3 Status Report

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

At the end of new post:

Quote:

I'm a big fan of frequent releases so I tend to lean towards releasing early and more often.

Right ! 1 update in half of year = right way. Basically i start to like how thinks changes in hyperion, all those blogs, forums are pretty nice..

Through, nothing about USB2.0 and new shell. That a bit scare me. Can't believe that update3 will not have new shell and usb2 .. (which all already done as i know).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

lets see...

@number6

yes!! i especially am looking forward to the SAM-specific performance enhancements. also enjoy the notion of 'early and often.'

a big thank you to steven and the OS4 developer team. here's to update 3 and a successful combined release of AmigaOS 4.2 and the X1000.



-- eliyahu

_________________
"Physical reality is consistent with universal laws. When the laws do not operate, there is no reality. All of this is unreal."

@eliyahu

Quote:

also enjoy the notion of 'early and often.

i dont think we can say, we miss the notion of "early" as much as "often" these days.

Last edited by wawa on 02-Jul-2011 at 12:44 AM.

@number6

Wonder if this will require a fresh install or not.

Quote:

number6 wrote: @thread Update 3 Status Report #6

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

A fresh install is always safer.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@tonyw

true.

A tool to backup and restore non OS files and fonts in Sys: would be nice though.

Quote:

tonyw wrote: @Spectre660 A fresh install is always safer.

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card