Qt 6 progress

@elfpipe

it is linked against amissl or openssl?

@afxgroup

Openssl. And I know, what the problem is (sort of). It is the Qt6 plugin system, that is not functional yet.

@Skateman

Looks nice. Is this part of enhancer software or something else?

@elfpipe

Filesystem by tony wyatt More info in the link.

https://forum.hyperion-entertainment.c ... wtopic.php?p=56320#p56320

@elfpipe
Quote:sg2's smartctrl only works with his own drivers (sii680ide.device, sii3[15]1[24]ide.device, it8212ide.device, lsi53c8xx.device and a1ide.device) since it's using undocumented, internal functions to make it work.

p5020sata.device doesn't seem to be based on sg2's PATA/SATA/SCSI driver framework. The disadvantage is that smartctrl can't work, the advantage is that it's working without requiring my diskboot.kmod (sg2's drivers need it), for which Hyperion has no licence.

@elfpipe

Quote:Don't you have Update 2 installed? If you did, the p5020sata.device would have been replaced by/changed to p50x0sata.device. (Not that I think it would help regarding smartctl, but there could be other fixes you are missing if you haven't installed the latest OS updates.)

Best regards,

Niels

@elfpipe

Quote:

I did port updated smartmontools but it cannot work with internal sata from X5000 and A1222 because it was decided to abstract them using vsata.device in an incompatible way. I seem to remember some information may be retrieved using a custom tool but I cannot remember it's name right now and am going to leave for work,maybe something like idetool or something like that.

@thread

So I got this far. The problem is the macro Q_GLOBAL_STATIC_WITH_ARGS. It seems it is never instantiated :

qglobalstatic.h at github

When instantiated, it looks like this :



Any cues/clues?

@elfpipe

Ok. Plugins load fine now. I don't know what to do with the certificates. I just want to hook up with google. What shall I do?

Take a look at snoopy output

@afxgroup

I think I found the right place to put them.

BUT no matter what server I try and connect to, the call to

ISocket->connect()

fails. I get a working ip address with QHostInfo(), and the port is correct (either 80 or 443).

Is there any good way to test http/https access without having to play with firewalls? I can use the same Qt6 app on my pc, and it gives bonus, but on the amiga all connect calls fail.

EDIT : connect to 127.0.0.1:80 fails, so probably my socket is not sane. Any advice?

you could try curl and see if https is working correctly

@afxgroup

Nopy. I can't even get that far (ISocket->connect comes before handshake). I am suspecting, that it is an issue with threads.

EDIT : I remember there being an issue with sharing sockfds across threads in Qt4. I thought, the solution would be to use bsdsocket.library instead of newlib calls, but maybe even that is not enough.

Do we have a network api that allows for sharing socket descriptors across threads?

@elfpipe
Quote:With the original (AmiTCP) bsdsocket.library API each process has to open it's own instance of bsdsocket.library/ISocket, you can't share them between threads. The newlib functions are just wrappers to the ISocket functions and can't change that, unless bsdsocket.library/ISocket would be opened before each ISocket function call and closed again after it. Additional problem using the newlib functions: You aren't opening the bsdsocket.library/ISocket yourself and therefore can't use different ISocket in different processes.

But RoadShow has an extension to the AmiTCP API which does allow shared bsdsocket base (and ISocket), using something like ISocket->SocketBaseTags(SBTC_CAN_SHARE_LIBRARY_BASES, TRUE, TAG_DONE).
I don't remember if newlib.library is using it internally.
But there are some problems with that as well, check the bsdsocket.library/SocketBaseTagList autodoc.

@elfpipe

I found this snippet in Qt4 :

Quote:

Is this something to use?

@elfpipe
Quote:Yes, but using it there are some other problems, for example with signals and maybe getting the correct errno.

@joerg

errno should have been task or process relative, by doing so it be treadsafe.

#define errno FindTask(NULL)->errno

@LiveForIt
IIRC it doesn't work that way by default.

While you could use something like ISocket->SocketBaseTags(SBTM_SETVAL(SBTC_ERRNOPTR),&((struct Process *)(IExec->FindTask(NULL))->pr_Result2), TAG_END); or ISocket->SetErrnoPtr(&((struct Process *)(IExec->FindTask(NULL))->pr_Result2),sizeof(int32));
and
#define errno IDos->IoErr()
it still only works for the threat which executed those calls.

With different per-thread ISocket you could use
#define errno ISocket->Errno()
But with a shared ISocket? No idea - except for using a Mutex or Semaphore before each call to an ISocket function, getting errno using ISocket->Errno() and releasing the Mutex/Semaphore again.

@joerg

Interface relative or base relative, you need different bases or different interface per thread.

Typical you open libraries it in main thread, and it won’t work with -D__USE_INLINE__

The next option is implemented TreadLocalStorage, something we need anyway.

@LiveForIt
Quote:That's the default, except that few people seem to know that and don't open a new bsdsocket base and ISocket per thread.
If you do it hat way each thread has an int socketfd = 1 but both are completely different sockets, i.e. you can't share anything socket related at all between the threads.
Each thread has his own errno that way, though.

Using a global bsdsocket base and iface instead, by usingyou can share socketfds between threads, but errno (and other things) is shared as well, causing other problems...