rosenkra@convex.com (William Rosencranz) (01/12/91)
---
is there any inherent reason why future TOS versions can't be case
sensitive, at least WRT file names (and directories)? i know that
certain (perhaps old) compiler startup code forces upper case in
several places (Fopen in GEMDOS may actually do this, or perhaps
goofy GEMLIB/alcyon). i always found it strange that cpm, msdos,
and tos could not deal with the difference between "a" and "A" in
filenames, and have not been able to figure out a valid/necessary
reason why the PC had taken a step backwards in this respect. i hope
the answer isn't "tradition". and i hope the answer isn't that it
would not fit in 192k...
the next logical question (to atari) is, if no real reason, is this
planned (at least with the TT)?
-bill
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.comkentd@FtCollins.NCR.com (Kent.Dalton) (01/15/91)
>is there any inherent reason why future TOS versions can't be case >sensitive, at least WRT file names (and directories)? i know that Seems to me that it would break a ton of existing code for a relatively small and (debatable) benefit. Not a win, IMHO. Also, Some people LIKE case insensitivity (ever heard of VMS? :^) -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollins.NCR.COM */ /* NCR Microelectronics * CIS: 72320,3306 */ /* 2001 Danfield Ct. MS470A * */ /* Fort Collins, Colorado 80525 * "This mind intentionally left blank" */ /* (303)223-5100 X-319 * All standard disclaimers apply */ /**************************************************************************/
apratt@atari.UUCP (Allan Pratt) (01/15/91)
rosenkra@convex.com (William Rosencranz) writes: >is there any inherent reason why future TOS versions can't be case >sensitive [...?] The quick answer is this: GEMDOS was that way originally because MS-DOS is that way, and GEMDOS is still that way because it was that way originally. There is little hope of a case-sensitive GEMDOS in the near future. If you're desperate, you can look up UNIXMODE from Bammi@cadence.com. I don't know if he has a stand-alone TSR version yet, or if it's still just part of libraries you have to link with to get it. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
silvert@cs.dal.ca (Bill Silvert) (01/15/91)
In article <2807@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >rosenkra@convex.com (William Rosencranz) writes: >>is there any inherent reason why future TOS versions can't be case >>sensitive [...?] > >The quick answer is this: GEMDOS was that way originally because MS-DOS >is that way, and GEMDOS is still that way because it was that way >originally. I suspect that the tradition goes back to CP/M and the use of teletypes. But with CP/M it was easy to change -- there was a masking operation that converted lower case to upper case, and I just changed that to NOP (no-op) and had a full case sensitive cp/m. Interestingly enough, Microsoft BASIC could create lower-case file names which could not then be removed with CP/M commands! With TOS in rom the hack would be harder, but since it is possible to get all kinds of odd characters in file names by various errors, why can't a case-sensitive version of TOS be generated? -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biomel!bill BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.ca
bill@mwca.UUCP (Bill Sheppard) (01/17/91)
Regarding case sensitivity of GEMDOS...
At work I use both OS-9 and Unix. OS-9 is not case sensitive, although
filenames will contain both upper and lower case in directory listings
("SOURCE" == "Source" == "source"). Unix, of course, is case sensitive.
I prefer the OS-9 method (employee bias notwithstanding) because it allows
me to use capitals where organization/convention calls for (directory names
in caps, for example), but still makes it easy to specify filenames. Besides,
I don't think it would be very good procedure to have both the file
"stuff.txt" and "Stuff.txt" in the same directory. Perhaps there would be
an easy patch to TOS to not have filenames converted to uppercase when
written to the directory sector, but still have "open" calls use uppercase
when comparing filenames for matches...
--
################################################################################
# Bill Sheppard -- bills@microware.com -- {uunet,sun}!mcrware!mwca!bill #
# Microware Systems Corporation --- OS-9: Seven generations beyond __/_!! #
#######Opinions expressed are my own, though you'd be wise to adopt them!#######rosenkra@convex.com (William Rosencranz) (01/18/91)
In article <2807@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
[ answered my question, thanx, allan... ]
does UNIXMODE (or should i say UnIxMoDe :-) actually cause things in disk
FATs to be case sensitive? if so, that is something to look into. otherwise,
it probably keeps a conversion table around which is a definite, tho
perhaps robust, kludge. as i recall unixmode supports links, so it is
probably the table variety, which could get hairy with 1000's of files...
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.comgl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (01/18/91)
In article <1991Jan18.005041.22961@convex.com> rosenkra@convex.com (William Rosencranz) writes: >it would probably not break any existing code. if so, how? I wouldn't be surprised if lots of programs force filenames to all upper or lower-case, because it's now legal and it makes them easier to compare. You'd never know until you try, and discover that half the applications that you didn't test don't work anymore. Example: remember all the .TTP programs that didn't work right from the desktop because it uppercases the argument string? I found such a bug in a major ST application installation program that I beta-tested. Yech. Let's encourage Atari to give us something useful, like say one big master-ROM-patch that would be updated frequently and contain all the patches that all versions of the ROMs need.
rosenkra@convex.com (William Rosencranz) (01/19/91)
In article <1991Jan18.021445.4010@murdoch.acc.Virginia.EDU> gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) writes: >In article <1991Jan18.005041.22961@convex.com> rosenkra@convex.com (William Rosencranz) writes: > >>it would probably not break any existing code. if so, how? > >I wouldn't be surprised if lots of programs force filenames to all >upper or lower-case, because it's now legal and it makes them easier yes, but i also mentioned a (new) backward compatibility GEMDOS call (e.g. int Fcase(int on)) which could be called by the deskop (like toggling the blitter) to toggle do it/not do it. if on != 0, the the code to upcase in TOS would be bypassed. if on == 0, then it would be executed. i.e. business as usual. and (well-written) new programs could test the TOS version before making this call, just as they do with the new calls added to the Rainbow TOS. simple (i think...). surely THAT would not cause any existing code to break, at least for this reason. if u happen across a program that does not work, u always have the option of turning off case sensitivity. i believe there were probably codes which broke with the blitter turned on, but u have the option to turn it off in a similar fashion. we are not talking about a major change to TOS here, just a relatively small amount of additional code. but i agree that such a change should not be made if it breaks (important) existing code or just to please me :-). >Let's encourage Atari to give us something useful, like say one >big master-ROM-patch that would be updated frequently and contain all >the patches that all versions of the ROMs need. yes, this is a good idea. it would make it very easy to customize a system, too. -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
depeche@cs.mcgill.ca (Acme Instant Dehydrated Boulder Kit) (01/23/91)
In article <1991Jan18.005041.22961@convex.com> rosenkra@convex.com (William Rosencranz) writes: >In article <KENTD.91Jan14172419@zappa.FtCollins.NCR.com> kentd@FtCollins.NCR.com (Kent.Dalton) writes: >>>is there any inherent reason why future TOS versions can't be case >>>sensitive, at least WRT file names (and directories)? i know that >> >>Seems to me that it would break a ton of existing code for a relatively >>small and (debatable) benefit. Not a win, IMHO. > >who decides what/how much benefit something is? you? i hope not. it IS a >win, and for me, at least, a relatively large benefit. really? ok... why do you think so? >it would probably not break any existing code. if so, how? For one thing, most file selector boxes, and command shells, translate lower case characters into uppercase before processing input lines (sometimes they even echo back uppercase, but sometimes they don't, so you find this out the hard way). Neodesk and PCOMMAND and LGSELECT are three examples I can think of offhand. Another problem is that the people who write programs which have a call like fp=fopen("datafile.in","r"); assume that there is a file on the disk matching this name - but when we suddenlly add case sensitivity to TOS, what happens to the files which are on disk already? will they be considered all caps (so most programs can read them after this conversion to uppercase) or all lower case (so the c programs with lines like above will work)? It is a FACT that if such a convention were added, TONS of programs would need little changes to work again. I happen to use a few programs which are no longer being maintained by the author, and I don't have the sourcecode. What do I do now that I can't run them anymore? > and it is a BIG win, IMHO. don't knock it 'til you've tried it. yeah you said that already. so lets hear why you think so! All you've said is "it's great - everyone who likes unix should love it!". Well, I love unix myself, I don't see the connection. Lets hear some support for your opinions. Why is it so great to have those extra 26 characters? Well, you can have IN THE SAME VERY DIRECTORY files like jove.RC jovE.rC JoVe.Rc JOVE.RC jove.rc big deal. And this is just a half-assed step towards a unix-like filesystem - if you want a real unix filesystem, you gotta throw out all this TOS and MSDOS bullshit and start FROM SCRATCH - we don't need all these tiny little steps which make everything incompatible but look a little more like unix - give me a break! -- |S. Alan Ezust McGill University SoCS depeche@cs.mcgill.ca | |---------------------------------------------------------------------------| | "Lick the carpet, dust the dog, mow the windows, shine the socks.... | | you got to keep things CLEAN." - E. KaSpel |
apratt@atari.UUCP (Allan Pratt) (01/23/91)
neil@cs.hw.ac.uk (Neil Forsyth) writes: >Patches would be posted _regularly_ [...] Huh? Patches come out when we find something that needs patching, not "regularly." The chaos of patches reflects the chaos of finding things that need patching. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
rosenkra@convex.com (William Rosencranz) (01/23/91)
In article <1991Jan22.170111.12465@cs.mcgill.ca> depeche@cs.mcgill.ca (Acme Instant Dehydrated Boulder Kit) writes: >In article <1991Jan18.005041.22961@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>it would probably not break any existing code. if so, how? > >For one thing, most file selector boxes, and command shells, translate >lower case characters into uppercase before processing input lines i don't know about "most" but gulam does not xlate to upper case. it passes things off to exec'd processes with no case conversion. some compiler startup codes and libraries do that, but i don't thing GNU c is one of the, and i even patched good ol' alcyon to stop that foolish practice. in fact no unix shell clone on the st does this now (gulam, bash, msh, etc). PCOMMAND and NEODESK are not unix-like shells. the desktop does, however, force upper case, which is why it is a pain in the *ss to run unix utilites from the desktop, especially ones which have different meanings of "-c" and "-C". all this talk has nothing to do with TOS itself supporting (even toggling this feature on/off) mixed case file names. look, i'd like to have the option of switching case sensitivity on and off at will. i myself see no reason why this cannot be added. i myself like having important files in caps (like README and Makefile) since with a directory list, they appear set aside, and easy to spot (i.e. more productive). pls don't argue that YOU may find it revolting. I do not. and besides, if it is SWITCHABLE, then it does not impact you our any program in the slightest. i have discussed how this can be done in a previous note. all i want to do is find out CAN IT BE DONE and IS ATARI PLANNING ON DOING THIS? which apratt@atari answered. >fp=fopen("datafile.in","r"); i can't see how/why a program has to force case anyway, since TOS does it for you. it IS case insensitive, so DaTaFiLe.In is the same file as datafile.in is the same as DATAFILE.IN is the same as DataFile.In, etc. The only reason programs force upper case is for cosmetic reasons, i.e. for consistency. try it youself: #include <stdio.h> main() { FILE *fp; char buf[256]; fp=fopen("datafile.in","w"); fprintf(fp,"Hello\n"); fclose(fp); fp=fopen("DATAFILE.IN","r"); fscanf(fp,"%s",buf); printf("%s\n",buf); fclose(fp); exit(0); } i bet this will print "Hello". meaning it does not matter AT ALL what case the file name is. both fopens open the same file. i already mentioned that the program can make a call like this to force old, compatible behavior: Fcase(CASE_OFF); BEFORE doing anything, if it must. and i already mentioned that the desktop of TOS x.x which would have this new feature can have an additional menu item for configuration (which would cause Fcase be called if the menu state changes, just like the blitter). FOr those of you who still don't understand this, i offer this hypothetical desktop menu (for those who hate cmd shells): ________________________________________ | Configure | |---------------------| . . . . |---------------------| | X Case sensitivity | |---------------------| . ^ . . | . "X" means it is ENabled... ________________________________________ | Configure | |---------------------| . . . . |---------------------| | Case sensitivity | |---------------------| . ^ . . | . no "X" means it is DISabled... >It is a FACT that if such a convention were added, TONS of programs >would need little changes to work again. I happen to use a few programs see above. it does NOT effect the programs, if implemented this way. and new programs can inquire the state of case sensitivity: state = Fcase (CASE_INQUIRE); or somesuch. here is the example program with this "new" TOS: #include <stdio.h> main() { FILE *fp; char buf[256]; if(Fcase(CASE_INQURE) == CASE_ON) Fcase(CASE_OFF); /* added...*/ fp=fopen("datafile.in","w"); fprintf(fp,"Hello\n"); fclose(fp); fp=fopen("DATAFILE.IN","r"); fscanf(fp,"%s",buf); printf("%s\n",buf); fclose(fp); exit(0); } for existing programs, the if(Fcase(CASE_INQURE) == CASE_ON) Fcase(CASE_OFF); /* added...*/ is done with the desktop menu selection, making it 10000000% compatible with older TOS. how can i make this any clearer? if the effort to do this is 2 manweeks (design, implement, debug, test, document), and it takes 50 bytes of ROM, WHY NOT DO IT????? sheesh! >which are no longer being maintained by the author, and I don't have the >sourcecode. What do I do now that I can't run them anymore? > >> and it is a BIG win, IMHO. don't knock it 'til you've tried it. i prefer seeing files in my directory like this: % ls Makefile bbb.c eee.c nnn.c README ccc.c hhh.c ppp.c aaa.c ddd.c iii.c sss.c over: % ls aaa.c ddd.c iii.c ppp.c bbb.c eee.c makefile readme ccc.c hhh.c nnn.c sss.c since my eye is trained to go to the upper left on a page first, so "important" files should be there (and i keep them there, consciously). Yes, this is unix. but it is equally valid for directories which use icons, or file selector boxes, or whatever. also, it is a pain in the *ss which moving mixed case file names between systems which do have case sensitivity (e.g. unix) and the ST. you always have to convert names. >can have IN THE SAME VERY DIRECTORY files like > >jove.RC >jovE.rC >JoVe.Rc >JOVE.RC >jove.rc not a very good example >And this is just a half-assed step towards a unix-like filesystem - if you >want a real unix filesystem, you gotta throw out all this TOS and MSDOS no one is talking about a unix file system, just something that can't be more trivial to implement, will NOT break any existing code, and certainly can't hurt at all (and can help, at least me...). a unix FS does not make sense (really) on the ST since it is not multitasking. note that ST/MINIX does implement FS, but then again it is not running TOS. all i want is a choice. right now we do not have one... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
fischer-michael@cs.yale.edu (Michael Fischer) (01/24/91)
In article <2811@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >neil@cs.hw.ac.uk (Neil Forsyth) writes: >>Patches would be posted _regularly_ [...] > >Huh? Patches come out when we find something that needs patching, not >"regularly." The chaos of patches reflects the chaos of finding things >that need patching. > >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt Dear Allan, Could you clarify for everyone the state of known bugs in TOS 1.4 and the official patches available to fix them? I am only aware of two official patches from Atari---poolfix3.prg and tos14fix.prg. Unofficially, I have heard of at least six TOS 1.4 "bugs" reported in a German magazine. -- ================================================== | Michael Fischer <fischer-michael@cs.yale.edu> | ==================================================
neil@cs.hw.ac.uk (Neil Forsyth) (01/24/91)
In article <2811@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >neil@cs.hw.ac.uk I wrote: >>Patches would be posted _regularly_ [...] > >Huh? Patches come out when we find something that needs patching, not >"regularly." The chaos of patches reflects the chaos of finding things >that need patching. OK OK! I should have said 'as soon as the problem/bug has been found'. Happy? At least I can reassure myself that you read the posting. Could you elaborate more on what you thought of it and perhaps on how you think you would implement a similar patch scheme. Puleez give it some serious consideration. >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt +----------------------------------------------------------------------------+ ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK "That was never 5 minutes!" ! +----------------------------------------------------------------------------+
ate@cs.ruu.nl (Ate Brink) (01/24/91)
In article <1991Jan23.115630.5846@convex.com> rosenkra@convex.com (William Ros encranz) writes: > >the desktop does, however, force upper case, which is why it is a pain >in the *ss to run unix utilites from the desktop, especially ones which >have different meanings of "-c" and "-C". This depends on the TOS version. With TOS 1.0 I couldn't extract a file from a ZOO archive with the x option when I started ZOO.TTP from the desktop. TOS translated everything to uppercase and the X option is illegal with ZOO. I had to use the -extract option. After I replaced TOS 1.0 with TOS 1.4 I can use the x option. The X option still generates an error message. So TOS 1.4 is case sensitive, it only translates FILENAMES to uppercase. Ate brink (ate@cs.ruu.nl) -- Ate Brink, Dept. of Computer Science, Utrecht University Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-534408 Email: ate@cs.ruu.nl
rosenkra@convex.com (William Rosencranz) (01/25/91)
In article <4723@ruuinf.cs.ruu.nl> ate@cs.ruu.nl (Ate Brink) writes: >This depends on the TOS version. With TOS 1.0 I couldn't extract a file >from a ZOO archive with the x option when I started ZOO.TTP from the desktop. >TOS translated everything to uppercase and the X option is illegal with ZOO. >I had to use the -extract option. >After I replaced TOS 1.0 with TOS 1.4 I can use the x option. The X option >still generates an error message. >So TOS 1.4 is case sensitive, it only translates FILENAMES to uppercase. probably semantics or splitting hairs, but the 1.4 desktop is now case sensitive when dealing with .ttp dialogs, at least. TOS itself (or probably more properly GEMDOS), when dealing with filenames and file operations (notably GEMDOS Fopen/Fcreate/et al), remains case insensitive, forcing file names to upper case. my entire point is that there is no inherent reason to force upper case in GEMDOS, really. the actual bytes representing the file name written to FATs need not be upper case or lower case, but can be any ascii char. i believe it is GEMDOS which defines legal chars in file names. all i was asking for was a way to toggle GEMDOS into expanding this definition of legal chars as to differentiate between upper and lower case letters. and regarding breaking programs, i suspect that since if u pass Fopen a ptr to string "file.nam", on return, the string IS CHANGED (a definite "bug", IMHO, that i've always detested), forcing you to change your idea of the filename, programs have the modifications mentioned when parsing a filename AFTER an Fopen/Fcreate/etc and probably because of this flagrant disregard for sanctity of user data. such parsing may be done to isolate paths, extensions, etc, tho these examples look for non-letters (i.e. ".", ":", and "\"). drive letter seems like the only real reason to worry, or perhaps extensions. so rather than strcmp/strncmp, use stricmp/strincmp (ignore case). and yes, i know these are not in POSIX/ANSI C... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
plinio@turing.seas.ucla.edu (Plinio Barbeito/;093091;allsites) (01/29/91)
In article <1991Jan22.170111.12465@cs.mcgill.ca> depeche@cs.mcgill.ca (Acme Instant Dehydrated Boulder Kit) writes: >In article <1991Jan18.005041.22961@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>In article <KENTD.91Jan14172419@zappa.FtCollins.NCR.com> kentd@FtCollins.NCR.com (Kent.Dalton) writes: >>>>is there any inherent reason why future TOS versions can't be case [sensitive?] [heated argument deleted...] >jove.RC >jovE.rC >JoVe.Rc >JOVE.RC >jove.rc > >big deal. You have a point, and I'll add to it. Case sensitive filenames are slower and more clumsy to type out. Only when you have filename completion in your shell ('a la gulam and unix csh), or a file selector written to show extra characters (read on) does this become moot. However, your next point I DON'T agree with. >And this is just a half-assed step towards a unix-like filesystem - if you >want a real unix filesystem, you gotta throw out all this TOS and MSDOS >bullshit and start FROM SCRATCH - we don't need all these tiny little steps >which make everything incompatible but look a little more like unix - give >me a break! There is a way, using some extra bytes (I forget how many, but enough to be useful) in the directory table which are presently "reserved" (by Atari) for each filename, that could be used to put a few more characters (or other attributes) into the filenames. True, a small step, but it could be made in such a way so that it would be upwardly compatible. It would be up to the disk driver (you'd have to write a new one) to decide how to use the extra information. You could use one or two of the bytes to provide an uppercase/lowercase bitmap for the other characters and the rest as extra filename characters, for example, just use all of them for extra filename characters, or other things (file protection bits, user id, etc...). If you wanted to go whole hog, you could use the extra bytes as a FAT pointer to an invisible, locked (but vanilla TOS) file containing lots more filename information. Or to a place on the disk mapped out so that old TOS treats it like as a bad sector... I argue that you could make it so that it wouldn't necessarily be incompatible with the present 8.3 case-insensitive filename system. You could use such a disk with a normal TOS file system, just that in a directory listing, you wouldn't see the extra attributes, and in a file-file copy, the extra bytes (probably) would not be copied. If any extra bytes are used for extra filename characters (e.g. 16.3 vs 8.3), the filename would be cut off at 8. But IMHO, you would be no worse off than before. About the only problem this is likely to cause is if you are trying to use two files that have the same first 8 characters (and the same 3 char extension) on the old TOS file system. The old TOS disk driver wouldn't be able to tell the difference between them. My guess is it will probably always choose the first of the two (unless you delete it) in the directory table for whatever operation you're doing. About all you'll need to see and use the nice new filenames from within your GEM programs is a new fileselector rewritten to accomodate the larger size of filenames (at least). Some shell programs not hardwired to the 8.3 convention, especially if they were originally ported from Unix, should work w/o modifications. Even the hardwired ones might only need a few trivial changes. There are other programs that do their own filename parsing, but in general these are not the "user-friendly" programs anyway. Atari itself might want to clear up just how "reserved" they presently consider the extra bytes in the directory table. My guess is that they won't be keen on the idea, since they've been going out of their way to go in the other direction (down towards DOS compatibility). plini b -- ----- Like ls * | grep string? How about grep string (ls *) ? plinio@boole.seas.ucla.edu * Boelter Hall 4442 lab: 206-1982
rosenkra@convex.com (William Rosencranz) (01/29/91)
[ boy oh boy. ask a simple question and i get STOMPED LIKE A GRAPE!!! ] In article <1709@lee.SEAS.UCLA.EDU> plinio@turing.seas.ucla.edu (Plinio Barbeito/;093091;allsites) writes: >[heated argument deleted...] > >You have a point, and I'll add to it. Case sensitive filenames are >slower and more clumsy to type out. Only when you have filename completion oh, pu-lease! now you guys are telling me because you are perhaps not a good typist, i should not have the option of using MY OWN shift key. sheesh, why can't u understand the fundamentals of this question: I WANT TO BE ABLE TO TOGGLE THIS BEHAVIOR. it need not affect u one bit. i already outline a reasonable method for implementing it, thought up in a fit of creativity in like one minute. and if i can figure it out, anybody can, though i seem to be a better typist than some :-). believe me, i'd much rather have 256 char file names, but that is infinitely more difficult than what i am talking about here, which just requires REMOVING code from TOS, not implementing a whole new file system. look, do u realize what i am talking about is removing an amount of code that resembles this: for ( ; *ps; ps++) if (islower (*ps)) *ps = toupper ((int) *ps; nothing fancy-shmancy, just that. all i want is a system call and a global internal variable and for these 3 lines to be implemented: /* this code in TOS */ if (global_var_telling_if_we_want_force_upper_case == TRUE) { for ( ; *ps; ps++) if (islower (*ps)) *ps = toupper ((int) *ps; } and have a system call: int Fcase (what) int what; { extern int global_var_telling_if_we_want_force_upper_case; int ret; switch (what) { case INQUIRE: return(global_var_telling_if_we_want_force_upper_case); case SET: ret = global_var_telling_if_we_want_force_upper_case; global_var_telling_if_we_want_force_upper_case=TRUE; return(ret); case UNSET: ret = global_var_telling_if_we_want_force_upper_case; global_var_telling_if_we_want_force_upper_case=FALSE; return(ret); } } now is that too much to ask? how can having an option to either use it or not be worse than not having the option in the first place? that's why your keyboard has a caps lock key. how is owning a ferrari and a 4x4 worse than owning just a 4x4 (or just a ferrari, assuming u can afford both, etc)? ok. lets drop this. it is getting far too silly for me... -bill -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
mjs@hpfcso.HP.COM (Marc Sabatella) (01/30/91)
> oh, pu-lease! now you guys are telling me because you are perhaps not > a good typist, i should not have the option of using MY OWN shift key. > ... > anybody can, though i seem to be a better typist than some :-). > ... > ok. lets drop this. it is getting far too silly for me... This coming from a guy who doesn't even capitalize the first word of his sentences :-? > how can having an option to either use it or not be worse than not having > the option in the first place? that's why your keyboard has a caps lock > key. how is owning a ferrari and a 4x4 worse than owning just a 4x4 (or > just a ferrari, assuming u can afford both, etc)? Well, some applications, upon finding the feature, might insist on using it, and not leaving it up to the user. Someone might write an application that creates internal data files named "foo" and "FoO" and requires them to be distinct. Realistically, this can probably be avoided, but the point is, it is not a given that people will be able turn the feature off just because it is made optional. Using the car example, if all there were in the world were ferrari's, then your boss could not expect you to drive through swamps. If the option to own a 4x4 became available, it is possible that your boss will be require you to drive through a swamp.
rosenkra@convex.com (William Rosencranz) (01/31/91)
In article <7340070@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes: >This coming from a guy who doesn't even capitalize the first word of his >sentences :-? hey, it made e. e. cummings a star :-) >Well, some applications, upon finding the feature, might insist on using it, >and not leaving it up to the user. Someone might write an application that >creates internal data files named "foo" and "FoO" and requires them to be >distinct. No. A well written application will test the tos version and bypass this. a poorly written application will not, but then these are not even guaranteed to run on any os other than what it was developed on (i.e. "undocumented" variables, locations, etc which apratt wisely warns us about). so why even bother keeping the guys who write lousy code in business by buying their products? i am sure DC/Beckmeyer/et al would not be around if they were not careful, and did not write good code. let the market decide. >Realistically, this can probably be avoided, but the point is, it is not a >given that people will be able turn the feature off just because it is made >optional. People WILL be able to turn it on/off. right from the desktop or with a 10 line (trivial) application. the system can be booted with feature disabled. the only thing i can think of which may break is if the state is saved to DESKTOP.INF and u try using the new version .inf on an older tos. this may be analogous to the blitter state. what happens in that case? will tos 1.0 die when reading a tos 1.2 .inf, if the blitter state is saved in the file? it sounds like u think that adding new features to an OS is bad, since new applications which use them will not run on older systems (unless they are well written - see above). so why even bother upgrading an OS? and u can get TOS upgrades (i.e. Rainbow TOS). infact, why even bother getting new equipment 20 years from now? today's software won't run on it in all likelihood. and what about things like MiNT, a really nice piece of work. MiNT applications will not run without MiNT (essentially an OS upgrade). the only difference here is that MiNT does not cost anything. a bona fide TOS upgrade may cost $100, if that. note that i realize that a disk saved with mixed case file names may be impossible to read on an older TOS. in that case, it should be up to the purveyor of the disk to decide how it should be written. if it is commercial s/w, then it is marketing decision. many, many programs do not run on 520s. that does not make them bad programs. it just means that for people to use them, they must have the correct hardware/OS. and people buy (or at least should, in most cases) computers because of the software they want to use. i REALLY don't want to talk about this anymore. i know it is 1) feasible, 2) won't really break anything (at least i have not heard any convincing arguments), so the point is now moot and really up to atari. -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
carter@cat34.cs.wisc.edu (Gregory Carter) (01/31/91)
rosenkra@convex.com (William Rosencranz) excerpt: >No. A well written application will test the tos version and bypass this. >a poorly written application will not, but then these are not even guaranteed >to run on any os other than what it was developed on (i.e. "undocumented" >variables, locations, etc which apratt wisely warns us about). so why >even bother keeping the guys who write lousy code in business by buying >their products? i am sure DC/Beckmeyer/et al would not be around if they ^^^^^^^^^ >were not careful, and did not write good code. let the market decide. I tend to disagree, I have beckmeyer hard disk accelerator and it NOW doesn't work with my brand new Mega STe. I don't even know of one that does, except Atari's really absurd cache program, which doesn't work worth a dam. --Gregory
rosenkra@convex.com (William Rosencranz) (01/31/91)
In article <1991Jan30.232200.5156@daffy.cs.wisc.edu> carter@cat34.cs.wisc.edu (Gregory Carter) writes: >I tend to disagree, I have beckmeyer hard disk accelerator and it NOW >doesn't work with my brand new Mega STe. dave b. is a business man, out to make $$$. i am sure if any s/w he writes does not work on a new model, he will have an upgrade soon after of even before the hardware reaches the street. why don't u call them up and ask about upgrades? and i am sure that if it IS version dependent that i is that way for a very good technical reason: like that is the only way to do it (using undocumented, changable TOS attributes). and it is VERY difficult to predict the future nature of an OS :-). how can u expect any s/w company to write code NOW for systems years away? be reasonable. why do u people think that just because u pay $39 for a piece of s/w, it should work on any computer atari ever makes for the next 10 years? of course you may need to buy upgrade s/w to stay current, especially system-oriented s/w like caches. that's life... the mere fact that DC/beckmeyer/et al are still in business while others have floundered and died means that the buying public accepts their products, and recommends the to their friends. if not, they would be dead. -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
jhenders@jonh.wimsey.bc.ca (John Henders) (01/31/91)
> >I tend to disagree, I have beckmeyer hard disk accelerator and it NOW >doesn't work with my brand new Mega STe. > >I don't even know of one that does, except Atari's really absurd >cache program, which doesn't work worth a dam. > >--Gregory It seems to be bash Atari month. I'd like to know in what way you find Atari's CacheXXX program absurd and non-functional? I recently switched to it after finding the cache built into my ICD booter to be less than optimal. I find Cachexxx to work much better and uses less memory other than cache buffer space. Of course reading the docs explains how to set up a variable data-fat buffer area for real fine tuning. Does it really break on the mega, or have you even tried it? -- John Henders jhenders@jonh.wimsey.bc.ca Vancouver,B.C. or jhenders@wimsey.bc.ca or ubc.cs!van-bc!jonh!jhenders
ekrimen@ecst.csuchico.edu (Ed Krimen) (02/01/91)
rosenkra@convex.com (William Rosencranz) writes: - why do u people think that just because u pay $39 for a piece of - s/w, it should work on any computer atari ever makes for the next 10 - years? Exactly. The same goes for $399 programs for the Mac and MS-DOS machines. Even though you pay much more for them, they can't be guaranteed to work on future machines. (Gee, I finally agree with something William has to say. ;^) -- Ed Krimen ............................................... ||| Video Production Major, California State University, Chico ||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661 / | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0
wolfram@cip-s02.informatik.rwth-aachen.de (Wolfram Roesler) (02/01/91)
mjs@hpfcso.HP.COM (Marc Sabatella) writes: >Well, some applications, upon finding the feature, might insist on using it, >and not leaving it up to the user. Someone might write an application that >creates internal data files named "foo" and "FoO" and requires them to be >distinct. In addition, many programs convert all filenames to lowercase before presenting them to the user (especially command shells)(the Okami Shell leaves the decision whether or not to convert to lowercase to the user). In this case, "foo" and "foO" would turn into the same filename. But do you really plan to use filenames that differ only in their cases? New programs would certainly not rely on filenames being case indepentant in order to stay compatible. So they will certainly not trust in foo and foO being different files. Using files that differ only in their case would be discouraged on an OS with optional case insensitivity anyway because turning the feature off would suddenly make a lot of files have the same name. As for myself, I dont really miss case insensitive filenames, I'd rather see a Unix filename convention that doesnt force filenames to the filename.ext con- vention. How about the difficulty of implementing that? In the disk directory, the filename "foo.bar" is written "foo bar", and programs (like Fsfirst) replace the spaces by a singe dot. If the directory entry was "foo.bar.baz", it should be possible to recognize that this is not a standard TOS filename, so an OS extension should be able to handle filenames in both MSDOS and Unix convention. Back to the case insentivities, there is however one advantage given by filenames being not case sensitive: if you are using a command shell which has, say, an internal command named "test" (it will have if it resembles the Bourne Shell) (guess which Shell does?) and you have a program called test.prg, then typing "test" on the command line will invoke the internal command, so you have to run test.prg by typing c:/bin/test.prg or something if filenames are case sensitive, but if they are not, you can simply type "Test" to invoke the external command (which is I suppose a lot easier to type even for people who do not like to use the shift key.)
carter@cat34.cs.wisc.edu (Gregory Carter) (02/02/91)
Well, EXCUSE ME Johnny boy! Fact is GUY, I just got a Mega STe, and CACHEnnn makes exactly ZIPPO performance difference in my hard drive. I hardly see that as Atari bashing, and I don't have any hard disk cache program for it, which I could really use. I didn't make ANY comment on HOW the software was written EXCEPT that for ME its USELESS on my machine. WHICH IT IS. What the hell does that have to do with me liking Atari or not? YOU IDIOT! --Gregory