Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL ("Info-IBMPC Digest") (05/26/90)
Info-IBMPC Digest Sat, 26 May 90 Volume 90 : Issue 95
Today's Editor:
Gregory Hicks - Chinhae Korea <GHICKS@WSMR-Simtel20.Army.Mil>
Today's Topics:
C and Fortran Compilers
DD and HD 3.5" Drives
Hard disk lookup tables
Re: Overwriting the PSP (2 msgs)
Paradox on LANs
Problem with Leading Edge D monitor
smail/PC - smart uucp mailer for MS-DOS
TECO wanted
TIDY5.ZIP - Clean up FORTRAN-77 programs w/FORTRAN src
UUPC 1.07j - uucp for MS-DOS - now available
WAF162.ZIP - Waffle BBS v1.62, with UUCP mail & Usenet news
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: Wed, 16 May 90 18:10:48 PDT
From: rli%bode.usc.edu@usc.edu (Li)
Subject: C and Fortran Compilers
I am writing a real time program on pc using C with some routines in
FORTRAN. I have the following questions and I would greatly appreciate
if someone can give me an answer (and send the answer to
rli@hot.caltech.edu or rli@bode.usc.edu)
1) What is best FORTRAN compilers available in the sense of the
efficiency of using 80x87 coprocessors ? I currently have MicroSoft
Fortran, Professional Fortran and NDP Fortran, which is the best ?
2) Can object module produced my MicroSoft C be linked with modules
produced by Non-microsoft fortran compilers ? If not, what is the
reason?
3) Someone recommended me to use NDP Fortran and C compilers? what is
good about it. My impression is that it is a very unprofessional
product.
4) What is the best C compilers for PC in terms of speed ?
Thanks in advance.
R. Li
------------------------------
Date: Wed, 16 May 90 18:05 CST
From: Paul Kleeberg <PAUL%GACVAX1.BITNET@CUNYVM.CUNY.EDU>
Subject: DD and HD 3.5" Drives
In V90 No85 Tim Cartwright <ESTIMCAR@Orion.YorkU.CA> writes:
| At school, we got some new clones last Fall with Panasonic DD/HD drives
| that insist on the second hole. I rang the local Panasonic headoffice
| and spoke to an engineer to find out it we could disable the detection
| circuit that looks for the second hole. The first answer was, "Oh no,
| you musn't do that." But when questioned closely he agreed that (a)
| there is a pull-connector that can be undone to disable the detection
| circuit and (b) using DD disks at HD poses no threat to your hardware.
I am curious if this completely defeats the error checking or if it
merely makes the machine think that ALL disks are high density. I once
was unable to read a disk given to me because it was a HD disk
formatted DD. Apparently the machine saw the hole and consequently was
unable to read it. I had to put it in my old NEC laptop to transfer
the information to a DD disk for my machine to use it.
Paul Kleeberg
St. Peter, MN
------------------------------
Date: 17 May 90 2:20 -0500
From: Dan Fandrich <shad04@ccu.umanitoba.ca>
Subject: Hard disk lookup tables
When I first got my AT clone 3 years ago, I had the same problem
in getting my hard disk going without the proper ROM BIOS parameters
(14 disks isn't much to choose from).
I ended up solving my problem by writing a small TSR that replaced
the hard disk parameters in ROM. INTs 41h and 46h are pointers to
structures containing the 1st and 2nd hard disk physical information
(number of cylinders, heads, etc.), so the TSR merely had to change the
interrupt vectors to point to the new structures in RAM and exit.
Details of the structure format are found in Ralf Brown's interrupt
list (PD1:<MSDOS.INFO>INTER290.ZIP at SIMTEL-20) and p. 159 of BYTE's
Fall 1985 IBM Special Issue.
The following procedure (as far as my memory allows) got me up and
running with my drive:
1) Set the CMOS configuration to the drive closest to the one in
the computer. It must have the same number of heads and no more than
the number of cylinders of the actual drive.
2) Reboot the computer from a floppy disk. Ignore the long wait
before bootup and the subsequent hard disk error message.
3) Install the TSR.
4) Low-level format the drive using IBM diagnostics, HDTEST or
whatever.
5) Run FDISK
6) Run FORMAT
7) Put the TSR in the AUTOEXEC.BAT file so it executes upon bootup.
That should about do it. You might get away without step 7 if the
ROM parameters are close enough, but chances are things like write
precomp and the landing zone will be off.
Works for me...
>>> Dan Fandrich
shad04@ccu.umanitoba.ca
------------------------------
Date: Thu May 17 09:20:59 1990
From: "Gregory Hicks <GHICKS@wsmr-simtel20.army.mil>
Subject: Re: Overwriting the PSP
I contacted Microsoft regarding overwriting the PSP (the DOS PRINT.COM
does this for versions 3.x and lower) and found the following:
| I recently added a routine to a tsr to release the environment memory
| block before terminating. The routine, lifted out of the Waite
| Group's MS-DOS Developer's Guide, works as advertised, but with two
| undesirable side effects:
| 1) Memory mapping utilities can no longer find the name of the program.
| I suspect that is because these utilities get the name from the
| undocumented fully qualified file name that is appended to the
| environment block. No environment = no name. Is there any way I
| coerce the program into reporting its name when it doesn't have an
| environment block?
Actually the name IS documented, it's just hard to find. Check out an
MS-DOS programmers ref sometime, not a PC-DOS tech ref. The MS-DOS
p.r. is a bit hard to find, but we document it anyway.
| 2) The environment block is allocated before the program block, which
| means that releasing the environment creates a small hole in memory.
| This is not completely useless, but it would clearly be better to keep
| all free memory contiguous. Is there any way to coerce the program
| into allocating its environment from the top down, while locating
| itself at the lowest available spot? This way I could release the
| environment without causing fragmentation. Move'em, a loadhi utility
| for 286s by Qualitas, uses this approach to let users load programs and
| their environments into high dos memory, the programs from the bottom
| up and the environments from the top down. Move'em provides a feature
| that allows the user to release the environment blocks, which keeps all
| free memory contiguous. It should be possible to do this within a
| program, but I have no idea how.
Unfortunately there is no way. However, if you free up your
environment, then any and all subsequent program loads will use the
hole in memory that you've conveniently made available. This can be a
significant savings in the long term (as long as you don't grow the
size of your environment later).
| The program in question is a com file in assembly language.
If it's a COM program, you can play games with yourself and relocate
yourself down in memory at startup. Basically you could:
1) Determine the size of your environment
2) Allocate all of memory (Block 1)
3) Shrink the allocated block by the size of the environment
4) Allocate more memory (Block 2)
5) Copy the environment into Block 2
6) Change the environment pointer in your PSP to point to Block 2
7) Free up Block 1.
8) Move yourself up in memory over your existing environment
9) Free up Block 2 and your environment.
This is REALLY dangerous and tricky however and you're likely to
get it wrong (you have to be REALLY careful what you do with your stack
in step 8, and you have to protect the code that actually performs the
move).
Also you have to make sure that your environment is contiguous with
the start of your program. If you have a hole in memory, your
environment will get put in that hole, if you blindly assume your
environment is adjacent to your code you'll be likely to trash someone
else's program.
| A couple of reference books have mentioned that it is technically
| possible to set up a tsr that will relocate itself back over its psp,
| thereby saving 256 bytes. They go on to say that it is usually not
| worth the trouble, but they provide no information on when this
| approach is safe or on how it might be effected if the programmer
| decided it *was* worth the trouble. I am aware that programs that
| perform file or device access using file handles must preserve their
| psp, but is the psp needed otherwise? When is it safe to sacrifice it
| in the interest of saving memory? And how should a program be
| relocated this way?
You can overwrite up to the command line in the PSP, ie the last 128
bytes. This is VERY dangerous and probably won't work on versions of
MS-DOS after DOS 4.0 (or whatever the current version is). This is
VERY bad behavior, so Microsoft can't guarantee that it will work,
however you MIGHT be able to get away with it.
| This provides 300 bytes of stack space: 256 bytes of psp, plus 4 bytes
| >from the jmp and the nop that even will generate, plus the 40 specified
| in ourstack. You should be able to use this quick and dirty method no
| matter how large a stack you need, as long as you provide explicitly
| for any amount beyond 256 bytes.
This is VERY VERY VERY VERY VERY VERY BAD!!!!! If you ever use more
than 128 bytes of stack you will HANG YOUR MACHINE!!!! Now remember
that DOS requires you to have 80 bytes of stack space available for
DOS's in addition to the stack usage you need for your program. This
means that if you take this solution you will only have 48 bytes (24
words) of stack space for your app.
Please note: Anything I've said above is my own personal opinion. I've
mentioned several things about the behavior of T&SR programs, I do not
wish to imply that they are in any way the official policy of
Microsoft. Microsoft may change the behavior of the DOS at any time to
require the ENTIRE PSP to remain untouched, etc. I'm just warning
developers of potential problems.
It's been my experience that there are just about no T&SR programs
that could benefit from a 128 bytes savings in memory, if you care
about memory that much, you should look at your code and see what you
can figure out how to save more memory by better code. Don't look for
memory savings by trying to squeeze bytes out of pieces of DOS you
shouldn't mess with until ALL options have been investigated. Messing
with DOS data structures that aren't defined (and some that are
defined) has a NASTY tendency of introducing bugs in your program that
you don't detect until the program has been out in the field for many
many years. The technique of freeing up your environment block is a
safe technique, none of the others you have mentioned is guaranteed to
work.
Larry Osterman
PS: All of the opinions expressed above are my own, based on years of
experience writing systems apps. None of the opinions are intended to
represent those of my employer.
------------------------------
Date: 17 May 90 10:19 EST
From: DIXON WALTER V <DIXON@CRDGW2.crd.ge.com>
Subject: Re: overwriting the psp
In Info-IBMPC Digest V90 #88 David J. Birnbaum asks:
> A couple of reference books have mentioned that it is technically
>possible to set up a tsr that will relocate itself back over its psp,
>thereby saving 256 bytes. They go on to say that it is usually not
>worth the trouble, but they provide no information on when this
>approach is safe or on how it might be effected if the programmer
>decided it *was* worth the trouble. I am aware that programs that
>perform file or device access using file handles must preserve their
>psp, but is the psp needed otherwise? When is it safe to sacrifice it
>in the interest of saving memory? And how should a program be
>relocated this way?
In addition to the Job File Table, the PSP contains initial values for
the break, termination, and critical error handlers, a storage area for
user ss:sp, and default dta buffer. DOS uses these fields at various
times. If you are unlucky enough to need any of these fields, you
could screw up the foreground task.
Any time a tsr does something that could lead to a critical error, you
really should switch to your own psp. If the tsr does not handle the
error, dos terminates the current task which is not the task that
incurred the error. Likewise one must be careful of the semantics of a
break when a tsr is active. (Of course even if you do switch PSPs when
activating, DOS is not going to handle termination real gracefully).
Another potential problem is the int 21h dispatcher records the current
ss:sp in the current psp. DOS uses this field for error processing.
If your TSR activates in a int 28 ISR (dos safe), makes an int 21h
request (not necessarily i/o), deactivates, and the foreground task
needs to use the ss:sp values, your are in trouble.
My advice would be to forget trying to overwrite the PSP.
Walt Dixon {internet: dixon@crd.ge.com }
{us mail: ge crd }
{ po box 8 }
{ schenectady, ny 12301 }
{phone: 518-387-5798 }
------------------------------
Date: Mon, 14 May 90 15:21 MST
From: William E Wilson <WILSON%NAUVAX.BITNET@UBVM.cc.buffalo.edu>
Subject: Paradox on LANs
Has anyone out there had any experience installing Paradox on a PC
Share Network?
William Wilson (wilson@nauvax)
------------------------------
Date: Mon, 14 May 90 11:21 EDT
From: "Navin S. Ganeshan, Wash DC" <NGANESHA%UDCVAX.BITNET@UBVM.cc.buffalo.edu>
Subject: Problem with Leading Edge D monitor
My ever-so-faithful workhorse PC, a Leading Edge model 'D',
has an unusual problem. Sometimes, the screen "swims", that is,
characters are shaky, misplaced and usually unreadable. Sometimes it's
so bad that the screen looks like a collection of dots. Then, after
some time, it all snaps into place. then it looks quite normal. But,
the time it takes to start working right has been increasing from 10
minutes to more than 48 hours !!!
It's probably a heat-related problem..but where ??? Is it the
graphics card (built-in on the motherboard) or the monitor
(hercules-compatible card/monitor) ? I checked all the connections in
the CPU and the monitor. (apart than the screen, it works just fine )
Before I have it committed to a service center (egad, the
warranty has run out), does anyone have any ideas ?
Navin Ganeshan
Academic Comp. Srvcs.
Univ. of DC, Wash DC.
------------------------------
Date: Thu, 17 May 1990 00:12 MDT
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: smail/PC - smart uucp mailer for MS-DOS
Keywords: simtel20,smart,mailer,uucp,uupc,ms-dos
[--forwarded message--]
From: sct@po.CWRU.Edu (Stephen Trier)
Now available from SIMTEL20:
pd2:<msdos2.uucp>
SMAILBIN.ZIP smail/PC - smart uucp mailer for MS-DOS, 1of2
SMAILSRC.ZIP smail/PC - smart uucp mailer for MS-DOS, 2of2
I am happy to announce the release of the beta-test version of
smail/PC, a port of the smail UUCP smart mailer to the MS-DOS operating
system. smail/PC serves as a mail transport agent (MTA) capable of
acting as a full-blown smart mailer with full routing capabilities. In
other words, provide a routing database and smail/PC will automatically
look up a path for your mail, even for mail of the form
"someone@yyyy.UUCP". smail/PC also provides sophisticated aliasing
capabilities, a full-name database that recognizes addresses like
Stephen.C.Trier@seldon.UUCP, and the ability to communicate with and
route mail for multiple UUCP hosts.
smail/PC is based on the public domain smail2.5 mailer, which was
written by the people at the UUCP mapping project. It uses a modified
UUPC uuio for UUCP protocol support, and requires an external mail user
agent (MUA) to provide a user interface. The only MUA with which I
have tested smail/PC is Mush-PC, although smail/PC should work with any
MUA that reads Unix-style mailboxes and can call smail/PC
appropriately. (Anyone want to port MH?) I highly recommend Mush-PC;
the mail environment it provides is superior to many Unix mail
interfaces.
Here's an (edited) excerpt from the Unix readme file for smail:
Read.Me - Updated 9/15/87
Features of smail include:
(1) Using pathalias data to choose the best route to your destination.
(2) Handling of user@domain, domain!user, and host!user syntax.
(3) Generation of domain!user syntax to be forwarded by other systems.
(4) Logging of traffic through your machine, by sender, recipient, and
size of message, so you can track use and detect abuse of your
machine.
(5) Mail being forwarded through your machine to another uux link is
correctly processed, not bounced.
(6) Sendmail-like alias capability.
(7) Generation of RFC822 required headers for locally generated mail.
(8) Robust delivery scheme that reroutes only if stated path is inaccessible.
(8) Mail that is undeliverable is returned to sender.
(9) Simplicity.
smail/PC is in the late beta stage. I have tested the code
thoroughly on seldon, and I believe it is sound. Bug reports are
requested.
smail/PC is mostly in the public domain. All programs derived from
the Unix smail2.5 package are in the public domain, as are the programs
I have added. The portions originating in the UUPC Post-1.0-interim
release are copyrighted by their original authors, but are freely
distributable.
In addition to SIMTEL20, smail/PC is also available by anonymous FTP
to shasta.scl.cwru.edu [129.22.32.7], in files /info/smailbin.zip and
/info/smailsrc.zip. These files are in the PKZip format and require
PKZip 1.01 or higher to extract. Because of disk space restrictions, I
am not able to place Mush-PC on shasta. You can find Mush-PC on
wuarchive.wustl.edu or SIMTEL20, in their MS-DOS UUCP directories. At
this time, no other archive sites or access methods are available.
Offers from other archive sites to carry smail/PC are hereby
categorically accepted! :-)
<=> Stephen Trier sct%seldon@skybridge.SCL.CWRU.Edu
{sun,att,decvax}!cwjcc!skybridge!seldon!sct
sct@po.CWRU.Edu
[--end forwarded message--]
Thanks, Stephen. Please keep us posted on new versions as development
of smail/PC progresses.
Keith
--
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: Wed, 16 May 90 17:50:23 EDT
From: Michael Harris <mharris@BBN.COM>
Subject: TECO wanted
Anyone know where I can get TECO for the PC?
-- Michael Harris mh@bbn.com 617-873-3794
------------------------------
Date: Wed, 16 May 1990 21:17 MDT
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: TIDY5.ZIP - Clean up FORTRAN-77 programs w/FORTRAN src
Keywords: simtel20,fortran,renumber,format,hollerith
[--forwarded message--]
From: forags@violet.berkeley.edu (Al Stangenberger)
I have uploaded to SIMTEL20:
pd1:<msdos.fortran>
TIDY5.ZIP Clean up FORTRAN-77 programs w/FORTRAN src
Version 5.0 of TIDY, a program to renumber and reformat Fortran source
files. Fixed a bug in processing multiple-line SUBROUTINE statements.
Also added ability to translate Hollerith constants to
apostrophe-delimited strings.
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
[--forwarded message--]
Thanks, Al!
--Keith
------------------------------
Date: Wed, 16 May 90 10:02:30 PDT
From: kumr.UUCP!pozar@cgl.ucsf.EDU
Subject: UUPC 1.07j - uucp for MS-DOS - now available
> [--forwarded message--]
> From: UUPC/Extended Help Desk <help@kendra.kew.com>
>
> UUPC/extended 1.07 is a small but FREE package for exchanging mail with
> a system running or emulating a UNIX UUCP connection. Other packages
> which perform this function include FSUUCP, WAFFLE, and UFGATE, but they
> are larger and include USENET NEWS support, which UUPC/extended lacks;
> most of those are shareware, rather than freeware.
>
> Drew Derbyshire
I should mention that the above is not totally correct. UFGATE
has a very loose structure for payment. If you are using UFGATE for
personal use and are not interested in dialup support (although if you
do call me, I won't hang up and curse your hometown. I may even be nice
:-) ), the package is FREE. If you are interested in support, then the
cost is $35. If you are using it for non-personal use (ie. your
cottage work on the side on up to Universities, and goverment) then the
cost is $195.
Most folks fall in the first catagory, where the package is free,
you could call it freeware for that catagory. It all depends how
sticky you want to be with the term freeware. I'm not writing to
debate that. I am here to explain our priceing structure.
If you have any questions, drop me a line here or give me a ring at
415-695-7727.
Tim
------------------------------
Date: Wed, 16 May 1990 21:34 MDT
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: WAF162.ZIP - Waffle BBS v1.62, with UUCP mail & Usenet news
Keywords: simtel20,waffle,uucp,mail,usenet,news,bbs
[--forwarded message--]
Thomas E. Dell <dell@APPLE.COM>
I have uploaded WAF162.ZIP, which is the MSDOS version of the Waffle
BBS / UUCP Mail / Usenet package, to SIMTEL20:
pd2:<msdos2.bbs>
WAF162.ZIP Waffle BBS v1.62, with UUCP mail & Usenet news
Excerpt from README for Waffle DOS version:
CAPABILITIES & FUNCTIONS
o Allows a PC to communicate with Unix systems using UUCP protocol,
giving them capability to send UUCP mail and Usenet news.
o Can be run as an single-user, individual UUCP node, either in slave
(they call you) or master (you call them) mode
o Can be run as a BBS program, including electronic mail, messages,
editor, transfer section, cookies and numerous other amenities.
o Can be run as a frontend to execute DOS tasks, with access control
on a per individual basis.
o Any combination of the above, with enough imagination.
--Tom
[--end forwarded message--]
Thanks, Tom!
--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
------------------------------
End of Info-IBMPC Digest V90 #95
********************************
-------