dd@beta.UUCP (Dan Davison) (09/25/87)
A problem: program always reads from drive A: I have an application program, available only as a .EXE file, which always tries to read a data file from the A: drive. Is there a way to change this using DEBUG? I'd like to change this to the C: drive. This program is not a commerical program, and is not available in source code to fix this problem. Any hints would be welcome. Because of the users of the program (real novices) this correction must be made in the program, not at the DOS level. Thanks! Dan Davison Arpa: dd@lanl.gov BITNET: dd%lanl.gov@wiscvm.bitnet CIS: 74065,41 UUCP: dd@lanl.uucp or ...cmcl2!lanl!dd Voice:505-665-1355| T-10 MS K710, Los Alamos Natl. Lab, Los Alamos,NM 87545
psfales@ihlpe.ATT.COM (Pete Fales) (09/28/87)
In article <10495@beta.UUCP>, dd@beta.UUCP (Dan Davison) writes: > A problem: program always reads from drive A: > > I have an application program, available only as a .EXE file, which > always tries to read a data file from the A: drive. Is there a way to > change this using DEBUG? I'd like to change this to the C: drive. This > program is not a commerical program, and is not available in source code > to fix this problem. Any hints would be welcome. Because of the users > of the program (real novices) this correction must be made in the > program, not at the DOS level. Thanks! I would go in with DEBUG and look for any occurrences of the string "A:" and change them to use drive C. This is not guaranteed to work because there are other ways to access the A: drive that can be used, especially by programs originally written for older versions of DOS. But it's worth a try. If that doesn't work, the only thing to do is trace through the execution of the program with DEBUG (or a better debugger) and figure out what is going on. -- Peter Fales UUCP: ...ihnp4!ihlpe!psfales work: (312) 979-7784 AT&T Information Systems, IW 1Z-243 1100 E. Warrenville Rd., IL 60566
jtn3@bsu-cs.UUCP (Jim Nelson) (09/29/87)
In article <10495@beta.UUCP>, dd@beta.UUCP (Dan Davison) writes: > A problem: program always reads from drive A: > Well, this method is a kludge that I've used that may work for you: Create a batch file to execute the program similar to this. CTTY NUL SUBST A: C:\PATHNAME SUBST B: C:\PATHNAME CTTY CON PROGRAM.EXT CTTY NUL SUBST A: /D SUBST B: /D CTTY CON I've run into a couple of programs that this won't work with, but only they are reading an absolute disk sector, and they need the floppy in anyway. =========================================================================== Jim Nelson UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jtn3 515 N. Main Fairmount, IN 46928 "Sex" is not the answer, "Sex?" is the question. "Yes" is the answer. ===========================================================================
jtn3@bsu-cs.UUCP (Jim Nelson) (09/29/87)
In article <2093@ihlpe.ATT.COM>, psfales@ihlpe.ATT.COM (Pete Fales) writes: > In article <10495@beta.UUCP>, dd@beta.UUCP (Dan Davison) writes: > > A problem: program always reads from drive A: > > > > I have an application program, available only as a .EXE file, which ^^^this will cause a major problem when using DEBUG since DEBUG uses the header block in .EXE files to figure out where to put the file in memory. > I would go in with DEBUG and look for any occurrences of the string "A:" ^^^*all* of them?!?!?!?! It may even be using B: on a single floppy system since B: and A: are the same physical drive on a single floppy system. =========================================================================== Jim Nelson UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jtn3 515 N. Main Fairmount, IN 46928 If at first you don't succeed, redefine success. ===========================================================================
dick@plx.UUCP (Dick Flanagan) (09/30/87)
Summary: Expires: Sender: Followup-To: In article <1186@bsu-cs.UUCP> jtn3@bsu-cs.UUCP (Jim Nelson) writes: >In article <10495@beta.UUCP>, dd@beta.UUCP (Dan Davison) writes: >> A problem: program always reads from drive A: Has anyone considered using the ASSIGN command? According to the Microsoft documentation, it's entire purpose in life is making these A:-only programs behave in a non-A:-only world. -- Dick Flanagan, W6OLD I'll take a drug test when UUCP: ...!ucbvax!sun!plx!dick Reagan takes an IQ test. GEnie: FLANAGAN
psfales@ihlpe.UUCP (09/30/87)
In article <1188@bsu-cs.UUCP>, jtn3@bsu-cs.UUCP (Jim Nelson) writes: > In article <2093@ihlpe.ATT.COM>, psfales@ihlpe.ATT.COM (Pete Fales) writes: > > In article <10495@beta.UUCP>, dd@beta.UUCP (Dan Davison) writes: > > > A problem: program always reads from drive A: > > > > > > I have an application program, available only as a .EXE file, which > ^^^this will cause > a major problem when using DEBUG since DEBUG uses the header block in .EXE > files to figure out where to put the file in memory. When I wrote this, I was assuming that anyone willing to use DEBUG to tackle a project like this would know how to use debug on an EXE file. (i.e. Change the name to something not ending in .EXE) > > I would go in with DEBUG and look for any occurrences of the string "A:" > ^^^*all* of them?!?!?!?! > It may even > be using B: on a single floppy system since B: and A: are the same physical > drive on a single floppy system. Yes, all of them. You might get lucky. As I mentioned in my original posting, this method comes with no guarantees. I also said that if searching for strings doesn't work, the alternative is the much bigger job of tracing the program execution. -- Peter Fales UUCP: ...ihnp4!ihlpe!psfales work: (312) 979-7784 AT&T Information Systems, IW 1Z-243 1100 E. Warrenville Rd., IL 60566
bo-j@obelix.UUCP (09/30/87)
In article <10495@beta.UUCP> dd@beta.UUCP (Dan Davison) writes: >A problem: program always reads from drive A: > Sometimes a simple ASSIGN A=C works. It works on my old version BASCOM basic-compiler that wants to read the libraries from A: but it does'nt work on Cyrus, the chess-program. -- Bo Jansson, Linkoping Sweden UUCP: bo-j@obelix.liu.se, or {mcvax,munnari,uunet}!enea!liuida!obelix!bo-j
paula@bcsaic.UUCP (10/02/87)
In article <1188@bsu-cs.UUCP>, jtn3@bsu-cs.UUCP (Jim Nelson) writes: >In article <2093@ihlpe.ATT.COM>, psfales@ihlpe.ATT.COM (Pete Fales) writes: >> In article <10495@beta.UUCP>, dd@beta.UUCP (Dan Davison) writes: >> > A problem: program always reads from drive A: >> > >> > I have an application program, available only as a .EXE file, which > ^^^this will cause >a major problem when using DEBUG since DEBUG uses the header block in .EXE >files to figure out where to put the file in memory. > Just rename the file so it doesn't end in .exe to prevent debug from mucking around with it. It will then be treated as a plain data file and loaded at 100H. > >> I would go in with DEBUG and look for any occurrences of the string "A:" > ^^^*all* of them?!?!?!?! It may even >be using B: on a single floppy system since B: and A: are the same physical >drive on a single floppy system. > I think Pete meant *all* of them. There shouldn't be that many. Dan would know if his program was asking for drive B: because it would ask him to put the diskette for drive B: in drive A:. Paul Allen ...!uw-beaver!ssc-vax!bcsaic!paula paula@boeing.com
zeeff@b-tech.UUCP (Jon Zeeff) (10/05/87)
Wouldn't the DOS command "assign a=c" be much easier than patching the program? -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
brown@nicmad.UUCP (Mr. Video) (10/06/87)
In article <3544@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes:
<Wouldn't the DOS command "assign a=c" be much easier than patching the
<program?
If the program uses INT13, then the "assign a=c" isn't going to work.
--
harvard-\ ihnp4--\
Mr. Video !uwvax.................!nicmad!brown
rutgers-/ terminus-/ decvax--/
BITNET: brown%nicmad.UUCP@spool.wisc.edu (until 12/01/87)