Info-IBMPC@USC-ISIB.ARPA (Info-IBMPC Digest) (05/10/86)
Info-IBMPC Digest Saturday, May 10, 1986 Volume 5 : Issue 52
This Week's Editor: Richard Gillmann
Today's Topics:
MS-DOS on the Cray X-MP
Formatting Floppies on the AT
Formatting 10M Hard Disk on PC
"POPF" bug in Intel 80286 (4 msgs)
Connecting IBM AT to ethernet (2 msgs)
TCP/IP for the IBM PC (3 msgs)
Lint Error Checker for "C" Programs
V20 chip on XT, VT240 emulator programs
Arc 5.13 is a Trojan Horse Program!
CPUID.ASM
How to tell if stdout is console
Memory addressing problem on PC-1 (2 msgs)
DOS 3.2
Current DOS Environment
Mathematical Text Editors
How to print WORD files on the LaserWriter
Problem with old Basic compiler
Mixed-Language Problems on Xenix 1.0
What's the best "C" Compiler (yet again)
----------------------------------------------------------------------
From: eugene@ames.UUCP (Eugene Miya)
Subject: MS/DOS on the Cray X-MP
Date: 3 Apr 86 17:46:59 GMT
I was wondering what it takes to port PC/MS/DOS [Time, software,
license, etc.]. Suppose I gave you a radically different
architecture. Let's say, as the joke went in the past, I gave you a
Cray. A real Cray X-MP. I want be serious about this. Ignore the
hardware cost [well I guess a Cray is not that radically different:
64-bit word oriented rather than byte oriented architecture, vector
instruction set]. I assume some but not all utilities such as those
written in higher-level languages might be portable. What would it
take? I gave this thought because I just gave a talk on
supercomputers at CSU Fresno and this thought about evolution occurred
to me. If we can keep increasing micro Si performance, is there
anything to really stop MS/DOS from moving to a Cray performance
hardware architecture? I note that MS/DOS is looking more and more
like Unix as time progresses, does that stop?
Anyone familiar with the internals of VMS is also welcome to respond.
What do you think it would take to port VMS to a Cray.
I'm not implying that I plan to do this. It's a combination of looking
back on some discussions we had three years ago and reflecting,
looking ahead a bit, and the fact that I can on occasion get a Cray
class machine to myself for my research, stand-alone (working on a
future-power micro computer, maybe?). I've been moving radically
languages to the 2, and this is not-unrealistic.
I normally don't read this digest, please send me mail directly,
and if I get more than 8 responses, I will repost a summary.
--eugene miya
NASA Ames Research Center
{hplabs,ihnp4,dual,hao,decwrl,allegra}!ames!aurora!eugene
eugene@ames-nas.ARPA
------------------------------
From: mikey@bbimg.uucp
Subject: Formatting Floppies on the AT
Date: 17 Apr 86 17:32:00 GMT
> When 360K floppies are written by a 1.2M drive, however,
> they are not always perfectly readable on a 360K drive.
> It helps if the floppy was formatted on a 360K drive.
WRONG!
The problem is the narrow head width of the 1.2 meg floppy drive
lowering S/N when read on a 360K drive. DO NOT format on a 360K
drive and then write on a 1.2M unit, this is the quickest way to
insure that the diskette will have problems when returning to a 360K
unit. To make the diskettes readable on a 360K unit, BULK ERASE them
FIRST, then FORMAT (40tk mode) and WRITE to them on the 1.2M unit. THEN
use the 360K unit to --->>> READ THEM ONLY!!!!<<<---. When a 360K
unit writes, it puts down a wider track than the 1.2M unit. Since
the 1.2M unit leaves some of this when it writes (it double steps)
when the 360K units try to read, it reads a NARROW data channel with
a NARROW trim erase band, with the OLD DATA causing noise around the
track! This is also the problem with the 80 track drives as used
in the Tandy 2000.
There is the possibility that if both drives are in perfect alignment,
formatting on the 360K will lay down a guard band that the 1.2M will
EXACTLY center in when it writes, but this is the real world, I don't
believe in tooth fairies or units that might be 'perfect' just
because they work once.
Understand how floppys work, they lay down a wide band of data, then a trim
erase (DC) comes along and clips the sides of the data band so that there is
a data track with a 'silent' buffer on either side. The head reads
wider than just the data track and the 'guard bands' are needed to be
'silent' for higher S/N ratio.
Mike Yetsko
trsvax!techsup!bbimg!mikey
------------------------------
From: bmw@aesat.UUCP (Bruce Walker)
Subject: Re: Formatting 10M Hard Disk on PC
Date: 17 Apr 86 18:02:24 GMT
Dan Lau writes:
>I just bought a 10M hard disk for my IBM/PC, but after I formatted
>it, format reported a size of 10584064 bytes total available instead
>of the usual 10592256 that is reported on a PC/XT. What is wrong?
>The particulars are:
>
> IBM/PC with ROM BIOS dated when original PC/XT introduced
> IBM/PC-DOS V3.1
> OMTI Hard disk controller 5510-3
> CMI 5412 drive (asme drive as used by IBM, 306 cylinders, 4 heads)
>
>FDISK was used to install one DOS partition using the whole disk. No bad
>sectors were reported when doing the hard and soft format.
>
>Does anyone know why I am missing 16-sectors (2 clusters of 8K each).
"Elementary, my dear Watson..." I'll bet you were using DOS2.1 on the
XT and just now switched to DOS3.1 when you FDISK'ed and formatted the
new drive. Every release of DOS fiddles some parameter or another and
3.1 is no exception. The culprit here is FDISK.
FDISK's task is to create and maintain "partitions" on the fixed disk.
It does this by storing a special boot program and partition table on
the first sector of the disk (ie - cylinder 0, head 0, sector 1). In
the table are structures which describe the starting cylinder and
ending cylinder numbers for up to four separate areas, or OS'es, only
one of which may be bootable at a time. Although the partitions may
be specified as beginning and ending at an arbitrary sector, FDISK
only allows the user to specify partitions to a cylinder boundary
(remember: cylinders are the "detents" that the mechanism carrying the
heads may step to, "tracks" is the product of "number-of-heads" times
"number-of-cylinders"; eg: the XT standard drive has 306 cylinders and
four heads, giving it a total of 1224 tracks).
In DOS2.1, if you specified to FDISK "gimme the whole disk", it would
set up the partition slot number 4 with the beginning of the disk as
cylinder zero, head zero, sector 2 and the end of the disk as the last
sector on the last track minus one (the last track is reserved for
diagnostics to scribble on). Now the value for the start of the
partition disobeys already the rule we said about starting on an even
track boundary (eg: given cylinder, given head, sector 1) because the
partition and boot block lives on the first sector. I suspect some
purist somewhere (and perhaps some confused software) convinced the
writers of DOS3.[01] to change that. So they did.
Now, partitions begin at a minimum of cylinder zero, head ONE, sector
one, which means you lose 16 sectors (the remainder of track zero after
the boot block).
A complete description of the contents of the "Boot Record/Partition
Table" is found in Appendix G of the PC/XT Technical Reference Manual.
Bruce Walker {allegra,ihnp4,linus,decvax}!utzoo!aesat!bmw
------------------------------
From: tom@vcvax1.UUCP (tom)
Subject: Suspected "popf" bug in Intel 80286 (long)
Date: 18 Apr 86 16:44:12 GMT
While experimenting with an asynchronous communication driver for
VENIX (in protected mode) on the IBM PC/AT, I encountered some rather
strange behavior that I now attribute to a bug in the Intel 80286
processor. In brief, I suspect that the "popf" instruction enables
interrupts under certain circumstances even though the IF flag is 0
before the instruction is executed and set to 0 by the "popf"
instruction itself.
Because of the "popf" is so often used successfully, I would like to
hear from others about whether they have encountered the same or a
similar problem. If so, I would like to know how they programmed
around it. My concern is that I'm either mistaken and there is no
hardware bug or that I'm correct and the fix that I found is not
applicable to all processor lots.
The Evidence
The problem expresses itself in the asynchronous driver by a loss of
characters on OUTPUT. Only single characters are lost every now and
then. The problem can express itself when kernel printf's indicate
that no interrupts other than transmit interrupts are occurring. I
have tried 2 different AT's with the same results.
The reason for the character loss turns out to be due to a completion
interrupt occurring while the tty startup routine is running. The
startup routine disables interrupts and stuffs a character into the
transmit buffer. But for some reason, the 80286 allows the COM port
to interrupt causing the transmit interrupt routine to overwrite the
character just put in the buffer. Kernel printf's triggered by sanity
checks in the driver indicate the the instruction being interrupted is
a "popf" and that the IF flag before and after the "popf" is 0.
A number of obvious checks were done to rule out programmer error.
For example, after a kernel was demonstrated to show the bug, I dumped
the code segment of the running kernel and compared it to the object
file. No difference.
Tom Scott
VenturCom, Inc.
..!seismo!harvard!cybvax0!vcvax1!tom
------------------------------
From: maddox@renoir.berkeley.edu (William Maddox)
Subject: Re: Suspected "popf" bug in Intel 80286 (long)
Date: 22 Apr 86 08:39:17 GMT
This is a known incompatibility between the 80286 and other members of
the 8086 family. See pages 9-6 and 9-7 of the AT Technical Reference
for details. I quote:
If the system microprocessor executes a POPF instruction in
either the real or the virtual address mode with CPL <= IOPL,
then a pending maskable interrupt (the INTR pin active) may be
improperly recognized after executing the POPF instruction even
if maskable interrupts were disabled before the POPF instruction
and the value popped had IF = 0.
IBM suggests the following code sequence as a compatible
replacement:
JMP $+3
IRET
PUSH CS
CALL $-2
Bill Maddox
ucbvax!renoir!maddox
------------------------------
From: cck@cucca.UUCP (Charlie C. Kim)
Subject: Re: Suspected "popf" bug in Intel 80286
Date: 21 Apr 86 05:17:43 GMT
Believe it or not, this is a documented "feature" or misfeature of the
286 processor (in both protected and real modes). See page 9-6 of the
IBM PC/AT Technical Reference or (I remember seeing it here) the
appropriate Personal Computer Seminar Proceedings to find out the
exact conditions under which it can occur, but it all has something to
do with the condition "CPL <= IOPL" holding true (I honestly have no
idea what they are talking about here. I suppose it is some internal
chip condition).
The documented workaround is:
jmp L1 ; jump around iret
L2: iret ; pop cs,ip, flags
L1: push cs ; push cs
call L2 ; call near
.... ; program to continue here
which would work for any 80* cpu. They suggest coding this as a macro
which make sense. (I guess you could replace the call near with a call
far and drop the push cs). I would probably have programmed it as:
push cs ; save fake cs
push L2 ; push return point (286 only)
iret ; really just jump ahead one instr with popped flags
L2: ... ; continuation point
if it wasn't going to have to run on anything but a 286 or 186 (push
immediate was new with these) so things at least look linear!
I'm sure you can come up with a dozen different way to accomplish the
same thing now that you know the problem exists.
Charlie C. Kim
User Services
------------------------------
From: john@inthap.UUCP (John Casey)
Subject: Re: Suspected "popf" bug in Intel 80286 (long)
Date: 23 Apr 86 02:11:13 GMT
Early 80286 chips (B step) did contain a problem like the one
described here. These chips can be identified by the copyright
notice marked on the chip. Chips bearing the notice:
(C) INTEL '83
may suffer from the popf problem. Chips bearing a later copyright date
(84 or beyond) do not suffer from this problem. While the B step 80286
has not been produced by Intel for some time they may exist in some
older 80286 based machines such as early ATs.
Since there are obviously machines out their with these older chips
let me further describe both the problem and the workarounds.
If a B step 80286 executes a POPF instruction while interrupts are disabled
a pending maskable interrupt (INTR pin active) may be improperly recognized
after executing the POPF instruction even if maskable interrupts were disabled
before the POPF instruction and the value popped had IF=0. IF the interrupt
is improperly recognized, it is processed correctly.
The problem occurs in B step 80286s executing a POPF instruction while
interrupts are disabled in either Real Address Mode, or in Protected Mode
with CPL <= IOPL. Executing in Protected Mode with CPL <= IOPL implies
that the processors Current Privilege Level (CPL) is numerically less than
or equal to the IO Privilege Level (IOPL), that is, the currently executing
code is privileged enough to enable/disable interrupts and do IO.
The occurrence of this errata may be affected by the number of wait
states during the data read bus cycle of the POPF, and by even or odd
address alignment of the stack. Two wait states added to the memory read
bus cycle will eliminate the problem.
The problem can be avoided by replacing POPF with an alternate code sequence
in code that may be susceptible to the problem. The original posting
stated that the following code failed:
> 1) pop cx | return address
> popf | new flags
> pushf | dummy arg
> jmp cx | return
Recoding without using POPF produced the following working code:
> 7) pop cx
> pop ax
> push ax
> test ax,#0x200 | Don't use popf!
> bne Lsplx
> cli
> jmp cx
> Lsplx: sti
> jmp cx
This illustrates one possible alternate code sequence for POPF
which will work if AX need not be saved and if IF is the only flag of interest.
Other more general alternatives to POPF are as follows:
push cs
push #popflags
iret
popflags:
OR
call popflags | must be a far call
where the routine popflags is defined as follows
popflags: iret
NOTE: This problem exists only in older 80286s, and occurs
only when a POPF is executed with interrupts disabled
and results in interrupts remaining disabled.
John Casey
Intel Corporation
(516) 231-3300
...!philabs!ron1!polyof!inthap!john
------------------------------
From: romkey@mit-vax.UUCP (John Romkey)
Subject: Re: Connecting IBM AT to ethernet
Date: 9 Apr 86 01:30:44 GMT
Dennis Michael writes:
>Is there a vendor that sells an ethernet board for the AT?
There are a number of vendors who sell ethernet interfaces for the PC
family.
3COM: the 3C500/3C501 (500 = 501 + software) "dumb" cards, and the 3C505
interface. The 3C505 is a smart card which can also use the 16 bit AT
bus, although it works on a normal PC bus too.
Interlan: the NI5010 card, pretty much equivalent to the 3COM
3C500/3C501 cards.
Ungermann-Bass: they also sell a dumb card and a smart card. I don't
know much about these.
Excelan: only a smart card, with TCP/IP for it. I believe that most of
the other smart cards come with no software by default.
Unfortunately, I don't have the addresses and phone numbers for these
vendors handy right now.
John Romkey FTP Software, Inc.
(617) 868-4878 PO Box 150
UUCP: romkey@mit-vax.UUCP Kendall Square Branch
ARPA: romkey@borax.lcs.mit.edu Boston, MA, 02142
------------------------------
From: cck@cucca.UUCP (Charlie C. Kim)
Subject: Re: Connecting IBM AT to ethernet
Date: 11 Apr 86 18:05:45 GMT
>3COM: the 3C500/3C501 (500 = 501 + software) "dumb" cards, and the 3C505
>interface. The 3C505 is a smart card which can also use the 16 bit AT
>bus, although it works on a normal PC bus too.
I believe the dumb board is priced around $600. I'm not too sure. I
don't have their number. Getting source from FTP software shouldn't
be that bad (I hope -- I've heard good things in this corner). 3com
and ub both sell software; 3com's is some proprietary system and ub's
is a implementation of ms-net.
In any event, you can get up and running for about $600-700 with a
dumb board ($1000-1100 if you need supported software) and
$1,000-1,800 using a smart board. (Software for the smart boards runs
about $500-600).
Charlie C. Kim
User Services
Academic Informations Systems Division
Columbia University
------------------------------
From: philipp@mit-trillian.MIT.EDU (Philip Prindeville)
Subject: Re: TCP/IP for the IBM PC
Date: 11 Apr 86 01:48:06 GMT
I've gotten a few requests for details regarding my previous posting
about PC/IP, so here it is:
PC/IP is available on mag tape in source form for $55.
Binaries are available on floppy for $12. Or you can
get both for the special price of $67.
The address to order from is:
MicroComputer Center,
Software Sales and Application
11-229, M.I.T.
Cambridge, MA 02139
(617) 253-6325
Serious questions can be sent via E-mail to:
pc-ip-request@xx.mit.edu
(or) pc-ip-request@mit-xx.arpa
(or) mit-eddie!mit-xx!pc-ip-request
A new version is currently being put together with many bug fixes, domain
name service, and the following programs:
telnet
nicname (like finger but at SRI-NIC)
whois (like finger)
netwatch (like 4.2 netstats but real-time)
tftp (simplified file transfer program)
It comes with drivers for the following hardware:
3Com (ethernet), Interlan (ethernet), Proteon (Ring net)
It should be available sometime next week.
The software is also available with added utilities including:
rsh, rcp, rlogin (as in 4.2)
ftp
and a mess of other stuff from:
FTP Software, Inc.
P.O. Box 150
Kendall Sq. Brnch.
Boston, MA 02142
for $400.
Philip Prindeville
M.I.T. Project Athena PhilipP@Athena.MIT.EDU
(617) 253-5264 {ucbvax,decvax,seismo}!mit-eddie!mit-athena!philipp
------------------------------
From: sob@talcott.UUCP (Scott O Bradner)
Subject: Re: TCP/IP for the IBM PC
Date: 8 Apr 86 04:05:27 GMT
We are beta testing a copy of ftp software inc.'s version of the mit
package. even in the beta version this package is quite good, it implements
a nice set of the unix tcp/ip functions (including real ftp, accessing
time servers etc).
scott bradner
harvard university
------------------------------
To: tcp-ip@sri-nic.ARPA, info-ibmpc@usc-isib.ARPA
Subject: Net Bios on top of TCP/IP
Date: Thu, 08 May 86 19:03:27 -0500
From: Stan Ames <sra@mitre-bedford.ARPA>
Recently several vendors (including Excelan, UB, and CMC) have anounced
products that support the IBM/Microsoft Net Bios on top of the TCP/IP/UDP
internet protocols for IEEE 802.3 LAN products.
Unfortuantly each has interfaced Net Bios to the internet protocols in a
somewhat different mannor. MITRE under the direction of the ULANA program
office is attempting to bring the vendors together to agree on an interface
specification. In order to be successful each of the vendors must participate
and users must make their desires for vendor interoperability known to the
vendors.
Anyone that is involved in an inpending implementation of Net Bios on the
internet protocols is encouraged to participate.
Stan Ames
sra@mitre-bedford.arpa
------------------------------
To: info-c@brl-tgr.ARPA, info-ibmpc@usc-isib.ARPA, delftcc!sam@nyu.ARPA
Subject: Lint Error Checker for "C" Programs
Date: Thu, 08 May 86 22:25:34 -0500
From: James R. Van Zandt <jrv@mitre-bedford.ARPA>
> I'm aware of four lint-type programs for checking C code on an MS-DOS
> machine:
>
> PC-LINT Tecware $ 99
> PC-Lint Gimpel Software $139
> Pre-C Phoenix Computer Products Corp. $395
> Lint Wizard Systems Software, Inc. $450 (bundled with compiler)
>
> Can anyone report experience with these or others, or point to
> published reviews?
All the responses but one were requests for information. Here's the one:
> We are using the Wizard C compiler and BSD 4.3 to develop a large
> (~150,000 lines) system that will run under UNIX and MS-DOS. The Wizard
> compiler reports intra-module errors and warnings. The lint option
> will create a lint library and do inter-module checking. Overall the
> Wizard system catches the same errors that the BSD lint catches and
> often reports more warnings. The whole package is well worth the price
> (especially since you get library sources and can get an update service
> from Wizard).
>
> Brad Davis {ihnp4, decvax, seismo}!utah-cs!b-davis
> b-davis@utah-cs.ARPA
Now I'm trying to decide whether (1) nobody else has buggy C code, (2) nobody
else wants to ADMIT to having buggy C code, or (3) lint is hazardous, and
few users survive :-).
- Jim Van Zandt
------------------------------
Date: Fri 9 May 86 06:37:10-PDT
From: Ivan Auger <LAWRENCE.Auger@IC2060>
Subject: V20 chip on XT, VT240 emulator programs
To: info-ibmpc@USC-ISIB.ARPA
boot most of the time. This doesn't happen at all on our PC models. Has
anybody else seen this problem ? (Our XT's have 640K)...
With regards to VT240 emulators, I have tried 2 of them, Polycom VT240
and Smarterm VT125. The latter has several bugs in its emulation of
REGIS protocol. I have found the former to be an excellent product,
its REGIS emulation is excellent.
------------------------------
From: Michael Mattock <mattock%tp3@rand-unix.ARPA>
To: info-micro@brl-vgr.arpa, info-ibmpc@usc-isib
Subject: Arc 5.13 is a Trojan Horse Program!
Date: 09 May 86 10:22:03 PDT (Fri)
WARNING!
Arc 5.13 is a trojan horse program that crashes hard disks. Do not
use this version of Arc! Please pass the word to other micro users.
------------------------------
From: schuler@psuvax1.UUCP (David W. Schuler)
Subject: CPUID.ASM source file (from PC Tech Journal - April 1986)
Date: 13 Apr 86 02:07:01 GMT
This is the source code for CPUID, a program which will determine the cpu
type and numeric coprocessor type in an IBM-PC (or compatible). This is
the source code directly from the April 1986 issue of PC Tech Journal.
David W. Schuler {akgua,allegra,ihnp4}!psuvax1!gondor!schuler
Penn State University schuler%gondor@penn-state.csnet
602 Sproul Bldg. schuler%psuvaxg.bitnet@wiscvm.arpa
University Park, PA {akgua,allegra,ihnp4}!psuvax1!tvw@psuvma.bitnet
schuler@gondor.uucp : schuler@psuvaxg.bitnet
[CPUID.ASM has been added to the Info-IBMPC Library. It's a very nice
little program, can even tell an old 8088 from a new one. Perhaps
someone will modify it to tell an old 80286 from a new one. -rag]
------------------------------
From: bc@cyb-eng.UUCP (Bill Crews)
Subject: How to tell if stdout is console
Date: 9 Apr 86 01:12:26 GMT
> In writing a number of utilities it has become desirable to be able to
> tell automatically if stdout has been redirected or not. For example
> in writing a directory lister which uses color through the BIOS it
> should automatically go back to normal DOS I/O if the device is not
> the console. I can do this through fstat or isatty in MSC 3.0 if the
> redirected device is a file and not a device, but I can't tell if the
> user has redirected stdout to the printer or another device.
>
> Any ideas?
>
> Glenn Connery, Bell Northern Research, Mountain View, CA
Bit 1 (i.e., mask = 0x0002) of the IOCTL word (interrupt 0x21, function
0x44) is labeled ISCOT in the DOS Technical Reference Manual, which means
that "this device is the console output". It would seem that this is the bit
you need to interrogate, but I don't know if MSC 3.0 has a library function
that passes it through.
------------------------------
From: bright@dataioDataio.UUCP (Walter Bright)
Subject: Re: Memory addressing problem on PC-1
Date: 5 May 86 17:43:26 GMT
Jim Moseman writes:
>I have and older IBM PC with a 64K motherboard. I have added more memory
>with a multifunction card but I can only address 544K. The switch settings
>for 640K don't work (and weren't documented in my original Operations
>Guide). Does anyone know a way around this?
I had the same problem. The bug is in the ROM BIOS. Fixed it by ordering
the ROM BIOS UPGRADE KIT from the local IBM Product Service Center. It
cost about $30.
------------------------------
From: cramer@kontron.UUCP (Clayton Cramer)
Subject: Re: Memory addressing problem on PC-1
Date: 6 May 86 18:29:15 GMT
I also have an antique PC-1. You need to replace the ROM BIOS on the
motherboard. IBM sells it on an exchange basis for $50. This also makes
it capable of booting from a hard disk directly.
Clayton E. Cramer
------------------------------
From: bc@cyb-eng.UUCP (Bill Crews)
Subject: DOS 3.2
Date: 2 May 86 15:38:45 GMT
> I have been having a problem with DOS 3.2 and I was wondering if anyone
> else out there has had the same problem. The first problem I have
> had is the FATAL SYSTEM ERROR that was documented in PC Week. That
> has only happened to me once.
>
> The other problem I have had is when I was in DOS I tried to do a
> DIR. DOS told me that I had a bad FAT table...
Until you install the fix that IBM has documented for the FATAL SYSTEM ERROR
problem, you are likely to have various unexplicable symptoms. The fix
involves the STACK(S?) command, I think, but since I don't have DOS 3.2,
I really don't remember the fix itself.
- bc -
..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc (512) 835-2266
------------------------------
From: connery@bnrmtv.UUCP (Glenn Connery)
Subject: Current DOS Environment
Date: 25 Apr 86 14:17:14 GMT
> Does anyone out there know how to get a pointer to the
> CURRENT environment in DOS? What about version dependencies?
> Note that "exit and stay resident" routines normally point to
> an "old" environment I need a pointer to the "latest and greatest"
> environment. That is to say the "real" DOS environment. Can
> anyone help?
> ----maybee@pogo
The following is from a turbo pascal posting by Michael Tsang. I
presume that you can figure out from this what you want, even if you
don't have/know turbo pascal. Basically, it seems that offset 16H has
some kind of backpointer to the parent program. Seems to work just
fine, but of course this will probably fail under a multi-tasking
version of DOS so take your chances...
{ [DOSEnvLib v1.00 (c) 2.13.86] by Michael H. Tsang }
function GetDOSEnvSeg: integer;
var
SegPtr: integer;
begin
SegPtr := MemW[CSeg:$0016];
while MemW[SegPtr:$0016] <> SegPtr do { Trace back to root process }
SegPtr := MemW[SegPtr:$0016];
GetDOSEnvSeg := SegPtr + MemW[SegPtr-1:$0003] + 1 { Skip DOS program seg }
end; { GetDOSEnvSeg }
Glenn Connery, Bell Northern Research, Mountain View, CA
{hplabs,amdahl,3comvax}!bnrmtv!connery
------------------------------
Date: Fri 9 May 86 08:26:34-PDT
From: David John Buerger <D.Buerger%SCU%PANDA@SUMEX-AIM.ARPA>
Subject: Mathematical Text Editors
To: unm406%dbnrhrz1.bitnet%wiscvm.wisc.edu@SUMEX-AIM.ARPA
cc: info-ibmpc@USC-ISIB.ARPA
The Boston Computer Society recently published their "Technical
Wordprocessors for the IBM PC and Compatibles" in NOTICES OF THE
AMERICAN MATHEMATICAL SOCIETY 33 (Jan 1986) 1:3-37. Thirty-eight
vendors supporting 36 programs were reviewed with ten programs
analyzed in depth. TeX accounts for two of these ten programs and
summary information is given for 22 others.
If you don't have access to the NOTICES, send a check for $8 to:
Carl A. Hein
Dunster House, Apartment 7
Swanson Road
Boxborough, MA 01719
to get your copy of the BCS report.
David J. Buerger
Dave%SCU%Panda@SUMEX-AIM.ARPA
------------------------------
Date: Fri, 9 May 86 18:42:56 pdt
From: gould9!ronb@nosc.ARPA (Ron Belanger @ CACI)
To: info-ibmpc@USC-ISIB.ARPA
Subject: Re: How to print WORD files on the LaserWriter
To print files on the LaserWriter using WORD you can use two
methods:
- Set the printer to "Special" (Diablo emulation
mode) and use Word with the D630 print options
or { much prefereable! }
- Set the printer to 9600
- COPY or PRINT the file MSSETUP.PS out the COM1:
port (I assume that is where the printer is connected).
This file is on Word's utility disk
- Set Word to use APPLASER print option AND COM1:
rather than LPT1: as its output port (using the "setup"
option under Printer Options)
- Select some of the great fonts and print options
and print away!
There is a README file on the utility disk of WORD that
explains this (unless you are using a real old version of
WORD)
Ron Belanger
{cbosgd, ihnp4, pyramid, sdcsvax} !gould9!ronb or,
gould9!ronb@NOSC.ARPA or,
MCI Mail to "Ron Belanger"
------------------------------
Date: Thu, 8 May 86 16:57 EDT
From: Deba Patnaik <DEBA%UMDC.BITNET@WISCVM.WISC.EDU>
Subject: Problem with old Basic compiler
To: INFO-IBMPC-REQUEST@USC-ISIB.ARPA
My program runs fine with interpreter but the compiler gives error
messages on the following statements: WINDOW and VIEW. Any ideas?
I am running IBM Basic Compiler version 1.00.
deba@mimsy.umd.edu
------------------------------
Date: 8 May 1986 17:25-EDT
Subject: Mixed-Language Problems on Xenix 1.0
From: MHARRIS@A.BBN.COM
To: INFO-IBMPC@USC-ISIB.ARPA
A thorny mixed-language problem on IBM Xenix 1.0:
I have a (trivial) mainline, and a (nontrivial) C subroutine package which
uses curses. When the mainline is in C (and the code linked with cc), it
runs fine, but when the mainline is in F77 (and the code linked with cl),
it seg faults. The stack is getting stepped on in such a way that debugging
is very messy.
I am using "large" model, since F77 doc sez that's all it supports. The F77
is v 3.3 and I have the 12/31/85 software development system updates.
A related (?) question: The F77 doc file sez "use cc -Ze -c -AL to compile
the C modules". I did but I don't know why; what does -Ze mean?
Needless to say, any advice, or pointer to same, would be greatly appreciated.
-- Michael Harris
617-497-3794
------------------------------
Date: Friday, 09 May 86 10:05:49 EDT
From: jaffe (elliot jaffe) @ a.psy.cmu.edu
Subject: What's the best "C" Compiler (yet again)
To: info-ibmpc @ usc-isib.arpa
I am moving code from a SUN, to an IBMPC. The code is written in C, and
make use of Yacc and Lex. The code is mostly floating point, but must run
without an 8087, so the compiler had better be pretty good.
I also would like to have the curses library, and some way to trap control-c.
Any suggestions, as to which C compiler would be best? Portablility is
important.
Thanks,
Elliot
replies to Jaffe@cmu-psy-a.arpa
------------------------------
End of Info-IBMPC Digest
************************
-------