@ssolie:

You could take this as a proposal for a new feature

As thomas said, theres simply no need for a CloseScreen() patch. Just follow the development guidelines, and do some wait if CloseScreen() fails. If theres a broken program still holding a Lock on your public screen, there is actually nothing you (or the OS) can do against this, beside freeing as many resources as possible and place yourself into a Wait() loop.

Some time in the future there may be some other solution for closing public screens, involving messaging perhaps, which would help with crashed programs holding a Lock on a public screen. As soon as Exec/Dos killed the broken program (and freed its resources/locks), Intuition could send a Signal/Message to the process that opened the public screen, telling that its safe now to attempt another CloseScreen(). Something along this line...

Maybe its not so strange at all... LockPubScreen() locks the screen bitmap, and it does so even for Intuition. If Intuition tries to draw the mouse pointer, it is blocked for the time you hold the lock to the screen.

I dont know much about internal workings, but it seems to me that Intuition (due to its higher priority) first redraws the mouse pointer (and traverses the display refresh lists) before it gives control back to your code.

For Intuition screens its not very wise to get the screen dimensions repeatedly, as long as your program has control over this particular screen. It wont close or change dimensions until you tell Intuition to do so

Maybe some cache mechanism would do the trick, but this might be not as portable as it should be, as most GUI systems lack certain Intuition features...

The point is, that there is no really good documentation for beginners to AmigaOS programming. Else you would have seen how GetAttrs() is working internally. It is explained deep in the autodocs, that GetAttrs() gives back 32 bit values that you have to cast to the appropriate type afterwards (as documented in the autodocs regarding the specific attribute).

Time for a RKM overhaul...

@tonyw:

You mean newlib, dont you? Well, the duplicating of library code argument would be futile then, as there is much more trouble to cure, if a program uses clib2 AND dos.library buffered file I/O calls additionally. And no documentation about all this and how to use it correctly, if you need some low-level functionality.

What a mess...

There is still the question, why on earth there is still NO system function with the ability to output formatted strings containing float numbers. Or simply convert float numbers into a string, which in turn is copied to a string buffer, which in turn could be used by the well-known output functions.

utility.library would be a perfect place for functions like this.

Hehe, yes... but it would be even more simple to implement floating point output for SNPrintf(), so one doesnt have to hassle with the (possible) caveats of using a system call/C runtime call mix.

I never understood why they chose to call the "more modern" RawDoFmt-replacement exactly like the full-fledged C runtime call, but dont implement the full functionality (thats a reason to ask where it indeed IS more modern, besides the name).

It would have been more clever to keep RawDoFmt as THE absolute low-level-call it was all the time, and give the functionality developers would expect to the SNPrintf() call (even more as its located within utility.library and not within exec.library).

Or, if some basic ouput function detached from exec context is needed so badly, give it another name.

And its still a good idea, because dos.library and C runtime still carry their very own contexts.

There is some kind of warranty that mixing up these contexts will do no harm to the system, but as context information is very scarce (still), there is some danger that a coder might mess up one or the other context, on e.g. program termination, by accident (e.g. Exit() instead of exit() for an "emergency shutdown" and some other cases still not cleared).

Edit: Forgot something Portability in mind is always a nice idea, but for AmigaOS only programs its quite useless to keep "portability" by using C runtime libraries. A program wont get portable magically by using C runtime calls only.

It depends on the intentions of the developer, if a program is "portable" by design or not. So, please, dont push developers to portability where it makes few or absolutely no sense.

AFAIK the only screen the mousepointer can be _seen_ over is the frontmost one And there is no concept like "inactive screen" in Intuition so far.

Im not on my Amiga right now, but AFAIR this information can be found in IntuitionBase structure, some structure member called FirstScreen or similar. There is a member for the active window (the one holding the input focus, not necessarily located on the frontmost screen, btw.), too, IIRC.

Oh, and dont forget to lock IntuitionBase first!

Edit: Uh oh, Im not right with my first sentence. There are indeed more screens possible. One has to calculate the screen offset into this! This means, if there occurs screen dragging, the screen the mouse is over could be one that is seen in the "background"! One has to check, if one of the possible screens (there is a list of all screens opened atm. one traverses locked IntuitionBase, dont know its name atm.) has its bounds hit by the mouse pointer "hot spot" in order to get the right screen the mouse is over. The bounds result from all screen´s offset differences. E.g. frontmost screens offset is 20, screen behind has offset 0, so the background screen´s bounds are 20 x screen width (roughly. There is more information in Intuition includes).

@Elwood

Thats the point... some applications dont ask, if you "escape" them. And its very likely that more applications will come (mostly ports), which doesnt ask either.

Thats why a single keystroke for a terminating action is so dangerous and should not become standard for AmigaOS (in fact, it shouldnt be "standard" at all).

I dont see the point in naming RAmiga + Q "complicated". I bet you often use even more complicated hotkey combinations, consisting of two or even three keystrokes. Commodities are an example for this.

I really dont understand why people insist on closing a program being "not complicated", if all you need to do is pressing two keys or move the mouse and click the left button.

As I said, there are much more "complicated" keystrokes in alldays use.

@Phantom

Maybe a dumb question, but:

Wouldnt it be sufficient to alter the existing .7zip deficon?

I mean, using the pattern "#?(.7zip|7z)".

This should do the trick, too, and you dont need to maintain two nearly identical deficons for 7zip-archives.

@ChrisH

Wouldnt be necessary, if programmers would obey the rules stated in the Amiga User Interface Style Guide you mentioned ;)

Its clearly stated there, that applications should listen to certain standard shortcuts, RAmiga + K is one of those...

I think the problem here is, that too many people inherit bad GUI + coding style from other platforms and dont obey the Style Guide rules (although some of them demand such a style guide, revised).

This should be mentioned in bug reports, over and over. Until developers change their mind, and make their code more user + OS friendly.

@Phantom

As you realized already, its never a good idea to start a "terminating action" with a single key. RAmiga + Q or RAmiga + K (for closing windows) is the better choice. No "accident" possible ;) And still fast operation, if needed.

Regarding SimpleMail, AFAIK some SimpleMail development people are reading here... maybe its possible to equip the delete function with a "are you sure?" requester, even if one wants to delete a single mail? Immediate Delete without a backup is a frustrating thing sometimes...

@ChrisH

Indeed, youre right here. Some Style Guide (updated) is needed urgently.

I feel very sad about OS4 inheriting more and more ugly behaviour of other OSes.

The use of Escape for closing windows is one of them.

It would have been a wiser choice to use any other key for this (e.g. function keys or Amiga key combinations which were used for more than 20 years now!). Users should become used to them, finally. Theyre using AmigaOS, not Windoze!

Escape is meant to be used in situations, where a user wants to "escape" from a program state he doesnt want to be in, not to "escape" the program itself. So its the task of the application to react on Escape adequately, not the task of the OS GUI.

@Antique

Its found here:

http://www.estamos.de/makecd/

Do yourself a favour and read all the text given there, as there are some additions to MakeCD sprinkled all over the place (download links and explanations, I mean).

For CD-only burning, MakeCD is still a superior package once you get used to it

Regards

Edit: Hehe, ZeroG was faster, but ok...

@Coder & ChrisH

The book can be found here:

http://www.stack.nl/~marcov/compiler.pdf

Have fun!

@Ant

Check if theres an assign called CDDB: on your system. If not, create it (use a senseful place to store the cddb data, RAM: is not a real good place for this ).

After that, and if your machine is connected to the Internet, some info will be retrieved and stored to the "local cache" of cddb.library.

Oh, and check, if cddb.library exists on your system. If not, get it from Aminet (and the "glue code" addition for usage with OS4+).

@ChrisH

Well, you are aware of the fact that e.g. DefIcons does it exactly the way you desribed it? If theres some uncertainity with the type of a file, it examines the file name extension additionally (if the DefIcons Prefs file is made up correctly, that is).

Still no need to "fix" the protection bits.

Shell power users should have the knowledge how to distinguish between simple text files and scripts and how to use them properly, shouldnt they? How many new users you know use the Shell first, instead of the "Desktop"?

IIRC, the topic was about some problem with nested scripts. Why caring about protection flags/file name extensions then? They arent the cause of the missing functionality of script nesting and wont help a bit curing this problem...

@ChrisH

Quote:

Well, you suggested to get rid of protection flags, you and some other people claim to have no use for. But another bunch of people have perfect use for those flags.

That would be functional reduction for the OS, wouldnt it?

Quote:

Oh, you mean, in such a way, that executables, which wrongly claim to be "pure", cannot be made behave correctly by a quite simple intervention from the user?

A brilliant idea...

Quote:

So, if even C= made such a mistake, its even more important to tell all the publishers/developers out there to take much more care on the protection flags.

Removing the functionality of protection flags wont help with this, sometimes the missing protection flags will make it worse even (see above).

Quote:

If your program isnt used, despite of its usefulness, well, then it is the point.

Quote:

Well, I heared of it, and I wont use it at all for serious work. Because its not able to support vital functions of the AmigaOS filesystems. Besides other quirks it has...

Quote:

No, we dont miss them really. For user information purposes file extensions are useful, but not for recognizing them by the system itself.

For user information, the file extension is more a question of convention. E.g., how an ARexx script is named. You could add the extension .rexx for example, to make it absolutely clear to the user, that its an ARexx script. Or you could call it .rx, or whatever.

For the system itself, if you want the system to be very flexible (and thats what AmigaOS still is), file extensions for file type recognition is a bad idea. You bind yourself to some extension mimic and would not be able to re-use an extension, if time for this has come.

I think people try to make too much "modernizing" (well, its better said "windowsizing") on AmigaOS where it isnt really necessary. Protection flags themselves werent a problem at all, and most people (including you, it seems) dont use them very much. So wheres the problem?

The problem is, where people, claiming to have knowledge, set flags wrongly or use inappropriate tools to assemble a package for publishing.

So, not AmigaOS needs to be changed, the mind of some people needs to be changed. This is done best by telling them, when and how to use those flags.

@ChrisH

The point is, that, if you reduce the functionality of an OS just to be compatible to some other OS to some extend, you give up the OS itself.

I for myself see no point in raising "incompatibility" talks regarding e.g. FAT/NTFS, as there in fact is just "incompatibility" in one direction. And AmigaOS is not the one being "incompatible" here...

To avoid the protection bit problem when migrating data from a Windows machine on to an Amiga machine, just use appropriate helper programs, e.g. lha. There is no point in storing native Amiga data onto a Windows machine directly, if Windows isnt able to preserve the AmigaOS flags, isnt it?

The "some archivers dont support the e flag correctly" argument is a straw man argument. If the archivers are broken, the OS should be "repaired"? Weird way of doing things, isnt it?

Some other important point: It doesnt make sense to work with Amiga executable files on a Windows machine, so theres no need to store them directly on the Windows drive. Its much better to store them within an lha archive, which is easily transferred to an AmigaOS machine and extracted there, preserving all AmigaOS flags.

Regarding the script and executable flag topic: theres indeed much sense in this distinction. You might remember that it is possible since some time to "execute" scripts in the shell, by simply typing the scripts name (without execute in front).

It would be much more effort to learn the OS recognizing the difference between a mere executable and a script data file, which might exist not only in form of an ARexx script, but maybe some other language.

So, how to decide, which kind of file some file is, if theres no clean way to distinguish between executable and some form of executable script? Simple: by using some flags.

I dont think it is the right way to make AmigaOS more "fool proof" to attract new users. The real fools are some people, publishing files/archives with broken flags. If this wouldnt happen all the time, the whole discussion made up here would be superfluous.

So, the better and simpler solution is: Make developers and publishers aware of such problems and insist on non-broken archives/archivers and/or files with proper flags.

Its very easy to achieve, even if the developer/publisher uses some Windows machine for archive/file preparation. I do this quite often and there were no problems with flags at all.

I use WinUAE.