woodside@ttidcb.tti.com (George Woodside) (07/20/90)
I've had some success at using Codeview with MSC 6.0 to debug GEM applications, but I still have a few problems. The development system is a 4M 386 with VGA and monochrome displays. The software being developed is in a directory of its own. Codeview has been renamed to .APP, and installed in the \GEMAPPS\GEMSYS directory. It is also necessary to place a copy of the test application's resource file in the \GEMAPPS\GEMSYS directory, but the application program, and the source files, are all resident in the development directory. The following batch file puts the target software on the VGA, and the Codeview display on the monochrome display: @echo off what ye set drive=%what%: what y set cpath=%what% if %cpath% == "\" set cwd=%drive%%cpath% if not %cpath% == "\" set cwd=%drive%%cpath%\ d: cd \gemapps\gemsys gemvdi cv /M /2 /X %cwd%%1.app %drive% cd %cpath% echo on The program "what" places the current drive and path into the environment variable "what", for access by the batch file. The only problem with this script is that the mouse is limited to the top half of the screen. This batch file uses the VGA as the Codeview display, and the monochrome display as the GEM screen (assuming the current system configuration is for GEM on the monochrome display): @echo off what ye set drive=%what%: what y set cpath=%what% if %cpath% == "\" set cwd=%drive%%cpath% if not %cpath% == "\" set cwd=%drive%%cpath%\ d: cd \gemapps\gemsys gemvdi cv /50 /F /M /X %cwd%%1.app %drive% cd %cpath% echo on Again, the mouse range is the top half of the screen only. When the target program is running, the VGA is in graphic mode, and unreadable. The Codeview display is constantly being redrawn, and is quite slow. At the exit from Codeview, the GEM desktop display is redrawn on the monochrome screen, then the system locks up. Any help anyone can offer will be greatly appreciated.
frotz@drivax.UUCP (Frotz) (07/26/90)
woodside@ttidcb.tti.com (George Woodside) writes:
] I've had some success at using Codeview with MSC 6.0 to debug GEM
] applications, but I still have a few problems.
] The following batch file puts the target software on the VGA, and the
] Codeview display on the monochrome display:
] @echo off
] ...
] gemvdi cv /M /2 /X %cwd%%1.app
] ...
] The only problem with this script is that the mouse is limited to
] the top half of the screen.
Where is the mouse limited? GEM or in Codeview? You may have to give up
use of the mouse in Codeview and let GEM have it.
--
John "Frotz" Fa'atuai frotz%drivax@uunet.uu.net (email@domain)
Digital Research, Inc. {uunet|amdahl}!drivax!frotz (bang!email)
c/o MIS Dept. (408) 647-6570 (vmail)
80 Garden Court, C13 (408) 649-3896 (phone)
Monterey, CA 93940 (408) 646-6248 (fax)
==========
"He who knows does not speak. He who speaks does not know."
-- Lao Tzu
woodside@ttidca.TTI.COM (George Woodside) (07/30/90)
In article <Y94MX83@drivax.UUCP> frotz%drivax@uunet.uu.net writes: >woodside@ttidcb.tti.com (George Woodside) writes: > >] I've had some success at using Codeview with MSC 6.0 to debug GEM >] applications, but I still have a few problems. > >] The following batch file puts the target software on the VGA, and the >] Codeview display on the monochrome display: > >] @echo off >] ... >] gemvdi cv /M /2 /X %cwd%%1.app >] ... > >] The only problem with this script is that the mouse is limited to >] the top half of the screen. > >Where is the mouse limited? GEM or in Codeview? You may have to give up >use of the mouse in Codeview and let GEM have it. The mouse limitation occurs in the GEM program only while the GEM program is running under Codeview (aka debugging). When running in GEM alone, things are correct. The /M parameter in the codeview (cv) line in the batch file tells Codeview to leave the mouse alone, the application being debugged is using it. When debugging non-GEM software, and not using the mouse in the software, Codeview uses it properly, and with no problems. The fact that the mouse works fine in any situation other than a GEM program being debugged under Codeview indicates (to me) that there is either something else I have to do to normalize things, or that there is some incompatibility between GEM and Codeview. MSC 6.0 comes with a replacement mouse driver that must be used when Codeview is used. It will not work with any older mouse driver. And, I was never able to get Codeview, GEM, and a target program all up and running in versions of MSC prior to 6.0, since none of them would use extended or expanded memory. Now Codeview will use the additional memory, both for itself, and for the source files of the program being debugged. That leaves nearly all normal memory free for GEM, and the target program. If I can get the mouse problem solved, things would be quite nice for debugging. Being unable to get the mouse below the middle of the screen makes it nearly impossible to deal with the vast majority of dialogs, since all the exit buttons in nearly every dialog box are at the bottom, which puts them out of mouse range. -- * George R. Woodside - Citicorp/TTI - Santa Monica, CA * * Path: woodside@ttidca * * or: ..!{philabs|csun|psivax}!ttidca!woodside *
frotz@drivax.UUCP (Frotz) (08/01/90)
woodside@ttidca.TTI.COM (George Woodside) writes:
] The mouse limitation occurs in the GEM program only while the GEM
] program is running under Codeview (aka debugging). When running in GEM
] alone, things are correct. The /M parameter in the codeview (cv) line
] in the batch file tells Codeview to leave the mouse alone, the
] application being debugged is using it. When debugging non-GEM
] software, and not using the mouse in the software, Codeview uses it
] properly, and with no problems. The fact that the mouse works fine
] in any situation other than a GEM program being debugged under Codeview
] indicates (to me) that there is either something else I have to do
] to normalize things, or that there is some incompatibility between
] GEM and Codeview.
You should avoid the use of the "/M /2" switches as the GDOS is being
interpreting as the GDOS mouse specification switch. The way that the
manual specifies the GDOS /M switch is: /M=ab; where a=port and
b=mouse type. Since '=' in does is a transparent character (eg gets
mapped to a blank) the GDOS is reading something like: "/M=/2" which
makes no sense to the GDOS.
The GDOS will look for all recognizable GDOS switches and then pass
the entire command line to the application (everything after the
application name). This information is what is found in the GDOS'
PSP.
Suggestions from engineers here are:
1) Rename codeview.exe as codeview.app and invoke from the Desktop.
This implies that you [are able to] set the /M, /2 and /X switches
somehow other than from the command line. Invoke by clicking on
the codeview.app.
2) Set the /M, /2, and /X switches somehow other than from the command
line. and invoke via "gemvdi cv %cwd%1.app".
3) Debug the GDOS... (I wouldn't...) via "cv gemvdi %cwd%1.app".
--
Frotz
[God is real, unless declared integer]