Something I've long wondered about is why SObjs were added to AmigaOS4, when we already have a good (dynamic) library system. Particularly when SObjs introduce "version hell", while our library system easily handles new versions. I don't know too much about the technical side of SObjs, but I can think of some possibilities:
1. Function calls for SObjs are faster than dynamic libraries. But maybe only slightly faster (similar to procedure call vs method call), and not really worth it most of the time?
2. Might make usage of GPLed code easier, without worrying about the GPL forcing the whole OS to be made open source? (This however requires that SObjs calls are significantly faster.)
3. Make it easier to port Linux/Windows libraries?
Something I've long wondered about is why SObjs were added to AmigaOS4
Simple answer: lazyness. Programmers are lazy like hell. SObjects exist in Linux. Adding them to AmigaOS allows to reuse them without difficult adaption.
thomas wrote: Adding them to AmigaOS allows to reuse them without difficult adaption.
I'd rather say they introduce a heck lot more difficulty to the already conceptually challanged OS. Or to put it bluntly, it creates a much unneeded mess.
On Linux it works because one can recompile just about anything anyways, and programs that are not opensource _do_ cause pain - just look at latest GoogleEarth for Linux that suffers from a silly symbol namespace crash with expat library (googleearth comes with its own) that Google for some weird reason seems unable to fix (at least it wasn't fixed just a few weeks ago, after having been reported and identified way back in May or so).
If OS4 will be anything like OS3, recompiling all programs that link against old versions of libraries will not be an option, sadly. So hence it will become very messy over time. The sooner OS4 gets rid of SObjs, the better.
Haven't you read this article so far? I think it explains it quite well. If we hadn't have shared object libraries, it would be pretty hard to port necessary and worthwhile linux libraries to AmigaOS.
If we hadn't have shared object libraries, it would be pretty hard to port necessary and worthwhile linux libraries to AmigaOS.
Uh ? The effort to port statically linked libraries is exactly the same as for shared objects. The difference is that with the latter you will end up with a directory full of different versions of the same library that are incompatible with one another, and not even shared in memory in the case of OS4.
At least with shared objects if a program only works with a specific version of the library you can simply put that version inside the program directory and it will use it while all other programs will use the version you have in SOBJS:. This solution is OTOH not possible with shared libraries because of the way that they are shared in the computer's memory.
Only system that would be completely immune to "dll hell" type problems would be statically linking everything into every executable, a solution which isn't without it's problems either.
Helping me to keep http://sobjs.os4depot.net updated might help alleviate some of the problems of using sobsj in the os4 environment.
Also it might be useful to move all sobjs into their own category on the main os4depot site and allow them to have version numbers in their filenames so that users can download specific versions.
MickJT recently joined the os4depot team to keep his stuff on teh sobjs sub site updated, but there's need for more people helping to keep the rest updated. It would also be easy to add information and guides on the site if anyone wants to write something up (like that you can have app specific sobjs in progdir: )
Thanks to shared objects the next released version of diskimage.device will have both FLAC and WavPack support. If the only possibility to use these libraries was to directly link them into the CUE plugin then I wouldn't have bothered but thanks to the shared objects support in AmigaOS I can access them through DLOpen, DLSym and DLClose functions in elf.library.
Something I've long wondered about is why SObjs were added to AmigaOS4
I think that's quite easy: to allow/simplify/speed up the porting of crucial software technology from Linux. The idea was good and logical but we're beginning to experience the fact that the Linux environment is, simply, different.
Thanks to shared objects the next released version of diskimage.device will have both FLAC and WavPack support.
Please elaborate how FLAC and WavPack are in any way related to what diskimage.device is supposed to do - are you setting a new standard for bloatware?
Just do a google search on "cue flac" f.e.. In addition to .bin (binary) the .cue format allows storing audio tracks in several other formats like wav, aiff, mp3, flac and wavpack. The diskimage.device CUE plugin supports all of these formats. WAV and AIFF support is builtin, the rest are handled through external libraries if they are available. If a needed library can't be opened when it's needed then an error message is displayed. The current size of the CUE plugin is about 36 kb. I don't really see how you can call that bloat...
Uh ? The effort to port statically linked libraries is exactly the same as for shared objects. The difference is that with the latter you will end up with a directory full of different versions of the same library that are incompatible with one another, and not even shared in memory in the case of OS4.
That's not true. First because you can always put your .so in your progdir: if you have used different library version. But even with classic libraries you could have problems if you replace a wrong .library with another one. There is no differences between .so and .library in code usage except the shared code of the .library in memory but in the day usage if a developer replace your bzip.library with another one bugged you will have the same problem of libbz2.so replaced by another one
Please, please, please more native amiga libraries and less linux Sobjs
They are not linux Sobjs, they are amiga Sobjs. and as i said there is not great difference between .library and .so (except that amiga library can be loaded one time and shared between programs and this means less memory) but nothing else
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
