Hi all

We have now native versions of dopus5.library done on gcc for os3,os4 and morphos. If anyone in interest and want to help with tests of morphos library, plz read that topic

The only difference with topic on amigans, is that now "libs.lha" have morphos library inside. So check it plz as described, and if anything going wrong report there.

For the bold and adventurous only.

bash64,
Quote:

As Fab (and other talented programmers) had a hand in creating this, I'll try it.
Looks cool.

Hi Kas1e!
Since Amigans website is currently closed for new user registrations, I'm reporting here a fast test I did with Dopus5:
mos-dopus5.library once renamed starts program wich crash immediately with no chances to quit.
Using one of the os3 libs (saasc or gcc) works flawless: no crashes, copied some files without problems, browsed inside dirs/files, displayed some jpegs.
To start Dopus5 with a double click I deleted its icon because recognised as "folder" (Samo wrote yet).
Here a screen grab:
Dopus5 on MorphOS
I will check more and I will post.
Thanks!

@bash64

I didn't have time to touch it at all, by the way. :)

@Jambalah
Quote:

I point Itix on that thread, so i assume pretty soon he will fix it

With mos-dopus5.library it doesn't recognize the registration and gives registration requester in the start. It doesn't accept valid serial number either. Listers hit in the start and don't show any files/dirs. Settings windows are empty from text too. Here is log after it opens screen and tries to read directory listings with provided example installation.

os3-gcc_dopus5.library and os3-sasc_dopus5.library run fine with that example installation, but when I tried them on my own configuration opened listers stay busy and never show any files/dirs... they don't hit either, but are just stuck there. I haven't found any option or other reason for that yet... any ideas?

@jpv

Can you please try again using another dopus5.library and post crash log here?

I dont have test environment here (I am lazy to install new things...) and whole thing is untested.

[ Edited by itix 15.04.2013 - 21:10 ]

itix: that version works like those 68k versions. Doesn't hit anymore with listers and doesn't nag about registration.

With a _very_ quick play around I found that doubleclicking library files causes hit on both 68k and MorphOS versions:
http://jpv.wmhost.com/testi/dopus/dopus_gcc68k_library.log
http://jpv.wmhost.com/testi/dopus/dopus_morphos_library.log

[ Edited by jPV 15.04.2013 - 22:13 ]

@jpv
Quote:
That because we fix some hard-code in dopus5 (PF_ASYNC flag) which involve and library and dopus5 binary. So if you will test new library on any config, you also need that new (still 68k) dopus5 binary from main archive.

@itix
It was VARARGS68K as you think before? (ps. commit plz your changes so i can pack new libs.lha and reupload for everyone to try)

Good to hear. It mean it was just a compiler issue. Kas1e compiled his build with GCC 4 and mine was built with GCC 2.

Taking a look at those hits next.

@itix
Quote:

It can be related to what we fix for os4 version: https://sourceforge.net/p/dopus5allamigas/discussion/dev/thread/576ca5ad/

Check posts 3,4,5

Quote:

It can be VARARGS68K then, because crash in the registration window and not-pass of registration module = lsprintf = VARARGS (i have the same kind of crashes on os4 version till we not fix VARARGS)

[ Edited by kas1e 16.04.2013 - 06:55 ]

kas1e,
Quote:

Thanks, that did it. I'll leave it on my permanent use to test properly.. although that ugly iconify gadget came back (which had been patched away with DIP, I guess it doesn't work with modified exe anymore) ;)

BTW. You seem to have DOpus modules from 5.80 version in that main archive. Not the latest ones from 5.81 and 5.82 updates. Any reason for that or is it a mistake?


[ Edited by jPV 16.04.2013 - 11:22 ]

@jpv
Quote:

Dunno, in general only what we change in terms of that PF_ASYNC is:
https://sourceforge.net/p/dopus5allamigas/discussion/dev/thread/62a4dd8f/

If DIP somehow refers on IPC and stuff, then pretty possible it will not works. But when we will have native binary of main program i assume we can add an option for disabling it, or kind. Also if DIP have sources, then fixing of it (if it related to PF_ASYNC) also can be pretty easy.


Quote:

just mistake yep, same as wrong tooltype of main binary

[ Edited by kas1e 16.04.2013 - 09:54 ]

kas1e,
Quote:

The best option would of course be to make it use OS's native iconify gadget instead just removing whole thing. And that DIP only removes it from listers while other windows still have the same problem. It's just doing the absolutely minimum makeup ;) Good thing is that we have the sources now and can do something for it. But of course, other more important things first, no hurry :)


[ Edited by jPV 16.04.2013 - 12:38 ]

New bug... there's a crash if you try to open filerequester for background images for example. Both gcc compiled (os3 and morphos) versions hit in the log and no requester appears. Here are logs for MorphOS and os3-gcc versions. os3-sasc version does work without problems.

Font requesters and at least some filerequesters where you select exes for example do work with gcc versions, but seems that image related don't.. for example selecting image to lister toolbar button crashes too.. is it coincidence or not...

@jpv

Yep, i can reproduce it on mos even with os3-gcc library like this:

1. run dopus
2. Enveronment / Background
3. Choice there "Enable background", and untick "wbpatter settings".
4. Pressing on any dropdown gadget (desktop, window or requester) cause a hit.

I also do test it on aos4 (with the same 1:1 os3 version of library, and with os4 native library) : with os3 library there is the same crash, with os4 native library there is no crashes. Seems os3/mos builds have a bug..

[ Edited by kas1e 17.04.2013 - 07:52 ]

jPV,
Quote:

It looks like it is trying to execute library file. Is it possible you have used different config?

@jpv & kas1e

Quote:

I think I fixed this now. Please try dopuslib-17-04-2013.lha.

If it works I commit fix to SVN which should fix this issue in OS3 GCC builds, too.

itix,
Quote:

Actually libraries look like executables and that's why they are executed unless you have defined any other action for library filetype. In that example installation there's a filetype called "os4binary" which is identified by $7F454C46 in start of the file. That is actually generic for all ELF files, not just for os4exes. 3rd party MorphOS libraries also have this and that's why they are executed. In fact Ambient tries to execute library files too, at least if you haven't changed mimetypes for libraries yourself.

But uhm... it's starting to look that it's just some certain libraries which hit. And they hit on Ambient too! So this isn't Opus fault here now it seems. So far I haven't found 68k libraries doing that, but some MorphOS native libraries do. For example ahxplay.library and codesets.library hit, but for example powersdl.library doesn't.

Quote:

Yes, seems to work.

@jpv
Quote:

codesets.library was buggy in that terms (as well as all the other stuff from the same code base like NLIST classes and co, i.e. everything which use the same code-base for initialisation). Xenic find out the problem, and we fix it and in dopus5.library, and Thore fix it in all his projects (include codesets.library). My bet is that another ones which hits, use the same init code as codesets (or just take them from), and because of that they just hits when you run them as binary.

[ Edited by kas1e 18.04.2013 - 10:35 ]

Quote:

It is normal. Libraries are using executable format but they are not really "executable" and can crash. It is same with classes, MUI classes, drivers and anything that is not a data file. You can also "run" libraries from CLI.

Most libraries are protected against this either by adding dummy startup code or clearing execution (e) flag.

Perhaps default filetypes in Magellan could be tweaked to not try to execute #?.library files.

itix,
Quote:

Yeah, and maybe Ambient mimetypes too ;) I've always had library filetype to show libraries' version with double click on my own setups and naturally tried to do that on those other setups too :)

@all
Itix rewrite fully VARARGS68K crap, so no more of it in dopus5.library code, and so we can build library and with gcc2.x, and with latest 4.4.5. Will do some more tests and upload fresh one in next days. Currently we works on main dopus binary, and if all will going well, in next days main dopus binary will be on gcc as well

Getting closer:

DOpus5.png

It almost works ;)

It loads 50% and then crashes because 68k code is trying to execute some PPC call as 68k native. There is still some work to do to find out where PPC pointers are passed to 68k. But shouldnt take long have main program running PPC native.

[ Edited by itix 21.04.2013 - 19:56 ]