Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL ("Info-IBMPC Digest") (05/28/90)
Info-IBMPC Digest Mon, 28 May 90 Volume 90 : Issue 97
Today's Editor:
Gregory Hicks - Chinhae Korea <GHICKS@WSMR-Simtel20.Army.Mil>
Today's Topics:
ARC file
Compressed Files and Virus Scanning
DHRY0217.ZIP - Dhryston benchmark with LOTS of results, Turbo C TC's
Kermit screen intensity (inverted?)
overwriting the psp
PKZIP 1.20 is bogus
OSI Communications Protocol
Recent msdos uploads to SIMTEL20
TIDY6.ZIP - Clean up FORTRAN-77 programs w/FORTRAN src
Directory Listings for PC-BLUE
Using EMS in TSRs
Where's McAfee's ACS Software (PC)
Getting 640K in IBM-AT
Send Replies or notes for publication to:
<INFO-IBMPC@WSMR-SIMTEL20.ARMY.MIL>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to:
<INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
The Lending Library is available from: WSMR-SIMTEL20.ARMY.MIL (see file
PD1:<MSDOS.FILEDOCS>AAAREAD.ME details on file directories and
descriptions.)
Archives of past issues of the Info-IBMPC Digest are available by FTP
only from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.
WSMR-SIMTEL20.ARMY.MIL can be accessed using LISTSERV commands from
BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe from EARN
TRICKLE servers. Send commands to TRICKLE@<host-name> (example:
TRICKLE@TREARN). The following TRICKLE servers are presently
available: AWIWUW11 (Austria), BANUFS11 (Belgium), DKTC11 (Denmark),
DB0FUB11 or DTUZDV1 (Germany), IMIPOLI (Italy), EB0UB011 (Spain),
TAUNIVM (Israel), and TREARN (Turkey). SIMTEL20 is not accessable on
the first Wednesday of each month from 6-8pm Eastern Standard Time.
If you are unable to access SIMTEL20 via Internet FTP or through one of
the BITNET/EARN file servers, most MSDOS SIMTEL20 files, including the
PC-Blue collection, are available for downloading on the Detroit
Download Central network at 313-885-3956. DDC is a networked system
with multiple lines that support 300, 1200, 2400, and 9600 bps (HST).
This system is a subscription system with an average hourly cost of 17
cents per hour. It is also accessable on Telenet via PC Pursuit and on
Tymnet via StarLink outdial. New files uploaded to WSMR-SIMTEL20 are
usually available on DDC within 24 hours.
----------------------------------------------------------------------
Date: Sat, 19 May 90 12:23:31 CDT
From: rs.miller@pro-harvest.cts.com (Randy Miller)
Subject: ARC file
Mr. Travsky,
In for article that appeared in the May 7th edition of the
Info-IBMPC digest, you were trying to determine the type of archiving
used to compress files that are needed by your colleagues. May I
suggest a program called IFL?
While it will not extract the files from the archive, it WILL tell
you what program did the compression. If you need the program, please
drop me email, as I do not have FTP from this system. Randy Miller
Randy Miller
Follett Software Company
rs.miller@pro-harvest
fsc@pro-harvest
GEnie: rs.miller
America Online: rsmiller
Never teach a pig to sing. You'll drive yourself nuts, and annoy the pig!
------------------------------
Date: Sun, 20 May 90 10:40:03 -0700
From: Alan_J_Roberts@cup.portal.com
Subject: Compressed Files and Virus Scanning
This is a forward from John McAfee:
Rich Garzon's posting, (VIRUS-L Digest V3 #96) about the dangers of
LZEXE compressed files, mirrors the real and growing problem with
people planting viruses inside such self-extracting executables. LZEXE
has become extremely popular and is readily available to anyone wishing
to hide a known virus and distribute it. Nearly all EXE files can be
compressed with LZEXE and one need only infect a given file with a
common virus, LZEXE it, and the end result is a functioning program
carrying a non-detectable virus. The average user cannot distinguish a
compressed executable from a non- compressed version in most cases.
In addition to purposefully planting viruses inside LZEXE'd files,
many cases have surfaced where end users have inadvertently compressed
already infected files for their own use. These files have then been
passed around to friends and co-workers.
After a virus begins to spread from one of these self- extracting
executables it can readily be identified. But the problem, of course,
is that the disinfection process usually skips over the compressed
carrier program -- since it can't be identified with normal scanning
techniques -- and the virus begins spreading all over again.
The issue is further complicated by the fact that LZEXE compressed
files may carry an external infection as well as an internal infection.
What this means is that a virus inside such a file may re-infect the
compressed executable as if it were a normal EXE file. The virus fails
to detect that it has already infected the program (internally). This
external infection may be cleaned using a disinfector and yet the file
will still be infectious. This adds confusion to the end user who is
trying to deal with an infection.
All in all this is becoming a serious problem. Numerous shareware
and commercial packages (SHEZ, CHECKOUT, etc.) have been developed as
companion programs to allow VIRUSCAN to scan inside ZIP, ARC, LZH, ZOO,
PAK and other non-self extracting archive files. Even without special
utilities, the non-self extracting archives do not represent a serious
problem because the user may simply UNZIP (or UNARC etc.) the archive
and then scan the contents prior to execution. But no-one has yet
addressed the LZEXE problem.
Since we are not compression specialists, we were hoping for someone
competent in the field to develop another SCAN companion program, like
SHEZ, to do the internal scanning. This has not happened. Therefore,
version 63 of SCAN, to be released June 1, will contain its own
internal scan capability for LZEXE compressed files. It automatically
identifies LZEXE compressed files and scans inside them.
The program works fine and successfully identifies all the known
viruses inside such files, but it probably is not as fast as it could
have been if it had been developed by hands more experienced in
compression/decompression algorithms. Nevertheless, it's all that we
have for now and it works. If you have only a few LZEXE compressed
files in your system, you probably will not notice a significant
slowdown in the scanning process. If you have no such files, the scan
time will be the same as before. If ALL of your files are LZEXE'd,
then I'd suggest you go out for coffee and donuts during the scan, or
possibly take a brief nap, catch up on your paperwork or do a few
calisthenics -- you'll have plenty of time. We have included a switch,
by the way, to turn off the internal LZEXE scan if you choose.
John McAfee
408 988 3832 - voice
408 970-9727 - fax
408 988 4004 - BBS
------------------------------
Date: Sun, 20 May 1990 17:35 MDT
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: DHRY0217.ZIP - Dhryston benchmark with LOTS of results, Turbo C TC's
[--forwarded message--]
From: David Kirschbaum <kirsch@usasoc.soc.mil>
I have uploaded to SIMTEL20:
pd1:<msdos.info>
DHRY0217.ZIP Dhryston benchmark with LOTS of results, Turbo C TC's
Someone asked for a Dhrystone benchmark executable for the PC. I first
found a somewhat old one from Dr. Dobbs Magazine. It needed slight
tweaking to compile under Turbo C v2.0, and the results were
suspicious.
Keith Petersen then suggested I check around for more current versions.
He specifically pointed me at DHAMP.C and DHRYSTON.C in SIMTEL20's
UNIX-C archives.
DHAMP.C is somewhat newer, but quite different from the widely
distributed and tested DHRYSTON.C. I'm ignoring it.
The most recent DHRYSTON.C I could find was right on my own host, and
is more recent than the DHRYSTON.C Keith pointed me at. This is a
version dating from Feb 86 or so, and includes a bug report. Lots of
results from different systems .. so this is the one I'm going with.
(It's been renamed to DHRY0217.C to keep it separate from all the
others floating around.)
I'm including two Turbo C ".TC" files to help you make your own
versions for testing. Comments in DHRY0217.C explain about results
with and without registers.
The DHRY0217.EXE in DHRY0217.ZIP has been compiled with registers
optimization for best possible results.
I'm throwing in a little text file that discusses benchmarks and how
they should be used (snarfed from yet ANOTHER benchmark package) just
to keep benchmarkers honest.
If you want the Unix version (and/or the big .shar file with LOTS of
benchmarks), yell.
David Kirschbaum
Toad Hall
[--end forwarded message--]
Thanks, David! Please contact Dave Curry
<DCurry@WSMR-SIMTEL20.ARMY.MIL>, the manager of the Unix-C archives,
for upload instructions for the Unix version. I'm sure he'll want them
to replace the earlier version which reportedly has bugs.
--Keith
------------------------------
Date: Fri, 18 May 90 19:57 MDT
From: Joe Doupnik <JRD@cc.usu.edu>
Subject: Kermit screen intensity (inverted?)
In a recent issue of the Kermit Digest a comment arose about inverted
screen intensity in MS-DOS Kermit's terminal emulator. It is really simple,
but a little "setup" might help.
If you have a color system then much more often than not the screen
is run as say bold white on a blue background. We do that because the non-bold
white looks more like grey. So, to such users bold is a "normal" screen.
On DEC terminals the screen intensity is normally half way up and bold
makes things super bright. Most DEC utilities put the screen in this DEC
"normal" condition, very often.
Now we are ready for the meat of this discussion. Suppose Kermit obeyed
DEC commands to make the screen dim most of the time. This would be contrary
to conventional DOS usage. Ok, now suppose the DOS screen is taken as the
"normal" value so that when the DEC programs say normal then we get the DOS
intensity as the result. The other intensity is DEC bold, so we'd have to use
the other IBM intensity, dim. That's what Kermit v3.0 does. Normal is what
we see 99% of the time and Kermit says that's the DOS screen intensity,
else DEC bold is the other (dim) way.
If your DOS screen is greyish then Kermit will make it bright when
DEC commands a bold attribute.
Now I used "DEC" to mean the external host, clearly. Here's another
gotcha between DEC and IBM. IBM controls the intensity of only the foreground
colors, but DEC means any illuminated dot. This yields some difficulties of
representation but Kermit copes with those as best as possible.
So, in summary what Kermit will use for a DEC normal intensity is
exactly what you use as a normal intensity, and DEC bold is the only other
alternative. See, I said it would be simple!
Joe D.
------------------------------
Date: Fri 18 May 90 19:14:41
From: tweten@prandtl.nas.nasa.gov
Subject: overwriting the psp
From: djb@wjh12.harvard.edu (David J. Birnbaum)
>... if it isn't too much trouble, I'd be interested in taking a look
>at the source for the tsrs you mention.
I've enclosed the source code for my simplest TSR for illustration of the
following points:
1. By using the undocumented MS-DOS INT 21 function 52H, you can
find the beginning of the chain of MS-DOS memory blocks. Run that
chain and you will find all environment and code blocks in the machine
(see the code after "blkscn" and the data structure at
"BLK_HDR_SEGMENT").
This is a better way to find a previously installed copy of a TSR
than is use of any MS-DOS interrupt such as the MicroSoft-recommended
"multiplex interrupt", 25H. Even if you use an interrupt MicroSoft has
"reserved for user programs" all that means is that the inevitable
collision will be with some third party's program rather than with
MicroSoft's.
If you run the list of memory blocks, you can string compare some
portion of the block's contents with your own code. If the string is
long enough and if it matches, you can bet it is another copy of your
TSR. The most important considerations in selecting a "signature" to
compare are to make sure that it is long enough and is unchanging. The
machine instructions in the resident portion of your program will do
nicely. Just be sure not to embed any variable data in the comparison
range, or you'll never find it.
The technique can be used for simple duplicate detection, or can be
used to pass new parameters to the existing TSR without having to use
interrupts and risk collisions (see all references to "sibling").
2. In a TSR, the non-resident code and data should be positioned
at the end of the program, so their space can be surrendered at initial
termination (see the code at "START" and "go").
3. You can deal with the changed addresses of code relocated into
the tail end of the PSP by modifying CS (see all references to
"res_offs") before entry to the code, so it compensates for the move.
That requires that the code be originally assembled at a location an
even multiple of 16 bytes away from its final destination in the PSP.
The result may be the "waste" of a few bytes in the initial .COM image
(range between "START" and "beg_pr"), but you don't care because no
space is wasted after termination.
Some care must be devoted to the segment registers. In the included
program, I simply told the assembler not to use any segment registers
but CS (see assume directive after "_TEXT"). This works well if you
have few instructions which use another segment register by default;
MASM will automatically prefix any such instructions with a CS segment
override.
If there would otherwise be a lot of prefixes, it may be worthwhile
to save and restore initial contents of some other segment registers,
and give them new values derived from CS. If you do so, be sure to
reflect that fact in your "assume" directive.
I hope all this helps. Good luck.
----------------------------8<--- CUT HERE ---8<--------------------------
page 58,132
TITLE Go -- Control (and measure) speed for Heath/Zenith PC
; (c) Copyright 1987 David E. Tweten
; All rights reserved. Permission for distribution is granted
; provided that no direct commercial advantage is gained, and
; provided that this copyright notice appears on all copies.
; --------------------------------------------------------------------
;
; Go serves three purposes relating to Dante Bencivengo's "TurboPlus
; V2.0" modification to 4.77 MHz Heath/Zenith PCs. It permits FORMAT
; and VERIFY ON to work. It also permits the user to speed or slow
; the processor. Finally, it measures the processor's speed setting
; (primarily for batch file use). "TurboPlus", the predecessor
; version of "TurboPlus V2.0", was described in the June, 1986 issue
; of REMark, the journal of the Heath/Zenith Users' Group.
;
; Due to a quirk in the diskette BIOS, errors will occur when a track
; format or verify operation is requested at any high speed, or when
; any diskette operation is attempted at 8 MHz. The terminate-and-
; stay-resident portion of this code will prevent the errors from
; occuring by slowing the processor for the duration of the
; operation, unless it is already operating at the slow (4.77 MHz)
; speed.
;
; The optional switch for Go can specify the speed to use when not
; formatting or verifying a floppy disk. It can be "f", which will
; set the clock speed to fast, or it can be "s", which will set the
; clock speed to slow. In any but its initial (TSR installing) call,
; if no switch is given, Go does not change the speed setting. On
; the initial call, if no argument is given, Go assumes "f". Go uses
; whatever switch character is current.
;
; The termination code for Go is set according to the processor speed
; at call, and by whether or not it has previously been called. The
; meaning of its termination code is as follows:
;
; 0 - Go has been called before so the TSR portion is already
; resident. Before the call the clock was set to run at
; 4.77 MHz.
;
; 1 - Go has been called before so the TSR portion is already
; resident. Before the call the clock was set to run at
; its fast speed.
;
; 2 - Go has not been called before. This call installed the TSR
; code and set the clock speed to the specified value (either
; Fast or Slow). If no speed was specified on the call, the
; default of Fast was used.
;
; 3 - Go has been called in error. It did nothing.
;
; NOTE that the actual processor speed is the slower of the speed
; specified and detected by Go, and the speed specified by the
; hardware switch included in the "TurboPlus V2.0". The actual speed
; is indicated by the LED included with the "TurboPlus V2.0" package.
;
; Written by: David E. Tweten <tweten@prandtl.nas.nasa.gov>
;
; 12141 Atrium Drive
; Saratoga, CA 95070
;
; (408) 446-4131
;
; Inspiration: FV.COM, a program of unstated authorship, included on
; the "TurboPlus" software disk.
;
; Modification History:
;
; 1.0 5-10-87 Initial version.
;
; --------------------------------------------------------------------
[Source code and the text of this message has been uploaded to
SIMTEL20. Suggested location was PD1:<MSDOS.SYSUTL>SPEED.ZIP.]
------------------------------
Date: 16 May 90 10:55:42 GMT
From: ralf@b.gp.cs.cmu.edu (Ralf Brown)
Subject: PKZIP 1.20 is bogus
(389) Tue 15 May 90 10:12
By: Stu Turk
To: All
Re: Re: PKZIP 1.20
-----------------------------------------------------------------
* Forwarded from "PittNet "
* Originally from John Williams
* Originally dated 14 May 90 12:17:00
05/12/1990 12:26pm CDT
WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
--------------------------------------------------------------------
There is a file being circulated on BBS's called PKZ120.ZIP or
PKZ120.EXE or similar, and that claims to be version 1.20 of PKZIP but
in fact is a hacked version of PKZIP 1.10.
As of the date of this writing, the latest version of PKZIP is version
1.10. Furthermore, due to this intentional act of vandalism, PKWARE
will not release any versions of PKZIP in the future with the version
1.20.
If you see the files PKZ120.ZIP or PKZ120.EXE on any BBS or on-line
system, please ask the SysOp of that system to remove the files
IMMEDIATELY, and please contact PKWARE to report where the files were
seen.
REWARD!
-------
PKWARE is offering a reward of lifetime free upgrades for PKZIP to
anyone who can provide information leading to the identification and
prosecution of the person or persons responsible for creating this
bogus version 1.20 of the software. They have only served to confuse
and hurt the user community, and the perpetrators of this crime are at
minimum in violation of Federal Copyright Law.
If you have any information about the source of PKZ120.EXE or
PKZ120.ZIP, please report it to PKWARE immediately, either:
by Voice at 414-352-3670
by BBS at 414-352-7176
by FAX at 414-352-3815
or by mail:
PKWARE Inc.
7545 N. Port Washington Rd.
Glendale, WI 53217
Sincerely,
Phil Katz
President, PKWARE Inc.
{backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/46
BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask
DISCLAIMER? | _How_to_Prove_It_ by Dana Angluin 20. by vehement
assertion: It What's that?|is useful to have some kind of authority
relation to the audience
------------------------------
Date: Sun, 20 May 90 12:47 EST
From: <LIANG%IPFWCVAX.BITNET@UICVM.uic.edu>
Subject: OSI Communications Protocol
OSI standard specifies seven-layer communication protocol. Many books
talks about it. But they all give some defitions and concepts only.
To make it clear to me, I would like someone to tell me, when I use
Kermit or Procomm to connect my PC to a mainframe computer, how many
layers and which of the seven specified layers exist.
I would also appreciate it if someone can recommend a book that
thoroughly discusses this topic.
------------------------------
Date: Sat, 19 May 1990 22:40 MDT
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: Recent msdos uploads to SIMTEL20
The following files have been recently uploaded to SIMTEL20:
NOTE: Type B is Binary; Type A is ASCII
Filename Type Length Date Description
==============================================
Directory PD1:<MSDOS.ARC-LBR>
AM451.ZIP B 172766 900517 ArcMaster front-end/convert for .ARC/.ZIP/.LZH
Directory PD1:<MSDOS.ASMUTL>
SOUNDEXA.ZIP B 5769 900519 Assembly language source for soundex routine
Directory PD1:<MSDOS.BATUTL>
SPRBAT3B.ZIP B 35008 900519 Winchester Computer Systems SuperBat utilities
Directory PD1:<MSDOS.DATABASE>
BK45BD1.ZIP B 200935 900512 Brother's Keeper (v4.5B) Family History, 1of3
BK45BD2.ZIP B 326317 900512 Brother's Keeper (v4.5B) Family History, 2of3
BK45BD3.ZIP B 208568 900512 Brother's Keeper (v4.5B) Family History, 3of3
Directory PD1:<MSDOS.DBASE>
SOFTC103.ZIP B 82304 900514 C library of dBase/Clipper-compatible routines
Directory PD1:<MSDOS.DESQVIEW>
TAME230.ZIP B 49566 900518 Speed up pgm execution in DesqView/VM386/other
Directory PD1:<MSDOS.EDITOR>
EZXW-W23.ZIP B 113575 900518 EZX-WRITE, WordStar-compatible word processor
Directory PD1:<MSDOS.FILEDOCS>
SIMIBM.ARC B 258147 900519 SIMTEL20 MSDOS files listing with descriptions
SIMIBM.IDX A 456268 900519 SIMTEL20 MSDOS files listing with descriptions
SIM_PDOX.ZIP B 8822 900516 Paradox converter/reader for SIMIBM.IDX
Directory PD1:<MSDOS.FILUTL>
LZESHL30.ZIP B 24397 900518 Shell program for LZEXE. English output
TM120.ZIP B 83941 900519 TreeMaster v1.20: Hard disk directory manager
Directory PD1:<MSDOS.FORTRAN>
TIDY5.ZIP B 116205 900516 Clean up FORTRAN-77 programs w/FORTRAN src
Directory PD1:<MSDOS.MSJOURNAL>
MSJV5-2.ZIP B 122830 900513 MicroSoft Systems Journal Vol 5, #2 listings
Directory PD1:<MSDOS.SCREEN>
EXPLS122.ZIP B 13117 900514 CGA/EGA/MCGA/VGA/Herc fireworks/screen saver
NNANSI02.ZIP B 39503 900515 Enhanced ANSI console driver for EGA/VGA disp.
Directory PD1:<MSDOS.SYSUTL>
4DTECH01.ZIP B 8693 900517 Official 4DOS technical notes #1 for 4DOS 3.0
SD-200.ZIP B 78316 900517 StupenDos V2.0 disk/directory management util.
VU-XM1B.ZIP B 34499 900517 286 extended memory peeker using LOADALL
Directory PD1:<MSDOS.TROJAN-PRO>
VTAC42.ZIP B 21968 900519 Protects disk against alteration or formatting
Directory PD1:<MSDOS.TXTUTL>
PTF12.ZIP B 178593 900514 Portable Text Formatter with contents & index
Directory PD1:<MSDOS.ZIP>
PK-WARN.ZIP B 1026 900518 Warning about a hacked version of PKZIP (1.2)
TOZIP51.ZIP B 18922 900519 Cvt ZOO/PAK/DWC/LHARC/PKUNPAK/PKXARC to ZIP
Directory PD2:<MSDOS2.BBS>
386PCBDV.ZIP B 4818 900517 Tips: Using PCBoard with DESQview 2.0/QEMM-386
WAF162.ZIP B 316692 900516 Waffle BBS v1.62, with UUCP mail & Usenet news
Directory PD2:<MSDOS2.TELIX>
HOST43.ZIP B 94841 900518 Host 4.3, improved BBS Host mode for Telix 3.x
Directory PD2:<MSDOS2.UUCP>
SMAILBIN.ZIP B 113817 900516 smail/PC - smart uucp mailer for MS-DOS, 1of2
SMAILSRC.ZIP B 123476 900516 smail/PC - smart uucp mailer for MS-DOS, 2of2
UUPC07JS.ZIP B 138462 900515 MSDOS uucp, TC 2.0 src for UUPC v1.07j (05/90)
UUPC07JU.ZIP B 124552 900515 MSDOS uucp, user files for UUPC v1.07j (05/90)
Directory PD2:<MSDOS2.ZMODEM>
NZMOD993.ZIP B 6604 900518 Zmodem interface v.99.36 for DSZ.COM/DSZ.EXE
--Keith Petersen
Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74]
Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.mil BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
------------------------------
Date: Mon, 21 May 1990 00:05 MDT
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: TIDY6.ZIP - Clean up FORTRAN-77 programs w/FORTRAN src
[--forwarded message--]
From: forags%nature.Berkeley.EDU@jade.berkeley.edu
I have uploaded version 6.0 of my TIDY program to SIMTEL20:
pd1:<msdos.fortran>
TIDY6.ZIP Clean up FORTRAN-77 programs w/FORTRAN src
This revision corrects the processing of alternate return addresses in
CALL statements to conform to ANSI standard (previously it had been set
up for IBM Fortran, and this mode can still be invoked if desired).
Al Stangenberger Dept. of Forestry & Resource Mgt.
forags@violet.berkeley.edu 145 Mulford Hall - Univ. of Calif.
uucp: ucbvax!ucbviolet!forags Berkeley, CA 94720
BITNET: FORAGS AT UCBVIOLE (415) 642-4424 FAX: (415) 643-5438
[--end forwarded message--]
Thanks, Al!
--Keith
------------------------------
Date: Fri, 18 May 90 15:52:19 CDT
From: "Jeffrey W. Spencer" <C0025JS%UMRVMB.BITNET@VTVM1.CC.VT.EDU>
Subject: Directory Listings for PC-BLUE
Hello,
I have a friend here at school who would like to find software to
'unarchive' macintosh files on his IBM pc. He has a program that
will view pictures created on the macintosh if only he can get them
out of their 'archived' formats. Any help would be appreciated.
Also, I've not heard any news on how to get descriptions of the
files on other lists such as pc-blue yet, so if anyone could give
me some help I would be thankful......
Thanks in advance,
jws
[Perhaps the following from Frank Wancho can assist with the
PC-BLUE question:
Date: Mon, 20 Nov 1989 12:45 MST
From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
Subject: Directory listings for PC-BLUE
is there something for the PD1:<PC-BLUE> directory like SIMIBM.ARC
for PD1:<MSDOS>?
The closest we have are the files in PD1:<PC-BLUE.VOL000>. This is
the only volume in that collection which is updated with every new
batch of PC/Blue releases.
--Frank]
------------------------------
Date: Sun, 20 May 90 00:32:39 EDT
From: "David J. Birnbaum" <djb%HARVUNXW.BITNET@pucc.PRINCETON.EDU>
Subject: Using EMS in TSRs
I have been working recently on a popup reference tsr, written in
assembly language. The com file loads and executes properly; but, not
content with this, I conceived the questionable desire of adding a
command line switch that would let the user load as much as possible of
it into ems. Never having written code that used ems before, I
consulted the MicroSoft documentation and various programming
guidebooks, the end result of which is that my ems programming no
longer crashes the system, but it also doesn't work.
If anyone has any experience in this sort of thing and has a bit of
time to spare, I'd be grateful if he or she could contact me at one of
the addresses listed below.
Thanks,
David
David J. Birnbaum djb@wjh12.harvard.edu [Internet]
11 Adams Terrace ...!wjh12!djb [UUCP]
Cambridge, MA 02138 USA djb@harvunxw.bitnet [Bitnet]
617-492-8511 [voice]
------------------------------
Date: Fri, 18 May 90 19:54:00 EDT
From: <SANTO%SENECA.bitnet@ugw.utcs.utoronto.ca>
Subject: Where's McAfee's ACS Software (PC)
SSgt Elliott J. Coerper writes:
>Subject: Re: New anti-viral programs from McAfee
>
>I downloaded ACS Virus scan from simtel20 and by doing a
>avs c:\ /a /e ...
Where is this AVS in the archives? How new is it? I looked under
PD1:<MSDOS.TROJAN-PRO> and it's not there.
Anxiously awaiting your reply,
Santo Nucifora
SANTO@SENECA.BITNET
------------------------------
Date: Thu, 17 May 90 23:22 CDT
From: KLF1305%TAMVENUS.BITNET@tamvm1.tamu.edu
Subject: Getting 640K in IBM-AT
I have an IBM question. I have an IBM AT. It has 512K on the
motherboard, and a 2 meg ram board. So, I have 2.5 Meg of ram, but dos
only has 512K. Is there any way to get the full 640K? I have looked
in the Technical Reference, and the Guide to Operations, and others,
but nothing suggests itself. Any help would be appreciated.
Kelly Fergason
VENUS::klf1305 DECNET
klf1305@tamvenus.bitnet BITNET
klf1305@venus.tamu.edu INTERNET
[Sounds like you need to do two things:
1. Make sure your ram board allows a 'back-fill' of 128K to fill in the
main memory gap. Check the documentation on how to do this. It
usually involves changing a jumper or two.
2. Re-run your 'setup' program and change the CMOS settings on how much
memory is present in the AT.
hope this helps.
gph]
------------------------------
End of Info-IBMPC Digest V90 #97
********************************
-------