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???

@tonyw

Yes, I'm currently using Term 4.8 (was always my terminal program of choice) in conjunction with SysLog to save the capture with date info. File transfers do not appear to work in Term on OS4 though - trying to initiate an Xmodem upload, for example, causing the system to lock up. I've read people blaming the XPR libraries in other threads, but it looks like Term is really the problem, as NComm uses those libraries too, and Xmodem uploading works fine with that.

Some people seem to think serial is dead, but it is still popular for debugging many devices. For anyone interested, these are the PVRs, DTRs, DVRs, or whatever else you wish to call them, that I am currently helping to debug using my A1XE to see and log all the debug output.

@Valiant

Have now tried VLT and Terminus, and they don't seem to have the option of logging the date/time with the capture lines either.

I have found some sort of solution though, by using SysLog. I can now open the capture to LOG: and the serial output gets saved by SysLog, prepended with the date and time on each line which is exactly what I need. A bit of a round about way of doing it, but it'll do until I can find something better.

I'm currently helping debug a PVR, which is spewing out serial debug which I need to capture. The PVR is connected up to my A1XE with an RS232 lead, and I can update the software on the PVR using NComm (Term crashes) and capture the raw serial output to a file from the PVR box using Term. However, this is not quite enough as the manufacturer really needs time/date info prepended to each line of serial output, which Term cannot do.

So, is anyone aware of any existing software that can help with this task, OS4 native or failing that classic? I can't seem to find any terminal program newer than Term on OS4depot/Aminet. Perhaps there is a way to pipe the capture output from Term using a some sort of handler as the file?

Quote:
That may have been true initially, but others have been updating the OS4 datatype sources, so I can't guarantee that recent versions sport my enhancements from the WarpDTs anymore .

I'm kinda sick of fixing other careless developers' bugs, which is all I tend to do in OS4 development terms these days unfortunately (e.g. because IBrowse and the WarpDTs keep getting blamed for being buggy when the bug is in fact in OS4). However, I am going to take a closer look at the requester problem because it certainly didn't used to happen - it started happening after some OS4 update. Since the problem involves a complete system lockup, it's going to be hard to track, and it may be sufficiently complex that I won't be able to work out which component the problem is caused by, and in which case maybe I can add a workaround to the WarpDTs instead. We'll see.

@Chris

Just tried with "Accept-Encoding: deflate" and the server returned uncompressed text. Although it also returned an empty "Content-Encoding: " header - don't think that is quite right either.

@Chris

Oh, I dunno... the RFCs are actually pretty clear on this. Although I remember cases of servers sending gzip encoded data anyway, even when the client did not say it could support that, but that's something different obviously.

I doubt Apache itself is at fault in this case, and it's most likely a site specific mis-configuration of Apache, it's modules and/or a PHP script issue that is causing the Content-Encoding header to get mangled. Can't really blame OWB just because it is sending the accepted encodings in a different order than "expected" by the site - in theory clients are allowed to use whatever ordering they want.

@Deniil

Yes, it is a server bug. It looks like the server has double gzipped the content for some reason, so when OWB unzipped the result is still a gzip stream. Probably the server does not recognise "deflate" because...

FYI, IBrowse normally sends:

Accept-Encoding: gzip, deflate

and receives:

Content-Encoding: gzip

But, after changing IBrowse to send:

Accept-Encoding: deflate, gzip

just like OWB does, then IBrowse encounters the same problem:

Content-Encoding: , gzip, gzip

Along with binary jibberish being displayed.

The headers returned are the same for IBrowse 2.4 too, which does have gzip encoding support (unless disabled in the prefs).

@Chris

Which browser did you use to upload? No browser should ever send the local file path to the server - only the filename. In fact, doing so would generally be considered a security flaw.

@Thematic

Bear in mind that OS4 ships with the same version of OpenSSL (0.9.7g) as is used in the 68k 3.6 build. It is safe to enable all ciphers via the IBrowse prefs - you will probably find that DH is disabled, and that's because it is incredibly slow on 68k . There shouldn't be any problems with AmiSSL on OS3.x or OS4.