How is OS4 ?

[Karlos]

It's easy to create normal amiga shared libraries with per caller data. bsdsocket.library is a common example, every AmigaOS 3.x installation with a networking installed has such library installed. The added bonus is that you don't need to load the code in memory for every caller, like you have to with AmigaOS 4 SObjects.

Not every shared library can be implemented using old style shared libraries. Consider libstdc++.so, for example.

[Karlos]

What's a "woss"? :p

[Karlos]

If another moderator feels this thread should be moderated, I would support it. So far I don't see enough to moderate it, without pissing everyone off.

I sincerely thought the days of red v blue penis measuring on the site were a thing of the past, gone with those that went away and created their own niche forums.

[Karlos]

OS4 is merely a sub-standard substitute for MorphOS (that was here long before OS4 development was even started), with quite poor Amiga compatibility in comparison, so it always puzzles me how anyone *really interested in Amiga* would even consider OS4. The only reason I can think of is some strange brand following (which is the only thing you are interested in as shown by your posts here), which is kind of sad, especially considering it was kind of "robbed" from the IP-owner under miserable circumstances.

My god, this post is no different in tone than the worst BAF posts of old :roflmao:

The most reasonable "pro MorphOS" poster in this thread by far has been Piru, who thankfully, as one of the MorphOS core developers speaks with authority when discussing MorphOS. Anybody that actually wants to know more about it should really talk to him.

Unlike the few "cheerleaders" whose only comments about MorphOS are how it's "teh besterest amigaos evar" and "OS4 is teh suxx0r wannabe and worserer in every way!"

Really guys, I honestly thought we'd grown up in the last few years. You're a disappointment.

[Karlos]

@ xeron, karlos, etc

Hehe, "Foul! Foul! Can't some referee do something? These kind of discussions shouldn't be allowed! Take away those arguments! Do something!"...

Oh, do grow up. How old are you? This is not about MorphOS etc, it's about your behaviour on this thread.

Try to remember who you are talking to. We are all enthusiasts. Who actually gives a rats arse if one person prefers something over another? Being enthusiastic about something does not mean you have to trash everything else like some damned schoolkid.

We all understand that you find MorphOS better than OS4. Most of us also understand that MorphOS is a mature and well-realized evolution of AmigaOS. Who do you see disputing that? That's right, nobody. At least nobody that isn't just reacting directly you your continuous OS4 bashing.

The original poster was asking a question specifically about OS4. He's already asked about MorphOS previously. You posted on that thread too. Where were all the BAF trolls in that thread? Nowhere, because they've either all left or grown up. I'm not for people storming off of forums in a fit, but you might just try the latter.

Even when the OP thanked people for their responses but made it clear that he just wanted some info from OS4 users about what was "fun and cool" about it, you simply couldn't respect his wishes.

And now that you are being called out, you are crying the old "you just can't take the fact that MorphOS is better! boo! ban the discussion" persecution line. You really are no different to the BAF's of old.

You need to learn that some people, for whatever reason, prefer OS4 (as well as OS3.x, AROS etc) and not get an apoplectic fit over the fact that some do prefer OS4 and resorting to insulting them as irrational name followers and the like. After all, if someone decides to blow a huge wad on an X1000, it isn't your money they are spending, is it?

[Karlos]

With this track record I am not very afraid of hardware failures.

It really depends on the components that were used. It was alleged that in the late 90's, an employee of Rubycon (The Japanese component manufacturer, nothing to do with the exotic soft drinks company ) left and took the formulation of their capacitor electrolyte with him.

He subsequently sold the formulation to various Chinese companies but was unaware of the fact that the formulation he had was missing a few essential components that weren't documented (presumably to mitigate espionage) anywhere he had access to. Among these were anti corrosion compounds and the like. The result is that the electrolyte is not stable long term and results in internal corrosion and the build up of gases, that eventually pop the casing and leak.

Consequently, said Chinese firms started shipping cheap electrolytic capacitors that were bought up by electronics companies across the globe.

I've seen quite a few such dead caps in all kinds of hardware released from about 1998 onwards.

-edit-

As some of those bad caps were also Rubycon, it's possible the allegations above are not entirely correct and that that particular formulation was complete but bad regardless. It's not easy to say with certainty.

[Karlos]

It's worth noting that some eMacs were among the machines affected by the "capacitor plague"

http://macosx.com/topics/emac-capacitors.html

[Karlos]

If you feel brave you could of course attempt to repair it yourself, the capacitors are cheap enough (do get some decent quality replacements) and if you have the soldering skills it might just work

Sure, but I would advise any normal end user to get someone with the requisite experience to do it for them.

Replacing SMD electrolytic capacitors in particular can be tricky. You either need the right tools or a pair of soldering irons and a steady hand. Even then, it's easy to lift the pads and traces off the board.

[Karlos]

@Crumb

Even one of the Friedens used Peg2 as main machine one year before OS4.1 Peg2 release because it was better hardware than MAI/ACube.

:lol:

I'm sorry, but the above reasoning is just very silly. Better hardware or not, I'm pretty sure it wasn't the reason he had a Pegasos 2.

Call me old-fashioned, but if I was developing software for some target hardware, I'd pretty much want to have that hardware available to test it on during development.

[Karlos]

Of course.

Found this link with some images, looks doable.

I know old macs may be cheap second-hand but do you really want to have practise runs?

[Karlos]

Even in the old days when I actually did some OS4 for classic beta-testing, I can't say it was sluggish, even running on AGA, let alone RTG: See here.

[Karlos]

If they haven't failed by now, they are probably fine for another 15-20 years.

That kind of depends on what role a given cap has and how the machine has been used overall. Caps that just decouple audio aren't subject to the same stresses as those that are used in power stepping/regulation.

If the previous owner hasn't used the machine since he got his juiced up Xeon based Mac, the chances are suspect caps haven't yet reached failure. The second hand owner, if making this their main machine might end up having to bite on that one.

[Karlos]

That was around one year before it was decided if OS4 would see the light on Peg2.

What, and you suppose absolutely no experimentation into the feasibility of a version for Peg2 was done before it was announced? Come on.

OS4 default settings are unfortunately too slow for AGA... solid window dragging is pathethic on AGA and should have been disabled as default.

Using 256 colour highres/laced/scandoubled modes on AGA under any supported version of AmigaOS is painfully slow. period. You can't actually blame OS4 for that. It takes all of 2 seconds to disable solid window sizing/dragging. After which it's actually OK.

Or at least as OK as AGA is on 3.x.

[Karlos]

@Framiga

The AGA demo was in response to my claim that OS4 classic wasn't that bad even on AGA. On my 240MHz BPPC with a sensible 16-colour PAL interlace (externally FF'd) display, it wasn't. At least no worse than the same display on OS3.x.

[Karlos]

And regarding timberwolf, there's nothing to swallow, really. An half-assed port of something that should only have required one month to port has nothing really appealing.

If that really were the case, how come nobody else has actually bothered in all the years the bounty was up?

OWB (even for OS4) probably required much more work, since the GUI had to be written from scratch, in addition to the usual layers like memory/thread/file/events/network/graphics... In timberwolf case, the whole UI is based on the graphics layer, which means it's just much less work to port.

It seems that the GUI is the most problematic part of the current alpha version. At present, I'm inclined to believe that WebKit might be easier to manage since it's no doubt a lot cleaner code wise than gecko is.

[Karlos]

Why not ? C++ function names are mangled and after that can be handled as C functions are handled now in amiga shared library.

There's slightly more to C++ linkage than name mangling...

How, using nothing but a jsr style jump table library vector do you propose to enforce exception specifiers, for example? If a virtual function in your application throws an exception from within a library call (perfectly possible under the current libstdc++), is the amigaos shared library implementation expected to unwind the stack and properly invoke destructors for everything?

I'm not saying it's impossible to achieve but in the end, your library would likely end up deviating from amigaos shared library norms in order to offer the required features expected of the C++ standard library. And if you are going to deviate from the norm, then why bother? Static linking has no such problem. And really, that's all .so files do, except actual linking is deferred until runtime.

It's true that no compiler or other tool support exist ATM to do it.

This answers your own question and it's unlikely to change as long as gcc remains the compiler of choice.

Virtual methods are handled by a vtable and by the class constructor(s). The constructor with mangled name can be part of the shared library.

greets,
Staf.

There's more than just the vtables and even the stuff above to worry about. Templating and RTTI present other interesting problems as does thread concurrency. The latter isn't a problem for amiga libraries but remember the STL was not designed with concurrency in mind. GCC has gotten around this on platforms like linux by using a posix thread model in the compiler. In the end, you wouldn't just be creating the shared library, you'd have to reimplement the entire entire STL it provides as well.

So, for your suggestion to work, you need to first build a new compiler and then implement your own complete runtime and STL for it. It isn't exactly a cakewalk. Who is going to bother?

On the other hand, you can take an already tried and tested C++ standard library and statically link it to your application. Which is fine. However, with .so files you can defer that until runtime.