Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL (02/26/89)
Info-IBMPC Digest Sat, 21 Feb 89 Volume 89 : Issue 31
Today's Editor:
Gregory Hicks - Chinhae Korea <COMFLEACT@Taegu-EMH1.army.mil>
Today's Topics:
DOS use of both .EXE and .COM files
EMS-SIMULATOR
Low level format
Re-entrant C
pk(un)zip
Printing graphics with TurboPascal
QuarterDeck Customer support is awful
Easy to Use 3D CAD Program Wanted
Trouble with MS Windows
TurboC list
Very slow Hard drive
want info on Floyd-Steinberg dithers
----------------------------------------------------------------------
Date: Wed, 22 Feb 89 08:26:34 PST
From: sheridan%mrl.span@io.arc.nasa.gov
Subject: DOS use of both .EXE and .COM files
I saw the answer to this question recently but have lost all pointers to
its storage location.
Why does DOS use both .COM and .EXE files?
Thanks.
Michael Sheridan
------------------------------
Date: Wed, 22 Feb 89 14:22+0100
From: Marx <@DMZRZU5P.BITNET:Marx%DMZRZU71.BITNET@CUNYVM.CUNY.EDU>
Subject: EMS-SIMULATOR
I have read in a German computer magazine about a software product called
"TURBO EMS 4.01". With this program you are able to simulate the EXPANDED
(not extended) memory on an AT-compatible pc without ems-board but with
the hard disk.
Since in the moment the RAM-chips are very expensive that would be a cheap
alternative. The most interesting feature of this program is for me that
it only should use 9 kb RAM as resident program.
In Germany there exist another EMS-program but this one uses 68 kb RAM.
Since I will use this program for software engineering under Borland's
TURBO-PASCAL 5.0 and it's debugger I only can use a EMS program which
needs a little bit of the RAM (as the 9 kb).
Are somebody able to look for me in the USA for this (or any similar)
program and test how much RAM it use in the resident mode. The
distributors named in our computer magazine are:
Lantana Technology Inc. Teleware Corp.
San Diego ?
I appreciate any informations about this or similar programs and the
costs.
Thanks in advance
-Achim-
------------------------------
Date: Wed, 22 Feb 89 01:21:32 -0500 (EST)
From: John Duchowski <jd3a+@andrew.cmu.edu>
Subject: Low level format
Hi there,
I have read several of recent posts concerned with low level formating
and certain benefits thereof. However, I'm not exactly clear as to what
this process really does. For example, would it be worth it for me to low
level format my 30 Mb drive (type 20 on a true blue IBM AT) ? If so is
ILEAVE16 the right program to use and would I loose my data in the process?
The second question has to do with the great popularity of good ole'
simtel and the resulting difficulty in trying to ftp files from it. I have
tried to get around this by using listserv@rpicicge, but I was only
success- ful in obtaining a directory of recent files. I tredi using:
send listserv@rpicicge /pdget pd1:<msdos.*>file.ext binary
to get some arc files but never got a response. I suspect that the above
may not be a proper way of doing things but I'm not sure of what I'm doing
wrong.
Any hints and/or comments would be appreciated.
John Duchowski
Internet: jd3a+@andrew.cmu.edu
Bitnet: jd3a+%andrew.cmu.edu@cmccvb
UUCP: ....uunet!andrew.cmu.edu!jd3a+
------------------------------
Date: Tue, 21 Feb 89 23:24:02 PST
From: JAJZ801%CALSTATE.BITNET@CUNYVM.CUNY.EDU (Jeff Sicherman,CSU Long Beach)
Subject: Re-entrant C
Are there any commercial C compilers that can produce reentrant
programs. I am interested in whether the libraries also support reentrancy
or not. That is, if avoiding certain (or most) calls would preserve
reentrancy, it might be acceptable, so long as essential code (such as
startup and termination) could be dealt with and the rest was the
programmers responsibility. Any addon packages that would also make this
possible might be considered.
Jeff Sicherman
JAJZ801@CALSTATE.BITNET
------------------------------
Date: Wed, 22 Feb 89 21:55 N
From: <KOLB%HTIKUB5.BITNET@CUNYVM.CUNY.EDU>
Subject: pk(un)zip
hi,
now that Phil Katz' new non-ARC compression program (PKZ090.EXE in
SIMTEL's PD1:<MSDOS.ZIP> directory) is out, people might be interested in
a first evaluation.
After a few days of playing around with it (including transfer of more
than 100 ARC-files to ZIP-files) I got the following impression.
1. PKZIP in default mode ("shrinking") is about as fast PKPAK/PKARC,
mostly insignificantly slower, sometimes slitely faster.
2. The ZIP-files produced in default mode were overall slitely smaller
than the corresponding ARC-files produced by PKPAK/PKARC. Big files
compressed even considerably better than under PKarc, small binaries were
about the same, and small ASCII-files did slitely worse.
3. The extended compression option of PKZIP works like a charm on
binaries. Even level one (50% slower than default mode) produces
ZIP-files considerably smaller than files produced by NoGate's PAK--at not
much more than half the time. And there lay worlds between the filesizes
of a PAK-file and a ZIP-file produced by level 4 (at about the same
speed).
4. On ASCII-files, however, the extended option is a mixed blessing: At
least level 1 seems to consistently produce bigger ZIP-files than the
default method. On not too big files some level will eventually reach and
eventually undercut the size of the NoGate-PAK-file (PAK is not very
efficient on small ASCIIs anyway), but the generalization seems to be: The
bigger an ASCII-file is, the bigger the overhead of the extended
option--up to the point where even level 4 produces bigger ZIP-files than
the default method. Fortunately the modes can (in fact, have to) be
specified seperately for binary and ASCII files.
5. Extraction times are about the same as for PKPAK/PKARC (slitely better
for files compressed with the extended method), and about 3 times as fast
as NoGate's PAK.
Some examples: (time_needed/Size_of_compressed_file)
Small Binaries Big Binaries Small ASCII BIG ASCII
(66 COM/EXE files) (2 EXE files) (40 C-sources) (1 text file)
1003527 bytes 360224 bytes 540531 bytes 643437 bytes
PKPAK/PKARC 1:44/731868 0:58/390219 0:48/242499 0:49/289800
NoGate PAK 4:42/674216 2:35/354061 1:56/240153 2:15/256231
PKZIP (default) 1:46/731595 1:02/381819 0:51/244284 0:55/264638
PKZIP -e?1 3:05/640774 1:39/331441 1:44/253859 1:47/291901
PKZIP -e?2 3:16/632277 1:40/322148 1:46/241161 1:49/275310
PKZIP -e?3 3:42/624898 1:44/315122 1:53/228533 1:56/264278
PKZIP -e?4 4:44/620614 1:58/311045 1:58/220348 2:18/255922
Just to illustrate my point (4), here are the figures for a huge textfile
(942449 bytes): PKPAK/PKARC 1:16/468810
NoGatePAK 3:31/420028
PKZIP(def) 1:23/431879
PKZIP -ea4 3:20/431919
To summarize: PKZIP in default mode is every bit as fast and efficient as
the defunct PKPAK/PKARC, and that means, clearly superior to the infamous
SEA-products. If time is not all that important, the extended mode is a
beauty for binary files. My own compromise between speed and size is
PKZIP -eb3 meaning: extended method level 3 for binaries, default mode for
ASCII.
Overall, I think, Phil Katz and the others did a beautiful job on this new
program. I, myself, will most certainly switch to PKZIP and I'm happy that
the reasons for that don't have to be purely "moral". (just transforming
my ARC-files to ZIP-files gave me another 1.5MB of free space).
P.S.: I have no connection whatsoever with PKWARE Inc. or anyone else in
this business. (In fact, I didn't even pay my registration yet...)
-------------------------------------------------------------------------
hans-peter kolb, Tilburg University, Holland kolb@htikub5.bitnet
-------------------------------------------------------------------------
------------------------------
Date: Wed, 22 Feb 89 16:17:33 EST
From: Marc Dyksterhouse <mdd@SEI.CMU.EDU>
Subject: Printing graphics with TurboPascal
I've written a program in TurboPascal v5.0 that prints graphics to basic
Epson and IBM dot matrix printers in medium graphics mode. I'm
experiencing a puzzling problem. I create the bit pattern that makes up
the graphic image and send the data to the printer by assign'ing a file to
'prn' and write'ing the data to that device. Every time an EOF character
(ascii 26) is present in the graphic bit pattern the printing starts to go
south.
In itself isn't *that* surprising, but what makes it puzzling is that
everything works fine if the data is assigned to a disk file and that file
is later printed. I've examined the data extensively and everything is as
it should be. TP doesn't insert any extra characters or drop any
characters when an EOF is written. The problem only seems to occur when
the data is sent directly to the printer and once it leaves my system, I
can't tell what happens to it other than watching the sheets of paper come
flying out of the printer as every low ascii character known does its
little trick.
To get around the problem, I just scan the data for EOF characters before
printing it and if any are found, I substitute #27 instead. That extra
bit doesn't bother the graph any, but I'd like to know what makes this
happen so I can make sure it doesn't affect the program in any other way.
Also, while I have your attention, does Ctrl-KP really not work right in
TP5 or is my setup the problem? I can't print a block using Ctrl-KP from
within the editor like I could in TP4. All that happens is the word
'Printing' flashes on the status line. I hate going back to the TP3
method of marking a block and Ctrl-KW'ing it to 'prn'. I got TP5 as soon
as it became available directly from Borland.
thanks,
marc
mdd@sei.cmu.edu
Whatever I just said came solely from my finger tips, not those of my
employer.
------------------------------
Date: Wed, 22 Feb 89 12:21:15 PST
From: ROME%ATF.MFENET@NMFECC.ARPA
Subject: QuarterDeck Customer support is awful
With regard to Andre Pirard's plug for QEMM386 and DesqView, I must sound
a dissenting voice. Quarterdeck has the WORST customer support of any PC
software company.
QEMM386 has a bug when used with NCR 386 PCs. If it is installed, you can
only format 1 1.2Mb floppy disk. The previous version had this bug also,
and I reported it to Quarterdeck. NCR made a fix, but it does not work for
the new version. I wrote to them in December for a resolution of this
problem and have received no response (in two months). Their phone is
always busy, and they expect you to pay $30 for customer support. If their
software won't work, they should fix it. I followed up my letter with a
letter to Terry Meyer(?) the President of Quarterdeck; this has also
elicited no response.
As far as DesqView is concerned...
1) It wouldn't recognize my Tecmar VGA/AD board as a VGA, even though the
installation routine said it was a VGA. In fact, Tecmar's new BIOS fixed
this, but I sure got no help from Quarterdeck.
2) When it finally worked, in VGA graphics mode, it is so slow as to be
unusable. I need the 800x600 screen driver for Ventura Professional, and
using it hangs up the system, even in full screen mode.
DesqView claims to be selling like hotcakes, but I suspect that (like
Windows), most of them are sitting unused in desks.
In conclusion, I don't think that a software company with this lack of
concern for the customer should be supported.
Jim Rome
------------------------------
Date: Sun, 19 Feb 89 08:48:18 +0200
From: "David Leiser" <KDBG100%BGUNOS.BITNET@CUNYVM.CUNY.EDU>
Subject: Easy to use 3D CAD Program wanted
I am looking for an easy to use 3D CAD program. What I require is a way of
drawing points and curves (splines) in 3D space, then watch it from
various distances and angles. Commercial is fine. I am especially
interested in people's actual experience.
Many thanks, I will summarize to the list if there is enough response.
David Leiser kdbg100@bgunos.bitnet
Dept of Behavioral Sciences, Ben Gurion University
P.O.Box 653 Beer Sheva 84105 ISRAEL
------------------------------
Date: 22 Feb 89 13:13:28 GMT (Wed)
From: leif@ambone.ambra.dk (Leif Andrew Rump)
Subject: Trouble with MS Windows
Try running PIFEDIT.EXE (Program Information Editor) and edit one of your
.PIF-files. How many "KB Required"? Try to lower this value!
Leif Andrew Rump, AmbraSoft A/S, Roejelskaer 15, DK-2840 Holte (Denmark)
UUCP: leif@ambra.dk, phone: +45 2424 111, touch phone: +45 422 817 + 313
> > > Why are tall Irish girls with red hair so wonderful ? ? ? < < <
------------------------------
Date: Thu, 23 Feb 89 09:07 N
From: <PCHPAPL%HLERUL52.BITNET@CUNYVM.CUNY.EDU>
Subject: TurboC list
As an answer to the wuestion of overlays in Turbo C :
Recently I found a TurboC-List on which you can subscribe bye sending a
message/mail containing "SUB TURBOC-L <first-name> <last-name>" to the
following mailbox :
ListServ%ucf1vm.bitnet@edu.cuny.cunyvm
Middle names won't be accepted. After sending this message you will be
added to a direct mailing list. Mail for the list can be sent to the
mailer with the addres
TurboC-L%ucf1vm.bitnet@edu.cuny.cunyvm
Please do NOT send subscriptions to the mailer (as I did before) because
all mail is distributed to ALL list-members and some members really don't
appreciate getting junk mail.
Jeroen W. Pluimers
Gorlaeus Laboratorys
Leiden University
The Netherlands
e-Mail pchpapl@hlerul52.bitnet |________________________________
phone +31-2522-11809 | Time goes, you say?
| Ah no! Alas, time stays, we go.
p-Mail Kagertuinen 65 | (A.Dobson)
2172 XK Sassenheim
The Netherlands
------------------------------
Date: Wed, 22 Feb 1989 20:45:42 EST
From: Kalman Schecter <kms@cunixb.cc.columbia.edu>
Subject: Very slow Hard drive
I've got a Seagate ST238 30MB drive that runs very slowly. When I run
Vseek on it I get a reading of 91ms average seek time. This means that I
end up drumming my fingers while this thing loads programs.
Anyway I am using an Adaptec ACB-2072 controller that formats the drive
with 25 sectors per track (the interleave adjustment utilities on SIMTEL
that I tried reject drives that are not 17 sectors per track). Aside from
interleave, what else can slow down a drive? From what I understand the
ST238 should seek at around 65ms.
I optimize it frequently using Norton SD and don't overload any of the
subdirectories. Also, what's the difference between MFM and RLL? I don't
what the drive is, but the controller information says that the ACB-2072
will support either RLL or MFM with interleave 2 to 8. Any help would be
greatly appreciated.
Thanks in advance
KMS
------------------------------
Date: 22 Feb 1989 21:02:00 CST
From: LARRY.J.GRANROTH@IOWASP.PHYSICS.UIOWA.EDU
Subject: want info on Floyd-Steinberg dithers
Can anyone out there send me some info on Floyd-Steinberg dithering?
References, comments, or (especially) source code (C, Pascal, Fortran,
MASM) would be much appreciated.
Thanks in advance!
------------------------------
Date: Wed, 22 Feb 89 21:04:11 CST
From: Brian D. Carlton <carlton@rice.edu>
In v89 #22 I asked if anyone had successfully ran a bbs in the
background under a multi-tasking program such as Desqview or Windows.
Thanks to everyone who replied to my querry.
Kurt Riegel <kriegel@note.nsf.gov> reports that he is successfully running
a RBBS board on a 286. He is able to run other large programs
simultaneously using 2M of EEMS ram. He recommends to use Desqview 2.23
or 2.25 or later.
Betty Harvey <harvey@nems> has run two RBBS boards at once but warns this
requires a great deal of memory. The RBBS manual has a section on running
it under Desqview.
Andre' Pirard <a-pirard%bliulg11.bitnet@cunyvm.cuny.edu> warns that
BBS's that write directly to the screen could mess up the foreground
processes' screen. Other applications that disable interrupts (such as
some TSR's) could cause trouble as well.
Bob Peterson <peterson@osage.csc.ti.com> notes that a 4.77 MHz machine
can't really perform at over 2400 bps, but others have been successful.
Bob is using the MINIHOST package on a XT. Since the BBS requires 200K,
he is not able to run large programs concurrently with it. He suggests
EEMS rather than expanded memory when using a 286, although Kurt says that
LIM 4.x memory will work too.
RTGCS@UNO has ran a WWIV 3.21d BBS under DoubleDos. That might be worth
looking in to as well, and even thought Desqview is the more popular
solution.
Brian Carlton
carlton@rice.edu (Internet) bcarl01@rice (Bitnet)
{usual}!psuvax1!marsh.rice.edu!carlton (uucp, untested)
------------------------------
End of Info-IBMPC Digest
************************
-------