I can only repeat that the way to go would be to provide proper alloc/free function pairs in your (it is yours?) library code (maybe even multiple pairs, if needed. Or with flags for different situations, etc.) and keep the implementation details private to the library

- OR -

leave full control to the caller. So the caller would then be responsible for allocating appropriate memory and freeing it again.


I'd personally always go for the first/internal approach if anyway possible. This way you have full control over the memory you are going to use elsewhere in your code and don't have to rely on the assumption/hope developers will do the right thing.

Only if there really is no choice, I'd leave the memory handling up to the caller, but then also in full, without interfering with it in the straight assumption I will get the correct memory denying any responsibility.

This really is a black/white thing without any greys IMHO.

@GregorQuote:

Unfortunately, the "subvariants" are the problem. It is not said, that two 8168H chips actually have the same MAC or PHY version. They should, but in reality they don't have to. I had this issue with 8139 and 8169 already. The documentation gives many information, but i heavily depends on the version of the documentation you've got.

Basically, for 8168 I'd have to hunt for the latest documentation version I could get. Then start implementing a new driver from scratch. The generic framework is of course the same for all my network devices, but the chip specific parts obviously differ. Especially the initialisation code is the critical part here as that is, where the driver has to be very exact on which bit in which register it sets or unsets for each variant of a chip, with each combination of MAC and PHY version. Most likely it would take long until another new, unsupported variant surfaces in the wild :/

Quote:

No, see above. It is pure luck that there is an 8168 variant, which works with rtl8169.device. Supporting other 8168 variants would just create even more mess in the 8169 driver. A separate driver would the only sensible way to go, with all its ups and downs.

Quote:

I understand your issue, but it seems to me that the first one to ask for a fix would be the responsible dev for the Linux X5000 network driver. Granted, that might be difficult, but it really is rather a Linux issue than an AmigaOS issue. But even if not, there is still the thing with halfways economical use of my rare spare time, which doesn't really fit for writing a complete new network driver, which is not really of use for the majority of users, but basically solves only a very rare problem (you are the only one I know of) ... and that problem isn't even caused by AmigaOS nor my drivers, which work just fine with the chipsets they were designed for.

May if I'd win the lottery or if someone would pay me the regular rate, so I could spend time on such a driver without sacrificing part of my income, but each is rather unlikely.


If you can't find a chipset, supported properly by all three systems, the suggestion of nbache is probably the way to go for you. Use two network cables, one on the internal NIC for AmigaOS and MOS and the other one for Linux.

Quote:


This is the real issue here.

This powerpacker.library API is broken by design if it really relies on the caller to free memory with a certain system function, which was allocated by the library's code and not actually by the caller himself. So the only real fix to this issue would be to deprecate the function in powerpacker.library containing the implicit memory allocation and create a new pair of libraries to create and free the corresponding data structures. Old software would continue to work using the old function and their own FreeMem(), new software would use the new function pair leaving the details of memory allocation fully up to the library's implementation.

Quote:

No, you MUST NEVER intermix different function pairs, just because they seem to do similar things. AllocMem/FreeMem is NOT interchangeable with AllocVec/FreeVec as they simply are different function pairs. Whatever they might do internally must not be of your concern as it is continuously subject to change without warning and would rather sooner than later break your software, if it wouldn't break it right from the start.

This is exactly the kind of issue I (and obviously also the MOS devs) faced when developing network drivers for Realtek chipsets: there are a zillion different versions of each chip. Each with more or less subtle changes and incompatibilities. Setting only a single bit of one of the registers different may cause one chip of the "same" family work and another one fail.

In this case, it is even worse, because you are trying to use a driver for one family (8169) with chips from a different family (8168 - the 8161 is a variant of it).

There are actually a few variants of 8168 chips (those are native PCIe chips), which work similar enough to an 8169 (PCI) variant and hence work with rtl8169.device. The vast majority doesn't however.

The only way to support most (not all) variants of 8168 would be to write a dedicated driver for 8168. As far as I can see from a very quick look, there are at least 9 (!) different configuration paths to follow, depending on the exact variant. So it is not exactly a 5 minute job, if I even could be motivated to take the job .. I don't really see the benefit of it beyond rare special cases. Most of the time the internal NIC is enough or a supported PCI solution can be used.


So, I would actually suggest to get a plain 8169 board for good old PCI if you aren't able to use the internal NIC.

Solved by Orgin, thanks!

Hey!

I recently uploaded a new version of AutoDocViewer, which still hangs in the upload queue. I just wonder, if my upload/replace password was wrong and that is why it is still pending, because I didn't get any confirmation mail of any sort about a wrong password ..

Sure, any ordinary 9 pin null-modem cable works. As of the USB adaptor, I'm using a similar one on my Mac.

@kas1e

Ok, what you then probably want is to install http://os4depot.net/?function=showfil ... nt/library/misc/libdl.lha in your SDK.

libdl is for using functions from shared object libraries. libdl itself is a shared object, which is why you can't find it in the SDK. It resides in SYS:SObjs/

To make use of it, you have to use the linker option -use-dynld, then you can pass -ldl and use its functions.

You have to remove the bitmap from Prefs/GUI->Styles. If that is set, it overrides the rest. Afterwards, you can change the window border colours as you wish.

Quote:

No, as long as the attribute has applicability OM_SET. As it is implementation specific, you have to check the corresponding AutoDoc for each case.

Quote:

I was about to write I didn't see this before, but now I see your mistake. You are removing the whole Gadget list from the window, which is NOT what you want. Your gadgets[GID_MAIN] is actually a layout_gc, which you gave to window_cl by using WINDOW_ParentLayout tag.

What you want to do instead, is to tell window_cl to remove the layout and later add the layout again. Something like this (somewhat Pseudocode):

Ah, did you buy via the "AMIStore" application maybe? Because that is ran by A-EON ... the original developers of AmiPhoto ran a webstore called "www.amiga-store.net", which is why I might have got confused.

The original developers (Simon/Alinea/www.amiga-store.net) are very reliable and react to orders (and complaints) almost immediately. He didn't know about any issue, so very likely you were talking about "AMIStore" actually, hence you have to wait for Matthew Leaman/A-EON/AmigaKit to react to your complaint.

The guys from Alinea are usually very reliable. I take it, you did already check your spam for the registration mail?

I'll notify Simon about your issue (he doesn't usually read English forums), I'm sure, he will help you asap.

@ joerg

As I never saw your contract, I obviously can't judge your assertions. Why didn't you just get in touch with Tim or myself while we were in charge to try to clarify and maybe even remedy the situation? Instead you removed code from the SVN way beyond what you might have rights to without any notice and went silent for the last 7 or so years .. as I said, we tried to remedy every dispute as much as we could, but this doesn't work one way and when I asked you specifically about PartitionWizard, you clearly told me you have no interest in clarifying the situation and didn't even mention other things. So you had all means to get this resolved together with us. You've opted against it and instead complain now after years again in forums.

Looking at the CDFS log shows that you contributed lots of work, but contrary to what you say, there were - besides the original 3.1 CDFS base code of course - quite some additions and changes done by others .. Olaf, Fredrick, Sebastian, even myself and others. Thats why I said, it is not simply a matter of black and white and you oversimplify things if you make it look like that.

Quote:

Interesting... when I suggested Final Edition to the principal shareholder and "managing partner" back then (who is in charge now again), I was not told about any license issues. I was only a developer back then and license issues of Hyperions product were not part of my job description anyway, so I did Final Edition. Afterwards, when I got basically forced to become a Hyperion director to prevent it from going bankrupt, the previous "managing partner" was still the principal shareholder and legal counsel, who got consulted about everything. Nothing even remotely contractual related was done by Tim or me without the clear OK from the legal counsel. So obviously, there exists totally different understandings of the contracts.

@Chris
Correct and I notified Rigo about it (as some others maybe as well), but the thread starter had a typo in his URL and that was actually what I reacted to initially before checking the actual reachability.

Yes, working fine again, thanks :)

Hi Jörg,

first, nice to see you again after all those years. Hope you are fine!

We agree on many things you are saying here and on others we don't. I do not want to start defending what Hyperion with its principal shareholder did and not did. That would be ridiculous. But some points you raise are just overly simplified and thus misleading.

For example, there is the concept of a "legal successor". Only by changing the company form does not automatically nullify existing contracts, rights and duties. In my limited legal understanding, this is the same for Belgium as it is e.g. in Germany. According to your statements, you seem to believe this is not the case and everything became void as soon as Hyperion changed its company form. Can you share information this is based on?

Also, as you say yourself, for many components of the OS the legal situation is not easy at all as many people contributed to them over the years. CDFS is one example where you contributed big chunks, but where others contributed as well and all that on a basis, which Hyperion clearly had the rights for, which makes it even more complicated. And you are right, proper contracts with the developers, which stipulate proper licenses and compensations if desired would have made everybody's life so much easier and prevented so much nonsense, irritation, disputes and bad blood in the first place. But this built up since Hyperion started AmigaOS development in 2001.

After Tim and myself took over management in early 2015, we worked very hard on putting AmigaOS development on stronger feet also by ironing out as many legal and contractual issues as possible. We payed out more money to developers than was done the 15 years before (mainly from the income of the "illegal AmigaOS 4.1 FE compilation" as you call it) even if it was not nearly enough, we set up and signed new contracts (like a default developer agreement to avoid exactly said legal issues with contributions) and we also tried to settle the disputes we've inherited from the 15 years before. Unfortunately, some developers just went ahead and sold their stuff to other parties, before we've got a chance to intervene and for others there was already too much bad blood, that serious discussion was next to impossible as long as certain people were still be involved in Hyperion in some form or another. For example, I remember also asking you how much would be needed to get everything resolved, but your answer was clear in that money would not solve it. It was tried hard to minimise the impact of this "other reason", but in the end, after doing a second, non-paid full-time job at Hyperion for about 3 years, Tim and myself were beat by tricks a normal human being would never think of and had to give back control again, disillusioned, frustrated and also just tired of it. Was it our own fault? Up to some extend, definitely. We listened to wrong advice and idiotically, we could not nearly imagine, what people are willing to do way beyond all common sense to reach their own purely selfish agenda.

You propose everybody to go to A-EON? Just let me say that A-EON also had and has its parts in the whole story and the mileage with what and how they treated their "partners" - be it individuals or companies - may and does quite vary. Its just not as widely known/accepted as people like black/white more than several greys. Your experience was obviously perfect, others' has not have been so perfect.


Again, I'm not trying to defend Hyperion nor excuse everything Tim and myself did. We also made mistakes we regret, but contrary to others we can wholeheartedly tell you (and prove with our doings) our mission always has been solely the well of AmigaOS and its developers. What I'm trying to say with this long post is simply that things just are not as black and white as you (and others) often make them look like. There are wide parts of consensus between you an me, but details do matter a lot in this whole drama.

Sure, may well be the case .. IF you can get an X5000 at all that is. I heard from a couple of people trying since months to no avail with or without AmigaOS.

If OS4 for X5000 will be sold separately or not is the decision of Hyperion management, which I left quite some time ago as you know.

@walkero
I noticed my signature, albeit configured since ever, does not show up on new posts of mine. As I did not change anything in my settings, maybe this is a bug in the new site software?

@kas1e

The point is, that OS4 for X5000 never was and as of today still not is available separately from anywhere AFAIK ... at least it was that way back when I was still in management. It was always part of a X5000 purchase. As A-EON/ML stated to amiga-news, they don't have any licenses anymore, so even if they would sell new X5000, the customer would be on his own without AmigaOS. The only options left would be Linux or MorphOS.

So, if dealers are selling X5000 including an AmigaOS 4 license, then those machines very likely stem from the time the OEM contract between A-EON and Hyperion was still in effect ... "new old stock" so to speak, which isn't bad at all. I appreciate every way to get hardware and AmigaOS 4 to the people.


@Antique

Three! What on earth are you doing with three of them? :D