DOS question...
The Mosquito ScriptKiddiot
is there any command in DOS that can make changes to all the filenames in a
directory? i have a directory, and many of the filenames in it contain
underscores...for example,
one_two_three.mp3
what can i enter in so that ALL such filenames that have underscores should be
renamed so that the underscores are replaced by spaces?
thanks
--You've been here too long. Get this stuff right.
Ross Simpson
message...
> is there any command in DOS that can make changes to all the
filenames in a
> directory? i have a directory, and many of the filenames in it
contain
> underscores...for example,
>
> one_two_three.mp3
>
> what can i enter in so that ALL such filenames that have underscores
should be
> renamed so that the underscores are replaced by spaces?
Hey!
If your using native DOS you shouldn't really have spaces in your
filenames (it's a big no, no) or in any DOS mode situtation.
Judging by the filename you've got there though, it looks like your
using DOS under Windoze. You might be able to get away with doing like
this ren "*_*_*.mp3" "* * *.mp3", but I advise against it.
It's more approate to keep filenames to 8 characters plus the 4
character extension (since in native DOS it know nothing about
extended filenames).
Regards,
Ross.
The Mosquito ScriptKiddiot
filenames conform to the 8.3 format...
Ross Simpson
message...
>
can make the
> filenames conform to the 8.3 format...
Well I guess the people who use CP/M or native DOS wouldn't want to
hear about that problem because that's how it used to be (like it or
lump it!).
Being a Windozer 95er myself I have to put up with the rubbish from a
program when it doesn't support a filename & in some cases selecting
'all files *.*' such as in the horrid program notzpad means that it
stamps a '.txt' on top of an existing filename & extension I wanted it
to do.
In the case in DOS once I file has been created using notzpad in DOS
it looks like this 'myfile~1.txt' and in the far right hand corner
(after the date & stuff) lies the full name which is supported though
Windoze which might look like this 'myfile.asm.txt' which is shocking.
To change it to conform with the 8.3 standard (the standard which
works under a DOS box under Windoze) & Native DOS (which means your
doing someone with an older computer with older version of DOS) you
could easily change it like this: "ren myfile~1.txt myfile.asm"
There's nothing worse than download a free game (from Game Hippo or
something simular) which claims to be a DOS game, but once you
download it the file is full of all this extended filename rubbish, it
is at that point where there is no chance that game would work under
native DOS (take that simple problem into consideration & you'll make
more people happy!).
BTW, if your looking for a half decent $harewarez editor (which allows
you to add filename extensions, merely text files which have different
extensions & can view DOS text files with the extended characters &
all) I suggest you look for a program called 'Textpad' (only problem
is the price, but if you don't intend on writing your masterpiece on
it then I suppose it's as good as 'free!' just ignore the loverly
message when it starts up!).
Regards,
Ross.
Frank Kotler
> one_two_three.mp3
>
> what can i enter in so that ALL such filenames that have underscores should be
> renamed so that the underscores are replaced by spaces?
Ross' suggestion of "ren *_*_*.mp3 * * *.mp3" *might* work (I kinda
doubt it), or you might ask Ralf about int 21h/43FFh or int 21h/7156h. I
agree with Ross that this would be an extremely bad idea. The space is
used as a "separator" - e.g., I think that "ren" command above isn't
going to work, as it's going to see "ren *_*_*.mp3 *", and take
everything else as "too many parameters".
Why do you want to do this? Just don't like typing underscores? I agree
that underscores are pretty ugly, but allowing spaces in filenames is
about the *worst* idea MS has ever come up with, IMO (and that's saying
something!). Would you settle for "OneTwoThree.mp3"? "CamelCaps" are
pretty ugly, too, but I really think that using spaces in filenames,
even tho it's allowed, is going to cause you no end of hassles in
anything *but* a "pointee-clickee" environment.
When I first started "computing", I would've given my right arm for a
few extra characters in a filename, but I soon learned to cope. That's
why God gave us subdirectories! "progra~1\mymp3s\one\two\three.mp3"...
If you're gonna try this, at least work on a copy of the subdirectory
until you're sure it works and it's really what you want to do.
Best,
Frank
The Mosquito ScriptKiddiot
Herbert Kleebauer
The Mosquito ScriptKiddiot wrote:
> is there any command in DOS that can make changes to all the filenames in a
> directory? i have a directory, and many of the filenames in it contain
> underscores...for example,
>
> one_two_three.mp3
>
> what can i enter in so that ALL such filenames that have underscores should be
> renamed so that the underscores are replaced by spaces?
In NT/Win2000 you can use FOR /F. But because you asked in alt.lang.asm,
here is an assembler solution which also works in Win9x:
@echo off
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>rena.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>rena.com
echo AL}AstHmqH~w?@xALZp{wq`CttGD{CIAisIssL{OwEJS[{gOH1tlZjt~aC>>rena.com
echo FB~E_cHAG?gtlFDJeHAEzAsFwOBBJSGz@MsqAsBCjr@FIEq@{SY{EOKAv@>>rena.com
echo DG_Gs?G[?sUWzyHm??@_td=O`LEKs[ql`L?LFUq\uvx[lHxq@CNgCF~NEI>>rena.com
echo LONnH]aDEBjlp{_1cEmdqTma_O0>>rena.com
dir /b|rena.com >_.bat
del rena.com
:: call _.bat
:: del _.bat
The source code:
; replace any inputline from stdin by:
; ren "inputline" "newname"
; newname = string after last \ converted to lower case
; replace: _ -> space
; usage: dir /b/s/a-d | rena >r.bat
@=$100
_40: move.w #buf,r5
move.w r5,r4
_20:
move.b #$3f,m0
move.w r5,r1
move.w #1,r2
eor.w r3,r3
trap #$21
bcs.b _100
dec.w r0
bne.b _100
move.b (r5.w),r0
cmp.b #$0a,r0
beq.b _20
cmp.b #$0d,r0
beq.b _10
inc.w r5
bmi.b _100
cmp.b #'\',r0
bne.b _20
move.w r5,r4
br.b _20
_10: move.w #' "',(r5.w)
inc.w r5
move.w #buf0,r6
_30: or.w r4,r4
bne.b _95
move.l (r6.w),r0
move.w #tab,r3
_80: cmp.b r0,(r3.w)
beq.b _70
inc.w r3
inc.w r3
cmp.w #tab_end,r3
blo.b _80
br.b _90
_100: rts.w
_70: move.b 1.b(r3.w),r0
_90: cmp.b #'A',r0
blo.b _50
cmp.b #'Z',r0
bhi.b _50
or.b #$20,r0
_50: move.b r0,(r6.w)
or.b r0,r0
beq.b _60
_95: move.b #$40,m0
move.w r6,r1
move.w #1,r3
cmp.b #'%',(r6.w)
bne.b _61
trap #$21
bcs.b _100
move.b #$40,m0
_61: trap #$21
bcs.b _100
_60: inc.w r6
cmp.w r5,r6
bls.b _30
or.w r4,r4
beq.w _40
move.w #$0a0d,(r5.w)
inc.w r5
move.w r4,r6
dec.w r6
move.b #'"',(r6.w)
eor.w r4,r4
br.b _30
tab: dc.b '_' , ' ' ; replace space by _
; dc.b '-' , '_' ; replace - by _
; dc.b '(' , 0 ; delete (
; dc.b ')' , 0 ; delete )
tab_end:
buf0: dc.b 'ren "'
buf:
R.Wieser
Herbert Kleebauer <kl...@unibwm.de> schreef in berichtnieuws
3CFFB535...@unibwm.de...
[Snip]
> In NT/Win2000 you can use FOR /F. But because you asked in alt.lang.asm,
> here is an assembler solution which also works in Win9x:
>
> @echo off
Can you tell me what program you've used to ASCII-Fy the program-code ?
Regards,
Rudy Wieser
J Yazel
> =============================
The above suggestion works in Win98.
I made two files with the names:
xx_xx_xx and yy_yy_yy
Then I issued the command: ren "??_??_??" "?? ?? ??"
The result was:
xx xx xx and yy yy yy
Jack
Herbert Kleebauer
> > @echo off
> > echo Bj@jzh`0X-`/PPPPPPa(DE ...... =>rena.com
>
> Can you tell me what program you've used to ASCII-Fy the program-code ?
I use the batch file below. There is a similar program written by
laura fairhead:
>> Assemble .COM file using MASM6+ and convert .COM file
>> to ascii-code using my CM3 utility ( http://lf.8k.com/TOOLS/TOOLS.HTM )
-------------------------------------------------------------------------
rem - save the lines below as CONVERT.BAT
rem - write a COM program and assemble it with ORG=0x178 (PROG.COM)
rem (you must not use the standard ORG=0x100 for this com programs!!!!)
rem - enter: CONVERT PROG.COM PROG.BAT
rem - the BATCH file PROG.BAT contains an encoded form of PROG.COM
@echo off
echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>bat.com
echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>bat.com
echo ??wQ@tyM?WxI?@zA=`Lbw?y_y~?_xA[bz?B_L??oAN`_H?e?as?Fx?pkz?>>bat.com
echo B_}A[aIA]b@MCs?A_rVAgr?\gBGpangV_~r?TO?wGJLy?hKxAG@z?G`L?K>>bat.com
echo K?wQO`LRaRPdwA_by??cxA_bL?@O=Et`x?y_z?P_L?@oXZ`SdBW\ngbTiA>>bat.com
echo _Syi?To_gD_lWPOOnSOOOTg`ODgDCDgLCDgNCDggCDgrKDgtKDgWKDYdKT>>bat.com
echo \QQTDDDTQXTTCqWP}=w@s`aTnbmSILl@gbdTo_n@EwCTokO@mwWDOosPW=>>bat.com
echo kOrFsTnsAP~c?@xHOTV_TPoWvDTvFTV_XPnzuPWAuTuFqSwDoStHFTusgD>>bat.com
echo a}}Oms`DlnbTdILOngbT}o_?`a}SbmsPLlnD??I??~?OBA@TEDCTHGFTKJ>>bat.com
echo ITNMLTQPOTTSRTWVUTZYXTp\[D`_1TcbaTfedTihgTlkjTonmTrqpTutsT>>bat.com
echo xwvT=zyD?}=D????}}??s`aTnbmSILl@gbdTg_nP0>>bat.com
bat.com <%1 >%2
del bat.com
-------------------------------------------------------------------------
The source code for this program:
; dieses Programm convertiert com-Programme die mit ORG=0x178 uebersetzt
; sind in ein bat-Programme
;
; Aufruf: com2bat <infile >outfile
; V0.01 : ohne die Zeichen < > | %
; V0.02 12.4.99 : zusaetzlich fuer NT ohne die Zeichen ^ & "
; V0.03 20.5.02 : zusaetzlich fuer W2000 ohne !
zeilenlaenge=58
@=$100
move.w #$4000,r0
move.w #head,r1
move.w #head_l,r2
move.w #1,r3
trap #$21
move.w #zeilenlaenge,r4
_20: move.w #$3f00,r0
move.w #ibuf,r1
move.w #3,r2
move.w #0,r3
trap #$21
bcs.w _100
or.w r0,r0
beq.b _100
eor.w r0,r0
move.w #3,r2
move.w #tab,r3
move.w #ibuf+2,r5
_10:
move.b (r5.w),r0
dec.w r5
lsl.w #2,r0
lsr.b #2,r0
move.b (r3.w,r0.b),r0
bsr.w out_byte
dbf.w r2,_10
move.b m0,r0
move.b (r3.w,r0.b),r0
bsr.w out_byte
bcc.b _20
_100: move.w #$4000,r0
move.w #tail,r1
move.w #tail_l,r2
move.w #1,r3
trap #$21
move.w #$4c00,r0
trap #$21
out_byte:
move.w r0,-(sp)
move.w r2,-(sp)
move.w r3,-(sp)
move.b r0,obuf
move.w #$4000,r0
move.w #obuf,r1
move.w #1,r2
dec.w r4
bne.b _30
move.w #zeilenlaenge,r4
move.w #obuf_l,r2
_30: move.w #1,r3
trap #$21
move.w (sp)+,r3
move.w (sp)+,r2
move.w (sp)+,r0
rts.w
head:
dc.b 'echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls'
dc.b '(Lu(LX(LeZRR]EEEUYRX2Dx=>bat.com',13,10
dc.b 'echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0'
dc.b 'GwUY Wv;ovBX2Gv0ExGIuht6>>bat.com',13,10
dc.b 'echo '
head_l=@-head
tail: dc.b '0>>bat.com',13,10
tail_l=@-tail
even4
tab: dc.b '?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]1'
dc.b '_`abcdefghijklmnopqrstuvwxyz{=}~'
ibuf: dc.l 0
obuf: dc.b 0,'>>bat.com',13,10,'echo '
obuf_l=@-obuf
-------------------------------------------------------------------------
The source of the decoder header:
; Dieser Code sind die Headerzeilen fuer ASCII-com-Programme fuer batch Dateien
; V0.01 : ohne die Zeichen < > | %
; V0.02 12.4.99 : zusaetzlich fuer NT ohne die Zeichen ^ & "
; V0.03 20.5.02 : Zusaetzlich fuer W2000 ohne !
@=$100
inc.w r1 ; Fuellbyte
moveq.w #$40,-(sp)
moveq.w #$7a,-(sp)
move.w #$3060,-(sp)
move.w (sp)+,r0
sub.w #$3060-$100,r0 ; r0=$100
move.w r0,-(sp)
move.w r0,-(sp)
move.w r0,-(sp)
move.w r0,-(sp)
move.w r0,-(sp)
move.w r0,-(sp)
movem.w (sp)+,r0-r7 ; r0=$40, r2=$7a, r1=r3=r4=r5=r6=$100
sub.b r0,_b1+1-$100.b(r5.w)
sub.b r0,_b2+1-$100.b(r5.w)
sub.b r0,_b3+1-$100.b(r5.w)
sub.b r0,_d1+3-$100.b(r5.w)
sub.b r2,_c1+1-$100.b(r5.w)
sub.b r2,_c2+1-$100.b(r5.w)
sub.b r2,_c3+1-$100.b(r5.w)
sub.b r2,_d1 -$100.b(r5.w)
move.w (sp)+,r1
move.w r1,-(sp) ; r1=0
move.w r1,-(sp)
move.w (sp)+,r4
inc.w r4
inc.w r4
inc.w r4 ; r4=3
_20: move.w r4,-(sp)
move.w (sp)+,r2 ; r2=3
_30: move.w r1,-(sp)
move.w (sp)+,r0
eor.b buf-$100.b(r5.w),r0 ; r0 = nextch
cmp.w #$0a0d,r0 ; crlf
eor.b r0,buf-$100.b(r5.w) ; clear buf
inc.w r5
move.w r0,-(sp)
sub.b #'0',r0 ; < '0'
move.w (sp)+,r0
_b1: bmi.b _30+$40 ; ja, dann ignorieren
beq.b buf ; =, dann fertig
move.w r0,-(sp)
sub.b #'=',r0 ; < '='
move.w (sp)+,r0
_b2: beq.b _10+$40 ; =, dann nicht veraendern
_b3: bcc.b _11+$40 ; > '=', dann um 1 erhoehen
eor.b #'o',r0 ; 1 wird zu ^
_11: inc.w r0 ; um 1 erhoehen
and.b #$3f,r0 ; nur 6 Bit
_10: move.w r0,-(sp) ; auf stack ablegen
dec.w r2 ; schon 4 mal durchlaufen
_c3: bpl.b _30+$7a ; nein, dann zurueck
; and.w r1,tmp-$100.b(r3.w) ; 20.5.02 ersetzt, da !
and.b r1,tmp+1-$100.b(r3.w)
move.w (sp)+,r0
eor.b r0,tmp+1-$100.b(r3.w)
move.w r4,-(sp)
move.w (sp)+,r2
_50: and.b r1,tmp-$100.b(r3.w)
_d1: dc.b $c1+$7a-$100,$6f,tmp-$100,$02+$40 ; lsr.w #2,tmp-$100.b(r3.w)
move.w (sp)+,r0
eor.b tmp-$100.b(r3.w),r0
eor.b r0,buf-$100.b(r6.w)
inc.w r6
dec.w r2
_c1: bne.b _50+$7a
_c2: beq.b _20+$7a
tmp: dc.b 13,10
buf:
Tim Robinson
| Why do you want to do this? Just don't like typing underscores? I
| agree that underscores are pretty ugly, but allowing spaces in
| filenames is about the *worst* idea MS has ever come up with, IMO
Why?
1) It wasn't Microsoft who came up with the idea
2) In a GUI environment it doesn't make sense to disallow spaces -- it
allows you to give your files proper names
3) If you do need to use files on the command line whose names have spaces,
enclose them in quotes. NT CMD.EXE will do this automatically if you type
the first part of the name and press Tab.
--
Tim Robinson
http://www.themoebius.org.uk/
Ross Simpson
> Frank Kotler <fbko...@attbi.com> wrote:
> | Why do you want to do this? Just don't like typing underscores? I
> | agree that underscores are pretty ugly, but allowing spaces in
> | filenames is about the *worst* idea MS has ever come up with, IMO
>
> Why?
You may want to check the answer I wrote earlier. (If you want to
increase the chances of making something work on all machines....)
Native DOS was never designed to have spaces in a filename, IMO.
> 1) It wasn't Microsoft who came up with the idea
> 2) In a GUI environment it doesn't make sense to disallow spaces --
it
> allows you to give your files proper names
> 3) If you do need to use files on the command line whose names have
spaces,
> enclose them in quotes. NT CMD.EXE will do this automatically if you
type
> the first part of the name and press Tab.
Sure it was probably the Mac's which probably first implemented that
idea, but the more ideas they want to copy from a Mac the worse an IBM
becomes.
As you happily mentioned you can use the quotes in between the
filename in a DOS box under Windoze, but some people (like me) are
unhappy about using a DOS box as it's still too slow (for games &
maybe other stuff), so we use native DOS, which as I'll go back to
know's nothing about extended filenames & filenames with spaces in.
Regards,
Ross.
Daniel Camp
> inc.w r5
> move.w r4,r6
> dec.w r6
> move.b #'"',(r6.w)
> eor.w r4,r4
> br.b _30
>
> tab: dc.b '_' , ' ' ; replace space by _
> ; dc.b '-' , '_' ; replace - by _
> ; dc.b '(' , 0 ; delete (
> ; dc.b ')' , 0 ; delete )
> tab_end:
>
> buf0: dc.b 'ren "'
> buf:
Hi, I'm fairly novice when it comes to assembly, and I
don't recognize this syntax... could you please tell me
what assembler you use?
Thankyou very much :)
end
Campster, the chinese whisperer
daniel <Mot> camp <CatSatOnTheMat> btopenworld <Mot> com
mailto:%64%61%6E%69%65%6C%2E%63%61%6D%70%40%74%6F%74%61%6C%69%73%65%2E%63%6F%2E%75%6B
dead_c...@deadspam.com harmless fun? I think not
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.368 / Virus Database: 204 - Release Date: 30/05/02
The Mosquito ScriptKiddiot
windows...for example..
02-syntone-cant_believe_it__original_mix-vinyl-pow.mp3
04-Paul_Oakenfold-Live_Radio_538_(05-18-2002).mp3
and so on...i was thinking of writing the progee myself, but i've found the
perfect program (freeware) that does this and much more...mostly for those who
have tons of mp3s.
thanks
Herbert Kleebauer
>
> "Herbert Kleebauer" ...
> > inc.w r5
> > move.w r4,r6
> > dec.w r6
> > move.b #'"',(r6.w)
> > eor.w r4,r4
> > br.b _30
> >
> > tab: dc.b '_' , ' ' ; replace space by _
> > ; dc.b '-' , '_' ; replace - by _
> > ; dc.b '(' , 0 ; delete (
> > ; dc.b ')' , 0 ; delete )
> > tab_end:
> >
> > buf0: dc.b 'ren "'
> > buf:
>
> Hi, I'm fairly novice when it comes to assembly, and I
> don't recognize this syntax... could you please tell me
> what assembler you use?
I don't like the Intel syntax, so I use Motorola 68000
syntax. But it is a very simple assembler (only 486
instructions without floating point instructions), which
can only generate com files:
R.Wieser
Hello Herbert,
> "R.Wieser" wrote:
>
> > > @echo off
> > > echo Bj@jzh`0X-`/PPPPPPa(DE ...... =>rena.com
> >
> > Can you tell me what program you've used to ASCII-Fy the program-code ?
>
> I use the batch file below. There is a similar program written by
> laura fairhead:
[Snip]
Thank you very much.
Regards,
Rudy Wieser
Tim Robinson
| As you happily mentioned you can use the quotes in between the
| filename in a DOS box under Windoze, but some people (like me) are
| unhappy about using a DOS box as it's still too slow (for games &
| maybe other stuff), so we use native DOS, which as I'll go back to
| know's nothing about extended filenames & filenames with spaces in.
Hmm, fair enough, from the point of view of a mixed DOS and Windows user.
But IMO there's no reason why Windows (e.g. NT running on NTFS) shouldn't
allow spaces. I guess this comes down to the old GUI vs. command line
argument. :)
TS
>windows...for example..
If I remember correctly, the name can´t be of any length. At least the
header file describing the Win32FindData-Structure uses a fixed-length
field for the file name supporting 260 characters, the value of the
MAX_PATH field. Maybe this only applies to ANSI, but not to Unicode
functions.
Tim Robinson
It's possible to have files with names of up to 32,000 Unicode characters by
prepending \\?\ onto the path name. However, I think it's then limited by
the file system (although I don't think FAT LFN or NTFS limit file name
lengths).
The Mosquito ScriptKiddiot
>header file describing the Win32FindData-Structure uses a fixed-length
>field for the file name supporting 260 characters, the value of the
>MAX_PATH field. Maybe this only applies to ANSI, but not to Unicode
>functions.
yeah, i knew sum1 would point that out ;p
what i meant is that the file names wouldn't all be 3_3_3.mp3, (where the "3"
means any 3 characters)...
Ross Simpson
> Hmm, fair enough, from the point of view of a mixed DOS and Windows
user.
> But IMO there's no reason why Windows (e.g. NT running on NTFS)
shouldn't
> allow spaces. I guess this comes down to the old GUI vs. command
line
> argument. :)
If someone was writing a TRUE Windoze program, then yes I'd have no
problems with them putting spaces in their filenames (because your
taking full advantage of the filename support system).
However, if you were dealing with files which can used in either DOS
or Windoze, then I'd say stick with the 8.3 filename routine, because
it might limit someone (in Native DOS, or someone who doesn't use
Windoze) to playing that file.
The issue is that if you were planning to upload a file somewhere
(such as a text file) which has spaces in it & someone downloads it to
view in DOS I don't know how DOS would treat those spaces in the
filename, particularly in native DOS!
But it's even worse when someone in another case writes a DOS game &
it's being done in a DOS box under Windoze with the extra long
filenames. In that event if the main program wants to load some other
file, if that filename is an extended filename (above the 8.3 routine)
that means the game is useless to someone in native DOS.
Regards,
Ross.
Frank Kotler
>
> Frank Kotler <fbko...@attbi.com> wrote:
> | ..., but allowing spaces in
> | filenames is about the *worst* idea MS has ever come up with, IMO
>
> Why?
'Cause I didn't know the trick with the quotes.
> 1) It wasn't Microsoft who came up with the idea
Okay. Did they come up with *any* ideas?
> 2) In a GUI environment it doesn't make sense to disallow spaces -- it
> allows you to give your files proper names
I guess most people don't mind being trapped in a cartoon interface.
Some of us like to be able to be more flexible. Any OS, living or
dead...
> 3) If you do need to use files on the command line whose names have spaces,
> enclose them in quotes. NT CMD.EXE will do this automatically if you type
> the first part of the name and press Tab.
Good tip! Thanks. And file name completion in NT, huh? What will they
think of next? :) (I still can't get "ren" to work with the wildcards).
I notice that the "short form" of the name catches a bit more of the
original if it's got spaces, rather than underscores, so that's
something in it's favor. "name_too_long" -> "name_t~1", "name too
long"-> "nameto~1"...
I'll retract it, then. Spaces in filenames *isn't* the worst idea MS has
ever come up with... okay, "borrowed"... :)
So what *was* their worst idea? DoubleSpace?
Best,
Frank
Tim Robinson
| So what *was* their worst idea? DoubleSpace?
Abandoning OS/2, in my opinion.
Ross Simpson
>
> Abandoning OS/2, in my opinion.
I reckon them abandoning OS/2 was pretty good. At least the OS is
stable enough to run properly.
Okay, so it wasn't successful compared to Windoze (at the time), but
if they did continue the project then OS/2 might of turned into the
piece of buggy code that Windoze is today!
The second problem (which guarantee Windozes success) was it required
less resources, OS/2 is a large OS & requires more memory as well the
right kind of memory to perform properly.
And unless you were really ambitious installing software for OS/2 (by
writing your own large scripts) that might of turn a few people to
Windoze.
But apart from that I thought it was quite a good OS, just tad big for
my purpose! :-)
So the way I see it, if Windoze was abandoned (which it wasn't), OS/2
would be buggy, however because M$ abandoned the project it was for
the better, except that there is still piles of rubbish created today,
which need faster CPU's & Larger Hard Drives as a consequence, so
either way is bad.
But at least OS/2 still works well! :-)
Regards,
Ross.
Tim Robinson
|| Abandoning OS/2, in my opinion.
|
| I reckon them abandoning OS/2 was pretty good. At least the OS is
| stable enough to run properly.
|
| Okay, so it wasn't successful compared to Windoze (at the time), but
| if they did continue the project then OS/2 might of turned into the
| piece of buggy code that Windoze is today!
I disagree; Small Windows (3.1, Win9x) is buggy because of the layers and
layers of code that have built up to support running 32-bit multitaking on a
1970s-era OS (MS-DOS). OS/2 was closer to NT than to Windows.
| The second problem (which guarantee Windozes success) was it required
| less resources, OS/2 is a large OS & requires more memory as well the
| right kind of memory to perform properly.
Better: OS/2 was a large OS which needed more memory. I agree, Windows was
better for the small home machines of the time.
| And unless you were really ambitious installing software for OS/2 (by
| writing your own large scripts) that might of turn a few people to
| Windoze.
?
Are you comparing installing of Windows software now with installing of OS/2
software in 1990?
| So the way I see it, if Windoze was abandoned (which it wasn't), OS/2
| would be buggy, however because M$ abandoned the project it was for
| the better, except that there is still piles of rubbish created today,
| which need faster CPU's & Larger Hard Drives as a consequence, so
| either way is bad.
Microsoft authorship doesn't make software buggy; it's the backwards
compatibility which DOS users demanded in the early 1990s which used to (and
still does) let Small Windows down. In any case, IBM designed most of
OS/2...
anon...@bogus_address.con
On 2002-06-08 fbko...@attbi.com (Frank Kotler) said:
> > 1) It wasn't Microsoft who came up with the idea
>
>Okay. Did they come up with *any* ideas?
Sure: building a mega-billion-dollar empire entirely on
pilfered and purloined technology.
>So what *was* their worst idea? DoubleSpace?
Nah. Mikro$loth stole that from Stakk Technologies.
The concept of 'file handles' has to rate right up there
among the Top 10 Worst Ideas.
But then, M$ only did that in an attempt to: 1) distance
itself from its filched CP/M roots, and 2) help insure
that code written for an M$ O.S. was less easily portable
to any competing O.S.
The ultimate irony is that present-day WinDoze has become
a microcosmic rendering of Mikro$loth itself: huge, bloated,
sluggish, layer upon layer of inefficient heirarchy and
bureaucracy, and ultimately unmanageable.
The Peter Principle prevails; M$ has risen to its level of
incompetence.
"...[Mikro$loth] is like a beautiful wild girl on heroin
who doesn't believe she's dying -- even when you show her
the marks."
- variation of S. E. Hinton
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ross Simpson
> I disagree; Small Windows (3.1, Win9x) is buggy because of the
layers and
> layers of code that have built up to support running 32-bit
multitaking on a
> 1970s-era OS (MS-DOS). OS/2 was closer to NT than to Windows.
Yes, I believe that is one of Windozers problems, but if M$ did stick
with IBM on the OS/2 project who knows what sort of code they might of
put into it, bit's of DOS, early Windoze which might of come from some
other code, et cetra.
> | The second problem (which guarantee Windozes success) was it
required
> | less resources, OS/2 is a large OS & requires more memory as well
the
> | right kind of memory to perform properly.
>
> Better: OS/2 was a large OS which needed more memory. I agree,
Windows was
> better for the small home machines of the time.
Which helped guarantee the success of it!
> | And unless you were really ambitious installing software for OS/2
(by
> | writing your own large scripts) that might of turn a few people to
> | Windoze.
>
> ?
>
> Are you comparing installing of Windows software now with installing
of OS/2
> software in 1990?
No actually, I was comparing OS/2 Warp software to installing Win3.1!
Of course OS/2 Warp had the Rexx script language (some needed to be
approately altered to install the program into the system) which were
like batch files (under DOS) only larger & more complex, I thought
they were great fun to work out, even when it came to installing the
software & getting it to work was like a game of getting it all to
work!
One good idea I found was there was a program written for OS/2 which
handled automatically installing the programs.
> Microsoft authorship doesn't make software buggy; it's the backwards
> compatibility which DOS users demanded in the early 1990s which used
to (and
> still does) let Small Windows down. In any case, IBM designed most
of
> OS/2...
...Which I thought was for the better! :-)
Incidentally while I was using OS/2 Warp for that short time I had it
setup so it was running the Win3.1 programs though it & occasionally
when it did fail I was so glad that I could get back to OS/2 (probably
my favourite feature of it!)
Regards,
Ross.
Beth
> Tim Robinson wrote:
> > Frankie say:
> > | Why do you want to do this? Just don't like typing underscores?
I
> > | agree that underscores are pretty ugly, but allowing spaces in
> > | filenames is about the *worst* idea MS has ever come up with,
IMO
> >
> > Why?
>
> You may want to check the answer I wrote earlier. (If you want to
> increase the chances of making something work on all machines....)
>
> Native DOS was never designed to have spaces in a filename, IMO.
Correct; But the question then arises: Is that DOS's fault or every
other OS?
> > 1) It wasn't Microsoft who came up with the idea
> > 2) In a GUI environment it doesn't make sense to disallow
spaces --
> > it allows you to give your files proper names
> > 3) If you do need to use files on the command line whose names
have
> > spaces, enclose them in quotes. NT CMD.EXE will do this
automatically
> > if you type the first part of the name and press Tab.
>
> Sure it was probably the Mac's which probably first implemented that
> idea, but the more ideas they want to copy from a Mac the worse an
IBM
> becomes.
Well, when I used to have a Commodore 64, filenames were also
permitted to have spaces in them (because you always quoted
filenames)...a BASIC interpreter I had for the Atari ST similarly put
filenames in quotation marks and allowed spaces...the BBC Micro also
allowed the same thing, as did an Acorn Archimedes, I used at
school...I never owned a Spectrum but it also used the idea of
quoting filenames as well, so it probably allowed many characters used
for other things into filenames...the Apple Mac did also permit spaces
with no problems...
In fact, the first and only command prompt that I met that didn't take
the quite sensible option of quoting filenames was DOS on the
IBM...Windows wasn't copying only the Mac, it was copying almost every
single machine there was..._DOS_ was the bizarre exception to the rule
and introduced this idea of prohibiting certain characters...by
quoting filenames, this allows almost any character to be present in a
filename and is a sensible idea...
And, to be fair on DOS, the reason they probably decided to do this is
because commands weren't built-in like most prompts but were actually
filenames themselves (e.g. 'C:\> "C:\Command\MS Linker v2.exe" "My
object file.obj"')...so, DOS, I guess, only did this to try to be more
cosmetically "friendly" about things and remove the temptation for
multiple word commands like "Microsoft Linker v3.exe" (as we all know
how fond MS are of sticking their name in font of something and
putting the version number after it, if they can ;)...
Plus, as we had a limit of 8 characters for the filename "proper",
then the need for bothering with support for spaces wasn't really
worth the effort...but, if I remember rightly, even the C64 used to
allow up to about 16 (or was it 20? Something like that ;) characters
for a filename so with that much extra room, a space is a handy thing
to be able to have...it's much like all those voodoo black magic names
on UNIX systems because filenames couldn't be more than 6
characters...it wasn't that it was all that sensible an idea, it was
simply a space-saving exercise that still haunts these systems, even
though it's no longer really applicable to save a handful of bytes on
an 80GB hard drive, which the file system is allocating in 4KB chunks,
anyway...
It's a throw-back to a by-gone age...it's not necessarily "wrong" or
undesirable or whatever - so if you prefer that, that's just fine -
but it's not right to accuse LFNs as being "evil" or something...and
certainly not right to suggest that it's all Apple's fault and IBM's
are going downhill because they eventually learnt to conform with what
all the other micros were doing...
Remember, when the IBM PC first came out, it was a backward step and a
bit of a joke in comparison to its rivals...the "plug and play"
design, though, and IBM's muscle in the business arena secured it the
bright future we're now in...even IBM didn't take the PC at all
seriously...they only produced a micro because they wanted "all IBM"
businesses and didn't like seeing all these Apple Macs appearing on
people's desks...I'm sure by their own admission, if asked, it was a
_retrograde_ step...so it's probably more accurate, if you ask me, to
think "at last!" when PCs got with the programme that every other
machine had long established...
> As you happily mentioned you can use the quotes in between the
> filename in a DOS box under Windoze, but some people (like me) are
> unhappy about using a DOS box as it's still too slow (for games &
> maybe other stuff), so we use native DOS, which as I'll go back to
> know's nothing about extended filenames & filenames with spaces in.
Yes, a DOS box is too slow for many things...but, then, it's only
really provided as a "backwards compatibility" thing to an OS that MS
no longer has any interest in supporting (and, well, a command prompt
of some sort is always a useful thing to have for batch, rather than
interactive, processing and seeing as they had coded such a beast
before, it's easier to bring it into Windows and kill two birds with
one stone rather than invent a brand new one)...
But, as usual, a battle is invented where there doesn't need to be
one...the GUI people _wrongly_ condemn command prompts as "backward",
when they have more than legitimate uses...and the prompt people
_wrongly_ condemn GUIs as the spawn of the devil or something...this
is all a bit nonsensical and is actually a bit of a PC-ism because it
was so retrograde when it first came out...
The PC showed up with hardware that provided "text modes" where the
hardware would translate character codes into actual pixels...the
fonts would be built into the cards...teletype ruled the roost because
graphics were too cumbersome and not properly supported...graphics
modes and graphics modes that were reasonable to look at were a later
addition...and then this bizarre (false) division showed up on PC
systems that doesn't really hold with the other machines...it really
is a PCism that people think there's a division at all here...
There is no "hierarchy of interfacing" where GUIs sit at the top and
command prompts at the bottom or whatever...teletype and streaming and
such have their uses, pointing and clicking has its uses...but
everyone is so happy to jump to taking "sides" and having a Holy War
about it...for batch processing - which, of course, is the actual
reason why the ScriptKid is looking for a prompt-based solution
because renaming each file one by one is a stupid and time-consuming
idea that GUIs don't handle very well at all - the command prompt is
undisputed King...but for interactive processing, a command prompt can
get ugly fast (note that things like EDIT.COM basically "fake" a GUI
in text mode rather than descend to the depths of ugliness and
confusion found in something like "vi", with its voodoo black
magic)...and all those games you play in DOS probably delight in
switching to graphics mode and implementing their own GUI-like
interfaces as soon as is possible ;)...
Teletype has uses...GUIs have uses...neither is "wrong" or
"evil"...what's actually "wrong" and "evil" - if anything is - is this
insistance on "taking sides" and refusing to acknowledge that the
other style of interface can be beneficial...that is, the GUI people
do tend to act as though their interface is "superior" to prompts and
that prompts should be thrown onto the "recycle bin" icon in the
bottom corner of their desktops...but, then, the prompt people insist
on fighting fire with fire and want to "deltree C:\Windows" at the
first available opportunity...two wrongs, in both directions, don't
make a right...
What really should be happening is that the right style of interface
is matched up with the right style for the application involved...file
management with Explorer can be a major PITA (as ScriptKid's original
question is obviously referring to...he wants a single command that'll
do all the work in one go...because pointing and clicking and renaming
things one by one is just stupid and in no way is a GUI "superior" at
this sort of thing)...
Anyway, I'm heading towards a trademark ten-page rant so I'll stop
here :)
Beth :)
Beth
> The issue is that if you were planning to upload a file somewhere
> (such as a text file) which has spaces in it & someone downloads it
to
> view in DOS I don't know how DOS would treat those spaces in the
> filename, particularly in native DOS!
>
> But it's even worse when someone in another case writes a DOS game &
> it's being done in a DOS box under Windoze with the extra long
> filenames. In that event if the main program wants to load some
other
> file, if that filename is an extended filename (above the 8.3
routine)
> that means the game is useless to someone in native DOS.
But, by the same rationale, what about forward and back-slashes?
Colons? Asterisks? Question marks? Upper and lowercase? Semi-colons?
All these things are also non-portable between various systems...DOS
prefers blackslashes where it's forward-slashes on other systems...do
we abandon directory hierarchies to be "compatible"?
I used an Alpha system once (I think it was an Alpha, anyway...I had
to log onto it remotely so I never actually got to see the machine
itself but I think everyone kept saying it was an Alpha :) where the
file system naturally employed "versioning" on files...if you saved a
new file with the same filename as an older file, it didn't overwrite
it but added a "version" suffix to differentiate which "version" was
which...so, you'd save "MyFile.txt"...and then you'd save a new
version on top of it and it would rename the original file
"MyFile.txt;1" and the new file "MyFile.txt;2"...and you'd have
commands like "purge MyFile.txt" to remove all but the latest
version...quite radically different from most other file systems (and,
I have to say, wasn't a bad idea at all...had something like FAT or
NTFS had such a notion then they'd automatically be the concept of
"driver rollback" in the way the file system worked because this file
system didn't permit files to be implicitly deleted by overwriting)...
Anyway, the point of this example is that they use a semi-colon for a
specific file system purpose, where (I've just checked ;) NTFS permits
it...another issue is that ASCII has an English bias...for
"compatibility", does this mean a Japanese user cannot even use their
own native language? Or even something quite minor like the those
umlaut characters in German or the accent marks in French (just to
show you don't even need a completely different "alphabet" and writing
system to run into problems)? Then we enter into ASCII / ANSI /
UNICODE debates and about how to translate between them and deal with
sticky situations that can't be translated...and we're only just
beginning to list the issues involved here...
And what caused all this? Short-sightedness, as usual...had DOS
followed the (which you accuse of being "evil" or something) example
of others and put filenames in quotation marks to delimit the start
and end, we could have freed up almost every character including the
"dreaded" space character...had it also decided to follow the forward
slash of other systems rather than trying to be clever and swap it for
a backslash...had it originally been that filenames were stored
dynamically rather than into fixed-sized slots on the file system,
then limits could have been eased...blah-blah-blah...but it didn't
happen so there's no sense playing "what ifs" here...
Perhaps the best idea for "universal compatibility" would be simply
number files rather than give them names...that is, the file "name"
would just be an integer value...but, then, of course, we'd have
problems with endianness and how many bits to use...
Of course, a game labelled as being for DOS should abide by the DOS
filename conventions but it gets silly to insist on this all ways
round...least of which, if all files have to be 8.3 then what's the
point of long filename support on any OS because, for "compatibility",
we'll always be forced to work to the lowest common denomitor and if
people keep using DOS, then it'll always remain as 8.3...but if long
filename support is made somewhat meaningless by this insistance on
"compatibility" then it'll never be used sufficiently for 8.3 to ever
be eventually replaced...
I've made this case elsewhere but, basically, at some point, you
really do have to draw the line with "backwards compatibility"...and
when you don't do that, you end up with the horrible mess of quirks
and exceptions you get with Windows 9x...which, no doubt, is a large
reason why you prefer to remain in DOS (on which note, I really can't
blame you at all for that ;)...
For a long while, nothing was "compatible" so everyone suddenly got
obsessed with "backwards compatibility" for everything under the
Sun...but flying from one extreme to the other rarely works...so much
so, that I'm really being quite heretical here in suggesting it's not
an absolute god that cannot be challenged at any point...of course,
compatibility is good...but not to the extent that nothing else
matters or is a consideration (so we end up with massive bloated code
everywhere to deal with every single version and variation for the
last three decades or so)...that's just getting a touch silly about
things...
"Backwards compatibility" is a boulder at the top of a hill...be wary
about pushing it and which direction you push it in because it'll be
nigh-on impossible to stop once it starts rolling...if you make a
mistake or a bad decision, it will haunt you for longer than you'd
like...Y2K, filenames, 16 vs. 32 bits (which then just becomes 32 vs.
64 bits ;), etc., etc....it's a major reason why the PC is the
messiest and ugliest system around..."backwards compatibility" to an
extreme has been the motto of the system...
It's a guarantee that I'm unlikely to make in future, looking back in
hindsight to what it's done to so many systems before anything I might
write...rather, I'd make a guarantee to provide data conversion
utilities to update file formats (so that a new version of something
doesn't invalidate old stuff and can just be "upgraded" to the new
version...yes, that's less convenient but, in the long run, it will do
everyone a favour...and you could always integrate such a utility with
the main application - triggering it when it spots an old file format
being used - so that no-one would probably notice it's even happening
;)...something that a DOS advocate would like is that it would also be
sensible not to declare anything as "obselete"...rather you let things
die off naturally and become "obselete" that way rather than declaring
it just to usher people into the shops to buy the latest and greatest
version...support would continue until it quite naturally isn't needed
anymore...
Beth :)
Beth
> Tim Robinson wrote:
> > Frankie say:
> > | filenames is about the *worst* idea MS has ever come up with,
IMO
> >
> > Why?
>
> 'Cause I didn't know the trick with the quotes.
Perhaps you've found out yourself with experimenting, but, just in
case, it should be noted that the trick only works under Windows and
not in "pure" DOS (including switching Win98 or whatever into "DOS
compatibility mode"...for complete compatibility, it stops supporting
that stuff...just in case it would effect how some older program
interprets command lines or whatever ;)...
> > 1) It wasn't Microsoft who came up with the idea
>
> Okay. Did they come up with *any* ideas?
Don't get me started on this one...on technical grounds, they don't
seem to have invented anything (and I had a long rant in
alt.os.development about it :)...
On "dubious business practices", "introducing absurdities into
software licences", how to hype something quite lame (that they
probably should have done decades earlier) as being the best thing
since sliced bread (e.g. "it's completely 32-bit" announced two
processor generations after the hardware had actually let things go
32-bit and _still_ it was mostly hype as only recently has the claim
finally become a reality ;) and teaching other software companies how
they can scam people so that they end up making more money than oil
barons and diamond merchants can (they are the richest company in the
world - above all of these other companies - and they don't sell
refined oil nor 24 carrot gold nor top quality diamonds...they sell
chunks of binary that is prone to crashing every five minutes...think
about that for a second and then try to tell me there isn't a scam
going on ;), they wrote the book on the subject...
> > 2) In a GUI environment it doesn't make sense to disallow
spaces -- it
> > allows you to give your files proper names
>
> I guess most people don't mind being trapped in a cartoon interface.
> Some of us like to be able to be more flexible. Any OS, living or
> dead...
Oh, it's good that you put "any OS, living or dead" at the end there
because I was going to point out that it's not fair to judge all GUIs
on MS's monsterous beast...on other systems, it's often quite
liberating and "flexible" to go GUI rather than stick with a command
prompt in some instances...
And, to be honest, though I agree with the sentiment of "cartoon
interface" (I mean, they really do have cartoon characters come on the
screen to annoy you ;)...that's a little unfair on cartoons to be
compared to Windows...the Japanese make some rather excellent cartoons
(because, in their culture, they don't ever seem to have considered
cartoons as being a "kid's medium" so they create all sorts of things
in cartoon form...some of which is _definitely_ NOT for kids...they
rather just tend to think of it as an incredibly cheap way of letting
your imagination run wild because, as long as you can draw it, it's
possible...whereas, a live action equivalent would require incredibly
expensive effects to do the same thing...anyway, enough of that, it's
going off on a tangent ;)...
[ oh, alright, I'll just admit it, I love watching the Cartoon
Network, even if it's meant for kids...hehehe ;) ]
> > 3) If you do need to use files on the command line whose names
have spaces,
> > enclose them in quotes. NT CMD.EXE will do this automatically if
you type
> > the first part of the name and press Tab.
>
> Good tip! Thanks. And file name completion in NT, huh? What will
they
> think of next? :) (I still can't get "ren" to work with the
wildcards).
Yup; Just tried it...with a bunch of files called "test1.txt",
"test2.txt", the command "ren test*.txt tset*.txt" doesn't work..and
neither does "ren test?.txt tset?.txt" either...basically, the "*" and
"?" work for the source filename but aren't transferred to the
destination filename (so, "test1.txt" with "ren test?.txt tset?.txt"
is renamed to "tset.txt" rather than "tset1.txt" causing a "duplicate
filename" error :)...
I knew about the quotes thing but not about filename completion...I've
a feeling, though, that now I know about it, it'll suddenly become my
new bestfriend...hehehe ;)
> I notice that the "short form" of the name catches a bit more of the
> original if it's got spaces, rather than underscores, so that's
> something in it's favor. "name_too_long" -> "name_t~1", "name too
> long"-> "nameto~1"...
>
> I'll retract it, then. Spaces in filenames *isn't* the worst idea MS
has
> ever come up with... okay, "borrowed"... :)
>
> So what *was* their worst idea? DoubleSpace?
The worst idea was Bill thinking "hmmm...maybe I should start up a
software company", of course...hehehe ;)
Beth :)
Tim Robinson
|| Good tip! Thanks. And file name completion in NT, huh? What will they
|| think of next? :) (I still can't get "ren" to work with the
|| wildcards).
|
| Yup; Just tried it...with a bunch of files called "test1.txt",
| "test2.txt", the command "ren test*.txt tset*.txt" doesn't work..and
| neither does "ren test?.txt tset?.txt" either...basically, the "*" and
| "?" work for the source filename but aren't transferred to the
| destination filename (so, "test1.txt" with "ren test?.txt tset?.txt"
| is renamed to "tset.txt" rather than "tset1.txt" causing a "duplicate
| filename" error :)...
It works for me (again, using CMD). Well, partially:
[H:\unix\root] dir
[...]
28/02/2002 15:31 1,171,484 miu.exe
28/02/2002 15:38 4,664 miu.o
28/02/2002 15:29 441 miu.pro
28/02/2002 15:37 6,186 miu.s
28/02/2002 17:07 1,173,299 miutim.exe
28/02/2002 17:08 359 miutim.exe.stackdump
28/02/2002 17:07 1,105 miutim.pl
26/03/2002 00:26 290 paranoia.pro
11 File(s) 2,524,500 bytes
6 Dir(s) 5,904,052,224 bytes free
[H:\unix\root] ren miu* uim*
[H:\unix\root] dir
[...]
28/02/2002 15:31 1,171,484 uim.exe
28/02/2002 15:38 4,664 uim.o
28/02/2002 15:29 441 uim.pro
28/02/2002 15:37 6,186 uim.s
28/02/2002 17:07 1,173,299 uimtim.exe
28/02/2002 17:08 359 uimtim.exe.stackdump
28/02/2002 17:07 1,105 uimtim.pl
11 File(s) 2,524,500 bytes
6 Dir(s) 5,904,052,224 bytes free
[H:\unix\root] ren uim* uim*.bak
A duplicate file name exists, or the file
cannot be found.
A duplicate file name exists, or the file
cannot be found.
A duplicate file name exists, or the file
cannot be found.
A duplicate file name exists, or the file
cannot be found.
| I knew about the quotes thing but not about filename completion...I've
| a feeling, though, that now I know about it, it'll suddenly become my
| new bestfriend...hehehe ;)
Very handy.
|| So what *was* their worst idea? DoubleSpace?
|
| The worst idea was Bill thinking "hmmm...maybe I should start up a
| software company", of course...hehehe ;)
I think that was a *very* good idea, at least for Bill. ;)
Daniel Camp
> I used an Alpha system once (I think it was an Alpha, anyway...I had
> to log onto it remotely so I never actually got to see the machine
> itself but I think everyone kept saying it was an Alpha :) where the
> file system naturally employed "versioning" on files...if you saved a
> new file with the same filename as an older file, it didn't overwrite
> it but added a "version" suffix to differentiate which "version" was
> which...so, you'd save "MyFile.txt"...and then you'd save a new
> version on top of it and it would rename the original file
> "MyFile.txt;1" and the new file "MyFile.txt;2"...and you'd have
> commands like "purge MyFile.txt" to remove all but the latest
> version...
sounds like VMS, I've got a[n open]VMS shell account :)
> quite radically different from most other file systems (and,
> I have to say, wasn't a bad idea at all...had something like FAT or
> NTFS had such a notion then they'd automatically be the concept of
> "driver rollback" in the way the file system worked because this file
> system didn't permit files to be implicitly deleted by overwriting)...
didn't I suggest versioning? when "we" were talking about DLL hell in
a.o.d? well, using the streams of NTFS in your ownOS to store diff
versions of files seemed like a good idea [tm].
I'm like that woman on the fast show!
HELLO, CAN YOU HEAR ME?
> Beth :)
I'll bet!