Thank you Deadwood

[quote name=deadwood post=4804]@deadwood - @OlafSch It's pretty much like @magorium described. See attached screen shot for MultiView running through AxRuntime and using datatypes to display picture. One thing that is not yes implemented is passing arguments - so opening an image via double-click won't work yet .[/quote] Looks good. It would be fantastic if you could mix it like on Aros 68k mixing Aros and AmigaOS binaries. For example starting components with parameters, be it AxRuntime components (Aros) or real Linux components In this example starting Multiview with path to picture as parameter

[quote name=magorium post=4794]@magorium The only thing that I can not seem to realize is AXRuntime. That really requires 2 different RTL's to be active at the same time for which FPC does not have provision (and I was already told it will not be accepted would it be added)[/quote] That should be ok - AxRuntime can run ABIv11 AROS executables, so as long as you can compiled Pascal source code to AROS executable, the program will also be available for Linux/Windows users.

@OlafSch It's pretty much like @magorium described. See attached screen shot for MultiView running through AxRuntime and using datatypes to display picture. One thing that is not yes implemented is passing arguments - so opening an image via double-click won't work yet .

And the voting is now closed! Two bugs that will be tackled in April are: #116 and #105. (y)

[quote name=OlafSch post=4795] you can develope a picture viewer, multiview as example, that accepts path to a picture as parameter and then shows it? [/quote] That question has many hidden subfeatures inside it. Could you elaborate ? Know that it is already possible to show a picture using multiview using tooltypes, hence the question. [quote] Second, how do you add or improve datatypes? Normally you copy a file in a directory.. How is it done in AxRuntime?[/quote] Exactly the same. In principle: anything that goes for classic amigaos/AROS also works for AxRuntime. If it doesn't then it is worth considering a feature request but that is ofc if deadwood decides it would be beneficial to support such a feature or not. Perhaps better to compare it with hosted instead of native. If AxRuntime does not support something in particular then it is possible to use host functionality in order to accomplish such task.

[quote name=deadwood post=4793]@deadwood - [quote name=OlafSch post=4786]@OlafSch - Then datatypes. It is a cool concept in my view..[/quote] In what function do you see datatypes? They are already included in AxRuntime.[/quote] that might be enough. Two questions.... you can develope a picture viewer, multiview as example, that accepts path to a picture as parameter and then shows it? Second, how do you add or improve datatypes? Normally you copy a file in a directory.. How is it done in AxRuntime?

[quote name=deadwood post=4777] 4) Test program written in Pascal [/quote] Note that I still have the intention to fork Free Pascal as soon as a new version emerges in order to add/implement the necessary changes to support 64-bit AROS. So far I have not noticed any issues with Free Pascal compiled 64-bit AROS executables, it is just that the ruling dragons decided that they will not support AROS ABIv11 and seem to have a sweet-spot for ABIv1 (which does not work and will never work for Free Pascal with current imposed restrictions. But hey, what do I know :) ) The only thing that I can not seem to realize is AXRuntime. That really requires 2 different RTL's to be active at the same time for which FPC does not have provision (and I was already told it will not be accepted would it be added)

[quote name=OlafSch post=4786]@OlafSch - Then datatypes. It is a cool concept in my view..[/quote] In what function do you see datatypes? They are already included in AxRuntime.

Hi All, Just a reminder - one day left to vote! As it stands right now, the winner of the poll would be #116, and the winner in total votes would be #105. Total votes: #123 - 12 #116 - 13 #105 - 13 However, as you can see we have a very tight race this month, so even one vote can now make the difference. Looking forward to seeing how this plays out...

There are some components I would also like to see on a potential new linux environment. Diskimage device to f.e. mount adf. Then datatypes. It is a cool concept in my view. And Arexx ports. And of course a amiga desktop as base. I know and like both magellan and scalos. With both you can do similar things. What you prefer is a matter of taste. The basic difference, Magellan always was a solution on its own, whereas Scalos always obviously was designed as a workbench replacement. If possible both would be nice to have ;).

[quote name=deadwood post=4777]@deadwood - Hello, Emulator reached a point where it can successfully run ABIv0 calculator - check the attached video. As you can see, the 32-bit calculator is integrated with other 64-bit programs so as a user you don't really know that you are running a 32-bit application. Prototype implementation of "proxy" graphics.library and intuition.library is proceeding and while there are some caveats around message passing, so far no blocker problem has been found. I also defined a checklist of tests needed to be completed before a final decision on emulator can be made: 1) Test a recent program written in C using new C library (Calculator) [b][DONE][/b] 2) Test an old, 3rd party program written in C using old C library (ZuneARC) [b][IN PROGRESS][/b] 3) Test program written in Hollywood 4) Test program written in Pascal 5) Test emulator under AxRuntime and confirm ABIv0 programs can be run directly on Linux/Windows Emulator sources are available here: [url]https://github.com/deadwood2/AROS/tree/AoA/workbench/tools/AoA[/url] If you are a developer and you would be interested in contributing to emulator in future, please send me an email or PM on the forums.[/quote] Thanks deadwood, you are great, I spread your post on the sites I frequent !

Hello, Emulator reached a point where it can successfully run ABIv0 calculator - check the attached video. As you can see, the 32-bit calculator is integrated with other 64-bit programs so as a user you don't really know that you are running a 32-bit application. Prototype implementation of "proxy" graphics.library and intuition.library is proceeding and while there are some caveats around message passing, so far no blocker problem has been found. I also defined a checklist of tests needed to be completed before a final decision on emulator can be made: 1) Test a recent program written in C using new C library (Calculator) [b][DONE][/b] 2) Test an old, 3rd party program written in C using old C library (ZuneARC) [b][IN PROGRESS][/b] 3) Test program written in Hollywood 4) Test program written in Pascal 5) Test emulator under native AROS x86_64 and confirm it can work with native kernel 6) Test emulator under AxRuntime and confirm ABIv0 programs can be run directly on Linux/Windows Emulator sources are available here: [url]https://github.com/deadwood2/AROS/tree/AoA/workbench/tools/AoA[/url] If you are a developer and you would be interested in contributing to emulator in future, please send me an email or PM on the forums.

.

Ok, thanks for translation. Bug #140 is not about Relabel shell command, but about using Icon->Rename from Wandeder menu to relabel a disk.

Sorry I thought I wrote it in English, now it is translated ! SmartWB is not directly addressing bug #140, but what I had written in post #4, in the sense that after the relabel, the new name would be immediately visible, without using the procedure I described in post #4.

@AMIGASYSTEM Your post #4 is in Italian and I don't know what relation SmartWB would have with bug #140.

Sorry deadwood, on that note on Aminet there is SmartWB10 which also includes sources in C. SmartWB10 if I understand correctly allows an automatic update of the Workbench, I tried to compile it but it requires sources not in development, this could be useful if intehrated in the wanderer menu, or in the startup-sequence http://aminet.net/package/dev/src/SmartWB10

deadwood, regarding bug #140, when using the Relabel command to rename a volume, you don't need to reboot the system to see the new name (as in the bug report), actually just do a "Refresh" on Wanderer, you get the same result by using the Backdrop comado "Menu Wanderer", just turn Backdrop activate/deactivate This procedure also works when changing the icon to a Volume or folder, after "Refresh" from wanderer, the new icon will be visible.

Voted for #116