@MickJT & DAX:

Yes, indeed. After adding the missing > MUI-OWB did a complete font parsing run and starts without reparsing the fonts all the time now. This is true for both "versions", plain OWB and OWB launcher. I wondered, too, and read about the missing > in the font.conf for the first time here

@djrikki:

If your future applications would do this as default, I would most likely never install them. Why? I dont like any program messing up my very personal dock by spreading dock icons all around and in between.

First, AmiDock is very flexible by the subdocky concept. If any applications want to install their icons there, where to put them? In the "Extras" subdock? Main dock? Coder dock? How large shall it grow, if somebody uses many, many applications, but only few of them frequently?

Second, some people use a very personal style, even for the dock. You would make them unnecessary work in removing or re-arranging their dock, if your application messes with it. Depending on the number of dock icons and subdock-depth, its not that easy to remove an icon every time an application installs its icon somewhere.

Its much more easier for the user to throw the application icon in his dock by hand, if he really needs it there. Its just drag and drop. No messing around with the AmiDock preferences. Or tick the appropriate option of the installer script, if asked for, this is just one mouse click.

If possible, never prescribe, how a user wants an application being installed. We had that for ages with Windows, and it was found being bad. I dont understand why it should be better now, as Apple does it with its AppStore-thingies.

@SimplePPC:

Well, I have a PCI card working very reliable in my MicroA1... its a SII0680 RAID controller, and it works perfectly good (except RAID functionality, that is. No support for RAID atm.).

Theres no need to completely disable USB (theres still a bug somewhere, so that one has to disable rear or front USB ports in order to use a secondary IDE channel) and in theory the onboard IDE is usable, too. Well, usable, but not very stable, that is. But this is true for a bare system (without any PCI card inserted), too

The point with USB2.0 is, that the system freezes partly, if a USB device is plugged in. I think its the EHCI driver that makes big trouble here. For me it seems that USB2 wasnt tested very intensive on MicroA1. Maybe betatesters used FX machines only, which are a bit more reliable than the GX types.

Over at os4welt.de (german forum) theres somebody who found a USB2/SATA combination on PCI card and he states that it works fine, except USB2. He had to disable the EHCI driver, but OHCI works. And he doesnt need to disable the UHCI driver in Kickstart then.

@pvanni:

I wish the MicroA1 would have some more PCI slots... it has only one

@Darren:

Thx! Now the card is recognized correctly, but it behaves the same as the NEC one. As soon as I plug in something, my µA1 freezes. Anything I could do against this?

Oh, and I had to comment out the uhci parts in kicklayout, otherwise the machine wont boot at all, it hangs directly after the splash screen

@nbache:

I have a VIA VT6212L card here, but no luck so far. Definetly not found on the PCI. I have a MicroA1 and had a NEC based card partially working. Strangely, there are no PCI problems with a SII0680 IDE controller, even a SII3112 based Adaptec was found on the PCI at least. Ok, possible that the card is broken, would have to verify this...

Edit: Hmm, the card is ok, and it seems to influence the Micro in some ways, when its plugged in. As soon as I comment out ehci in Kicklayout, the machine boots fine

Edit2: Grrr, yes, the card is working, but is NOT recognized by the ehci driver. Just the same thing as for my Adaptec SII3112 controller. Works, but not recognized by the sii3112ide driver

Here the important parts of the Ranger PCI dump:

0x3038 Rev: 0x61 (N/A)
0x1306 (Duet Technologies)

@ChrisH:

You missed "gimp" Ok, depending on personal view this one isnt native, too, but its there and it works.

Youre right in saying that we should get some more native applications, but this is often a question of time and even more money.

I would really like to do some applications in the range of AE, Wordworth, Turbocalc, Cinema, DynaCADD etc. etc. But for me, as the only coder of Insane-Software, this is too much work, and atm. it would be without any insurance that it will pay even our daily needs (or cure the not-Amiga-related troubles I experienced since Amijeweled release back in 2007).

We have to wait, as usual

@Trixie:

No, I have never seen them advertising for help on ArtEffect code. Neither did I for any project they searched help for (and they did this also for projects that actually were released). Go figure...

You should take into account that they aquired certain rights from H&P, but I dont believe in these rights being free from any restrictions regarding 3rd party developers. Maybe thats the reason why they never advertised for help on ex-H&P-projects (like StormC and others).

Just let them work (or not work), we will see, if and when "AE OS4 native" will hit the market. Actually, there is enough replacement of similar quality available, so that we dont need AE that badly. Its a "nice to have", but not a must.

Maybe Update 3 (or 4.2) gives more drive to the market, so that theres more need for something like "AE OS4 native" and Alinea gives more strength to this project.

@Trixie:

AFAIK Alinea Computer aquired the source code and the distribution rights for ArtEffect (among other products of Haage&Partner). Stefan Robl did a huge work to make it run at on PPC at least (and make it compilable with a non-Storm-gcc), but there is far more work required to make it usable actually.

Last time I heard of it, Alinea Computer searched for some coder to make it work without the internal VMEM facility, which is overall messy and broken (I saw the source code of the 68k version. Very ugly...).

It may take a long time until ArtEffect is released as OS4.x native version, but I wouldnt say that this would never happen.

Hmmm... maybe Im missing something, but is the first link not doing exactly what it is supposed to do? Showing the file, aka showing the files properties?

The second link is another one, its a direct link to the file, without any command to "show" any properties, so any decent browser will recognize the download header and starts the download.

For me this behaviour is absolutely correct?

Yes... the same information you got already ;)

Regarding the crosscompiler: you should say what kind of crosscompiler you want. For C there is vbcc. Fully crosscompiling from any platform to any platform. Easy to build for any platform on any platform ;)

For c++, there is none that compiles from OS4 to 68k, but vice versa. I dont think that theres any chance to get some crosscompiler for 68k that runs on OS4. Maybe you should use some win/lin crosscompiler then.

Would you share your totally different approach with us?

@ChrisH:

No problem... in the essence we had the same thoughts (finally ). Reading CLI/WB parameters of one task by another task.

But with the task control block I gave you a hint where to find the corresponding WBArgs you search for. For OS3.x systems it IS possible to fetch those arguments, but it is NOT easy to do so. You have to dig deep into structures of the OS for this. Somewhere in the dark depths of the system you will find the WBStartup message, which was send to the corresponding task when it was loaded.

Some examples how to get more internal information of a foreign task you could find in e.g. the DICE source code (aminet). Those nasty little old debuggers often worked the way you want, including library function patching

Hans stated the important already: It is very dangerous to do such things, and not very compatible, too.

Quote:

Easy... FindTask(NULL) gives back the pointer to the task control block of the calling task (here: program A, the patching one).

If you want to get the task control block pointer of a foreign task (program B, the one calling the patched functions), you have to supply a task identifier (the task name) in order to give FindTask() a chance to work properly

Thats why it was very confusing. You tried to find your own task, and then it should have been as easy as nothing to use the solution mentioned by thomas/colinw

Back to topic: I dont think that there is a very simple solution to trace back the task who is calling a patched OS function, and its even more complicated to get more information about this tasks internals (like globals and function entry points). Lots of register ping pong and stack backtrace, not to mention segments, relocation/symbol tables etc. etc.

Finding the calling task should be the easiest part, as there is a global task list. IIRC it contains all information necessary to find out, which task "owns" a certain address (the callers return address on the stack).

With this information, you should be able to find the tasks task control block pointer and over there the contents of the WBStartup message, including WBArgs.

Edit: I could imagine that this is the way FindTask(NULL) works internally. Backtracing the callers return address, found on the stack.

Obviously this couldnt work from within library functions (even patched ones), as FindTask(NULL) would find a return address belonging to the library´s code segment, which is not registered with the global task list. FindTask(NULL) should return an error indication then.

@ChrisH:

Well, the first question you made here wasnt a mystery at all. thomas´ and colinw´s first answers were the solution to this. This solution should work in any normal case.

The mystery started when you stated that you´re unable to access main() and/or global variables

Your explanation is a bit confusing... you want to get the WBArgs of your patch program (FindTask(NULL))or the WBArgs of a foreign task, running already? In the first case, use thomas´ and colinw´s solution. Simple as that (and it works until you do something really weird within your startup code or use a very weird compiler).

In the second case its not so easy...

@thomas:

colinw´s answer made perfect sense as an answer to ChrisH´s initial question. Like your first answer. And with more details than yours. So, wheres the problem?

@ChrisH:

broadblues hit the nail

The unability to access even global variables is shown by which evidence? gcc error message? Crash?

Quote:

You see that your argumentation has a serious flaw? If Ringhio manages to "work around" the Intuition screen locking system (which it seems to do!), its definetly Ringhio which is at fault for now

You couldnt call Intuition the bad, if you do tests involving Ringhio only. Test "normal" CloseScreen() use, means: without Ringhio intervention, and then tell us, what it returns. I bet that it works exactly as documented.

If Ringhio invents a new display locking method and Intuition for normal users cant handle this new method yet, we should wait for some OS developer (IIRC Rigo is responsible for Ringhio) to tell us more about it. Instead of yelling "bug! bug!" all the time, I mean.

Btw., I share broadblues´ feeling of Deja Vu. Some time back these Ringhio related problems with Screens were mentioned and reported already. But I dont remember yet, where it was. Maybe AW?

@ChrisH:

Well, if you see explanation of your bug report more deeply as spamming, well... ok.

But I definetly reject your "off-topic" accusation. The bug you reported was about a specific CloseScreen() pitfall, and thats what I was talking about.

Thanks.

Yeah, Ringhio seems to have some screen lock problems, but as m3x stated, this seems to be solved in the meantime.

MUI isnt really part of AmigaOS4.x, AFAIK, but it can be fixed. Good message so far

I tried to tell you and others, that CloseScreen() is working exactly as documented and expected, and that application developers should not try to do their work using lin/win developing behaviour. This means, relying on the OS to do cleanup work they (the developers) should do. Thats all.

What we should really talk about is a proper way of responding to the CloseScreen()-fail-case. As far as I see the SDK contents, there is no official procedure mentioned for giving up. For future compatibility there should be a standardized and documented procedure for handling this case, so that a possible future solution to the screen lock "freeze" will not be useless for older software.

Edit:

@ChrisH

You misinterpreted my post. I didnt argue against your patch specifically. I just stated that there is no patch needed in any case for this specific problem.

This problem results from misbehaviour of other, new, OS components (not tied to the CloseScreen() function code) or 3rd party software (that MUI still is).

I argued against the mainstream method of talking about software quirks. Did you realize that there is more and more talk about "bugs" in long term proven OS components? Public screen automatic open/close worked from the first day it was incorporated into AmigaOS, and it worked in an expected manner.

There is actually no way to close a screen a foreign process still holds a lock on, and this is absolutely correct and necessary for OS stability.

Any attempt to solve this by brute force will mess up future (and clean!) solutions.

Thats why my post was so huge... you cannot talk enough about this

@ChrisH:

I still dont believe in an OS4 bug, despite your experiments with MUI programs. The interesting point is the following:



This one quite clearly states, that the calling process is responsible for a senseful reaction to the case, that a public screen cannot be closed. Its easy as that.

In case of MUI (and related programs) this still doesnt take away the responsibility from MUI or the application using the MUI autoscreen features to check for a successful close of the public screen it opened.

There are still cases, where a process opening a public screen could be prevented from closing it. I.e., if a foreign process (CygnusEd in your case, this one doesnt use MUI AFAIK) holds a lock on this public screen on closing time.

Turn it as you like. Its just another application development quirk. People doesnt obey AmigaOS software development rules just to save some cleanup work.

If MUI isnt able to close the screen after the locking process frees all of its screen locks and terminates, its broken. If the OS4.x PublicScreen automatic open feature isnt able to close a (after some time) lock-free public screen it opened, its broken. If any application that opened a public screen itself isnt able to close it after the last visitor window vanished, its broken.

Let me recall this: You have to check for a successful close since V36 and you have to take measure for the negative case (i.e. waiting or give up in a Wait() loop, i.e. waiting for an Intuition message. SDK isnt very clear here, sadly).

Some day there may be a more elegant solution to this problem, I suggested some kind of "SAFE_TO_CLOSE_PUBSCR" message from Intuition, maybe some people come up with another solution.

Until that day, all applications/application layers have to check for a CloseScreen() fail and response to it accordingly. This includes a "I give up on this and I free all resources I can free" in the hardest case.

There is no need for a patch or a mere bug fix. All we need is some discipline for the clean up part of our software pieces.

Edit: Forgot to tell, that you as application developer are still free to request the user to close all possible visitor windows in the case CloseScreen() fails on a public screen your application opened. IIRC, there were some applications in ancient times which did exactly that.