With the original clib2, it is possible for user code to check if it is thread safe using the __THREAD_SAFE preprocessor symbol. This is/was set only when using -mcrt=clib2-ts (causes libs to be used from SDK:clib2/lib.threadsafe) and not -mcrt=clib2. Does this check still work with this replacement clib2, which I understand is thread safe by default? If not, how can it be detected at compile-time?

The context to this question is that I am doing some work on adding proper OS4 support to libcurl and it really needs to detect whether clib2 is thread safe or not, in order to allow the threaded resolver to be enabled (which needs a thread safe malloc/calloc/free).

@devils_advisor

It is a solution, but not the best solution . What do you have the "Max. number of connections" set to in the network preferences? This also affects the number of sockets cached for persistent connections.

You can use "shownetstatus tcpsockets" in a shell to show the currently allocated sockets. It smells like a bug in the network card driver to me, which could be falling over if there are too many connections. It could be a bug in IBrowse, but I don't see it on my A1200 with PCMCIA network card + Miami, or on my A1XE with onboard networking.

@devils_advisor

Under the network settings, in IBrowse, try switching "Persistent connections" off. That would be the one thing I would think could cause a problem, although if it does, it is possibly a bug in the network driver.

It works fine on my A1XE. I saw a similar report of this elsewhere - will try to find it, to remember what the resolution was .

@ktadd

The one that will get used for reading is defined by which BMP descriptor you have installed in DEVS:Datatypes. "AddDatatypes LIST" will show you which are active.

It is impossible to support stdio OpenSSL functions in AmiSSL. However, try using the BIO versions of the functions instead, which will work fine. See test/https.c for an example of how to use ERR_print_errors().

Don't link with -lssl and -lcrypto. Just use -lamisslauto or -lamisslauto_newlib if you are not manually opening AmiSSL.

The stack/safestack stuff has always been a bit of headache - fortunately, this has been reworked a lot for OpenSSL 3.0 (now uses macros instead of inline functions). Did you get it working? You shouldn't need to create stubs for those functions - just make sure to compile with -D__USE_INLINE__ and it should be ok.

@tomsoniq

Datatype classes do not need to specifically support DTST_MEMORY. Datatypes.library itself handles DTST_MEMORY, creating a pseudo file handler, so that classes still see a normal file handle. As far as classes are concerned, they're reading from a file, yet in the case of DTST_MEMORY, datatypes.library feeds the file handle with the memory buffer instead.

@broadblues

Good to hear much work has gone into improving the AK datatypes. The AK name is something of a double-edged sword really. In one sense, those datatypes were popular and well known in the 1990s (helped because there were no other alternatives for some years), but I'm sure people will remember the many updates that fixed some bug, only to break something else entirely. The basic coding bugs that you mention are precisely why some classed the old AK datatypes as unstable. They were never really mature in that sense. So, I guess it's 50/50 whether it would have been wiser to drop the name and rebrand them, particularly as it sounds like the new ones bear little resemblance to the original versions, in a good way.

I agree it was never wise to version chase libpng, libtiff, libjpeg, etc, as it's hard to pick a stable version sometimes, as those come with their own bugs too. However, in the last couple of years, development of libjpeg, libpng and zlib has stagnated. Particularly with libpng, some of those more recently involved have been making pointless changes, such as changing types, formatting comments, etc, which do not affect functionality at all.

In contrast to the old AK datatypes, I'd argue that the WarpDTs are far more muture, having of course been in constant development and refinement over the last 20+ years and are no less modern than the new AK datatypes. Not saying they are perfect, but I hope closer to perfection than they were at the beginning .

The CA.pl helper script would possibly have been useful here too. AmiSSL 4.9 will come with that too, as well as openssl.cnf.

Just discovered I had put a vanilla copy of openssl.cnf in AmiSSL: on my install 14 months ago and completely forgotten about it since then! :)

Since that didn't interfere with IBrowse, or seemingly anything else, since then, I'll add a modified openssl.cnf to the AmiSSL installation.

@broadblues

Ah, ok - perhaps I should include it with the next release then. Obviously, only if it doesn't already exist. Just need to check if it interferes with Amiga apps.

What was the OpenSSL command line that you used to create the cert and key?

Just to clear a few things up:

1. WarpDTPrefs comes in OS3, OS4 and MorphOS native versions, albeit only since May 2020 (it was 68K only before then).

2. The WarpDTs have never supported DTM_WRITE - I've always felt the datatype system doesn't lend itself well to saving, partly due to lack of control over encoding options.

3. The OS4 datatypes were originally written by me, but I don't tend to get involved with them much anymore (only to fix bugs that were my fault), for various reasons. DTM_WRITE support was added more recently by another developer. I got a bit sick of other developers slowing my code down and breaking stuff.

4. The stability issues mentioned probably are in reference to the ancient original AK datatypes, which were indeed a bit flakey (especially akTIFF), even if they were "mature". I would hope the new ones are more stable and complete than those.

If you care about DTM_WRITE, either stick with the datatypes supplied with OS4 or try the AK datatypes. Otherwise, you are probably better off with the WarpDTs if you have already purchased them - they outperform the OS4 supplied datatypes for reading images.

@broadblues

No, we've never included one - users are free to create their own, but generally Amiga applications provide their own configuration, so it perhaps is not necessary in most cases.

There is a sample at https://github.com/jens-maus/amissl/bl ... /openssl/apps/openssl.cnf if it is any use. To be honest though, I've never really tried messing with those config files.

@JosDuchIt

Actually, I posted that message last week - not 2 years ago .

The SSL/TLS fix for IBrowse 2.4 is still relevant because it is limited to using AmiSSL v3.

@zzd10h

Yes, please add to the issue tracker. Jens went ahead and released AmiSSL before I had really finished writing script that builds the release archives. The included libamisslauto.a is for apps compiled to use clib2, and not newlib (the old SDK contained two versions). I did raise my concern, but was also unsure how many developers actually used it.

Anyway, as you've found, the quick fix is to use the one from the old SDK - nothing substantial, if anything, has changed in that code. Hopefully, we can get this fixed for the next release.

edit: I've just now pushed in changes to github that will resolve this for the next release.

http://www.digitalspy.com/gaming/ps4/ ... -amiga-original-for-free/ - Emulated Amiga original included with PS4 game.

@Deniil

I've been trawling all my old e-mails and trying follow all the discussions on the memcpy/CopyMem subject. The most recent being a couple of years ago, but I did find this:

newlib.library 53.19 (7.1.2012) <ssolie>

- Changed memcpy()/memset()/bzero() to use
IExec->CopyMem()/IUtility->SetMem()/IUtility->ClearMem().

The idea is to let the kernel handle any optimizations and
avoid duplicating the code for these functions.

It doesn't look like anything has changed with that since. I am 99% sure the kernel has no AltiVec optimisations in place at all for these functions, which means neither does newlib. It may also be the case that the X1000/PA6T has less well optimised CopyMem() compared to other machines. So, using an AltiVec memcpy should well be worth it on a G4 and PA6T.

@broadblues

Are IExec->CopyMem and INewlib->memcpy definitely AltiVec optimised? I'm not so sure, although I do remember it was being toyed with at one stage. Certainly they are well optimised in other ways though.

@Fab

I'm not sure if it is relevant or not as far as Gnash goes, but although NPAPI plugins for IBrowse revolve around a normal AmigaOS shared library implementation, it is pretty much guaranteed that the library will only be opened once and calls to the plugin will come via a single context/task. So, you don't have to worry too much about fully re-entrant code as you normally would have to with a shared library. Of course, if the flash code relies on globals then this could be problematic if it is not able to work with multiple streams concurrently.

Quote:I still don't understand the apparent reluctance of making a Gnash NPAPI plugin for IBrowse 2.4 - we've had this browser for years. All the stuff about GPL doesn't make a lot of sense to me either - if that argument is to be believed, OS4 must be made GPL because what's to stop people installing free libraries, datatypes, etc, that contain GPL'd code?

I eventually had to give up on my Term / SysLog solution as debug was added to the PVR that contained the '%' character which in turn made LOG: go bang for obvious reasons.

So, in the end I made my own app to read from the serial port and dump it to a file in the desired format. In hindsight I should have done that from the start, but I was too lazy and was hoping there was a solution already out there on Aminet or OS4depot . Fortunately, I have made apps in the past that use the serial port, so it didn't take more than 30 minutes to knock something up using existing serial routines that I had almost forgotten I'd written years ago .

Thanks for everyones help - maybe I'll develop this program into a tool that can be released (I'm still lazy and there are no command line options yet - everything is hardcoded). Perhaps somebody other than me might find it useful???