dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (03/28/89)
I have an old program compiled under Microsoft Fortran (version 3.x or 4, I think) that has worked fine for a long time. Just recently I bought Sidekick Plus, and find it has broken my program. What happens is that when the program tries to read a line from standard input, using something simple like READ(*,*) i,j,x,l,m where i,j,l,m are integers and x is real, it is never satisfied - it keeps prompting (with a CR/LF) for more input, even after 5 items have been entered. It's really bizarre, because it still works fine if I remove SKPlus from memory. In case it makes a difference, I think the program is compiled to emulate an 80x87 on machines (like mine) without one. The machine is a clone 386, with nothing else resident to confuse things. I'm running MS-DOS 3.3. Does anybody have any ideas for fixes for this? Even explanations? Duncan Murdoch
mcdonald@uxe.cso.uiuc.edu (03/29/89)
>My question is: Is the input method used by the Fortran program legal?
Yes. Service 34 is marked "reserved" in my DOS reference. This means
"RESERVED TO MICROSOFT". Your Fortran compiler was written, along with
its run-time code, by Microsoft. They used a reserved function -
RESERVED TO THEM. If another Fortran vendor used that method, it would
not be legal.
It is Sidekick that is broken. They used a reserved function -
RESERVED TO SOMEONE ELSE!
Ralf.Brown@B.GP.CS.CMU.EDU (03/30/89)
In article <45900219@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: }>My question is: Is the input method used by the Fortran program legal? } }Yes. Service 34 is marked "reserved" in my DOS reference. This means }"RESERVED TO MICROSOFT". Your Fortran compiler was written, along with }its run-time code, by Microsoft. They used a reserved function - }RESERVED TO THEM. If another Fortran vendor used that method, it would }not be legal. } }It is Sidekick that is broken. They used a reserved function - }RESERVED TO SOMEONE ELSE! Sorry, RESERVED TO MICROSOFT only means that MS won't officially tell you what it does, and reserves the right to change its meaning at will. However, INT 21h function 34h is a vital call for any TSR that wants to do disk I/O, and the _MSDOS_Encyclopedia_ acknowledges that by telling you what it does (return a pointer to a flag byte that says whether or not DOS is already in an INT 21h call). On the other hand, just because it is officially documented doesn't mean that MS won't change it anyway (look at function 38h). -- 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 claimed something? You cannot achieve the impossible without attempting the absurd.
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (03/30/89)
In article <45900219@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > > >>My question is: Is the input method used by the Fortran program legal? > >Yes. Service 34 is marked "reserved" in my DOS reference. No, it wasn't using service 34 - it was service 3F, which is the standard read from file service. Sorry if I had a typo in my original posting. I've since determined that what Fortran was doing _is_ legal, and _is_ documented, and should have worked. DOS is supposed to buffer input being read from a device in ASCII mode; for some reason Sidekick Plus messes this up. I've informed Borland of the bug. They told me they were aware of problems with SKPlus and MS Fortran, but apparently didn't know the cause of them. If they tell me any fix, I'll post it, but I don't really expect them to. Borland seems to be very poor at coming up with bug fixes for their products. (But they're very good at supporting novice users. And it did require their Turbo Debugger with its 386 hardware debugging support for me to find the bug in the first place - one of the things the Fortran program does is to move its code around upon startup, which is really frustrating if you're relying on breakpoints set in memory. This isn't entirely a flame.) Duncan Murdoch
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/31/89)
In article <103@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: [MS-]DOS is supposed to buffer input being read from a device in ASCII mode; for some reason Sidekick Plus messes this up...Borland seems to be very poor at coming up with bug fixes for their products. My own point of view is that SideKick *is* one huge bug. It does weird things to the MS-DOS software interrupt vectors that would make Bill Gates turn over in his grave. And it does these weird things at each clock interrupt, not just once when it starts up. There is no solution to this other than "del sk.com". SikeKick in memory is a disaster waiting to happen. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) (03/31/89)
In article <45900219@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >Yes. Service 34 is marked "reserved" in my DOS reference. This means >"RESERVED TO MICROSOFT". Your Fortran compiler was written, along with >its run-time code, by Microsoft. They used a reserved function - >RESERVED TO THEM. If another Fortran vendor used that method, it would >not be legal. Well, it seems to me that if Microsoft reserves a function and then uses it in their own software (which may be floating around for quite some time), they must plan to make that function available in new versions of DOS for quite some time to come. Therefore, why don't they say what it does in their manuals, and include a warning that it may be removed in the future? That way, the rest of us could use what must obviously be a useful service if we wanted to. Am I naive, or am I making a valid point here? Regards, -- ====================================================================== ! Stephen M. Dunn, cs3b3aj@maccs.McMaster.CA ! DISCLAIMER: ! ! I always wanted to be a lumberjack! - M.P. ! I'm only an undergrad ! ======================================================================
bobmon@iuvax.cs.indiana.edu (RAMontante) (03/31/89)
dhesi@bsu-cs.UUCP (Rahul Dhesi) <6407@bsu-cs.UUCP> : - -My own point of view is that SideKick *is* one huge bug. It does weird -things to the MS-DOS software interrupt vectors that would make Bill -Gates turn over in his grave. "But Bill Gates isn't dead!" "Well, this would kill him!" ...Yet another big plus for Sidekick. p.s. :-)