bob@imspw6.UUCP (Bob Burch) (10/28/88)
J.R. Stoner: COG Gateway, Hayward, CA writes: >In 1982 CompuPro introduced a multiple-user system based on the dual >processor (85/88) which ran Concurrent CPM release 3.1 as its native OS >starting about 1985. This was essentially "compatible" to the DOS 1.1 >level, meaning some INT21 functions worked as they would on your XT. >................... and goes on to fault Borland for not supporting this device with Turbo Pascal versions beyond 3.0. I've got to confess here, Turbo Pascal 4.1 doesn't run on my old slide-rule either; I can't begin to tell you how much sleep I've lost over this. Ted Holden HTE
spolsky-joel@CS.YALE.EDU (Joel Spolsky) (10/29/88)
In article <190@imspw6.UUCP> bob@imspw6.UUCP (Bob Burch) writes: > J.R. Stoner: COG Gateway, Hayward, CA writes: >>In 1982 CompuPro introduced a multiple-user system based on the dual >>processor (85/88) which ran Concurrent CPM release 3.1 as its native OS >>starting about 1985. This was essentially "compatible" to the DOS 1.1 >>level, meaning some INT21 functions worked as they would on your XT. >>................... >and goes on to fault Borland for not supporting this device with Turbo >Pascal versions beyond 3.0. I've got to confess here, Turbo Pascal 4.1 >doesn't run on my old slide-rule either; I can't begin to tell you how >much sleep I've lost over this. Actually, Turbo Pascal 1.0 started out as Compas Pascal (made by a Danish company), which I used and loved for years. It originally ran on CP/M systems (Digital Rainbow e.g.). So this program really was born in the CP/M world. Last year in this newsgroup there was a whole discussion about how the _execultables_ for WordStar (I think) were converted from CP/M-86 to DOS 1.0 by changing _one byte_. I think just about all the INT21 functions were identical between CP/M and PC-DOS 1.0. +----------------+---------------------------------------------------+ | Joel Spolsky | bitnet: spolsky@yalecs uucp: ...!yale!spolsky | | | arpa: spolsky@yale.edu voicenet: 203-436-1483 | +----------------+---------------------------------------------------+ #include <disclaimer.h>
jkr@pyr.gatech.EDU (J. Kenneth Riviere (JoKeR)) (11/01/88)
In article <10@cpro.UUCP> asgard@cpro.UUCP (J.R. Stoner) writes: >However, if you had read my original posting, you would have seen that TURBO >did run correctly in a prior version of their compiler and their change to >3.1 essentially broke what used to be a working and useful tool for what >appeared to be no reasons. How did their release of a new version of the program break a version of the program which was already working? Given the realities of the marketplace it is absurd to think that a company is going to continue to support outdated equipment endlessly when there is a much bigger market using different equipment to which they are pitching their product. If there is one thing you can count on in the computer marketplace it is that if you hold on to your hardware long enough you will eventually find that there is almost no support available for it. Too bad. J. Kenneth Riviere (JoKeR) ISA, Georgia Tech, Atlanta, GA 30332 Internet: jkr@pyr.gatech.edu Bitnet: iadt1kr@gitvm1 uucp: ...!{decvax,linus,rutgers,ihnp4,hplabs,seismo}!gatech!gitpyr!jkr Fidonet: JoKeR's BBS, 133/103, (404)894-5784, 5:30p-8a M-F,24hrs wknds
asgard@cpro.UUCP (J.R. Stoner) (11/03/88)
[I first said] ;>;>In 1982 CompuPro introduced a multiple-user system based on the dual ;>;>processor (85/88) which ran Concurrent CPM release 3.1 as its native OS ;>;>starting about 1985. This was essentially "compatible" to the DOS 1.1 ;>;>level, meaning some INT21 functions worked as they would on your XT. [Ted Holden jumped in with] ;>;and goes on to fault Borland for not supporting this device with Turbo ;>;Pascal versions beyond 3.0. Borland was not being asked to support a 'device'. I was requiring them to maintain the same functionality that permitted their product to operate as experienced in my environment. ;>;I've got to confess here, Turbo Pascal 4.1 ;>;doesn't run on my old slide-rule either; I can't begin to tell you how ;>;much sleep I've lost over this. Reductio ad absurdum. I was not expecting their product to operate on anything which it did not previously support, with reasonable expectation they would continue to improve products 'reasonably'. [Then I said] ;>However, if you had read my original posting, you would have seen that TURBO ;>did run correctly in a prior version of their compiler and their change to ;>3.1 essentially broke what used to be a working and useful tool for what ;>appeared to be no reasons. [J. Kenneth Riviere responded] ;How did their release of a new version of the program break a version of ;the program which was already working? Given the realities of the marketplace ;it is absurd to think that a company is going to continue to support outdated ;equipment endlessly when there is a much bigger market using different ;equipment to which they are pitching their product. If there is one thing you ;can count on in the computer marketplace it is that if you hold on to your ;hardware long enough you will eventually find that there is almost no support ;available for it. Too bad. [And Wayne Hamilton responded] ;huh? did 3.1 jump out of the box and reformat your 3.0 disk? did someone ;hold a gun to your head to force you to throw 3.0 away? if 3.0 was a working ;and useful tool before 3.1, what made it unworking or useless afterward? A similar question would be: Why would anybody possibly want to use DOS 3.3 when 1.1 was working fine. My response would then be: Fine. You have both options, but if you want to take advantage of improved features (file handle functions, and subdirectories, and environments, and...) you need the later versions. In the mean time, prior investment in programs is not wasted since equivalent functionality is maintained where required. An equivalent experience with DOS of the Borland experience would have been the unannounced removal of all those FCB-related DOS functions in favor of the file handle related functions. You might say they were functionally similar in that that you could still open files, say, but all those programs would have to be redone completely, even if you don't intend to use paths. So this would have represented equivalence of Function, but not Form or Fit. People often complain these days about the broken functionality of DOS 4.0 and why it does not run old programs in binary form without problems. This is the same thing as my problem with Borland. Are we then expected to do away with our prior investment in DOS programs in order to use 4.0? If so, then do not call this product DOS since it does not run DOS programs. What TP 3.0 was doing inside the compiler and every object compiled with it was reading the keyboard using DOS INT21 functions, which IMHO were sufficiently expressive as to be the proper way to get input from the user, without the performance hit you might suppose. The use of CDOS was for the same reasons that somebody would pay a lot of money for DoubleDOS or DeskView or whatever. More mature technology and it translated the DOS INT21 calls (and, increasingly, ROM BIOS accesses) to equivalent machine-independent functionality. This allows the peer processors in CompuPro systems to function as well as they do and could not be done without. The compiler people decided that direct hardware access to the keyboard ports and video devices were a "neat" way of getting input and using undocumented ROS locations to synchronize the timing. This caused the compiler and all objects derived from it to hang just after establishing the stack. I would then have to switch to another VCON and run STOP on it to get my shell back. The "incompatibility" was not any change on the part of CompuPro to the system as my expectation was not to be undercut without warning, but due to Borland making some gratuitous change to the product which did not improve "portability" or "performance" or any other user-oriented issue, but did eliminate the possibility of using the "standard" INT21 calls to read input. The whole experience over the course of two compiler revisions is likened to a long-term bait-and-switch game which was compounded by the unresponsive attitude Borland support gave me when I reported this as the bug it was. A bug can be either a flaw in the logic of a program caused by faulty implementation, or a reduction of functionality due to gratuitous change in product specification which does not add to the ability of the program to serve its purpose but makes it impossible to use due to the nature of its original implementation. What Borland did was not follow the hard-earned lesson of product manufacturing: When you want to claim "compatibility" with prior versions of a product you must retain Form and Fit, as well as Function. I thought I was buying Turbo Pascal. I guess I was wrong. The other point you raise is why did I need 3.1 when 3.0 was working. The reason for that is I knew, when I ran 3.1 on the PC that the environment and supporting programs (graph3 unit and the turtle stuff) were better developed on language feature issues. Only the binary implementation stunk. I also saw (with a debugger) the hooks for large model programs and knew that might make my DSP projects not need the hit in responsiveness from the overlays. What my projects required were improved user interfaces that the graphic units provided (which did not eliminate any functionality at the language level, BTW). By the time I learned about this problem, which was not about to be repaired by the responsible party my investment in time for this DSP was tied too closely with 3.0. I also started hearing about the features of newer floatbox chips which were then coming out (Weitek) and was thinking *very* seriously about them in DSP projects and was hearing about 3.1 support of floatboxes and later versions to be able to link application libraries uniformly. I wanted this badly. Unfortunately, the rather callous disregard Borland showed to real users using their 3.0 compiler for real projects made me reconsider the idea entirely. -- "To prevent having to tell fools to RTFM don't let on you WTFM in the first place." - J.R. (May the Source be With You) Stoner asgard@cpro.uucp asgard@wotan.uucp asgard@well.uucp ...decwrl!pacbell!cpro!asgard
allbery@ncoast.UUCP (Brandon S. Allbery) (11/11/88)
As quoted from <11@cpro.UUCP> by asgard@cpro.UUCP (J.R. Stoner): +--------------- | The compiler people decided that direct hardware access to the keyboard ports | and video devices were a "neat" way of getting input and using undocumented | ROS locations to synchronize the timing. This caused the compiler and all | objects derived from it to hang just after establishing the stack. I would | then have to switch to another VCON and run STOP on it to get my shell back. | The "incompatibility" was not any change on the part of CompuPro to the | system as my expectation was not to be undercut without warning, but due to | Borland making some gratuitous change to the product which did not improve | "portability" or "performance" or any other user-oriented issue, but did | eliminate the possibility of using the "standard" INT21 calls to read input. +--------------- Let me ask you what may sound like a dumb question: did you buy the MS-DOS version or the PC-DOS version? At least for a while, Borland had *both*: one for MS-DOS compatibility and one for added speed and capability on IBM PCs and 100% compatibles. As far as your discussion of compatibility: I don't know of any current DOS programs that still use the DOS 1.x file calls. By your arguments, all programs would have to continue using them in case someone still running DOS 1.x wanted to run them. I'm sure Lotus Development, Ashton-Tate, and Microsoft would be impressed with that argument. ;-) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
Ralf.Brown@B.GP.CS.CMU.EDU (11/11/88)
In article <12897@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) writes: }As far as your discussion of compatibility: I don't know of any current DOS }programs that still use the DOS 1.x file calls. By your arguments, all COMMAND.COM! It uses the DOS 1 "delete files" call because it can handle wildcards, while the DOS 2 version can only delete one file per call (which is slower, since DOS has to scan the directory for each file being deleted, rather than once for all deletions). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.