Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!ucbvax!WSMR-SIMTEL20.ARMY.MIL!Info-IBMPC From: Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL Newsgroups: comp.sys.ibm.pc.digest Subject: Info-IBMPC Digest V7 #60 Message-ID: <8812112334.AA03956@ucbvax.Berkeley.EDU> Date: 11 Dec 88 02:45:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Info-IBMPC@WSMR-SIMTEL20.ARMY.mil Organization: The Internet Lines: 497 Approved: info-ibmpc@walker-emh.arpa Info-IBMPC Digest Sun, 11 Dec 88 Volume: Issue 60 Today's Editor: Gregory Hicks - Chinhae Korea Today's Topics: COMMAND.COM lost during Backup/restore BITNET Archives for Info-IBMPC (Digest) Basic program to print SIMIBM.IDX from SIMTEL20 New MSDOS uploads Please send Info on FTP to BITNET Movebp Problem (MOV [BP-disp],AX) (3 msgs) Stand-alone XMODEM query ---------------------------------------------------------------------- Date: Mon, 05 Dec 88 01:49:20 +0200 From: Subject: COMMAND.COM lost during Backup/restore Dear readers, I possess an IBM AT computer with an original 20 MB hard disk and another 45 MB hard disk. Both disks are booted form the original one - drive c - and were formatted together by a softwere called Vfeature Deluxe. I was told that the 45 MB disk is significantly faster than the original one. Each time I backup drive c (the original), by BACKUP /S Dos command, as soon as I finish the backup I lose the command processor together with many files on this drive. When I restore the system and all of drive c, after installing the system files, by RESTORE /P, drive c is fine, but there is no connection to drive d. It turns out that IBMBIO and IBMDOS of my backup ARE DIFFERENT than the original DOS files in the Dos diskette. If I replace the original system files with those of my backup diskette I get back a connection with drive d and everything is fine. There can be two possibilities: 1. Vfeature program changes IBMDOS and IBMBIO files, which become incompatible with the BACKUP program. 2. I have a virus that modified these system files, which shows its presence when I perform a complete backup of drive c and otherwise lives "in symbiosis" with the modified system files and the other programs. Did any reader of this note encounter a similar phenomenon and can inform me of the true reason? Sincerely, Michael Maschler e-mail: MASCHLA@HBUNOS.Bitnet ------------------------------ Date: Mon Dec 5 00:09:49 1988 From: dtseap!cover@ames.arc.nasa.gov (Robin Cover) Subject: BITNET Archives for Info-IBMPC (Digest) Is there a fileserver (LISTSERV ?) somewhere that is accessible for getting missing issues of the digest? Gateways have been fragile over the past few months, and I am missing issues I'd like to obtain. I'd appreciate sug- gestions for how to reach the fileserver best from uucp or BITNET location. Thanks, Robin Cover ames!killer!dtseap!cover [On BITNET, the archives can be obtained from DATABASE@BITNIC.BITNET and the program library can be obtained from CCUC@UMCVMB.BITNET. The Simtel20 FTP server may also be reached via . For more details, send a mes- sage to the above addresses with the first line of 'HELP'.] ------------------------------ Date: Mon, 5 Dec 1988 10:27 MST From: Keith Petersen Subject: Basic program to print SIMIBM.IDX from SIMTEL20 In my haste to make PD1:SIMCVT.BAS available I neglected to give credit to the author, Ken Van Camp . Here is his original message to me: > I downloaded the SIMIBM.IDX file from PD1:. This is > really great -- I don't know who took all the time to type those comments > in, but they are to be commended! Great job! Anyway, I didn't see any > programs to put it into a simple readable form, so I wrote a simple one > and have included it below. If you think mine is worthwhile, you might > want to put it in the FILEDOCS directory. That should make it easy for > people to find. > > Thanks again for your tireless efforts! > > --Ken Van Camp >ARPANET: kvancamp@ARDEC.ARPA -or- kvancamp@AC4.PICA.MIL >BITNET: (use above through normal gateways, like UBVM.CC.BUFFALO.EDU) >USENET: uunet!ardec.arpa!kvancamp@UUNET.UU.NET Thanks, for a very useful program, Ken! --Keith ------------------------------ Date: Sat, 3 Dec 1988 23:17 MST From: Keith Petersen Subject: New MSDOS uploads [--forwarded message--] >From: James R. Van Zandt >Re: program updates I got bug reports from Rahul Dhesi on two files I had uploaded to SIMTEL20. I have now fixed the problems, and have uploaded the revised files to SIMTEL20. Here are revised blurbs... PD1:GETF.ARC BLDFUNCS scans one or more C source files and notes where each function is defined. GETF is then used to locate the source file containing a particular function and direct your favorite editor to it. The system is particularly helpful when editing someone else's large program which is divided into many files. The ARC file includes source code, executables, and documentation for both. BLDFUNCS now accepts wild cards on the command line. From Marvin Hymowech's article in DDJ #142 (August 1988), transcribed and modestly enhanced by James R. Van Zandt . PD1:FILE-CRC.ARC FILECRC calculates CRCs for all files on a disk and records them in a file. COMPARE then compares two such files and reports differences, highlighting suspicious changes (file contents changed but creation date unchanged). Useful for spotting viral reproduction and/or damage. Both programs now allow users to change the parameters at run time. FILECRC also now traps control-C so it does leave file attributes changed if it is interrupted. This ARC includes source code, executables, and documentation for both. Written by Ted H. Emigh, translated from Pascal to C and modestly enhanced by James R. Van Zandt . - Jim Van Zandt ------------------------------ Date: Sat, 3 Dec 1988 08:40 MST From: "Frank J. Wancho" Subject: Please send Info on FTP to BITNET > If you have an FTP (File Transfer Protocol program), the best way > is to connect directly to WSMR-SIMTEL20.ARMY.MIL address > [10.0.0.74] and grab the files that way. Greg, The address for WSMR-Simtel20.Army.Mil is 26.0.0.74 ... --Frank ------------------------------ Date: Sat, 3-DEC-1988 17:36 +0100 From: "UBMJS2::RMEYER" Subject: Movebp Problem (MOV [BP-disp],AX) (3 msgs) A friend wrote a large FORTRAN program. After some changes it would not run. I found the problem in a DO loop that didn't stop at the right time. The code was correct (I beleive so), but mov [bp-2e],ax didn't work. Can anyone tell me, what's happening there? small piece of code (for DEBUG) follows: -r AX=0000 BX=0000 CX=0015 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=338A ES=338A SS=338A CS=338A IP=0100 NV UP EI PL NZ NA PO NC 338A:0100 B8B37D MOV AX,7DB3 -p AX=7DB3 BX=0000 CX=0015 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=338A ES=338A SS=338A CS=338A IP=0103 NV UP EI PL NZ NA PO NC 338A:0103 8ED0 MOV SS,AX -p AX=7DB3 BX=0000 CX=0015 DX=0000 SP=7340 BP=0000 SI=0000 DI=0000 DS=338A ES=338A SS=7DB3 CS=338A IP=0108 NV UP EI PL NZ NA PO NC 338A:0108 BD6A73 MOV BP,736A -p AX=7DB3 BX=0000 CX=0015 DX=0000 SP=7340 BP=736A SI=0000 DI=0000 DS=338A ES=338A SS=7DB3 CS=338A IP=010B NV UP EI PL NZ NA PO NC 338A:010B B83412 MOV AX,1234 -p AX=1234 BX=0000 CX=0015 DX=0000 SP=7340 BP=736A SI=0000 DI=0000 DS=338A ES=338A SS=7DB3 CS=338A IP=010E NV UP EI PL NZ NA PO NC 338A:010E 8946D2 MOV [BP-2E],AX SS:733C=338A -p AX=1234 BX=0000 CX=0015 DX=0000 SP=7340 BP=736A SI=0000 DI=0000 DS=338A ES=338A SS=7DB3 CS=338A IP=0111 NV UP EI PL NZ NA PO NC 338A:0111 8B46D2 MOV AX,[BP-2E] SS:733C=338A -q values SS,SP,BP from original program (work correctly with other values). Is this a Processor-error? (I tried on 80286 and 80386 machine) Reinhold Meyer Abt. Forstliche Biometrie u. Informatik Buesgenweg 5 D-3400 Goettingen BITNET: U0018@DGOGWDG5 ------------------------------ Date: Sun, 4 Dec 88 10:45:29 EST From: David Kirschbaum Subject: movbp problem Comment ~ Message 1: Date: Sat, 3-DEC-1988 17:36 +0100 From: "UBMJS2::RMEYER" Subject: what is a processor doing whith MOV [BP-disp],AX? Toad Hall Note: I received the above message and hacked a little test program to see just what was going on. The code below replicates (I believe) the DEBUG session Reinhold enacted. When I compile this code (into a .COM program) and step through it in SYMDEB, all instructions (via the 'u' command) are EXACTLY what Reinhold got in his DEBUG session. So .. it hasn't compiled strangely, picked up any segment overrides, or whatever. One difference from Reinhold's experience, however: it works perfectly! SS:733CH (the same place as SS:[bp-23H] when BP = 763AH) starts off as 0 before the AX stuff (in my system anyway), and changes to 1234H when I stuff AX (mov [bp-2EH],ax). So .. I donno WHAT's going on in Reinhold's system! My XT clone (8MHz 80286) running PC-DOS 3.1 runs that code perfectly. Reinhold, you DO have real memory at that SS segment, right? Can't im- agine why a ROM would be sitting there (which wouldn't permit a write to it). Donno WHAT memory would 'look' like if you had less memory than 640Kb and that SS segment was empty. Just as a note, when programming in assembler, I routinely disable inter- rupts (via the CLI instruction) before I fiddle SS, but that really shouldn't matter here or in your Fortran code .. might be kinda hard to do in Fortran anyway .. donno. Regrets I can't be of more use with a real fix .. a 'no problem' report isn't very helpful, is it? See beyond the test assembler code for my SYMDEB dump of the test program. David Kirschbaum Toad Hall kirsch@braggvax.ARPA Compile the below with MASM, LINK, EXE2BIN (or EXE2COM or whatever) to produce a .COM program. end comment ~ CSeg SEGMENT ASSUME CS:CSeg,DS:CSeg,ES:CSeg,SS:CSeg .radix 16 org 100 TestBP proc near mov ax,SS ;save our SS mov saveSS,ax mov saveBP,bp ;and BP MOV AX,7DB3 MOV SS,AX ;Work around the SYMDEB problem where we can't see BP being loaded. nop MOV BP,736A MOV AX,1234 MOV [BP-2E],AX MOV AX,[BP-2E] xor ax,ax ;let's clear AX just to be sure mov ax,[bp-2E] ;now get that value again mov ax,saveSS ;restore mov SS,ax mov bp,saveBP int 20 ;terminate ;save some values saveSS dw ? saveBP dw ? TestBP endp CSeg ends end TestBP Toad Hall note continues: Here's a capture (commented) of a SYMDEB test of the above program. D:\XFER>symdeb movbp.com Microsoft (R) Symbolic Debug Utility Version 4.00 Copyright (C) Microsoft Corp 1984, 1985. All rights reserved. Processor is [80286] [First a disassembly of our little test code... ] -u 2F30:0100 8CD0 MOV AX,SS 2F30:0102 A32B01 MOV [012B],AX 2F30:0105 892E2D01 MOV [012D],BP 2F30:0109 B8B37D MOV AX,7DB3 2F30:010C 8ED0 MOV SS,AX 2F30:010E 90 NOP 2F30:010F BD6A73 MOV BP,736A 2F30:0112 B83412 MOV AX,1234 -u 2F30:0115 8946D2 MOV [BP-2E],AX 2F30:0118 8B46D2 MOV AX,[BP-2E] 2F30:011B 33C0 XOR AX,AX 2F30:011D 8B46D2 MOV AX,[BP-2E] 2F30:0120 A12B01 MOV AX,[012B] 2F30:0123 8ED0 MOV SS,AX 2F30:0125 8B2E2D01 MOV BP,[012D] 2F30:0129 CD20 INT 20 - [Looks ok to me .. let's step through it... ] -r AX=0000 BX=0000 CX=002F DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=2F30 ES=2F30 SS=2F30 CS=2F30 IP=0100 NV UP EI PL NZ NA PO NC 2F30:0100 8CD0 MOV AX,SS -t AX=2F30 BX=0000 CX=002F DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=2F30 ES=2F30 SS=2F30 CS=2F30 IP=0102 NV UP EI PL NZ NA PO NC 2F30:0102 A32B01 MOV [012B],AX DS:012B=0000 -t AX=2F30 BX=0000 CX=002F DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=2F30 ES=2F30 SS=2F30 CS=2F30 IP=0105 NV UP EI PL NZ NA PO NC 2F30:0105 892E2D01 MOV [012D],BP DS:012D=0000 -t AX=2F30 BX=0000 CX=002F DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=2F30 ES=2F30 SS=2F30 CS=2F30 IP=0109 NV UP EI PL NZ NA PO NC 2F30:0109 B8B37D MOV AX,7DB3 -t AX=7DB3 BX=0000 CX=002F DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=2F30 ES=2F30 SS=2F30 CS=2F30 IP=010C NV UP EI PL NZ NA PO NC 2F30:010C 8ED0 MOV SS,AX -t AX=7DB3 BX=0000 CX=002F DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=010F NV UP EI PL NZ NA PO NC 2F30:010F BD6A73 MOV BP,736A -t AX=7DB3 BX=0000 CX=002F DX=0000 SP=FFFE BP=736A SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=0112 NV UP EI PL NZ NA PO NC 2F30:0112 B83412 MOV AX,1234 -t AX=1234 BX=0000 CX=002F DX=0000 SP=FFFE BP=736A SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=0115 NV UP EI PL NZ NA PO NC 2F30:0115 8946D2 MOV [BP-2E],AX SS:733C=1234 -t AX=1234 BX=0000 CX=002F DX=0000 SP=FFFE BP=736A SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=0118 NV UP EI PL NZ NA PO NC 2F30:0118 8B46D2 MOV AX,[BP-2E] SS:733C=1234 [Let's take a separate look at that memory at SS:[bp-23H]... ] -d ss:7330 7DB3:7330 00 00 00 00 00 00 00 00-00 00 00 00 34 12 00 00 ............4... 7DB3:7340 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 7DB3:7350 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 7DB3:7360 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 7DB3:7370 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 7DB3:7380 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 7DB3:7390 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 7DB3:73A0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ - [Yep, memory has actually been changed. AX was correctly stuffed. Let's be double-sure SS:BP is working... ] -t AX=1234 BX=0000 CX=002F DX=0000 SP=FFFE BP=736A SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=011B NV UP EI PL NZ NA PO NC 2F30:011B 33C0 XOR AX,AX -t AX=0000 BX=0000 CX=002F DX=0000 SP=FFFE BP=736A SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=011D NV UP EI PL ZR NA PE NC 2F30:011D 8B46D2 MOV AX,[BP-2E] SS:733C=1234 - [Look below .. AX reloaded with 1234 just fine. Clean up and exit. ] -t AX=1234 BX=0000 CX=002F DX=0000 SP=FFFE BP=736A SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=0120 NV UP EI PL ZR NA PE NC 2F30:0120 A12B01 MOV AX,[012B] DS:012B=2F30 -t AX=2F30 BX=0000 CX=002F DX=0000 SP=FFFE BP=736A SI=0000 DI=0000 DS=2F30 ES=2F30 SS=7DB3 CS=2F30 IP=0123 NV UP EI PL ZR NA PE NC 2F30:0123 8ED0 MOV SS,AX -t AX=2F30 BX=0000 CX=002F DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=2F30 ES=2F30 SS=2F30 CS=2F30 IP=0129 NV UP EI PL ZR NA PE NC 2F30:0129 CD20 INT 20 -p Program terminated normally (0) ------------------------------ Date: Sun, 4-DEC-1988 18:58 +0100 From: "UBMJS2::RMEYER" Subject: movebp problem I think the problem is real simple now. I made some tests with the original program and found, that the generated code had some errors. We use an old IMSL-Library (no source code avail., compiled with MS-FORTRAN 3.20). So we have to use compiler switch /Gr (MS FORTRAN 4.10), for saving DI and SI. (3.20 didn't) if(string1.eq.string2) then ........ endif generates code that calls __FCccmp and then POPs DI and SI, without having saved them before. So for every string compare SP increases by 4 (wrong code). MOV [BP-2E],AX works correct, but BP-2E=SP-4 !! (SP is wrong). If an Inter- rupt occurs (timer,...) this place is used for the return address. For a long loop (p-command in SYMDEB) we will see the return address of the last interrupt, that had overwritten the original contents. and don't forget /Od: x(i)=a/b a=b c=x(i) write(*,*) c Reinhold Meyer Abt. Forstliche Biometrie u. Informatik Buesgenweg 5 D-3400 Goettingen BITNET: U0018@DGOGWDG5 ------------------------------ Date: Mon, 5 Dec 88 08:20:01 EST From: David Kirschbaum Subject: Stand-alone XMODEM query (He wants a "stand-alone" xmodem that could be executed by itself without a peripheral package like Kermit." I'd suggest DSZ.COM (which is available from SIMTEL20's subdirectory. It has a sufficient number of command line parameters to permit xmodem (checksum or CRC) sends or receives of desired file to desired COMM port at desired speed .. which is what you're trying to do, ne? I also have a wee little .COM program that does simple xmodem sends and receives .. but no source, and only checksum mode (no CRC). In the long run, I'd say use DSZ because of its greater variety of protocols, port flexibility, support, etc. And by all means, register and get the ZMODEM protocol enabled. Hope this helped. David Kirschbaum Toad Hall kirsch@braggvax.arpa ------------------------------ ************************ End of Info-IBMPC Digest -------