Strange change of behaviour, executing daughter programs in
in [Fortran]
|
Prev: RECL
Next: 'undefined reference to' compilation problem
From: meek on 9 Apr 2008 12:03 In a previous article, e p chandler <epc8(a)juno.com> wrote: >On Apr 9, 5:29=A0am, Terence <tbwri...(a)cantv.net> wrote: >> I just tried running a Fortran program compiled (CFV6.6.1) and tested >> in september 2004 under Windows. >> >> It calls on about 60 daughter =A0programs, among them MSDOS editors >> (which are called and still work with the associated files passed) and >> many for-MSDOS compiled (MSv3.31) F77 programs (which in this mode now >> do nothing until ctl-C is struck, when they abort; else just sit there >> with a pretty screen and no action in response to other keys. >> >> =A0All these called programs still work in DOS, and worked when called >> under the parent Windows program in 2004 (because of thorough testing) >> and probably 2005 or even 2006 because I suspect I used this mode >> myself in those years, and because they were "out there" and worked, >> without complaints being sent in. >> >> Now I checked on my own Windows NT 2000 Professional and this was the >> result. >> >> Anbody got any quick ideas before I start boring you with details? >> >> My own guess is I have to relink the daughter programs with more stack >> (I found this to be necessary with even DIRECT execution of some >> existing older programs - suddenly. > >Here are a few other wild guesses. > >1. Your early DOS programs lose focus and are lost? Maybe START with >WAIT will help. > >2. XP and up do strange things with I/O redirection of MS-DOS >programs. > >3. a. XP chokes on DOS extenders where Win9x did not (like MS FPS >1.0). > b. Vista chokes on "OS/2 family apps" (like MSF 4.x and 5.x). >Setting Win9x compatibility for each EXE might help. > >HTH > >-- e > ... and XP doesn't allow access to ports without a fight (e.g. porttalk) Chris
From: Terence on 9 Apr 2008 17:28 A little more detail. The parent program sems to wok entriely correctly. The call to editors loads and executes them correctly. The call to an F77 program which diretly works in DOS or OS-in- Windows, will load and paint the screen as expected, but dows not display any fields which require a reply. The "decorating" output routine is extremely similar ro the "output text and read response" routine, differing only in that the response routine reads back key strokes and echos them. I see neither the initial value nor response to keystrokes. I'm now guessing there is a new problem in this "display and edit" routine. The SCR-OUTSTR and SCR-SETPOS routines mentioned internally ARE working. The SCR-INPC routine is as follows. INTEGER*2 FUNCTION SCR_INPUTC(IWAIT) ! tests or waits for any keystroke, returns key code or zero USE DFWIN ! GETS OR WAITS NEXT INPUT CHARACTER IMPLICIT NONE INTEGER*2,INTENT(IN) :: IWAIT ! KERN32 FUNCTIONS ICHAR,PEEKCHARQQ,GETCHARQQ INTEGER*2 :: ICHAR LOGICAL*4 :: PEEKCHARQQ CHARACTER*1 :: GETCHARQQ IF (IWAIT.NE.0) THEN ! TEST KEY SCR_INPUTC=0 IF (.NOT.PEEKCHARQQ()) RETURN END IF ! WAIT ON KEY SCR_INPUTC=ICHAR(GETCHARQQ()) IF (SCR_INPUTC.EQ.#E0) SCR_INPUTC=0 IF (SCR_INPUTC.EQ.0) SCR_INPUTC=ISHFT(ICHAR(GETCHARQQ()), 8) END FUNCTION SCR_INPUTC And this is the main dispaly and edit function, returning the non- character keystroke that terminated the input. INTEGER*2 FUNCTION SCR_EDTSTR(IATT2,IROW2,ICOL2,LENG,STRNG) ! Writes string, then allows editing till non-function/pad key USE DFWIN IMPLICIT NONE ! DISPLAY STRING AND ALLOW EDIT TILL NON- TEXT ! 1) Calculate start col row and end col. ! 2) display the string. ! While col position is LT end col: GETCHARQQ and echo it ! If backspace or left arrow, do only if not at start. INTEGER*2, INTENT (IN) :: IATT2,IROW2,ICOL2,LENG CHARACTER(LEN=*),INTENT(INOUT) :: STRNG INTEGER*2 :: JRET,JCOLP,JCOLE,IROWP,ICOLP,J,K,MODE INTEGER*2 :: SCR_OUTSTR,SCR_INPUTC,SCR_SETPOS CHARACTER*1 :: GETCHARQQ,CH ! JCOLP=1 JCOLE=LENG IROWP=IROW2 ICOLP=ICOL2 MODE=2 ! WRITE SCREEN JRET=SCR_OUTSTR(MODE,IATT2,IROWP,ICOLP,LENG,STRNG) IF (JRET.NE.0) GO TO 9 DO WHILE (JCOLP.LE.JCOLE) ICOLP=ICOL2+JCOLP-1 ! SET CURSOR JRET=SCR_SETPOS(IROWP,ICOLP) ! GET KEYSTROKE CH=GETCHARQQ() JRET=ICHAR(CH) IF (JRET.EQ.#E0) JRET=0 ! SPECIALS? IF (JRET.NE.0) GO TO 3 JRET=ICHAR(GETCHARQQ()) ! LOOK FOR LEFT,RIGHT,INS,DEL,CTL-LFT AND TAKE ACTION, ELSE DONE IF (JRET.EQ.#4B) GO TO 1 IF (JRET.EQ.#4D) GO TO 2 IF (JRET.LT.#52) GO TO 9 ! CNTL LEFT ARROW GIVES #73 -> #4C IF (JRET.EQ.#73) JRET=#4C IF (JRET.GT.#53) GO TO 9 ! DELETE? IF (JRET.EQ.#53) GO TO 4 ! INSERT: MOVE ALL RIGHT END ONE TO RIGHT, PUT BLANK, AND SHOW RESULT J=JCOLE DO WHILE (J.GT.JCOLP) K=J-1 STRNG(J:J)=STRNG(K:K) J=K ENDDO STRNG(K:K)=' ' GO TO 5 ! LEFT ARROW 1 IF (JCOLP.EQ.1) GO TO 9 JCOLP=JCOLP-1 GO TO 7 ! RIGHT ARROW 2 IF (JCOLP.EQ.JCOLE) GO TO 9 JCOLP=JCOLP +1 GO TO 7 ! NORMAL. SPACE UPWARDS? #20- #FF 3 IF (JRET.GE.#20) GO TO 6 ! CONVERT CR=ENTER IF (JRET.EQ.#0D) GO TO 8 ! CONVERT ESC AND TAB IF (JRET.EQ.#1B) JRET=#3A IF (JRET.EQ.#09) JRET=#4A IF (JRET.NE.8) GO TO 9 ! IS BACKSPACE. (IF NOT AT START) IF (JCOLP.LE.1) GO TO 7 ! MOVE TO LEFT, THEN DO A DELETE JCOLP=JCOLP-1 ICOLP=ICOLP-1 ! DELETE: MOVE ALL RIGHT END ONE TO LEFT, AND SHOW RESULT 4 J=JCOLP DO WHILE (J.LT.JCOLE) K=J +1 STRNG(J:J)=STRNG(K:K) J=K ENDDO STRNG(K:K)=' ' ! SHOW STRING 5 JRET=SCR_OUTSTR(MODE,IATT2,IROW2,ICOL2,LENG,STRNG) IF (JRET.NE.0) GO TO 9 GO TO 7 ! STORE AND SHOW NEW CHARACTER 6 STRNG(JCOLP:JCOLP)=CH JCOLP=JCOLP +1 JRET=SCR_OUTSTR(MODE,IATT2,IROWP,ICOLP, 1,CH) IF (JRET.NE.0) GO TO 9 7 CONTINUE ! OK. PASS ENDDO 8 JRET=#004E ! DONE! AND JRET IS KEY CODE 9 SCR_EDTSTR=JRET END FUNCTION SCR_EDTSTR
From: Terence on 9 Apr 2008 17:56 Sorry about that! Google seems to use short lines and does not discard trailing blanks. Here is a replacement! A little more detail. The parent program sems to work entirely correctly. The call to editors loads and executes them correctly. The call to an F77 program which diretly works in DOS or DOS-in- Windows, will load and paint the screen as expected, but does not display any fields which require a reply. The "decorating" output routine is extremely similar ro the "output text and read response" routine, differing only in that the response routine reads back key strokes and echos them. I see neither the initial value nor response to keystrokes. I'm now guessing there is a new problem in this "display and edit" routine. The SCR-OUTSTR and SCR-SETPOS routines mentioned internally ARE working. So the suspects seem to be:- The SCR-INPC routine, which is as follows. INTEGER*2 FUNCTION SCR_INPUTC(IWAIT) ! tests or waits for any keystroke, returns key code or zero USE DFWIN ! GETS OR WAITS NEXT INPUT CHARACTER IMPLICIT NONE INTEGER*2,INTENT(IN) :: IWAIT ! KERN32 FUNCTIONS ICHAR,PEEKCHARQQ,GETCHARQQ INTEGER*2 :: ICHAR LOGICAL*4 :: PEEKCHARQQ CHARACTER*1 :: GETCHARQQ IF (IWAIT.NE.0) THEN ! TEST KEY SCR_INPUTC=0 IF (.NOT.PEEKCHARQQ()) RETURN END IF ! WAIT ON KEY SCR_INPUTC=ICHAR(GETCHARQQ()) IF (SCR_INPUTC.EQ.#E0) SCR_INPUTC=0 IF (SCR_INPUTC.EQ.0) SCR_INPUTC=ISHFT(ICHAR(GETCHARQQ()),8) END FUNCTION SCR_INPUTC The display and edit function, which is:- INTEGER*2 FUNCTION SCR_EDTSTR(IATT2,IROW2,ICOL2,LENG,STRNG) ! Writes string, then allows editing till non-function/pad key USE DFWIN IMPLICIT NONE ! DISPLAY STRING AND ALLOW EDIT TILL NON-TEXT ! 1) Calculate start col row and end col. ! 2) display the string. ! While col position is LT end col: GETCHARQQ and echo it ! If backspace or left arrow, do only if not at start. INTEGER*2, INTENT (IN) :: IATT2,IROW2,ICOL2,LENG CHARACTER(LEN=*),INTENT(INOUT) :: STRNG INTEGER*2 :: JRET,JCOLP,JCOLE,IROWP,ICOLP,J,K,MODE INTEGER*2 :: SCR_OUTSTR,SCR_INPUTC,SCR_SETPOS CHARACTER*1 :: GETCHARQQ,CH ! JCOLP=1 JCOLE=LENG IROWP=IROW2 ICOLP=ICOL2 MODE=2 ! WRITE SCREEN JRET=SCR_OUTSTR(MODE,IATT2,IROWP,ICOLP,LENG,STRNG) IF (JRET.NE.0) GO TO 9 DO WHILE (JCOLP.LE.JCOLE) ICOLP=ICOL2+JCOLP-1 ! SET CURSOR JRET=SCR_SETPOS(IROWP,ICOLP) ! GET KEYSTROKE CH=GETCHARQQ() JRET=ICHAR(CH) IF (JRET.EQ.#E0) JRET=0 ! SPECIALS? IF (JRET.NE.0) GO TO 3 JRET=ICHAR(GETCHARQQ()) ! LOOK FOR LEFT,RIGHT,INS,DEL,CTL-LFT AND TAKE ACTION, ELSE DONE IF (JRET.EQ.#4B) GO TO 1 IF (JRET.EQ.#4D) GO TO 2 IF (JRET.LT.#52) GO TO 9 ! CNTL LEFT ARROW GIVES #73 -> #4C IF (JRET.EQ.#73) JRET=#4C IF (JRET.GT.#53) GO TO 9 ! DELETE? IF (JRET.EQ.#53) GO TO 4 ! INSERT: MOVE ALL RIGHT END ONE TO RIGHT, PUT BLANK, AND SHOW RESULT J=JCOLE DO WHILE (J.GT.JCOLP) K=J-1 STRNG(J:J)=STRNG(K:K) J=K ENDDO STRNG(K:K)=' ' GO TO 5 ! LEFT ARROW 1 IF (JCOLP.EQ.1) GO TO 9 JCOLP=JCOLP-1 GO TO 7 ! RIGHT ARROW 2 IF (JCOLP.EQ.JCOLE) GO TO 9 JCOLP=JCOLP+1 GO TO 7 ! NORMAL. SPACE UPWARDS? #20-#FF 3 IF (JRET.GE.#20) GO TO 6 ! CONVERT CR=ENTER IF (JRET.EQ.#0D) GO TO 8 ! CONVERT ESC AND TAB IF (JRET.EQ.#1B) JRET=#3A IF (JRET.EQ.#09) JRET=#4A IF (JRET.NE.8) GO TO 9 ! IS BACKSPACE. (IF NOT AT START) IF (JCOLP.LE.1) GO TO 7 ! MOVE TO LEFT, THEN DO A DELETE JCOLP=JCOLP-1 ICOLP=ICOLP-1 ! DELETE: MOVE ALL RIGHT END ONE TO LEFT, AND SHOW RESULT 4 J=JCOLP DO WHILE (J.LT.JCOLE) K=J+1 STRNG(J:J)=STRNG(K:K) J=K ENDDO STRNG(K:K)=' ' ! SHOW STRING 5 JRET=SCR_OUTSTR(MODE,IATT2,IROW2,ICOL2,LENG,STRNG) IF (JRET.NE.0) GO TO 9 GO TO 7 ! STORE AND SHOW NEW CHARACTER 6 STRNG(JCOLP:JCOLP)=CH JCOLP=JCOLP+1 JRET=SCR_OUTSTR(MODE,IATT2,IROWP,ICOLP,1,CH) IF (JRET.NE.0) GO TO 9 7 CONTINUE ! OK. PASS ENDDO 8 JRET=#004E ! DONE! AND JRET IS KEY CODE 9 SCR_EDTSTR=JRET END FUNCTION SCR_EDTSTR
From: Kurt Kallblad on 10 Apr 2008 06:37 "Terence" <tbwright(a)cantv.net> wrote in message news:5203a4cb-cdbf-47f9-87b2-d2c90595039a(a)s13g2000prd.googlegroups.com... > Sorry about that! > Google seems to use short lines and does not discard trailing blanks. > Here is a replacement! > > A little more detail. <snip> > The SCR-OUTSTR and SCR-SETPOS routines mentioned internally ARE > working. > > So the suspects seem to be:- > > The SCR-INPC routine, which is as follows. > > INTEGER*2 FUNCTION SCR_INPUTC(IWAIT) <snip> > INTEGER*2 FUNCTION SCR_EDTSTR(IATT2,IROW2,ICOL2,LENG,STRNG) <snip> I don't think your problem is in those routines. DVF's online manual says: "However, PEEKCHARQQ does not work under Fortran QuickWin applications, since QuickWin has no console buffer to accept unsolicited input." However, I tested your functions with two small programs: !------------------ program xp ! 3 ways to start another program use dflib use dfport i = runqq('c:\...\xq.exe', ' ') i = system('c:\...\xq.exe') i = systemqq('c:\...\xq.exe') end program xp !------------------ program xq ! simple test of your routines integer*2 :: i integer*2 :: iatt2 = 1 integer*2 :: irow2 = 1 integer*2 :: icol2 = 5 integer*2 :: leng = 8 integer*2 :: SCR_INPUTC integer*2 :: SCR_EDTSTR character(len=8) :: strng = '1' i = 1 print *, SCR_INPUTC(i) i = 0 print *, SCR_INPUTC(i) i = SCR_EDTSTR(iatt2, irow2, icol2, leng, strng) end program xq !------------------ In your SCR_OUTSTR I replaced the use of OUTSTR with print *,strng and I comment out the use of SCR_SETPOS. Both programs were built as console and QuickWin applications with DVF6.6C and run under WinXP. All 4 combinations worked as expected which might indicate that the problem is somewhere else. Kurt
From: Gary Scott on 10 Apr 2008 11:27
Kurt Kallblad wrote: > > "Terence" <tbwright(a)cantv.net> wrote in message > news:5203a4cb-cdbf-47f9-87b2-d2c90595039a(a)s13g2000prd.googlegroups.com... > >> Sorry about that! >> Google seems to use short lines and does not discard trailing blanks. >> Here is a replacement! >> >> A little more detail. > > <snip> > >> The SCR-OUTSTR and SCR-SETPOS routines mentioned internally ARE >> working. >> >> So the suspects seem to be:- >> >> The SCR-INPC routine, which is as follows. >> >> INTEGER*2 FUNCTION SCR_INPUTC(IWAIT) > > <snip> > >> INTEGER*2 FUNCTION SCR_EDTSTR(IATT2,IROW2,ICOL2,LENG,STRNG) > > <snip> > > I don't think your problem is in those routines. > DVF's online manual says: "However, PEEKCHARQQ does not work under > Fortran QuickWin applications, since QuickWin has no console buffer > to accept unsolicited input." Quickwin doesn't have an associated console buffer, that's true, but it could easily be extended to accept such keyboard input via peekcharqq. There's nothing really special about consoles, they're just another GUI window with some special handling procedures associated. You can freely mix console windows and "normal" GUI windows. The OS doesn't care. > > However, I tested your functions with two small programs: > !------------------ > program xp ! 3 ways to start another program > use dflib > use dfport > i = runqq('c:\...\xq.exe', ' ') > i = system('c:\...\xq.exe') > i = systemqq('c:\...\xq.exe') > end program xp > !------------------ > program xq ! simple test of your routines > integer*2 :: i > integer*2 :: iatt2 = 1 > integer*2 :: irow2 = 1 > integer*2 :: icol2 = 5 > integer*2 :: leng = 8 > integer*2 :: SCR_INPUTC > integer*2 :: SCR_EDTSTR > character(len=8) :: strng = '1' > i = 1 > print *, SCR_INPUTC(i) > i = 0 > print *, SCR_INPUTC(i) > i = SCR_EDTSTR(iatt2, irow2, icol2, leng, strng) > end program xq > !------------------ > In your SCR_OUTSTR I replaced the use of OUTSTR with print *,strng and I > comment out the use of SCR_SETPOS. > > Both programs were built as console and QuickWin applications > with DVF6.6C and run under WinXP. All 4 combinations worked as > expected which might indicate that the problem is somewhere else. > > Kurt -- Gary Scott mailto:garylscott(a)sbcglobal dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford |