Prev: Spin-off
Next: In praise of compiler writers
From: Howard Brazee on 14 Apr 2010 10:35 On Tue, 13 Apr 2010 23:58:43 -0700 (PDT), Richard <riplin(a)Azonic.co.nz> wrote: >I seldom used MS-DOS, only when I couldn't avoid it. MS-DOS was >deliberately crippled to give a poor impression of command line >interfaces. That seems very unlikely - cite? >DRI's Multuiuser-DOS and DR-DOS had a decent command line >editor which made the CLI much easier than fiddling with an IDE. I've used DR-DOS & MS-DOS. For a while DR-DOS was more useful, but competition works. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Richard on 14 Apr 2010 16:07 On Apr 15, 2:35 am, Howard Brazee <how...(a)brazee.net> wrote: > On Tue, 13 Apr 2010 23:58:43 -0700 (PDT), Richard > > <rip...(a)Azonic.co.nz> wrote: > >I seldom used MS-DOS, only when I couldn't avoid it. MS-DOS was > >deliberately crippled to give a poor impression of command line > >interfaces. > > That seems very unlikely - cite? In 1983 Paul Allen gave a talk at COMDEC (I think it was) about 'the next version (2) of MS-DOS' where he promised various features such as 'Help' (which did appear in MS-DOS 5). One thing that was promised was command line editing and history (which was already in Unix and DRI's CP/M-86 and other). When MS did add DOSKEY to MS-DOS 5 it was not installed and was barely mentioned in the manual. It seems that it was only released so that MS could tick the feature box when compared to DR-DOS 5 (which had been available for nearly two years). Windows 95/98 also had DOSKEY (I think the name was different though) that was not even mentioned in the manual or help. The aim seemed to be to make the command line the worst experience possible. DOSKEY was not particularly good but it did give some basic facilities such as recall and line editing. Without it if you made a mistake the whole line had to be retyped. Of course there were add-ons such as 4DOS. > >DRI's Multuiuser-DOS and DR-DOS had a decent command line > >editor which made the CLI much easier than fiddling with an IDE. > > I've used DR-DOS & MS-DOS. For a while DR-DOS was more useful, but > competition works. DR-DOS was always more useful. While MS-DOS 5 caught up to DR-DOS 5 it did so nearly two years later. Then DR-DOS 6 was a year ahead of MS's catch up 6. Even the little known DR-DOS 3.3 and 3.4 was better than MS-DOS 3.3 (and 4.01) as it could support large disks while MS still had the 32MByte barrier. DRI's FDISK also had the ability to set different cluster sizes. FAT is a particularly poor file system for random file access. So COBOL indexed files were very slow. To access a specific block the system had to start at the directory entry and follow the chain of FAT entries to find the required clusters. By formatting the disk with clusters that were 8Kb instead of 2Kb that MS-DOS did, random access to largish (~1Mbyte) indexed files was 3 times faster. Another complaint against poor features in MS-DOS (and Win9x) when running COBOL systems was that record locking was done using SHARE. If the program locked a record and then crashed or was killed the lock stayed even though the process was no longer running. Start the program again and it reported the record was locked. A reboot was necessary. The way that 'competition' worked was that MS signed up its OEMs to the illegal (as determined later in court) Per-Box pricing scheme. In order to get _any_ MS software the OEM had to pay MS for every box sold regardless of what OS was installed (or none). So a DR-DOS machine still had to pay for MS-DOS as well. MS also illegally (as determined later in court) bundled MS-DOS and Windows 3.11 as one package so killing any DR-DOS market. You may call that 'competition' but then so is burning down your competitor's premises. > -- > "In no part of the constitution is more wisdom to be found, > than in the clause which confides the question of war or peace > to the legislature, and not to the executive department." > > - James Madison
From: Anonymous on 15 Apr 2010 08:05 In article <84aeba39-2d2b-4fff-96b6-e35b7ad3fcf1(a)y17g2000yqd.googlegroups.com>, Richard <riplin(a)Azonic.co.nz> wrote: [snip] >In 1983 Paul Allen gave a talk at COMDEC (I think it was) about 'the >next version (2) of MS-DOS' where he promised various features such as >'Help' (which did appear in MS-DOS 5). One thing that was promised was >command line editing and history (which was already in Unix and DRI's >CP/M-86 and other). My memory is, admittedly, porous, perhaps e'en moreso when it comes to two-and-a-half decades-old operating systems... but I seem to recall being able to get back at least the last command line Enter'd by pressing PF3. [snip] >The way that 'competition' worked was that MS signed up its OEMs to >the illegal (as determined later in court) Per-Box pricing scheme. In >order to get _any_ MS software the OEM had to pay MS for every box >sold regardless of what OS was installed (or none). So a DR-DOS >machine still had to pay for MS-DOS as well. > >MS also illegally (as determined later in court) bundled MS-DOS and >Windows 3.11 as one package so killing any DR-DOS market. > >You may call that 'competition' but then so is burning down your >competitor's premises. Arson's legal position has been established for a bit longer than software-bundling, as your own parenthetic notes might indicate. DD
From: Fred Mobach on 16 Apr 2010 15:48 Richard wrote: > DRI's FDISK also had the ability to set different cluster sizes. FAT > is a particularly poor file system for random file access. So COBOL > indexed files were very slow. To access a specific block the system > had to start at the directory entry and follow the chain of FAT > entries to find the required clusters. By formatting the disk with > clusters that were 8Kb instead of 2Kb that MS-DOS did, random access > to largish (~1Mbyte) indexed files was 3 times faster. In the late '90-s I tested a COBOL program with an index-sequential file on MS-DOS and GNU/Linux on the same (multi-boot) computer. The Linux ext2 filesystem was very helpful in order to speed the program by a factor 3 compared to the execution on MS-DOS. :-) -- Fred Mobach - fred(a)mobach.nl website : https://fred.mobach.nl .... In God we trust .... .. The rest we monitor ..
From: Pete Dashwood on 17 Apr 2010 08:53
Richard wrote: > On Apr 14, 3:32 pm, "Pete Dashwood" > <dashw...(a)removethis.enternet.co.nz> wrote: >> Richard wrote: >>> On Apr 14, 12:18 am, "Pete Dashwood" >>> <dashw...(a)removethis.enternet.co.nz> wrote: >>>> Daniel wrote: >>>>> Anyone tried that ? >> >>>>> confugure ran OK, but make abends >> >>>>> -Wwrite-strings -Wmissing-prototypes -Wno-format-y2k -MT >>>>> libcob_la-screenio.lo - >>>>> MD -MP -MF ".deps/libcob_la-screenio.Tpo" -c -o >>>>> libcob_la-screenio.lo `test -f ' >>>>> screenio.c' || echo './'`screenio.c; \ >>>>> then mv -f ".deps/libcob_la-screenio.Tpo" >>>>> ".deps/libcob_la-screenio.Plo" >>>>> ; else rm -f ".deps/libcob_la-screenio.Tpo"; exit 1; fi >>>>> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -march=i686 >>>>> -mtune=pentium4 >>>>> -finline- functions -fsigned-char -Wall -Wwrite-strings >>>>> -Wmissing-prototypes -Wno-format-y 2k -MT libcob_la-screenio.lo >>>>> -MD >>>>> -MP -MF .deps/libcob_la-screenio.Tpo -c screeni >>>>> o.c -DDLL_EXPORT -DPIC -o .libs/libcob_la-screenio.o >> >>>> <snipped diagnostics> >> >>>> Is it me? >> >>>> When I first saw this I thought it was a joke, then I realised it >>>> wasn't. >> >>>> Are people still interacting with computers to do useful work in >>>> this way? >> >>>> Is it true that "REAL" programmers only use command line >>>> interfaces? >> >>>> This looks like a nightmare conceived by a very insecure techie, in >>>> the interests of job security. >> >>>> Why would anyone inflict brain damage like this on themselves when >>>> they don't HAVE to? >> >>>> I honestly can't see how a system that needs this kind of interface >>>> can possibly be any use in this day and age. >> >>> Your inability to see has no influence on its usefulness. >> >> Absolutely. It does have influence on it's usefulness to me, >> though... >> >> >> >>>> If it were me, the first thing I would do is write a GUI command >>>> interface that hides all of this. >> >>>> Tick a few boxes, select a few options, click a button. >> >>> GUIs are for those who have no clue as to what is going on. >> >> Or those who want to deal with REAL problems rather than computer >> interfaces. I guess in your book people who don't know how to use a >> brace and bit or a hammer cannot be good carpenters, and yet master >> tradesmen are building houses with power drills and nail guns. > > Well, you completely missed the point there. > > I mainly solve _real_ problems by building systems that have no need > for a user interface at all. > > The point of computers is that they automate processes. Why have a GUI > so that things can be selected and clicked when the program can > determine what those settings should be and just get on and do it. > > If you have ever seen a house being built you will have noticed that > they still use hammers and brace and bit as well as nail guns and > power drills. > > >>> You probably missed that he mentioned 'configure' and 'make'. It is >>> make that determines what is required to be done. There is no need >>> for knowing which boxes to tick or which options to select, >>> 'configure' works all that out for itself while 'make' takes all >>> the actions that are necessary. >> >> I use 'make' in the windows environment all the time... through the >> Windows interface. I CAN use it from a command line and have done so >> on a few occasions when that made sense, but I PREFER not to. > > As it happens I have a user interface where I can navigate around the > files to the Makefile and press enter to run make to do all the > compiles. > > The point is that I don't need to select options and click checkboxes > to get what is needed done. > > >>> I have all my compiles and other regular actions under 'make' so >>> that I never need to tick boxes and select options. >> >>>> This just looks like too much work and eyestrain. >> >>> You obviously cannot tell the difference between a command line and >>> a diagnostic. >> >> Maybe not in 'Nix, > > Actually the diagnostics _were_ in Windows. > >> but I don't claim expertise in that. Given that I worked >> with computers for many years before display screens became >> available, I'm not altogether unfamiliar with CLI, and I did work >> with DOS on PCs before Windows became available. > > I seldom used MS-DOS, only when I couldn't avoid it. MS-DOS was > deliberately crippled to give a poor impression of command line > interfaces. DRI's Multuiuser-DOS and DR-DOS had a decent command line > editor which made the CLI much easier than fiddling with an IDE. > >> My post was actually light-hearted, > > No it wasn't. You made insulting and derogatory remarks. That was not the intention and I wrote it with tongue in cheek. You need to lighten up Richard. I don't think anyone was insulted or derogated (if there is such a word) by my post. Well, obviously, you say you were. All I will say again is that it was not my intention. At least one other poster responded in the same vein as my original, so the fact that it was not entirely serious was NOT lost on at least one other person. I guess that makes it 1 all... > >> but as we are >> now being serious, I would say that, given a choice between CLI or >> GUI, I would choose GUI every time. > > Given a choice I would prefer no UI at all and the job just gets done. > > Regular jobs get scripted and cronned. > > >> BUT, it is a personal preference, and I wouldn't argue that people >> who disagree are wrong. > > No, but you will call them "very insecure techie" and 'brain > damaged'. Not in a serious post I wouldn't. Other than that, I think your points are fair. I'd like to know how you psychically communicate with a computer so it doesn't need an interface,but if you have managed to pull that off, "Good Luck!" Pete. -- "I used to write COBOL...now I can do anything." |