Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL (11/07/88)
Info-IBMPC Digest Mon, 7 Nov 88 Volume: 7 : Issue 47
This Week's Editor: Greg Hicks - Chinhae Korea COMFLEACT@taegu-emh.arpa>
Today's Topics:
The final (hopefully) word in the SEA/PKware situation
Copyrighting programs based on PD may be ruled invalid
More about the SEA / PK Ware discussion
SEA vs. PK suit
Today's Queries:
Does a SIMPLEX system effect P.C.'s?
MASM 5.0, SYMDEB bug?
VGA configuration question
New Programs Available:
jrv: New MSDOS uploads to SIMTEL20
lbrown: new msdos files
Additional RBBS-PC files uploaded to SIMTEL20
DOSTIPS2.ARC (the real one) now available
NARC and NARC
New MSDOS uploads (8 msgs)
WSSINDEX 3.38 at Simtel20
XEQ115.ARC and XEQ-116.ARC
ZCOMMEXE.ARC new version uploaded
----------------------------------------------------------------------
Date: Wed, 5 Oct 1988 11:08 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: The final (hopefully) word in the SEA/PKware situation
[Note from Keith: the following is from Usenet. It is forwarded "as-is".
The statement that PKWare is out of business is hearsay until proven
otherwise.]
---forwarded message---
Date: Wednesday, 5 October 1988 00:04-MDT
From: wucs1!wuibc!gmat@uunet.uu.net (Gregory Martin Amaya Tormo)
Newsgroups: comp.sys.ibm.pc,comp.binaries.ibm.pc.d
Re: The final (hopefully) word in the SEA/PKware situation
Keywords: PKware SEA ARC PKARC ZOO FIDO FIDONEWS
The following is a copy of the special fido news issue on the
SEA/PKware debate. It includes submissions from the Usenet community, the
BBS community, and a statement by Thom Henderson of SEA. Unfortunately,
there is no statement from Pkware or Phil Katz.
Furthurmore, it is my understanding that the second lawsuit has
been settled and PKware is now out of business, with an injuction against
Phil Katz from releasing any shareware program relating to the archiving
of files. I am most disappointed. Not because I believed PKware was
right and SEA was wrong, but because I honestly liked the PKware programs
better than the SEA ARC programs. With the facts as listed by SEA in this
newsletter, and without any contest of these facts by PKware, I must
conclude that SEA was fully in the right to pursue a legal course of
action. I wish there had been another way because we have all lost from
this mess.
Finally, I beseach the usenet community to heed Dave Dodell's
request for the Fidonet Echomails. Let us stop wasting money and time
debating the issue any further. We must plan for the future. I believe
that all archive sites currently banning SEA archives should end the
protest as it is a mute point based on the now known facts. I encourage
the use of both ARC and ZOO (although I have never used it), and challenge
programmers out there to port the current ARC and ZOO version to unix, and
to take SEA up on their source code policy and use it to create ARC to ZOO
and ZOO to ARC converters (assuming Zoo has the same policy as SEA or
would be willing to licence the code as necessary).
It is also my understanding that in the settlement of the second
suit, SEA assumes ownership of the technical specifications to the PKware
program PKpak. I challenge SEA to upgrade ARC to utilize the features and
speed that endeared me to the PKware programs in the first place. I see
no need to fight for a new standard, nor any reason to abandon the current
one. Rather we must accept the situation that has been thrust onto the
shareware community. What follows is the relevant text of the latest
issue of Fidonews (IFNA specific material deleted).
[Note from Keith: the rest of this has been deleted to keep this message
down to a reasonable size. For the full text of the Fidonews issue
quoted, see PD1:<MSDOS.FIDO>FIDONEWS540.ARC on SIMTEL20.]
------------------------------
Date: Tue, 4 Oct 1988 21:34 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: Copyrighting programs based on PD may be ruled invalid
In a recent response to Apple's "Look and Feel" lawsuit, HP maintained
that the Mac's graphical interface is based on work done by other
companies - in particular, Xerox Corp. HP's filing further alledged that
Apple obtained copyright registrations on the screen display fraudulently
by not disclosing to the U.S. Copyright Office that the Mac's display was
derived from Xerox's work.
> "In copyrights and patents, if there is prior art, it has to be reported
> at submission", said Bob Frankenberg, group general manager for the
> information systems group at HP. "Prior art, whether protected or in
> the public domain, can make your patent or copyright invalid."
This is an interesting turn of events. If this is upheld by the court it
could invalidate the copyrights of all shareware and commercial programs
which contain a substantial amount of public domain code.
I wonder how that would affect the SEA vs. PKWare suit?
Would it make ZOO's copyright invalid?
How about all the copyrighted file transfer programs out there which use
the Ward Christensen protocol (popularly called XMODEM) and all those
YMODEM and ZMODEM programs based on Chuck Forsberg's PD code?
LONG LIVE PUBLIC DOMAIN!
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARMY.MIL [26.0.0.74]
Arpa: W8SDZ@SIMTEL20.ARMY.MIL
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!simtel20.army.mil!w8sdz
------------------------------
Date: Saturday, 24 September 1988 17:47-MDT
From: ecsvax!dmkdmk@mcnc.org (David M. Kurtiak)
Subject: More about the SEA / PK Ware discussion
The following is an extract from a file that I downloaded off of a local
BBS. Here's how some of the SysOps are viewing the case:
------------==========> Cut Here <==========----------------
Date: 08-15-88 (13:57)
From: RICH GREENE
Subj: ARC FIASCO
I understand that V. Buerg lost his case with SEA ARC and he must cease
from distributing his program. Some of us Sysops in the Northwest are
considering changing to ZOO or use Mr. Buergs new program that he was
granted permission to distribute as soon as it's available. If you have
any information concerning the results of the lawsuit, please let us know.
This will place ALL sysops in a predicament in deciding which utility to
use and I know as with myself, it will be a pain in the you know what to
re-arc or do a Zoo on all of my 120 Megs.
Comments?
Date: 09-11-88 (17:00)
From: DON MARQUARDT
Subj: ARC FILES
With the recent push to have all authors of programs that use the ARC
format or extention pay licence fees to SEA, I am wondering what they are
going to do. Also since PCB has a view option, what does that do to the
feature as well as cost? As for myself, I am ready to convert ALL FILES
to whatever format Phil comes up with and eliminate ARC completly. Any
other comments? Hope I am not starting up another hornets nest but I am
not very pleased with the action taken by SEA as well as the method used.
Beat the little guy up till you force him to give up just because of
costs. Sounds like some other outfits that can't seem to stand the
competition.
Don Marquardt
Riverside Premium BBS 312-447-8175 PCPable
Multi-Tasking & DOORS ConfERENCE
Date: 09-11-88 (17:49)
From: MARSHALL DUDLEY
Subj: SEA LAWSUIT
On the SEA vs PK affair, it seems to me that SEA is getting in a real
legal bind. Let me quote some material from "BUSINESS LAW" The Dryden
Press, 1986. Refer to this book for a more complete analysis, especially
pages 948 - 962.
Sherman Anti-trust act - An 1980 congressional enactment that (1) made
illegal every contract, combination in the form of trust or otherwise, or
conspriacy in restraint of trade or commerce among the several states, and
(2) made it illegal for any person to monopolize, or attempt to
monopolize, or combine or conspire with any other person or persons to
monopolize any part of the trade or commerce among the several states.
The federal antitrust laws are enforced in several ways. Violations of
the Sherman Act are felonies and may be prosecuted in a federal district
court by the Antitrust division of the U.S. Dept of Justice. The FTC can
prosecute any violations of the Sehrman act since any violations of the
Sherman Act will also violate the Federal Trade Commission Act. Private
parties can also file civil lawsuits in a federal district court against
alleged violators of the anstitrust laws. The plaintiffs in such a
lawsuit usually are customers, suppliers, or competitors of the
defendants. The law permits successful plaintiffs to recover TREBLE
DAMAGES! Lawsuits by private parties are an important part of antitrust
enforcement - over 90% of all antitrust cases are instituted by private
parties.
Date: 09-11-88 (17:58)
From: MARSHALL DUDLEY
Subj: SEA LAWSUIT(S)
OPEN LETTER TO THE FTC AND JUSTICE DEPARTMENT
Dear Sirs:
There is a precedent being set in the computer area which will have a
tremenous impact on both the computer telecommunications industry and the
software industry in general. The vast majority of software for personal
computers is written by other than large corporations, and this tremendous
resource could be lost almost immediately. The precedent of which I speak
is the affair where the two predominate sources of archieving programs
have reached an agreement where the first, System Enhancements Associated,
will receive the source and hold all claims to the work of the second, PK
Ware. This agreement was reached after an anti-competitive lawsuit was
filed by SEA against PK to force it's main competitor out of business.
They have effectively done this. SEA is now approaching other programers
who have written utilities to interface with the standard ARC format.
Basically every programmer or company which has embraced this format,
which was previously assumed public domain, is being threatened with a
lawsuit by SEA now. This is virtually the same as if Lotus sued everyone
who wrote a program to read data captured by 123, or by MicroSoft for
writing programs which work with DOS. This has already had a chilling
effect on independent programmers, those who are the backbone of the
personal computer business. Fact is there is very little software that
does not depend on interactions with other programs. If this precedent is
allowed to stand, the computer software industry will be fragmented, where
each company's and each programmer's programs will only work with with
their own software. This must not be allow to happen.
SEA is also claiming rights to the word ARCHIEVE and the extension ARC.
ARCHIEVE is a word which has a long history. The IBM computer has a bit
called the archieve bit, and some archieves (not computer) date back to
early Greek times. There are only 17,576 possible 3 letter extensions.
To allow a company or individual exclusive right to any of these few
extensions would make it impossible to write any software after all
extensions have been "claimed". The claiming of an extension for
exclusive use is monopolistic.
I implore you to investigate this apparent violation of the antitrust laws
before irreparable harm is done. This "agreement" must be declared in
violation of the Sherman Act. Be aware that virtually 100% of all public
domain software, shareware, and demo-ware is "ARCed" up for distribution.
Well over 90% of all files transferred via tele- communications are in the
ARC format. To allow this to be taken from the many computer users should
not be taken lightly. To allow every programmer to feel that writing a
simple utility to enhance another program can result in a devastating
lawsuit will result in loss of the computer industry's most important
resource, their programmers.
----------------------end of letter--------------------------------
I have seen several "letters" intended to be sent to SEA to try and get
them to reconsider their actions. I think letters to the FTC, and Justice
dept. might be more effective. I do think the agreement and actions by
SEA are in violation of the Sherman act. Lets everyone take up a pin and
write to one or both of these departments.
Marshall Dudley
Date: 09-12-88 (08:10)
From: DOUG LAINE
Subj: SEA
I agree with everyone about the fact that SEA is really getting out of
hand. Personally, as soon as Phil can come out with a new format, I will
take as much time as needed and convert EVERY file on my system to the new
format. Im sorry if this is provocing (spelling) this argument, but I am
glad to see that there are other Sysops anoyyed by this entire deal.
Doug
(Philly Exchange 215-563-8109 MNP5 -8137 HST)
Hope this may be of some use to those still following this fiasco.
David M. Kurtiak
UUCP: dmkdmk@ecsvax.UUCP {rutgers,gatech}!mcnc!ecsvax!dmkdmk
Bitnet: DMKDMK@ECSVAX.BITNET
Internet: dmkdmk@ecsvax.uncecs.edu
------------------------------
Date: Friday, 23 September 1988 12:21-MDT
From: tektronix!tekgen!tekigm2!timothym@beaver.cs.washington.edu
(Timothy D Margeson)
Subject: SEA vs. PK suit
Okay,
Enough is enough.... Does anyone have the address of the judiciating
court? And the judges name? If you do, send it to me, or post it as well.
If even 100 of us readers write letters to the judge, explaining that ar-
cing is a term used to compressing files long before ARC.XXX arrived, then
perhaps we can get this case thrown out of court.
We will need to express in the letter our credentials, to back up our
statements. College students who haven't worked in the field are invited
to write as well, but we really need 5 or more year veterans of the
computer industry.
Those interested in supplying a group letter may contact me.
--
Tim Margeson (206)253-5240
PO Box 3500 d/s C1-937 @@ 'Who said that?'
Vancouver, WA. 98668
e-mail replies to: timothym@tekigm2.UUCP or timothym@tekigm2.TEK.COM
------------------------------
Date: Wed, 17 Aug 88 10:34:55 CDT
From: "Daniel L. Laser" <COMC14@TRINITY>
Subject: Does a SIMPLEX system effect P.C.'s?
As a University we have a "SIMPLEX" system that rings the class bells on
campus. This system sends out a high frequency signal over the campus
power grid every half hour. We are wondering if these signals are
getting through our P.C. power supply filters and causing "gliches".
Specifically, we are having a lot of failures of "hard drives" for
applications that are long running.
Information / comments on the above will be greatly appreciated.
Daniel L. Laser - Associate Director
Trinity University Computing Center
------------------------------
Date: Mon, 10 Oct 88 10:10:37 EDT
From: David Kirschbaum <kirsch@braggvax.arpa>
Subject: MASM 5.0, SYMDEB bug?
Netlandians,
Can anyone tell me why the following code won't assemble/link correctly?
I'm using MASM 5.0. The compiled code goes bad when testing BX, CX, DX
for 0FFFFH (ends up with "-1").
Doesn't matter whether you use the macro MAX or hard code the "0FFFFH"
directly.
For that matter, fire up SYMDEB and try to enter these assembly
instructions directly:
a 100
mov ax,ffff
mov bx,ffff
mov cx,ffff
mov dx,ffff
mov si,ffff
mov di,ffff
<return>
u 100
Don't EVEN look like what you just directed! Ends up with:
mov ax,ffff
mov bx,-01
mov cx,-01
mov dx,-01
mov si,-01
mov di,-01
Gad, can't BELIEVE this! What's magic about 0FFFFH?
Following is a .LST extract from my compilation, matches the linked .EXE
or .COM file.
Microsoft (R) Macro Assembler Version 5.00 10/8/88
16:53:36
0000 cseg segment public para 'code'
assume cs:cseg, ds:cseg
= FFFF MAX equ 0FFFFH
0100 org 100h
0100 bogus:
0100 B8 FFFF mov ax,MAX
0103 BB FFFF mov bx,MAX
0106 B9 FFFF mov CX,max
0109 BA FFFF mov DX,max
010C 3D FFFF cmp ax,MAX
010F 75 0F jnz exit
0111 83 FB FF cmp bx,MAX
0114 75 0A jnz exit
0116 83 F9 FF cmp cx,MAX
0119 75 05 jnz exit
011B 83 FA FF cmp dx,MAX
011E 75 00 jnz exit
0120 exit:
0120 cseg ends
end bogus
David Kirschbaum
Toad Hall
kirsch@braggvax.ARPA
--- CUT HERE ---
MAX equ 0FFFFH
cseg segment public para 'code'
assume cs:cseg, ds:cseg
org 100h
bogus:
mov AX,MAX
mov BX,MAX
mov CX,MAX
mov DX,MAX
cmp AX,MAX
jnz exit
cmp BX,MAX
jnz exit
cmp CX,MAX
jnz exit
cmp DX,MAX
jnz exit
exit:
cseg ends
end bogus
------------------------------
Date: Fri, 23 Sep 88 13:04:45 PDT
From: saus@venera.isi.edu (Mark Sausville)
Subject: VGA configuration question
Hope this isn't too vague.
I dial into work using Kermit on my AT clone. I would like to be able to
get a hardware/software configuration such that I can do the following:
1. Dial in to another host and emulate a terminal with a big screen. I'd
like 60+ lines vertically if possible, but I could make do with less.
2. Run standard EGA applications transparently.
I was told that I could get 60 lines on standard VGA. Source for Kermit
is available, so I planned to hack the h19 emulator on the PC end and hack
the h19 termcap at the unix end, also making the assumption that my EGA
programs would just work with a VGA video board.
Then I tried to buy it. Haha!
I was told that there isn't a convenient way (without DOS 4.0) to put the
video board into a ~60 line mode, and that I would need a special VGA
driver program for any application I want to run under VGA.
Can someone recommend a monitor/video board combination (and possibly a
telecom program) which will do what I want.
I, naively I guess, never knew that the graphics situation on clones was
so complex. I'd be grateful for some order in all the confusion.
Thanks,
Mark.
Mark Sausville saus@venera.isi.edu 213-822-1511
University of Southern California Information Sciences Institute
4676 Admiralty Way, Marina del Rey, California 90292
------------------------------
Date: Sat, 8 Oct 1988 20:58 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: jrv: New MSDOS uploads to SIMTEL20
> From: James R. Van Zandt <jrv at mitre-bedford.ARPA>
I have uploaded the following programs to SIMTEL20...
PD1:<MSDOS.C>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. This ARC includes
source code, executables, and documentation for both. From Marvin
Hymowech's article in DDJ #142 (August 1988), transcribed and
modestly enhanced by James R. Van Zandt <jrv@mitre-bedford.arpa>.
PD1:<MSDOS.TROJAN-PRO>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. 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 <jrv@mitre-bedford.arpa>.
- Jim Van Zandt
------------------------------
Date: Wed, 28 Sep 1988 14:05 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: lbrown: new msdos files
Thanks, Les!
>From: "Leslie C. Brown" (USATHAMA|SYS|Chris) <lbrown at BRL.MIL>
I've uploaded the following files:
<msdos.sysutl>
TUTOR44.ARC latest version of the computer tutorial replaces comptutr.arc
<msdos.dskutl>
AUTOPARK.ARC parks hard disk after set time of inactivity
<msdos.editor>
TURBOQED.ARC configuration file for using turbo with qedit
<msdos.printer>
P4UP.ARC laser printer driver
<msdos.bbs>
X00V111A.ARC fossil driver version 1.11a
<msdos.modem>
JMODEM.ARC PD modem program uses xmodem with large blocks
<msdos.dskutl>
FBR163.ARC V.D. Buerg's fast backup and restore
These files are now in the PD1:<MSDOS.DESQVIEW> directory.
DESQ10 contains Turbo Pascal 4 routines for several of the most basic API
calls
DPC is a printer setup program that runs in a window under DESQview, APX
Core,
Double DOS, or MultiLink.
DV2_DOS3 explains one way to get more environment space
DVUNDOC lists a variety of undocumented DESQview features
PRINTDV prints a file in the background
QWIK42 is a newer version of QWIK40 already in the archive, but you should
keep the older version since WNDW40 requires QWIK40. I haven't
seen
WNDW42.ARC yet.
> I uploaded CNEWS009.ARC, CNEWS010.ARC and CNEWS011.ARC tonight. To be
> added to the rest of the CNEWS collection. The missing issues (4, 5,
> 6, and 7) will be sent at a later date after downloading from a local
> BBS.
I moved them to the PD1:<MSDOS.C> directory.
DOSTIPS2.ARC has been uploaded.
I have moved the file to PD1:<MSDOS.SYSUTL> and renamed the old (not
part of this series) file to DOSTIPS.ARC.
<msdos.sysutl>
SYSID30.ARC extensive system information with turbo pascal source
<msdos.lotus123>
123_SEEK.ARC 123 add-in search and replace function
---
Thanks, Les!
--Keith
------------------------------
Date: Mon, 10 Oct 1988 20:49 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: Additional RBBS-PC files uploaded to SIMTEL20
The following additional files have been added to the RBBS-PC collection.
Filename Type Bytes CRC
Directory PD1:<MSDOS.TEMP>
171A-ASM.ARC.1 BINARY 61509 9C13H
171A-BAS.ARC.1 BINARY 358019 44E3H
171A-CFG.ARC.1 BINARY 66406 7113H
171A-EXT.ARC.1 BINARY 86041 EFB9H
Here are the short descriptions for all the files in the RBBS package:
171A-ASM.ARC RBBS 17.1A source code - Assembler + OBJ's
171A-BAS.ARC RBBS 17.1A source code - Basic code
171A-CFG.ARC RBBS Convert 141d-161a DEF files to 17.1A
171A-DOC.ARC RBBS 17.1A documentation
171A-EXE.ARC RBBS 17.1A executables
171A-EXT.ARC RBBS 17.1A externals (same as 15.1c/16.1A)
171A-NEW.ARC RBBS Extra doc on just new 17.1A features
171A-UTL.ARC RBBS 17.1A optional utils-MU-PURGE/RECONFIG
--Keith
------------------------------
Date: Wed, 28 Sep 1988 12:54 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: NARC and NARC
Ralf, I saw a message from you on Usenet which said that NARC was only a
shell for PKARC/PKPAK. I can understand the confusion since there appear
to be two different programs called NARC.
One, a shell for PK*, has been around for quite a long time. The other,
written by Gary Conway, is a stand-alone program which is written entirely
in assembly language. Recently the latter was bundled with IDCSHELL and
released as IDC20.ARC, which you'll find in the PD1:<MSDOS.ARC-LBR>
directory. Gary has done a super job with IDCSHELL and NARC24. I use
them frequently and am a registered owner.
NARC24 doesn't make ARCs. It's more like a slashbar (mouse capable)
version of PKUNPAK.
--Keith
------------------------------
Date: Sun, 2 Oct 1988 01:23 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: New msdos upload
<msdos.keyboard>
BUF160_4.ARC - Device drive to expand BIOS keyboard buffer [w/ASM src]
ARC contains original source and driver, plus tweaked and
commented update (BUF160_4.ASM and .DVD).
Kudos to the original author!
<msdos.screen>
CONCOPY.ARC - Copy to a file all standard output to screen.
Snarfed from SEMPER BBS, Fayetteville NC.
Seems to work OK, will probably disassemble and tweak
later.
<msdos.asmutl>
PRIAC1.ARC - Inter-Applications Communications area expanded demo.
v1.1 has .COM format, demonstrates how to read AND write
data to the IAC for later program use.
Original and tweaked .ASM source and executables.
<msdos.filutl>
TOADUU16.ARC - Squashed more bugs in UUD16.ASM (harder this time).
Throw away earlier TOADUU.ARC's, UUD.ASM's, UUD.COM's.
This is a machine language uuencode/uudecode, very fast.
Corrects for lost trailing spaces, too.
<msdos.editor>
ACE124.ARC - Freeware Programmer's Editor
<msdos.dskutl>
SCAV31.ARC - Report/allocate bad disk sectors (w/ASM)(updated)
Report and optionally allocate bad sectors on hard disk
or floppy. Full assembler source (original v3.00 and
tweaked v3.01), compiled v3.01, short documentation.
David Kirschbaum
Toad Hall
kirsch@braggvax.arpa
Thanks, Dave!
--Keith
------------------------------
Date: Tue, 4 Oct 1988 11:44 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: New msdos uploads
The popular PMCAT disk catalog program has been updated.
Filename Type Bytes CRC
Directory PD1:<MSDOS.CATALOG>
PMCAT37.ARC.1 BINARY 52638 755DH
--Keith
------------------------------
Date: Sun, 25 Sep 1988 00:28 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: New MSDOS uploads
New files uploaded to SIMTEL20...
Filename Type Bytes CRC
Directory PD1:<MSDOS.ASMUTL>
PRENV.ARC.1 BINARY 2975 9D58H
PRIAC.ARC.1 BINARY 2866 C7D9H
SWITCH.ARC.1 BINARY 3462 BF8EH
PRENV demonstrates how to read this program's copy of the parent's
environment created by COMMAND.COM ... For DOS Ver 3.x, the fully
justified path name of this program will also be displayed. The
executable and the assembly source are supplied.
The environment consists of null-terminated ASCII strings (ASCIIZ), with
the entire list terminated by another null. A 2-byte entry at offset 2Ch
in the program's program segment prefix (PSP) contains the segment of the
copy of the environment. The code commenting, wording of printing
messages and some of the code itself have been changed in a number of
places.
PRIAC reads and reports the current contents of the Inter-Application
Communications Area (IAC). The executable and assembly source are
included.
The IAC is 16 bytes beginning at addr 0040:00F0h. Any program can write
information to the IAC for another program to read. The IAC can be used,
for instance, to pass an address from one program to the next.
SWITCH demonstrates one way to read single-letter switches from the
command line. The command line switches are received by the program from
the program segment prefix (PSP) beginning at offset 80h. The executable
and assembly source are supplied.
The program uses a single memory word (one bit per switch) to store
information for 16 switches, assumed to be /A through /P. All switches
are treated as toggles. The code commenting, wording of printing messages
and some of the code itself have been changed in a number of places.
--Keith
------------------------------
Date: Saturday, 8 October 1988 19:01-MDT
From: "James R. Van Zandt" <jrv@mitre-bedford.ARPA>
Subject: New MSDOS uploads to SIMTEL20
PD1:<MSDOS.C>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. This ARC includes
source code, executables, and documentation for both. From Marvin
Hymowech's article in DDJ #142 (August 1988), transcribed and
modestly enhanced by James R. Van Zandt <jrv@mitre-bedford.arpa>.
PD1:<MSDOS.TROJAN-PRO>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. 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 <jrv@mitre-bedford.arpa>.
- Jim Van Zandt
------------------------------
Date: Sun, 9 Oct 1988 22:01 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: New MSDOS uploads to SIMTEL20
I just uploaded the following new files to SIMTEL20...
Filename Type Bytes CRC
Directory PD1:<MSDOS.ARC-LBR>
NO-ARC3.ARC.1 BINARY 16258 B46AH
The third version of FIGHTSEA, how to fight the SEA ARC problem. Many new
names of BBS SysOps, software authors, and commercial users have been
added to the endorsement list at the end of the file and additional
details about the situation have been included.
--Keith
------------------------------
Date: Tue, 4 Oct 1988 09:44 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: WSSINDEX 3.38 at Simtel20
From: Bob Babcock <PEPRBV%CFAAMP.BITNET at MITVMA.MIT.EDU>
Version 3.38 of my shareware disk indexing program Wssindex is now
available from Simtel 20 in the PD1:<MSDOS.CATALOG> directory, replacing
version 3.22 formerly there. File names are WSSI338A.ARC and
WSSI338B.ARC.
This is a major upgrade, the most noticeable addition being the option to
do direct video writes for speed. The code size has been decreased and
the capacity increased by switching to Turbo C 1.5.
------------------------------
Date: Fri, 23 Sep 1988 19:37 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: XEQ115.ARC and XEQ-116.ARC
>From: Ralf.Brown at B.GP.CS.CMU.EDU
>
>After downloading PD1:<MSDOS.ARC-LBR>XEQ-116.ARC, I discovered that it
>is in fact version 1.15, which was already in the library.
After receiving that from Ralf I asked Dave to look into what the
differences were as the CRC's didn't match and the datestamps were
different.
From: David Kirschbaum <kirsch at braggvax.arpa>
Keith, the message you forwarded to me showed a CRC difference between the
XEQ.COM files in XEQ115.ARC and XEQ116.ARC.
I'd suggest throwing out the XEQ116 package entirely .. nothing gained
there at all, and just confusing.
I've disassembled the program .. no problems within re viri, etc. It's a
kludge, reminds me strongly of good old LU's filename organization, and
some keyboard macro programs I've seen.
David Kirschbaum
Toad Hall
kirsch@braggvax.ARPA
Thanks, Dave! XEQ-116.ARC has been deleted from the archives. XEQ115.ARC
remains as the correct latest version we are aware of.
Appologies to anyone inconvenienced by the bogus upload, obtained from a
usually reliable local BBS in Detroit.
--Keith
------------------------------
Date: Tue, 27 Sep 1988 00:53 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARMY.MIL>
Subject: ZCOMMEXE.ARC new version uploaded
I just uploaded Chuck Forsberg's ZCOMMEXE.ARC which has been recently
updated (file date 1-Sep-88). The other ARCs in the ZCOMM package remain
the same.
Filename Type Bytes CRC
Directory PD1:<MSDOS.ZMODEM>
ZCOMMEXE.ARC.7 BINARY 154944 45DDH
--Keith
------------------------------
**********************
End of Info-IBM Digest
-------