hicks@WALKER-EMH.ARPA (Gregory Hicks COMFLEACTS) (08/17/88)
Info-IBMPC Digest Wed, 17 Aug 88 Volume 7 : Issue 37
This Week's Editor: Gregory Hicks -- Chinhae Korea <hicks@walker-emh.arpa>
Today's Topics:
Comment on FSP_12 bugs
Do Editors that use BIOS vice Direct Writes Exist? (2 msgs)
Graphics with Turbo Pascal 4.0
How to tell the good DMA chips from the bad ones
INT 1Bh vs INT 23h (was Control-C trapping under MSC)
Parallel Port Reads
PK36.EXE Discussion (2 msgs)
PS/2 Model 25 disks
SEA versus PKWARE suit settled
Printer to Disk Utility
TSR Unloader/Manager
720Kb Floppies on AT-Drives
Saving and restoring paths and Directories
Permanently enlarge the DOS environment space
Restoring Directories from .BAT files
Today's Queries:
Creating Child Process PSP's
C Beautifier/Pretty Printer
Current loops and AT's
FTP Problems
Looking for MS Word file format
Z-248 COM3 and Kermit
Request for Tennis Match Scheduling Software
New Programs:
PKARC version 3.61 now available from SIMTEL20
Info-IBMPC Lending Library is available from:
Bitnet via server at CCUC; and from SIMTEL20.ARPA (see file
PD1:<msdos>files.idx for listing of source files)
SIMTEL20.ARPA can now be accessed access from BITNET via
LISTSERV@RPICICGE.BITNET using LISTSERV Commands
Send Replies or notes for publication to: <Info-IBMPC@Walker-EMH.arpa>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to: <Info-IBMPC-Request@Walker-EMH.arpa>
----------------------------------------------------------------------
Date: FRI AUG 05, 1988 15.14.36 EST
From: "David A. Bader" <DAB3%LEHIGH.BITNET@CUNYVM.CUNY.EDU>
Subject: Comment on FSP_12 bugs
In response to Dick Flanagan's criticism of Ross Greenberg's Flushot Plus
1.2, I entirely agree his point. I also swore that I would never touch
another piece of Greenberg's software after what it did to my AT clone,
its CMOS RAM setups, and various files.
Around the middle of July, however, I came across a file called FSP_14.
This is Flushot Plus 1.4, and I have been using it since I got it without
any problems. Of course, any application that repeatedly asks for user
confirmation before continuing becomes annoying, but this version has so
many more advantages and options since version 1.2. CMOS memory can be
checked periodically, TSR programs can be defined so that they won't get
in trouble for setting off FSP's alarms, files can be checked with their
CRC's everytime they are run, and files can also be cut off from FSP's
eyes. (Ross warns that this opens up a big hole in Flushot Plus for users
who do this, but the availability for this option is there for those who
requested it.)
I have yet to find any fatal bugs in FSP_14 like there were in FSP_12. If
you find any, or have any comments, please sned them to me at DAB3@LEHIGH.
------------------------------
Date: Sat, 6 Aug 1988 12:40 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: Do Editors that use BIOS vice Direct Writes Exist?
There is an editor that uses generic I/O to the console and therefore can
be used remotely. It's availablle from SIMTEL20 as:
Filename Type Bytes CRC
Directory PD1:<MSDOS.EDITOR>
EM15.ARC.1 BINARY 87928 9CEEH
--Keith Petersen
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARPA [26.0.0.74]
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {decwrl,harvard,lll-crg,ucbvax,uunet,uw-beaver}!simtel20.arpa!w8sdz
------------------------------
Date: Mon, 1988 Aug 8 23:57 EDT
From: Bob Babcock <PEPRBV%CFAAMP.BITNET@husc6.harvard.edu>
Subject: Do Editors that use BIOS vice Direct Writes Exist?
>From: manley@lbl-csam.arpa (Oscar Manley [ams-doe])
> is there an editor package that works through bios rather than directly
>writing to the screen buffer. I need it to work from my terminal using
>procomm 242 on my office pc (host mode will not work with the out put
>going directly to the screen buffer). Any ideas?
I think WordStar 4.0 can be configured to use BIOS screen I/O. Also,
there is a version of MicroEmacs which uses ANSI escape sequences for
screen control.
------------------------------
Date: Fri, 05 Aug 88 19:25:21 -0700
From: Alastair Milne <milne@ICS.UCI.EDU>
Subject: Graphics with Turbo Pascal 4.0
I work for a University of California software project that develops
state-of-the-art educational software. We are in the process of moving
our software support into Turbo Pascal from a Pascal environment in a
different operating system. However, we are encountering a particular
problem with Turbo's graphics support that gives us a considerable
hindrance:
There appears to be no control of drawing logic for line or arc
drawing.
In our present system, a line or arc can be drawn:
- by replacing every pixel lying on the line with a new value, no
matter its original value;
- or by giving each of those pixels a new value which is the exclusive
or of its original value and the foreground colour value in which the line
is being drawn.
The latter is very useful for drawing things onto an existing display,
then undrawing them later with the original display remaining intact
underneath. We use this for many things, but particularly for letting our
screen support use as a graphics input device a small flashing crosshairs
that the user can manipulate with the cursor keys to point to a place on
the screen. Using XOr logic for drawing this lets it move anywhere, over
anything already drawn, and damage none of it.
These varieties of drawing logic (and several more ) are all supplied
for the Graph procedure PutImage. They are *not* supplied (anywhere I can
find) for line drawing.
1. Why not !!??
2. How has this problem been handled by other groups using graphics
with different types of drawing logic?
We are eager to get our screen support up and tested under Turbo, but
this lack of a fundamental capability is a real hindrance to us. Any
assistance would be much appreciated.
Thanks in advance,
Alastair Milne
Educational Technology Center,
U.C. Irvine
------------------------------
Date: Tue, 9 Aug 88 13:36:48 PDT
From: willis@violet.Berkeley.EDU (Willis Johnson)
Subject: How to tell the good DMA chips from the bad ones
I had problems with pseudo-simultaneous DMA channels about a year ago and
called an engineer at A.M.D. for help. This is what he told me:
Screening for the problem began in early 1986. Chips manufactured after
that date have a "B" added to their date codes. This "B" appears only on
screened 8237s. A.M.D. is not the only manufacturer of the 8237, however.
The design is licensed to many factories all over the world. If you buy
an A.M.D. chip, you can be sure it has been screened for this problem if
it has the "B" added to its date code, which has this format "B" 86 month
serial number.
I didn't follow this up with the other manufacturers. Most electronics
stores carry the 8237 from A.M.D. They're cheap, and easy to replace if
socketed :-).
Willis Johnson
2490 Channing Way, #503
Berkeley, CA 94704
willis@violet.BERKELEY.EDU
------------------------------
Date: Fri, 05 Aug 88 17:04:59 EDT
From: Ralf.Brown@B.GP.CS.CMU.EDU
Subject: INT 1Bh vs INT 23h (was Control-C trapping under MSC)
>Anyways, I used CodeView to set breakpoints on the first instruction of
>the INT 1BH and 23H interrupts and found that ONLY the INT 23H was called
>when CTRL+C was pressed. Any PC gurus out there that can tell me the
>difference between the INT 1B and INT 23?
INT 1Bh is called when the keyboard decoding routine in the ROM BIOS (INT
9h) detects that ^Break was pressed. DOS grabs INT 1Bh at bootup and
points it to a short routine that sets a flag. When doing an I/O call
that checks ^C (or if BREAK=ON), DOS peeks at the keyboard buffer, and if
the first character is ^C, or the break flag has been set, calls INT 23h.
So ^C is special only to DOS, while ^Break is special to the BIOS. If you
press ^Break, INTERCEP will show both INT 1Bh and 23h having been called,
while ^C will only call INT 23h because the BIOS passes the control-C on
as it does any other ASCII character.
--
{harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=-
AT&T: (412)268-3053 (school)
ARPA: RALF@B.GP.CS.CMU.EDU
FIDO: Ralf Brown at 129/31
BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA
|"Tolerance means excusing the mistakes others make.
| Tact means not noticing them." --Arthur Schnitzler
-=-=- DISCLAIMER? I claimed something?
------------------------------
Date: Mon, 8 Aug 88 11:55:09 EDT
From: stevel@eleazar.Dartmouth.EDU (Steve Ligett)
Subject: Parallel Port Reads
An issue of Micro Cornucopia had an article that described making a
parallel port bi-directional. There's an unused flipflop (in TTL
implementations of the parallel port) that can be used to control an
output enable that's normally grounded. A quick look at the PS/2 Model 50
& 60 Tech Ref indicates that IBM has made the PS/2 parallel ports
bi-directional in the same way.
From the software end - writing a "1" to bit 5 of port 3be, 27a, or 27a
(depending on whether it's LPT1, 2, or 3) makes the port an input port.
Writing a "0" returns it to normal.
Disclaimer - all this is from memory (mine, not my computer's).
--
Steve Ligett steve.ligett@dartmouth.edu or
(decvax harvard ihnp4 linus)!dartvax!steve.ligett
------------------------------
Date: Monday 01 Aug 88 1:03 PM CT
From: Robert Pearson <BBUXEIPD%UIAMVS.BITNET@CUNYVM.CUNY.EDU>
Subject: PK36.EXE Discussion
> From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
>
> Now available via standard anonymous FTP from SIMTEL20.ARPA...
>
> Directory PD1:<MSDOS.ARC-LBR>
> PK36.EXE.1 BINARY 117781 977FH
>
I would advise caution in using this program. There have been many
reports on FidoNet, that this program has a serious bug in it.
Apparently, the program takes control of two interrupt vectors, to prevent
debuggers from finding out how it works, but DOESN'T release them when
done. I personally know one person who had his hard disk FAT scrambled by
this program! From what I have heard, it works OK on most systems, but
can go beserk if you have some 'unuasual' hardware/software like an
accelerator card.... For my money it's not worth the risk. Until I hear
that this problem is solved, I'll continue to use version 3.5.
------------------------------
Date: Sat, 6 Aug 1988 11:11 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: PK36.EXE Discussion
Brad, "a rose by any other name...". The PK361.EXE file extracts to PKPAK
and PKUNPAK. Phil complied with the court order to cease using the name
"ARC". The programs are functionally the same as PK36, only the name has
been changed and some bugs fixed. Phil added some new features in 3.61,
too.
In my opinion the court erred in stating that "ARC" was a valid trademark.
I have a CP/M program in the archives here at SIMTEL20 that used the name
ARC long *before* there was even anything called MSDOS. It was written by
Jim Loposhinski, the author of the machine language "SQ120.COM", a Hoffman
compression program for CP/M. I hope someone will file a class-action
lawsuit to invalidate SEA's trademark because of prior (and "common") use.
The CP/M program created files with the extension ".ARC" and the program
was called ARC. If SEA's trademark is allowed to stand, every software
author that creates utilities to deal with ARC files is in danger of being
sued by SEA.
--Keith Petersen
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARPA [26.0.0.74]
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {decwrl,harvard,lll-crg,ucbvax,uunet,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
------------------------------
Date: Tue, 09 Aug 88 17:01:46 EDT
From: Bruce O'Neel <XRBEO%VPFVM.BITNET@CUNYVM.CUNY.EDU>
Subject: PS/2 Model 25 disks
I found cheap a ps/2 model 25 system which I purchased. It only has one
3.5 floppy but it looks like it would take another. Any ideas whose
floppy drives work? Question 2: Also looks like a hard disk could/would
fit. It's system board looks like a model 30 pictured in byte a while
back which had a hard disk. Which hard disks might work?
Thanks in advance!
bruce <xrbeo@vpfvm> on bitnet
301-921-9240 x12
------------------------------
Date: Thu, 4 Aug 1988 23:31 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: SEA versus PKWARE suit settled
[The following is an official release]
FOR RELEASE ON AUGUST 1, 1988
From: System Enhancement Associates, Inc. (SEA)
and
PKWARE, Inc. and Phillip W. Katz (PK)
August 1, 1988 - Milwaukee, WI
In the first known "Shareware" litigation, pending in the local United
States District Court, the parties System En- hancement Associates, Inc.
(Plaintiff - SEA) and PKWARE, Inc. / Phillip W. Katz (Defendants - PK),
after reaching agreement, consented to the entry of the attached Judgment
for Plaintiff on Consent. That Judgment was entered by Judge Myron L.
Gordon, effective on August 1, 1988.
Part of the agreement reached by the parties included a Confidential
Cross-License Agreement under which SEA licensed PK for all the ARC
compatible programs published by PK during the period beginning with the
first release of PKXARC in late 1985 through July 31, 1988 in return for
the payment of an agreed upon sum which was not disclosed. Additionally,
PK was licensed, for an agreed upon royalty payment, to distribute its
existing versions of PK's ARC compatible programs until January 31, 1989,
after which PK is not licensed and agreed not to pub- lish or distribute
any ARC compatible programs or utilities that process ARC compatible
files. In exchange, PK licensed SEA to use its source code for PK's ARC
compatible programs.
PK agreed to cease any use of SEA's trademark "ARC" and to change the
names or marks used with PK's programs to non-confusing designations.
The Judgment provided for the standard copyright, trademark and unfair
competition injunctive relief for SEA a- gainst PK, as well as damages and
litigation expenses to be paid by PK to SEA.
Both parties agreed to refrain from any comment concerning the
settlement of the disputes, other than the text of this press release.
Also, the parties instructed all of their representatives to refrain from
any such activity.
Any other details of the Cross-License Agreement were agreed to be
maintained in confidence and under seal of the Court.
In reaching the agreement to dispose of the pending litigation and to
settle the disputes that are covered thereby, PK did not admit any fault
or wrongdoing.
------------------------------
Date: Mon, 08 Aug 1988 09:52:47 CET
From: A0045%DK0RRZK0.BITNET@CUNYVM.CUNY.EDU
Subject: Printer to Disk Utility
I have tried several public domain programs, which redirect printer output
to a disk file and had the most success with a PC- Magazine utility named
PRN2FILE. This can be found on SIMTEL20/RPICICGE in the file
<MSDOS.PCMAG>VOL6N22.ARC
------------------------------
Date: Mon, 08 Aug 1988 09:52:47 CE