hicks@WALKER-EMH.ARPA (Gregory Hicks COMFLEACTS) (02/21/88)
Info-IBMPC Digest Sat, 20 Feb 88 Volume 7 : Issue 16
This Week's Editor: Gregory Hicks -- Chinhae Korea <hicks@walker-emh.arpa>
Today's Topics:
Caution for those considering MSC 5.0 (2 msgs)
Copyright Revisited
NROFF-like DOS Formatter (4 msgs)
Hard Disks on the IBM PS/2 (2 msgs)
Boot Sector Format Information
MSC 5.0 Bugs, Microsoft ``support''
MindReader v1.03 Caution
Protecting system configurations (2 msgs)
UUCP/Internet mail for DOS (UULINK)
Today's Queries:
Need source for PD Communications Program
Windows 2 Bug
Info-IBMPC Lending Library is available from:
Bitnet via server at CCUC; and from SIMTEL20.ARPA (see file
PD1:<msdos>files.idx for listing of source files)
SIMTEL20.ARPA can now be accessed access from BITNET is via
LISTSERV@RPICICGE.BITNET using LISTSERV Commands
INFO-IBMPC BBS Phone Numbers: (213) 827-2635 and (213) 827-2515
----------------------------------------------------------------------
Date: 14 Feb 88 23:28:07 GMT
From: John Stanley <john@viper.Lynx.MN.ORG>
Subject: Caution for those considering MSC 5.0
In article <11754@brl-adm.ARPA>
PEPRBV%CFAAMP.BITNET@husc6.harvard.EDU (Bob Babcock) writes:
.......
>The manual seems to indicate that only initialized global
>data will go here, but isn't all global data implicitly
>initialized to zero if not otherwise specified?
It's true on "many", but not all systems. Rule of thumb is NEVER assume
any UN-initialized variable contains zero (or NULL)... If you haven't
explicitly put something into a variable, assume it's set to a random
value or the constant most likely to cause your procedure to bomb....
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john
------------------------------
Date: Mon Feb 15 14:07:31 1988
From: microsof!davewe%beaver.cs@beaver.cs.washington.edu
Subject: Caution for those considering MSC 5.0
| Date: 4 Feb 88 23:10:15 GMT
| From: Mark Chance <mc35+@andrew.cmu.EDU>
|
| In recompiling my application under 5.0 I discovered an annoying
| feature which effectively prevents me from using 5.0. My application is
| pretty large and I need a lot of stack space. I am using the large
| model and by adding the -Gt option to force data items to their own
| segment things are pretty cool. Now along comes 5.0 and I specify 20000
| bytes stack space, the linker says 'Error: stack+data>64K'. I say how
| can that be? Well the punch line is that 5.0 puts strings in the
| CONST space which is in the stack segment !!! :-(. So cluttering up my
| precious stack space is 40K worth of strings that used to be distributed
| among the various FAR-DATA segments. I intend to complain to Microsoft
| about this since I have not found any compiler switches to avoid this.
| Any other ideas?
|
| Mark Chance Information Technology Center
| mc35+@andrew.cmu.edu Carnegie-Mellon Univ.
A fixed version of the second pass of the compiler, C2.EXE, is available
for the asking from Microsoft Product Support at (206) 882-8089 or you can al-
ways call (206) 882-8080 and ask to be connected with Product Support.
The bug occurs because /Gt was not affecting allocation of string literals and
items declared with the 'const' keyword properly and as a result these items
were always being allocated in the default data segment. This was not a
design decision as Mr. Fountain mentioned in the Feb 9 issue (Vol. 7, #12),
but was in fact a bug.
Dave Weil
Project Manager, C Compiler
------------------------------
Date: 15 Feb 88 22:02:28 GMT
From: mcvax!dkuug.dk!keld@uunet.UU.NET (Keld J|rn Simonsen)
Subject: Copyright Revisited
Dave Sill <dsill@NSWC-OAS.arpa> writes:
>>> If it does not have a proper copyright notice along the lines of
>>> "Copyright (c) 198x by somebody or something" then it is in the public
>>> domain.
>>
>>Wrong.
>An basis for your statement would be helpful here. The following
>excerpt is from an article on copyrights (written by a lawyer) I
>picked up from sri-nic (I can't remember which directory).
>>... The one thing you
>>must do, however, is protect your copyright by including a copyright
>>notice on every copy of every program you sell, give away, lend out,
>>etc. If you don't, someone who happens across your program with no
>>notice on it can safely assume that it is in the public domain (unless
>>he actually knows that it is not).
The international copyright convention (the berner convention) does not
require you to put a copyright notice on it, for the work to be
copyrighted. A work which has a sufficient amount of intelligence put in
it, has the required "work height" to automatically enjoy copyright
protection when published. Almost all programs will have the sufficient
"work height", I think it will exclude things like AT&T's "true" program.
It does indeed improve your chances to prove that *you* made the program,
if you put a copyright notice on it. And to protect your work in
non-berner union countries, such as USA and some South American countries,
you must put the copyright notice on it according to some specific rules
and add "All rights reserved" to it.
So you cannot automatically assume that a programme is in the "public
domain" when there is no copyright notice on it, when you consider
international copyright.
Keld Simonsen U of Copenhagen keld@diku.dk / diku!keld
[There is a rather interesting article in file
PD1:<msdos>copyright.article that discusses this in some detail. Should
be required reading... gph]
------------------------------
Date: Mon, 15 Feb 88 11:29:55 -0800
From: Roy Stehle <stehle@tsca.istc.sri.com>
Subject: NROFF-like DOS Formatter
A utility called fmt is part of a set of UNIX-like utilities available
from Carousel MicroTools. It implements the formatting function found in
the Software Tools. I have used it on a few simple NROFF files.
The Use-A-Tool package contains over 50 utilities, including fmt. I
purchased it for $129 in 1984. Try the following for more information.
Carousel MicroTools, Inc Tenet
609 Kearney Street P.O. Box 2505
El Cerrito, CA 94530 Redwood City, CA 94026
(415) 528-1300 (415) 366-5505
(408) 288-6565
Roy Stehle
SRI International, Menlo Park, CA
------------------------------
Date: Mon, 15 Feb 88 14:30:35 EDT
From: Adam Lewis <ALEWIS%UTCVM.BITNET@CUNYVM.CUNY.EDU>
Subject: NROFF-like DOS formatter
Dr. Dobbs Journal sells a version of nroff for the PC at a price that is
fairly reasonable. More importantly, they aslo include the source code
for it.
I recall that there is aslo a PD version of nroff floating around on one
of the PD software libs. If you can FTP, check on SIMTEL20.ARPA or if you
are on BITNET, check the LISTSERVer at one of machines at RPI.
------------------------------
Date: Mon, 15 Feb 88 22:14:14 EST
From: Bob...Mon <iuvax!bobmon@ee.ecn.purdue.edu>
Subject: NROFF-like DOS formatter
proff was recently posted. I also have a package (from this net a year or
so ago) call nro. It has given me usable output.
RAMontante bobmon@iuvax.indiana.cs.edu
Computer Science Department If you listen to Tools...
Indiana University the Slide Rules!
------------------------------
Date: Mon, 15 Feb 88 20:32 CST
From: <CS_DAVIS%SWTEXAS.BITNET@CUNYVM.CUNY.EDU>
Subject: NROFF-like DOS formatter
In response to your message about an nroff look-alike: I have been using
a program called NR for the past few weeks which pretty much duplicates
nroff. It even comes with a macro file to do most of what ms does. Since
it comes with source code, I suppose that one could add about whatever
functionality one wanted.
NR is available from M&T Publishing, 501 Galveston Dr., Redwood City, CA
94063. I paid about $30 as I recall. It comes with a nice tutorial that
is a better nroff introduction than most.
The program is one of the products of Allen Holub, Software Tools
columninst.
--Wilbon Davis
CS_DAVIS@SWTEXAS.BITNET
------------------------------
Date: Mon, 15 Feb 88 22:11:44 -0800
From: Jerry Sweet <jsweet@ICS.UCI.EDU>
Subject: Hard Disks on the IBM PS/2
> We have been having a lot of problems with the hard drives (types 30
> and 32).
> ...
> Has anyone else experience this type of bug??? (or perhaps I should say
> flaw)??
Our PS/2 had exactly the same problem. We tried leaving it on all weekend
on the theory that the battery in charge of keeping the NVRAM alive simply
needed a long charge. No luck. We took it back to the dealer, and they
CLAIMED that they were unable to reproduce the problem. However, they
supplied us with some sort of device driver, DASDDRVR.SYS, purpose
unknown, which we included our CONFIG.SYS file. It may not have anything
to do with anything, but the problem has not recurred. We have no idea
WHAT the HECK this driver is, but you know the old saying: if it ain't
broke, don't fix it.
-jns
------------------------------
Date: Mon, 15 Feb 88 22:59:35 -0800
From: Jerry Sweet <jsweet@ICS.UCI.EDU>
Subject: Hard Disks on the IBM PS/2
"DASD", as in "DASDDRVR.SYS", means "Direct-Access Storage Device",
an IBM-ism for Hard Disk. /j
------------------------------
Date: Tue Feb 16 09:39:11 1988
From: microsof!larryo@beaver.cs.washington.edu
Subject: Boot Sector Format Information
>From: "George_C._Burkitt.ElSegundo"@Xerox.COM
>Just an adder to the discussion of the boot sectors and contents: if the DOS
>has not been loaded, the boot sequence depends on the ROM...a fairly limited
>storage area. So all the computer knows at start - up is the location of
>the system files... the first tracks on the first disk. This is the boot
>sector of the A: floppy (or the 1st hard disk, if set up for hard disk
>boot). IBM PCDOS 2.1 call the system files IBMDOS.com and IBMBIO.com;
>MSdos 3.1 calls them MSDOS.SYS and IO.SYS. These are flagged "hidden" so
>the usual "DIR" won't display them.
In fact this is not quite correct. There are two DOS products on the
market, MS-DOS (the product that Microsoft sells to its OEM's), and
PC-DOS, (the version of MS-DOS that IBM sells). The PC-DOS system files
are called "IBMDOS.COM" and "IBMBIO.COM", the MS-DOS system files are
called "MSDOS.SYS" and "IO.SYS". The IBM-PC ROM bios reads in the first
sector of the first side of the first cylinder of the boot disk (ie
physical sector 0) into RAM at 0:7C00H, then starts executing that code.
If this code is a DOS boot sector, depending on the version of the
operating system, it will do one of the following things:
On DOS 1.x and DOS 2.x, it will simply load in contiguous files starting
at the second physical sector on the disk, up to a preset limit in the
boot sector, to location 70:0 (the start of the BIOS (IO.SYS/IBMBIO.COM))
[[A quick note: there are two BIOS's in an IBM, the ROM-BIOS which is the
familiar INT xx services that we know and love, and the DOS-BIOS which is
the resident device drivers in the system. When I refer to the "BIOS" I
mean the DOS-BIOS, not the ROM-BIOS]]
On DOS 3.0 - DOS 3.2, the boot sector was rewritten to do the following:
It verifies that the first two files on the disk are IBMBIO.COM/IBMDOS.COM
[IO.SYS/MSDOS.SYS], and if they are, it will load in the BIOS at 70:0 (it
gets the file size out of the root directory, and then loads in that many
tracks from the disk into memory, thus if the BIOS is 17K, and each track
on the machine is 8K, we will read in 24K of data from the start of the
disk into memory. The BIOS will then look at the FAT on the disk and load
the DOS into memory from there, thus the only reqirement on the location
of the DOS on the disk is that it be the second directory entry on a disk.
The BIOS still has the same requirement that it must be the first
directory entry and be contiguous on the disk (ie it must lie in clusters
2-x with no holes (There is no cluster 1)).
Under DOS 3.3, the code was changed still further to remove the
restriction that the BIOS be contiguous, but it still has to lie in the
first sector on the disk.
The actual structure of a DOS boot sector is as follows:
00H +-----------------------------------------------+
| E9H XX XX or EBH XX 90H (JMP xxx) |
03H +-----------------------------------------------+
| OEM name and version (8 bytes) |
0BH +-----------------------------------------------+ --------+
| Bytes/Sector on disk (2 bytes) | |
0DH +-----------------------------------------------+ |
| Sectors/Cluster on disk (1 byte) | |
0EH +-----------------------------------------------+ |
| Reserved sectors (2 bytes) | |
10H +-----------------------------------------------+ |
| # of FAT's (1 byte) | (Usually 2)|
11H +-----------------------------------------------+ |
| # of root directory entries (2 bytes) | + BPB
13H +-----------------------------------------------+ |
| # of sectors in logical volume (2 bytes) | |
15H +-----------------------------------------------+ |
| Media ID byte (FAT ID) | |
16H +-----------------------------------------------+ |
| # of Sectors/track (2 bytes) | |
18H +-----------------------------------------------+ |
| # of heads (2 bytes) | |
1AH +-----------------------------------------------+ |
| # of hidden sectors (2 bytes) | |
1CH +-----------------------------------------------+ --------+
| # of hidden sectors high word (2 bytes) | |
1EH +-----------------------------------------------+ |
| # of sectors high word (2 bytes) | + EBPB
20H +-----------------------------------------------+ |
| Reserved (6 bytes) | |
26H +-----------------------------------------------+ --------+
: :
| <Boot code> |
: :
1FD +-----------------------------------------------+
| INT 13 Boot drive number (DOS 3.2+) |
+-----------------------------------------------+
1FE | 55H AAH |
+-----------------------------------------------+
The EBPB is the "extended BPB" which was defined in DOS 3.2. It allows
for support of drives larger than 32M in size. Note that no versions of
DOS currently support such drives, the structure was defined for use in
the future.
Larry Osterman
Most of the information above can be found in the MS-DOS encyclopedia
(second try) published by MS-PRESS (it's a hefty $134 retail, but well
worth it)
"The comments above are my own...."
------------------------------
Date: Mon Feb 15 14:07:31 1988
From: microsof!davewe%beaver.cs@beaver.cs.washington.edu
Subject: MSC 5.0 Bugs, Microsoft ``support''
| Date: 4 Feb 88 15:20:00 GMT
| From: mcdonald@uxe.cso.uiuc.EDU
|
| I ordered my Microsoft C 4.00 to 5.00 upgrade in middle December. It still
| hasn't come. Our purchasing agent called them and they said that it
| wasn't shipping due to bugs. They hoped to have some sort of product
| out soon (read: some bugs fixed).
|
| Remember that their Fortran 4.00 was so buggy that they shipped free
| fixed versions (4.01) .Maybe they'll do this for C. In any event,
| at least around here they are charging only $45 for the 4.00->5.?
| upgrade.
|
| Doug McDonald
| University of Illinois.
I don't know where the problem lies with his inability to acquire an update,
but it is most definitely not due to the product not shipping. C 5.0 shipped
in late Oct/early Nov. Beyond that I don't have enough information to help
much. I don't know who his purchasing agent talked to, but I would suggest he
try calling Product Support at (206) 882-8089. There is no reason that I am
aware of why he should not have received the update.
Dave Weil
Project Manager, C Compiler
------------------------------
Date: Tue, 16-Feb-88 07:00:22 est
From: David Farber <farber@cis.upenn.edu>
Subject: MindReader v1.03 Caution
I just tried the mindreader v1.03 program from the last ibfo-ibmpc notice.
It blew my computer's mind that is the battary configeration memory and
locked up the system. I have a 386 motherboard. Darn if I know what that
does but WATCH IT. Here's what I have and specifically what happened:
I put Mindreader v 1.03 into a sub directory under a dos 3.3 on a intel
motherboard 386 with 2 meg of memory. I use 386MAX to remap memory with no
previous compatability problems. I have a vega display with a ega (again
never a problem). I also run the apple talk card and a cd rom (no problems
there also).
I fired up Mindreader. The screen went blank, and a ctl-alt del would not
reboot and I had to power off. When I powered up I got the comment that
the battary backed ram config store was incorrect. The time seemed ok but
everything else had been reset to maybe garbage. No desire to try that
again. The file system was ok.
------------------------------
Date: 15-FEB-1988 12:44:09 GMT +01:00
From: BFDF2544%vax1.centre.queens-belfast.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Protecting system configurations
My Department makes available a bank of IBMPC/XT machines for use by
students in connection with class assignments. We are encountering the
irritating problem of "informed" students altering the "user friendly"
configurations (such as in AUTOEXEC.BAT, KERMIT initialisation files etc.)
we have set up to make life easier for non-computer orientated users.
The operating system does not appear to offer any means of preventing this
such as by making it impossible to delete, rename or amend files except
under password control. Does anyone know of software which would provide a
simple soltution to this problem?
Tom Patterson
Department of Applied Mathematics & Theroetical Physics
The Queen's University of Belfast
Belfast, BT7 1NN
N. Ireland.
------------------------------
Date: Tue, 16 Feb 88 8:01:28 GMT
From: Gregory Hicks COMFLEACTS <hicks@walker-emh.arpa>
Subject: Protecting system configurations
You might try using the program supplied with the IBM DOS called ATTRIB
... With this program, you can set file protections such as read-only,
hidden, system, archive...
I have never tried to set the protection for AUTOEXEC.BAT to hidden or
SYSTEM, but it may work... You might try this and see what happens.
However, if you set the protection, you'll have to remove the ATTRIB
program. See your DOS manual for instructions of the command line.
You can set the protections/reset protections using a product like Norton
Utilities, so ...
Generally, whatever you can do to the system, someone else can undo..
Someone could even twiddle the bits using DEBUG although it's not so easy
to do so...
If the users are really knowledgeable, they'll find a way to undo whatever
you do if they want to bad enough...
Regards,
Gregory Hicks
------------------------------
Date: Mon, 15 Feb 88 10:25:59 PST
From: vortex!lauren@rand-unix.ARPA (Lauren Weinstein)
Subject: UUCP/Internet mail for DOS (UULINK)
In response to a number of recent queries in this forum, a number of
persons have suggested that we post some brief information about our
UULINK product for IBM PC/XT/AT's and compatibles running MS-DOS/PC-DOS.
UULINK provides for comprehensive UUCP ascii and binary file transfers,
including full-speed multiple packet, full duplex operations. It both
sends and receives UUCP-style ("!") and Internet-style ("@") mail (single
hop, multiple hop, and pass-through) and includes the ability to send and
receive Usenet "netnews" articles. It includes aliases, distribution
(mailing) lists, a "cron" mechanism for scheduling executions at various
dates/times, and can operate fully unattended for both outgoing and
incoming calls, etc. The UULINK mail sending and reading programs include
facilities for sorting messages into different folders, replies, mail
forwarding, and a wide variety of other mail handling features.
If anyone interested in more details would send us their U.S. mail address
or give us a call, we'll be happy to send them more detailed information.
Thanks much.
--Lauren--
{clyde, decvax, sun, ihnp4, ...}!vortex!lauren
Vortex Technology -- (213) 390-3920
--Disclaimer: Of course I'm biased. I WROTE UULINK!
------------------------------
Date: Mon, 15 Feb 88 15:23 AST
From: FNRJH%ALASKA.BITNET@CUNYVM.CUNY.EDU
Subject: Need source for PD Communications Program
I am new with Turbo C and would like to obtain source for a public
domain comunications program written for use on a Zenith 248 AT
compatible.
I want to use it to write my own communications module for a program
used at the university. Right now all data trancefer between the program
on our Zenith AT and the program on the VAX is done by hand, I wish to
automate the process.
Thanks in advance.
Robert
------------------------------
Date: Mon, 15 Feb 88 23:39 AST
From: <JNDPH%ALASKA.BITNET@CUNYVM.CUNY.EDU>
Subject: Windows 2 Bug
I have been running pagemaker under windows 1.04 for several months, and
got the new version of windows several weeks ago. Neither Aldus nor
microsoft seem to be able to help with this problem that occurs on my 8
mhz deskpro 286 with 2.5 mb of memory...
When text mode is chosen from the tool box, the type ahead is
excruciatingly slow. When editing text in long documents, garbage appears
in the area of the edit. If I type too far ahead, the system locks up!
*and* ctrl-alt-del is disabled. At Aldus's advice, I am using a 384k
cache buffer (smartdrv.sys) and the rest of my extended memory is used as
a ramdisk for storing screen fonts and pagemaker. Has anyone else had
this problem? Is there an optimum size for smartdrv.sys? Microsoft user
support said it might be a Compaq bios campatibility problem, but my
dealer says there is no bios upgrade for my machine. I thought the
problem might be that I was editing files stored on our Novell server, but
it occurs with files from the local hard disk, too.
Any advice from other Windows 2 users would be appreciated.
thanks in advance...
------------------------------
************************
End of Info-IBMPC Digest
-------