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 do not care that you don't use those flags, nor do I care if "most users" have no need for them (who again? seriously, new users? who are you kidding?)
The point, for me, is that _I_ use them, every single one of them. I guess I must be really leet for knowing my ways around the system, huh?
I also use c:edit, but I suppose you want to get rid of that too, huh? Anything else you want to get rid of while we're at it? How about assigns? Only VMS has something vaguely similar, and we can't expect new users to come from VMS these days, so I suggest we get rid of assigns too. And ram-disk, it serves absolutely no practical purpose these days. And envarc:/env: should obviously be replaced with a database and a dedicated editor. And when you have a database, why not get rid of the various nonsense files inside devs:? And C: L: LIBS: S: - who cares? Why not just toss them all together into the system folder? Ditto for classes, fonts, prefs and anything else that any random n00b would not understand.
Yes, I too was once a new user, and all this stuff was _exactly_ what made me like the OS. They are tools that very rapidly allowed me to put together my own custom systems that did exactly what I wanted them to. Are you suggesting people today are more stupid than we were when we started? I don't they are.
The point is, that, if you reduce the functionality of an OS
I don't think I suggested anything of the sort.
For example, it would make SO MUCH MORE SENSE for the "P flag", which indicates that an executable can be made resident, to be stored within the executable itself. The P flag even seems to be wrongly set on most AmigaOS installations (even clean ones from Commodore).
Quote:
To avoid the protection bit problem when migrating data from a Windows machine on to an Amiga machine, just use appropriate helper programs
I already wrote a program to do this, but that isn't the point.
Quote:
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.
I guess you never heard of a cross-compiler? e.g. AmiDevCpp.
Quote:
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.
Or even better, just use the filetype extension. We only miss extensions for AmigaDOS scripts & Amiga executables. While it's too much to hope that everyone would want to use such extensions (and even I'd dislike them on executables), it would be supremly handy to be able to clarify the filetpye using the filename (extension) when necessary.
@kolla Quote:
The point, for me, is that _I_ use them, every single one of them. I guess I must be really leet for knowing my ways around the system, huh?
On AmigaOS3 they had some uses, but really I haven't seen them used at all on AmigaOS4, which is the OS being discussed. The P flag (resident) is obsolete on systems that don't have cripplingly slow I/O.
Quote:
I also use c:edit, but I suppose you want to get rid of that too, huh?
That's the worst thing you can ask. IMHO File extensions are stupid thing from stone age !
Btw. One way to make file type recognition faster. Recognize file types when the files are created and edited and if they have .info file store that file type info into its .info file. Next time you're reading a dir or that file it's faster to find file type from its .info file.
(Edit: But anyway rexx scripts usually has .rexx extension.)
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
(Edit: But anyway rexx scripts usually has .rexx extension.)
Not really, most of them have extension depening on what application they came with, for example arexx script that came with ced typically are named .ced.
I have lots of arexx scripts that don't have any extension, they just have +SE protection bits and are located in path. Or in sys:wbstartup, to be launched on startup.
@all I'd like to restate my earlier argument, since I did a damn poor job of explaining myself:
There are a few flags (mainly P & H) that are so rarely used/needed these days (on OS4) that it seems ridiculous to waste a whole flag on them *for every single file you have*. Even in the OS3 days they were usually used wrongly (intentionally or not). It makes much more sense to store their information inside the executable itself.
Even the S flag seems a bit silly, since it is used by so few files (and I say this as a 'script freak'). A file extension would seem to make so much more sense; while I tend to use ".script", it would probably be better to use something shorter like ".dos" or even ".bat". We couldn't actually get rid of the S flag any time soon (due to how often it is still used), but it would be worth starting the job of making it less necessary.
You could even argue that the Execute flag (which AmigaOS4 actually obeys unlike AmigaOS3) is superfluous, since you can check the first few bytes of the header to tell whether it is an executable or not.
@kolla Quote:
Are you saying that I'm not supposed to able to use OS4 the same way I've been using OS3.x?
No. I'm saying you probably don't NEED to use it the same way (in respect of the P flag). In the same way you don't need Workbench to use a 4-colour screenmode to same chip ram....
Quote:
You _really_ have no concept of what its use is for, do you.
Love the condescending attitude, it really helps me warm to your arguments (or lack thereof).
Perhaps you could remind me what the P flag is for (and the H flag while you are at it), since as I said I haven't needed to use them for years (and they were usually used wrongly when I did see them used!).
Quote:
It's not an argument, it's a question
Thats not the way it came across. (Admittedly, upon reading my earlier posts, I did a really poor job of explaining myself too.)
Quote:
do you want to get rid of c:edit also? If yes - why? If not - why not?
AmigaOS4 contains quite a few "obsolete" programs from the OS3.x, OS2.x & maybe even OS1.x days. It would make sense to have them as optional during OS4 installation (for the few users who still somehow have a use for them). At the very least, stuff like Picasso96Mode should be 'hidden' in a folder.
Quote:
Not really, most of them have extension depening on what application they came with, for example arexx script that came with ced typically are named .ced.
Luckily, in those cases, the *application* is the one that is going to run them. So we don't need Workbench to know they are ARexx scripts.
That's the worst thing you can ask. IMHO File extensions are stupid thing from stone age !
I used to think the same way, but they are just such a damn convenient kludge! Sure, they probably shouldn't be REQUIRED, but they can still be very useful in some situations.
Reasons that filetype extentions are so damn convenient, despite being a kludge: 1. The user can immediately see what kind of file it is, no matter how they view files (Workbench, ASL Requester, the DOS Dir command, etc).
2. The user can easily add/change the filetype, should he need to. No need to invoke special options or commands to do so.
3. File extensions are the lowest common denomenator, and transfer between different OSes without any problems.
2. The user can easily add/change the filetype, should he need to. No need to invoke special options or commands to do so.
This is absolute nonsense. I can very easily rename a binary executable to "picture.png", but this will not change the type of the file. It will not be a PNG image from that moment on, even if Windows will try to treat it as such. The contents define the type of a file, not its name. The name is just hint, nothing more, nothing less.
ChrisH wrote: There are a few flags (mainly P & H) that are so rarely used/needed these days (on OS4) that it seems ridiculous to waste a whole flag on them *for every single file you have*. Even in the OS3 days they were usually used wrongly (intentionally or not). It makes much more sense to store their information inside the executable itself.
Really - so you suggest I have to modify the binary executables themselve instead of using filesystem flags? Using what exactly... does OS4 come with a hex editor I can use?
Quote:
Even the S flag seems a bit silly, since it is used by so few files (and I say this as a 'script freak'). A file extension would seem to make so much more sense; while I tend to use ".script", it would probably be better to use something shorter like ".dos" or even ".bat".
From where did you get those gastly silly and nondescriptive endings?
Quote:
We couldn't actually get rid of the S flag any time soon (due to how often it is still used), but it would be worth starting the job of making it less necessary.
You could even argue that the Execute flag (which AmigaOS4 actually obeys unlike AmigaOS3) is superfluous, since you can check the first few bytes of the header to tell whether it is an executable or not.
What do you mean "unlike AmigaOS3"? It works perfectly well in OS3 thank you very much - what broken installation are you referring to?
And so what if you can check what the few first bytes are - that's not the point - the point is that _I_ - THE USER - can decide what files I want to have executable or not. It was just a few weeks ago that someone asked how he could prevent guests from accidently formatting a partition - well, the solution is simply to remove the E flag from the format command - THIS IS EXACTLY WHAT THESE FLAGS ARE FOR!!111oneone
Quote:
@kolla Quote:
Are you saying that I'm not supposed to able to use OS4 the same way I've been using OS3.x?
No. I'm saying you probably don't NEED to use it the same way (in respect of the P flag).
Whywhat? Why would I not need P and H on OS4? Why should I not be able to myself mark reentrant binaries with P, and unmark those that end up not being really pure despite the lame programmer claiming them to be? Why should I not be able to decide that I want certain binaries to automatically become resident when ran the first time?
And why should OS4 be different from MorphOS and OS3 in this respect, even AROS will most likely align with OS3 and MorphOS on these things in a not too distant future, why must OS4 stick out as the oddball, for _no_ sane reason at all?
Quote:
In the same way you don't need Workbench to use a 4-colour screenmode to same chip ram....
This is not even a strawman argument, it's a sillyman argument. And for what it matters - I _do_ need Workbench to use a 4-colour screenmode every now and then, but _not_ to save chip RAM.
Who are you to tell me what I need and not?
Quote:
Quote:
You _really_ have no concept of what its use is for, do you.
Love the condescending attitude, it really helps me warm to your arguments (or lack thereof).
Perhaps you could remind me what the P flag is for (and the H flag while you are at it), since as I said I haven't needed to use them for years (and they were usually used wrongly when I did see them used!).
OK, fair enough:
P - pure - to mark in the filesystem that a binary is pure, reentrant, can be resident in memory and be run multiple times, even simultaniously, from memory, without changing its own structures and thereby crashing. To make a binary resident, you use the command "resident", or you can mark it with the H flag - hold - which makes the binary automatically become resident when run the first time.
Why is it practical to have commands resident?
So you don't have to rely on filesystem access to run the commands. This simplifies alot of things, such as
* quick access to certain commands that are used very often, for example I have rx, list, zshell, assign, execute, setenv, lha, copy, tee, foreach .. and many others that I use quite extensively, resident. Not because I'm worried about slow disk access, but because...
* I avoid the risk of running some flawed version of a common command if I stand in a directory that just happens to have the same command around in it, since resident commands have precedence. It's funny what a malicious "dir" or "list" can do in an lha archive.
* moving system files and assigns around between different devices, including the system assigns, without "loosing" your commands (since they've become resident).
* it becomes easier to create tiny temporary boot systems that can be removed completely after bootup, be it floppy, usb stick, memory card, RAD, or even network device.
And seriously, the one who's to decide whether a command shall have P and H flags is _I_ - THE USER - not some jackass coder who didn't check his code/binaries well enough and added pure bit because he think it's leet.
Quote:
Quote:
It's not an argument, it's a question
Thats not the way it came across. (Admittedly, upon reading my earlier posts, I did a really poor job of explaining myself too.)
Quote:
do you want to get rid of c:edit also? If yes - why? If not - why not?
AmigaOS4 contains quite a few "obsolete" programs from the OS3.x, OS2.x & maybe even OS1.x days. It would make sense to have them as optional during OS4 installation (for the few users who still somehow have a use for them). At the very least, stuff like Picasso96Mode should be 'hidden' in a folder.
So does that mean you want to get rid of c:edit also? If yes - why? If no - why not?
(What, Picasso96Mode? me worry? What does it have to do with anything in this context)
Quote:
Quote:
Not really, most of them have extension depening on what application they came with, for example arexx script that came with ced typically are named .ced.
Luckily, in those cases, the *application* is the one that is going to run them. So we don't need Workbench to know they are ARexx scripts.
First - I typically execute rexx scripts from CLI, allthough I do have some that are I start from Workbench, but with them I use the provided tooltype that tells _Workbench_ that it shall be loaded with RX. And it's not true that all .ced scripts are solely meant to be used from within CED, they are typically used to address CED to do something specific, and they can be launched from just about anywhere. Likewise with scrips from other applications.
This is how we use rexx as glue between applications, I can from CLI, or some other application - for examply WordsWorth - tell CED to paste from clipboard to a new buffer, run a certain filter on the content and save the result, or dumpe it back to paste buffer so that I can paste back into WordsWorth, or whatever.
Of course, since Workbench (at least in 3.9, and Ambient on MorphOS, and DOpus Magellan) also has rexx port, one can control the desktop itself from scripts. And it doesn't matter what the name of those scripts are, that's for THE USER to decide.
And you want to remove my powers over the OS I love, and replace it with some dysfunctional fluffy nonsense to attract (non-existing) new users, making sure everything is as much identical to Windows as possible so that they will feel at home from first second...
Well, I have only one reaction to that - screw you guys... I'm going home.
(Luckily the people who actually write OS4 are not quite as .... dee dee dee ... as some of the vocal zealots in the community, so fat chance any of the wild stuff suggested will be implemented)
1. The user can immediately see what kind of file it is, no matter how they view files (Workbench, ASL Requester, the DOS Dir command, etc).
That's one good reason but only one. But then again, I've been thinking that, why should I bother if the file is jpg or png. Only thing I need to know it's picture and system opens it automaticly with Multiview (or whatever else).
Quote:
2. The user can easily add/change the filetype, should he need to. No need to invoke special options or commands to do so.
tboeckel?answered to that.
Quote:
3. File extensions are the lowest common denomenator, and transfer between different OSes without any problems.
kolla?answered to that.
kolla also answered to comment of use of e flag.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
This is absolute nonsense. I can very easily rename a binary executable to "picture.png", but this will not change the type of the file. It will not be a PNG image from that moment on, even if Windows will try to treat it as such. The contents define the type of a file, not its name. The name is just hint, nothing more, nothing less.
Perhaps you aren't aware that something can sometimes have more than one filetype? For example a script file (say .bat) is also a text file; scripts will usually be executed, but text files will be opened using Notepad.
But my real reason for suggesting this is that if AmigaOS has no clue of the filetype for some reason (*), then you can clarify it using a filetype extension (which is easy to do).
(* = Maybe there is no suitable datatype installed to recognise the filetype, even though he has programs capable of reading that filetype? Maybe the file has the wrong flags set? And in the case of the wrong flags set, it is SO much easier to tell a newbie how to change the filetype extension, versus change some hidden flag he's never seen before.)
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:
For example, it would make SO MUCH MORE SENSE for the "P flag", which indicates that an executable can be made resident, to be stored within the executable itself.
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:
The P flag even seems to be wrongly set on most AmigaOS installations (even clean ones from Commodore).
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:
Quote:
To avoid the protection bit problem when migrating data from a Windows machine on to an Amiga machine, just use appropriate helper programs
I already wrote a program to do this, but that isn't the point.
If your program isnt used, despite of its usefulness, well, then it is the point.
Quote:
Quote:
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.
I guess you never heard of a cross-compiler? e.g. AmiDevCpp.
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:
Or even better, just use the filetype extension. We only miss extensions for AmigaDOS scripts & Amiga executables.
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.
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...
I'm with the others as well, keep the flags for now, instead I suggest expanding them instead, (and maybe renaming some while we are at it)
If I'm not mistaken the flags looks like this:
* H = Hold, commands with P-bit set will automatically become resident on first execution. * S = Script * P = Pure, indicates reentrant commands that can be made resident in RAM. * A = Archive * R = Read a file, link or content of directory. * W = Write to file, link or inside a directory. * E = Execute * D = Delete file, link or directory.
So my humble suggestion would be something like this:
* Perhaps H and P could be merged into one single flag as K = Keep in RAM, will automatically become resident on first execution. * Change H to mean hide (like in Windows), since it's often misunderstood as hide anyway so let it be hide. (If the letter H is already occupied by above, rename to C = as cloak or some other convenient letter). * S = unchanged * A = unchanged * R = unchanged * W = unchanged * E, (or X) = unchanged or rename to X as in execute (like in Linux) to avoid future confusion/misunderstandings. This flag could also indicate setuid/setgid/sticky in future. * D, (or P) = unchanged or P for protect if P above is changed. * I? = Expand with a flag used to mark as indexed or not indexed, or something? To help a future indexing system. * Perhaps expand with a symbolic notation for the file type (as in Unix), where the first letter of the flags indicates the "primitive file type": d for dir/drawer, r for regular file, l for link, p for pipe, s for (perhaps S for script above could be moved here), etc... * Expand with a "quadriple" (R, W, E/X, D/P) for permissions for "future" group members. * Expand with a "quadriple" (R, W, E/X, D/P) for permissions for "future" other/everyone else users. * Oh, and with a field for the owner of the file (in future).
Oops, sorry for this off topic post
Edited by Marko on 2010/11/20 15:59:32 Edited by Marko on 2010/11/20 19:16:17
Expand with a "quadriple" (R, W, E/X, D/P) for permissions for "future" group members. * Expand with a "quadriple" (R, W, E/X, D/P) for permissions for "future" other/everyone else users. * Oh, and with a field for the owner of the file (in future).
As far as I'm aware there was just one application that ever thought of using H as hide, and that was old DirectoryOpus, AFAIK the entire HIDE thing is something GPSoft invented all on their own. For the programs that come with AmigaOS, it doesn't make any sense. Workench by default hides files to which there are no corresponding .info files, neither C:list nor C:dir have any flags to display "hidden" files (and why would anyone want to hide files anyhow?) If a file is "hidden", but its .info is not "hidden", what is workbench supposed to do? Or a file does not have any .info, and is hidden - is workbench then supposed to display it when "show all files", or must there be another level "show all hidden files as well"? To introduce a "hidden" flag opens a can of worms, really - alot of stuff will need to be changed
If anything, I really fail to see what use a hidden flag would have, other than to confuse new and old user alike.
And on second note, I find it slighly strange that noone has attacked the A (archived) flag yet. Is there any software that respects it? And with respect it I mean remove it when file is altered and have backup software add it when file is backed up.
And thirdly, I don't want _all_ programs that are pure to automatically become resident just because they're pure, I want to be able to control that myself, thank you, so please keep the two apart.
Yep, you're right. I have noticed the flags before when I use ls -l but I never thought they were actually implemented to that extent already. Seems the flag with the symbolic notation is there too.
I don't want _all_ programs that are pure to automatically become resident just because they're pure, I want to be able to control that myself, thank you, so please keep the two apart.
Fair enough, let's keep the flags.
Quote:
If anything, I really fail to see what use a hidden flag would have, other than to confuse new and old user alike.
You have a point there... But I myself rarely use the flag (on Windows, dot in Linux), and when I do, I never "hide" the hidden files from being viewed.
But I think the flag can be pretty convenient sometimes f.ex on lots of backup files of the same file etc, on some systems (Filebrowsers on Vista and some Linux distr. I think, but seems not default in Win7) the hidden files appears as ghosted, this can reduce the clutter of files you are not really that interested in but at the same time you can see the files are actually there...
So instead of the hide flag, have a G for Ghosted for convenience when viewing file listings.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
