[comp.sys.ibm.pc.digest] Info-IBMPC V6 #62

Info-IBMPC@C.ISI.EDU (Info-IBMPC Digest) (09/13/87)

Info-IBMPC Digest       Sat, 12 September 1987      Volume 6 : Issue 62

This Week's Editor: Gregory Hicks -- Chinhae Korea <hicks@walker-emh.arpa>

Today's Topics:

                  Interrupt Priorities on a PS/2 Model 30
                     Chinese Language Word Processing
                 PC/XT/AT Cables for Multiple Hard Drives
                    Micro-EMACS Available from SIMTEL20
         Multiple Hard Drive Installation/Cable Problems (2 msgs)
                          Digest format problems
                Non-Existent ROM Contents on Clone XT/AT's
                     CompuSystems and Mail Order Fraud
                       Copyright re-visited (2 msgs)
                       Mode Switching and Interrupts

Today's Queries:

         Experiences/choices when connecting to other PC Networks
                  Farsi (Persian)/Chinese word processing
                 Measuring speed from within Turbo Pascal
                Programming DOS TCP/IP interfaces to PC-NFS
             Where has Quaid Software and 'Disk Explorer' gone
                Possible to re-direct Standard Error Output
                  Problems with the ATI EGA WONDER board
          Making DOS calls from TSR utilities written in Turbo C
              Problems with the Inkey function of dBase III +
                      VT-100 Device Driver Available
                  Turbo-C .OBJ and .LIB files Differences
                FTP from SIMTEL20 to a VAX 11/750 on BITNET
               'MACE' and Hard Disk Problems on a COMPAQ 286
               Latest version of PC Kermit 2.29C (beta 2.30)
                      Two displays on a PS/2 Model 60
                          Smalltalk on IBM PC/AT

        INFO-IBMPC BBS Phone Numbers: (213)827-2635 (213)827-2515

----------------------------------------------------------------------

Date: Mon, 7 Sep 87 19:03:02 EDT
From: Shuo Huang <hs@eevlsi.ee.columbia.edu>
Subject: Chinese Language Word Processor

  >
  >Does anyone have any information regarding a Chinese Text Editor/
  >Word Processor for use on an IBM-PC and a Dot Matrix Printer.
  >Desire to generate Chinese characters for Church bulletins, etc.
  >Primary user will be a native Chinese speaker/writer who is not a
  >computer "hacker" so program needs to be "user friendly".  Budget
  >is also low.
  >

     I have seen a Chinese-DOC, Chinese WordStar, and Chinese DBASE-III.
They come from China.  There are four methods to enter data: Pin Yin
(Chinese pronunciation system), Character part code, Telex code, and GB
code (National standard code).  The easiest way is Pin Yin, but slower.
This software uses dot matrix printers to print chinese characters.  The
software requires a Color Graphics Monitor with CGA.

     Sorry, I've never heard of such software in public domain.  And I
don't know where to get them.  Perhaps you should contact China Books &
Periodicals Inc. for more information.

          China Books & Periodicals Inc.
          2929 24th Street
          San Francisco, CA 94110

     If you would like to discuss more with me, send mail to:
          hs%eevlsi.ee@cu20b.columbia.edu
/HS

------------------------------

Date:         Mon, 07 Sep 87 09:43:06 ULG
From:         Andre PIRARD <A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU>
Subject:      More on loosing interrupts

>...  IBM,  3Comm  and Microsoft have been pretty cavalier about losing
interrupts in the past. ... says Billy.

     And the beat goes on.  Here is a problem I reported to IBM:

>When a communication program drives an asynchronous adapter by interrupts
>and a national keyboard driver is used, typing while line input is being
>displayed produces screen garbage.  Keyboard interrupts are an infrequent
>and long process and assigned higher priority (1) than frequent and short
>communication interrupts  (3,4) (why?).  Their drivers send the 8259 EOI
>just before IRET, as most regretfully do.  Consequently, even if cpu
>interrupts are enabled, the 8259 will not request communication interrupts
>to the processor until the very end of keyboard interrupt processing,
>which, if excessive, causes communication line overrun.  DOS 3.2 KEYBBE
>(on XT), for example, is near the limit, and causes occasional overrun at
>9600 baud.

>But 3.3 KEYB (on PS/2 30!) is far beyond and does it nearly for every
>keystroke.  CTL-ALT-F1ing KEYB (to the original ROM presumably) removes
>the problem.  Rotating 8259 priorities (OUTing C1H to 20H) solves the
>problem for KEYBBE, but not for KEYB (why?).  But assigning the keyboard
>interrupt lowest priority also shuffles the other ones.  In particular,
>the timer interrupts get the next to lowest.  Is this practice advisable?

And some more comments for INFO-IBMPC:
     What frightens me is that the problems are worse on 3.3 PS/2 30 than
on a plain XT or AT. I was expecting maturity from PS/2.

     The priorities are as follows (0 highest):

0: timer ticks
1: keyboard
2:mouse (generally)
3,4: communication
5,6: disk and diskette
7: printer

     Generally, BIOS and MSDOS as a whole are careful not to disable
processor interrupts too long unnecessarily, even during interrupt
processing.  There could be occasional exceptions to this, but I never
experienced any in communication.

     But with the host of available TSR programs hooking onto interrupt
vectors,  the situation may change.  If such a program acts as a front end,
it cannot decently enable interrupts without presuming what its followers
do and need, and it will necessarily perform before 8259 EOI anyway.  For
this reason, such programs should act after the original sequence if
possible, when interrupts can be enabled for sure, except for another
reason, the stack growth nightmare.  It is therefore important to write or
choose such programs carefully.

     The TSR programs problem is all the more acute as timer and keyboard
interrupts are the most favored for hooks.

------------------------------

Date: Mon, 7 Sep 87 22:17:28 EDT
From: ames!pyramid!fmsrl7!mibte!ccd700!reh@RUTGERS.EDU
Subject: Adding Second Hard Drive

> To: Larry Smith <CMP.LSMITH%r20.utexas.edu@icse.uci.edu>
>

It is not impossible to have two drives on a pc with DOS 2.10.  I have such
a setup.

The rules as I understand them are:
  1. Both drives must be controlled by the same card (unless one has a
special card meant for a second drive)
  2. If they are both on the same card, they must both be the same size.
  3. The wide cable from the card must connect to both drives.
  4. A separate thin cable connects to each drive (the card should have two
     sets of pins for these).

I don't know how helpful this will be since I did not see the first
article.

Another note:  Under 2.x, DOS can use up to 32 Meg on one disk (without
special programs).

Bruce Harold

Replies to:
......................................................................
Bob Harold                      313-845-5404
Ford Motor Co., DPTC room B-206 ...!ihnp4!mibte!ccd700!eed090!bob
17000 Rotunda Drive             Disclaimer: The views expressed might
Dearborn, MI 48121-6010         not be those of my employer or myself
......................................................................

------------------------------

Date: Mon, 7 Sep 1987  23:12 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: MicroEMACS version 3.9 available from SIMTEL20

MicroEMACS version 3.9 is now available via standard Arpanet/Milnet
anonymous FTP from SIMTEL20.

Filename            Type      Bytes   CRC

Directory PD:<MSDOS.MEMACS>
EM39DOC.ARC.1       BINARY    169472  7733H
EM39EXE.ARC.1       BINARY    228219  46E3H
EM39SRC.ARC.1       BINARY    249472  7A6BH

The individual source code and documentation files are also available in
directory PD:<MISC.MICROEMACS>.  The Atari and MAC executable files have
been removed from EM39EXE.ARC but are available as individual files in the
PD:<MISC.MICROEMACS> directory.

--Keith Petersen

------------------------------

Date: Tue, 8 Sep 87 21:35:16 EDT
From: Chris Schmandt <geek@MEDIA-LAB.MEDIA.MIT.EDU>
Subject: Multiple Hard Drives

I remember one detail which may be giving some people trouble.  I don't
know why Brian had trouble with 2 drives on one controller; as I said, I
did it.  Problem: drives generally have jumpers for Drive0 / Drive1
(actually, most drives themselves jumper to one of 4 positions, but the
controllers support only 2).  So, you'd think to add a second drive you'd
jumper it to Drive1.  But NO; there's a twist in the daisy-chain cable from
the controller (the one with two endings) that specifically swaps the pins
for drive0/1 select on the ribbon cable.  Incidentally, it's the same on
standard floppy cables.  I spent some LONG hours on this one, many thanks
to Big Blues wisdom...

chris

------------------------------

Date:     Thu, 10 Sep 1987 15:21 PDT
From:     LSHIERY%CALSTATE.BITNET@wiscvm.wisc.edu
Subject:  Multiple Two Hard Drive Installation

    2 Hard Drives?...    Yes.  It is possible two install 2 hard drives in
an IBM PC.  I have two 20meg hard drives and two floppy drives, all living
contentedly in my PC.  (I did have to buy a larger power supply.)  In fact,
DOS will support up to 64 drives or block devices, but you'll have to get
additional software or firmware.  The Western Digital controller card has
it's own rom. I have also installed two hard disks in my Zenith, a 20meg
and a 40meg, set up as a 30meg and a 10meg, and as Jerry Sweet mentions,
the Zenith needs software to work.

    As for PC-DOS, I use 3.2.  DOS 3.x uses a smaller cluster size, which
will manage disk space better.  (A cluster is the smallest amount of space
that DOS can allocate to a file.) I did use 2.1 for a time, but I only had
one hard drive then so I can't comment on using it with two hard drives.

Good Luck
Glen Shiery
Instructional Computer Consultant
California State University, Fullerton
School of Business and Economics.

------------------------------

Date: Tue 8 Sep 87 22:43:19-CDT
From: Clive Dawson <AI.CLIVE@MCC.COM>
Subject: Digest format problems

Our undigestification software failed miserably on the latest
issue of the INFO-IBMPC digest (Vol. 6, #61).   You've probably
heard this from multiple sources, but just in case, PLEASE
restore the standard digest format, i.e. the proper message
separators!

Thanks,

Clive Dawson
Postmaster, MCC.COM

[My apologies to all who complained about the format of the last digest
(Vol 6, #61).  I haven't used 'undigestify' programs because there is a
large user base here in Chinhae that reads the Digest on paper because our
machines are not networked yet.  Normally, I print one copy and route it to
the other users.  This digest should meet the specs for 'undigestify'...
Again, my apologies -- gph]

------------------------------

Date:         Wed, 09 Sep 87 17:35:09 SET
From:         "N.Head" <ESC1111%DDAESA10.BITNET@wiscvm.wisc.edu>
Subject:      Non-Existent ROM Contents

As my contribution to the "why my AT wouldn't boot any more" discussions :

Put a ROM or two, contents unimportant, into the spare ROM sockets at
address E000:0 to F000:0.  Lord knows why but my Clone suddenly decided
that it was finding AA55 at the first two bytes of this address range when
the sockets were empty and rushed off to try and initialize this phantom
ROM software with sadly predictable results ...

All in all it seems a dubious technique to try and read nonexistent
addresses and place any trust in what you get from them. It seems that the
true blue AT's do a checksum of the extra ROM if they think they find one -
the chances of getting a valid checksum as well as AA55 must be minuscule I
suppose. Unfortunately, my Clone doesn't have this extra safeguard in its
BIOS.

Just as a by-the-by can anyone explain why I don't get parity errors right
left and center when I view these nonexistent addresses with, say, DEBUG??

As a last by-the-by -- why are the contents of these addresses different if
I read them with the parity check disabled??

------------------------------

Date: Thu, 10 Sep 87 13:48:18 EDT
From: mtune!lznv!psc@rutgers.edu
Subject: Avoid Compusystems bust-out scam

As reported in the August 17, 1987, issue of INFOWORLD ("Compusystems Mail-
Order Firm Under Investigation for Fraud" by Mark Brownstein, page one!),
Compusystems Co. of Beverly Hills, CA, "is apparently not a mail-order
operations, but rather a 'bust-out scam'."  The phone number is an
answering service; the address is a postal drop.

The INFOWORLD article goes into some length on how even they were ripped
off.  The ad was placed on credit.  Compusystems had provided the phone
numbers of several reputable-sounding references, and INFOWORLD's credit
department called them all.  But the same guy at Compusystems answered, and
(of course) assured them that Compusystems was a good risk.

It seems safe to say that Compusystems' prices really are too good to be
true.  Stay away.

------------------------------

Date: 10 Sep 87 18:10 GMT
From: aprm @ Hawaii-EMH.arpa
Subject: Copyright

In Vol 6 #61 munnari!mulga.OZ!wwen@uunet.UU.NET (Wilson Wen) is responding
to a query about Chinese word processors.  He lists several sources for
Chinese versions of MS-DOS, and goes on to say:

> Almost all of the MS-DOS standard editors, e.g. EDLIN and Olivitte EDIT,
> etc., run well under these systems. They also have some Chinese versions
> for more sophisticated editors, e.g. PE and BRIEF, for sale. The prices
> are surprisingly low, generally, you can have everything for less than
> $50! And there is no Copyright at all! So, if you come to Melbourne, I
> may give you all of those free of charge.
>

I know that dealers in Korea have been offering standard American
copyrighted software for $9 a disk, and have been told that the same sort
of thing goes on in Taiwan.

[By the by, as of July 1987, this practice has officially stopped.  The
Republic of Korea signed the World Convention on Protection of Intellectual
Property at that time.  (I think this name is correct...) -ed.]

I can't tell which products Mr. Wen is referring to when he says there is
no copyright, but MS-DOS is certainly copyrighted.  Perhaps the Chinese
versions of DOS he listed are clones, in the style of the Phoenix ROM BIOS.
Does PE refer to IBM's Professional Editor?  That must be copyrighted.  I
would be surprised to find that BRIEF is not.

Unauthorized copying of copyrighted material is illegal.  So is shop
lifting and car theft.  Looking past the specific laws and how they apply,
the fact is that the producers of software should get some money for it,
the same as farmers do for their crops, shoemakers do for shoes, house
painters do for houses they paint, and college professors do for courses
they teach.

As I said, I can't be sure of Mr.  Wen's intention, but I think the
moderator should catch this sort of thing and refuse to post it without
clarification.  I feel that info.ibmpc and indeed all of the groups on the
Internet have a responsibility to uphold this position.  All we need is for
those who fund this terrific network to decide that it poses too much risk
of a copyright infringement lawsuit, and to have it disbanded or castrated.

Gary Dunn
Ft. Shafter LAN: aprmso1!gd             IF THIS GETS INTO THE
usenet:  garyd@islenet.UUCP             HANDS OF THE RUSSIANS,
DDN: aprm@Hawaii-EMH.ARPA               IT'S CURTAINS FOR THE
work phone:  (808) 438-1030             FREE WORLD.
beach house: (808) 737-0601

[For more on this discussion, see the following message.  When I 'edited'
the last digest, I read Mr. Wen's statement on Copyrights as meaning that
the software (foreign language word processors) he was referring to was not
copyrighted.  I should have taken that portion of the message out.  As
always, Info-IBMPC does not condone any method of breaking copy protection,
distribution without fee of copyrighted works (ie. pirating software...) or
any discussions of this sort.  gph]

------------------------------

Date: 10 Sep 1987 14:13:30 PDT
Subject: Copyright
From: Billy <BRACKENRIDGE@C.ISI.EDU>

Gasp!

I was delighted for the help.  I was gone for an extended long weekend and
couldn't edit for nearly a week.  Gregory Hicks took over the digest,
FTPing the whole mess to his PC in Korea and then editing it.

I guess the digest sometimes looks like it is just messages strung
together.  The editor really does usually edit.  I guess he didn't realize
that and just printed the raw messages as is.  He has already been bit, but
on the whole I am delighted with the help and we will keep him.

Anyway, it was a mistake in communications on our end that it got in the
digest at all.

------------------------------

Date: 10 Sep 1987 17:46:10 PDT
Subject: Mode Switching and Interrupts
From: Billy <BRACKENRIDGE@C.ISI.EDU>

Following is an edited discussion with Gordon Letwin of Microsoft and
Richard Soley of AI Architects about interrupts and operating systems such
as OS/2 which attempt to switch between protected and real modes. At times
all afterburners were on full flame.  After editing out the slander,
denials of slander etc. there is very little left.  The names of the guilty
have been deleted.

Billy Brackenridge:

It looks to me that under OS/2 interrupts get lost.  IBM, 3Comm and
Microsoft have been pretty cavalier about losing interrupts in the past.
Many is the IBM seminar I have gone to and expressed my concerns as a real-
time programmer over BIOS's ability to disappear for 30 seconds or so on a
disk retry or VDISK's ability to lose interrupts entirely.

Richard Soley:

We have heard that other protected-mode solutions have this problem.

Gordon Letwin:

OS/2 does not 'loose' interrupts.  Interrupts may be delayed in their
acknowledgment for about 100 microseconds, except when mode switching when
this number can approach 800 microseconds.  This means that COMM
applications running at high baud rates may get overruns during mode
switching.

This interrupt lockout is a result of the fact that during mode switching
the processor is being master cleared and cannot receive interrupts.  There
is *no* mode switching product by anyone, (even those who use prosthetic
intelligence) which can avoid a prolonged lockout period.  Replacing the
IBM ROMs can shorten the time some, but not eliminate it.

I know of three methods of handling protect mode and real mode applications
on a 286:

     1) use protect mode emulation.  This is very slow.  There is no mode
switching, so your PROTECT MODE application or device driver can handle
high interrupt rates, but a real mode driver/application would be so slowed
by this technique that it's not a win.

     2) use special hardware, such as a 286 co-processor.  I don't know of
anyone who does this without having to change the code in the applications.
In any case, this is fine for your personal desk-top, but it's No Good as a
commercial product because people don't want to buy special hardware for
this.

     3) Mode switch.  Involves speed hit as above.

As I understand the A.I. Architects product description, their 286 product
handles interrupts and mode switching in exactly the same way as does OS/2,
with exactly the same advantages and disadvantages.

Billy mentioned one other problem: when you're running an application in
real mode under OS/2 and you switch to a protect mode screen group, the
real mode application receives no interrupts.  They're not 'lost', but the
overrun interval is so long that the point is nearly moot.  This had to be
done to prevent applications like SideKick from trying to "pop up" on the
screen when the real mode screen is not being displayed.  There is no way
to automatically detect these programs (halting problem) and no way to stop
them, since they run in true real mode.  These restrictions can be relaxed
on a 386-only release of OS/2.

In general, COMM applications under OS/2's 286 release need to be protect
mode, and the user needs to avoid the real mode screen group when they're
active.  Either that, or you need a protocol which will recover overruns;
they shouldn't occur all that often.

Billy Brackenridge: Did I correctly infer that the first real release of
OS/2 acts like it is on a 286 even if it is running on a 386?

Gordon Letwin: Yup.  We use the 386 mode switching hardware to improve
performance some and reduce the interrupt lockout considerably, but no
other 386 features yet.

Billy Brackenridge:  When running an application in protected mode
presumably I use system services to do I/O. I gather that even using the
system calls from protected mode I can lose interrupts on the serial port.
Suppose I have a background process running in protected mode and it is
reading from a serial port.  What happens when I jump into my real mode
window?  Are interrupts still coming in to my protected mode background
process?  Is this where the 800 microsecond latency comes in?  Is this the
same on a 286 vs. 386 machine?

Gordon Letwin:  You don't loose interrupts.  If the real mode box is in
foreground then interrupts for a protect mode guy may be delayed,
especially since the real mode guy might do a CLI for an arbitrary amount
of time.  The 386 reduces the mode switch delay (~800 us on a 6 mhz 286)
but it can't do anything about CLI.

Billy Brackenridge:  You mentioned I should "avoid the real mode screen
group when (a communication process) is active".  Can my process get a
signal when the user wants to move to real mode so I can send out an XOFF
to shut off the world gracefully?

Gordon Letwin:  This is being considered now.   Not sure of the current
status.

Billy Brackenridge:  Are there any "official Microsoft/IBM" plans for
support of IP/TCP under OS/2.  Are there hooks in place where the
university community can get access or is it like the Microsoft Redirector,
that is,  only open to the select few?

Gordon Letwin:  Sorry, I don't know.

Billy Brackenridge:  Also I could just fork over the $3K and then I
wouldn't be so darned ignorant of how OS/2 works. (or doesn't work)

Gordon Letwin: Yup, it costs $3k, and it's well worth it, according to our
surveys of those who bought it.  I take it that you're unhappy about this.
Sorry.  It could sell for about $1500 without support, in which case you'd
be no happier.  We can't sell it for less than that without undercutting
the retail prices of the component products in it (MASM, C compiler,
windows, etc.) which is a no-no because it burns our dealers.

             ------------ end discussion ---------------

My conclusions from all this are:

OS/2 switches from real mode to protected mode as fast or faster than any
other single CPU product on the market.  OS/2 may or may not be slow in
other areas, but calling it a crock and completely writing it off at this
point in time is premature.  While Microsoft hopes it will take over the
world, I suspect other companies will try to enter the wide open field of
protected/real mode operating systems.  All will face the same problems
with loss of interrupts.

Anybody who buys or produces 80286 machines now is asking for trouble
later.  ~800 us on a 6 mhz 286 for a mode switch is too slow for me.  If a
80386 machine is available buy it now.

I am still confused about Microsoft and networking.  I suspect Microsoft is
confused as well.  OS/2 has a lot of the hooks one needs to do networking
right.  Semaphores, inter-process signals, shared data areas, inter-process
communications, etc. provide tools to build a good networking environment,
however, the people who provide DOS environments under Unix have all that
as well as IP/TCP protocols, spoolers, and mail systems.

If you are interested in PCs pay the $3000 for a developer's kit.
Everybody I have talked with says the OS/2 that comes with the kit is a
slow crock and they have gone back to DOS to run real programs.  Some have
despaired and gone to various flavors of Unix.  I have seen enough
operating systems in their early days that I am not particularly
discouraged by this behavior.  It may be that OS/2 is a crock.  If it is,
and people can come up with examples of where it loses big, we will publish
it here in the digest even if you make a competing product.  I and
successor editors will try to edit things so we are at least fighting with
boxing gloves.   Microsoft is listening and some things might even get
fixed.

------------------------------

Date: 3 Sep 87 21:55:24 GMT
From: munnari!cidam.rmit.oz!rcedw@uunet.UU.NET (Dave Wilson)
Subject: Experiences/choices when connecting to other PC Networks
Organization: RMIT Mech and Prod Engineering, Melbourne, Australia

I am trying to collect information about PC networks, If you have
a pc network installed, I'd appreciate a response to the following
questions.

     What protocol is being used?
     What server do you need?
     What services does it offer?
     Can it connect to other networks (ethernet)?  If so, is it (nearly)
transparent to the user?
     Does all your software work on the network?  If not, which packages?
     Are you a satisfied customer?
     What is the cost/pc, server cost and software cost?

Do YOU have anything you wish to add on the subject of PC networks?

please respond via email and I will summarize to the net.

David Wilson, Civil Engineering, Royal Melbourne Institute of Technology
                                 Melbourne Australia
rcedw%cidam.rmit.oz@seismo.css.gov or
seismo!munnari!cidam.rmit.oz!rcedw

------------------------------

Date: Sun, 6 Sep 87 19:19:09 CDT
From: Esmail Bonakdarian <bonak%cs.uiowa.edu@RELAY.CS.NET>
Subject: Foreign language word processing

Does anybody know of any word processing packages capable of producing text
in Farsi (Persian) and/or Chinese? I would be interested in your experience
with packages and for any price information you can provide.

This is to be run on an IBM PC compatible with an Epson FX-86e printer
(although this could be changed if necessary).

thanks,
esmail

------------------------------

Date: Mon, 07 Sep 87 17:47:16 SET
From: RECK%DBNUAMA1.BITNET@wiscvm.wisc.edu (Gisbert W.Selke)
Subject: Measuring speed from within Turbo Pascal

I need to measure the approximate clock rate of a PC from within a Turbo
Pascal program.  So I wrote a little procedure which first got the current
time (via a DOS call), then executed some silly little loop and then got
the time again.

>>> First question: Is there a simpler or more intelligent way to find the
speed?

I ran this on several machines, XTs, ATs and compatibles. The results
typically looked like this:

                                 Low    High      (time in centi-seconds)
         AT clone (10 MHz)        267    412
         XT clone (4.77 MHz)     1620   1776

What puzzles me is that for each machine in about 80% of the cases the high
value would turn up (fairly stable) and in about 20% of the cases the low
value would turn up - but never any results in between.  Also, the
*absolute* difference between high and low times was always the same -
about 155 centi-seconds, irrespective of the clock speed of the machine.

>>> Second question: What causes this difference? Is it simply that the
real time clock is not always kept up-to-date?

Any help will be appreciated.

\Gisbert

------------------------------

Date: 4 Sep 87 06:16:12 GMT
From: ronb!munnari!metro.otc.oz.au!daemon@uunet.UU.NET (Ron Barrett)
Subject: Programming DOS TCP/IP interfaces to PC-NFS
Organization: OTC Development Unit, Australia

We have recently acquired PC-NFS and want to set up some "Socket-like"
communication between programs on an IBM-AT clone and our Pyramid-90X.

The problem lies in the fact that the PC-NFS documentation makes no
reference to a programming interface, mentioning only high level user
commands.  Is PC-NFS simply based on RPC/XDR, or are there some subtleties
worth knowing about for programming in a DOS environment.

Comments from anyone with knowledge/experience in this type of application
would be greatly appreciated. Please E-mail to the net address below.

Thanks in advance,

               Ron Barrett
              Systems Development
               |||| OTC ||

    ACSnet: ronb@otc.oz       UUCP: {uunet,mcvax}!otc.oz!ronb

------------------------------

Date:    Mon  7 Sep 87 17:16:08 GMT+2
From:    ACESTAB@HUTRUU0.BITNET
Subject: Where has Quaid Software and Disk Explorer gone

Has anyone recently heard from Quaid Software Limited (Canada). A few
months ago we had contact by telephone. Since that time we couldn't get any
contact, and we are desperately looking for their program DISK EXPLORER.
Please contact directly.
      greetings

       Bert Stals <ACESTAB@HUTRUU0.BITNET>

------------------------------

Date:     Tue, 8 Sep 87 11:53:29 EDT
From:     Kimball Kramer (FSP) <kkramer@ARDEC.ARPA>
Subject:  Possible to re-direct standard error output

How does one re-direct error messages into a file?  In particular, I am
interested in redirecting the error messages from the C-86 compiler and
linker.

     Thanks in advance,
               Kim Kramer - <kkramer@ardec.arpa>

------------------------------

Date:     Tue, 8 Sep 87 09:42 N
From:     <OBSGVA%CGEUGE51.BITNET@wiscvm.wisc.edu>
Subject:  ATI EGA WONDER board problems

We have half a dozen CAF brand Turbo PC-XT clones of the same version
number, and same configuration, i.e. 4.77 / 8 MHz switchable motherboard
with 1 MByte of RAM, an 8087-2 NDP, a multi-function I/O card, 2 FDDs, a 30
mbyte HDD and an ATI EGA-Wonder graphic adapter with a TAXAN 1213 TTL
monochrome monitor.

We have a problem when we use the EGA mode of the adapter in Turbo mode.
This occurs only in this mode, and on four of our six systems !

The screen appears as if the H-sync pulse was sometimes shifted a bit in
the video signal. Most characters are OK, but some are not. For these,
every second scan line get shifted to some other place on the screen, not
necessarily on the same line. So the effect is that some characters are
split up.  There may be two problems !

We have used a CRO to look at the video signal from the board, and we can
see the error in the signal. When we do a "Print Screen", the printout is
perfect, however.  We tried to swap the cards of the two systems that work
fine with others, but it didn't show consistent results. The test program
supplied with the board works well, but the problem is erratic, and seems
to rely on the content of the screen.

We are at Geneva Observatory, Switzerland.  Please contact

                        Denis Megevand
                        Geneva Observatory
                        51, ch.des Maillettes
                        CH-1290 Sauverny

                        "megevand@cgeuge51.bitnet"

We would appreciate hearing from anyone who has any ideas what is wrong or
what we can try next.

------------------------------

Date:     Wed, 9 Sep 87 14:53 EDT
From:     <RSCHELLE%DREW.BITNET@wiscvm.wisc.edu>
Subject:  Programming TSR utilities from Turbo-C

I have been trying to write a Terminate and Stay Resident utility in Turbo
C.  Using Turbo's library procedures, it was a fairly easy matter to re-
program the keyboard interrupt vector to point to my interrupt handler, but
whenever I try to use any DOS or BIOS calls from my resident routine (or
try to use any library routines that call DOS or BIOS) the system hangs
with interrupts disabled.  (Ctrl-Alt-Del doesn't work)  This is especially
strange since I can call my own (near) functions from my interrupt handler
without any problem.  I tried calling enable() at the start of my routine,
but that didn't help.  What else do I need to do?

[There have been many discussions on calling DOS from within TSR programs.
Unless you're willing to do some tricky programming, the bottom line is:
DON'T!  See the files printcom.info and indos.txt for a discussion on calls
to DOS.  For examples of programs that make DOS calls, see lptx.asm and
stayres.pas.  (All are available from the lending library) -- gph]

------------------------------

Date:     Wed, 9 Sep 1987 20:58 IST
From:     <EFAA277%BGUNOS%LISTSERV%TAUNIVM.BITNET@wiscvm.wisc.edu>
Subject:  Problems with the Inkey function of dBase III +

I am having trouble getting the ESC key to my program when using the dBase
III function INKEY().  My program stops when I press ESC or the <Cursor
left> key.  What am I doing wrong?

 thanks
 Sefi

------------------------------

Date: Thu, 10 Sep 87 09:08:35 EDT
From: Russell Nelson <bh01@clutx.clarkson.edu>
Subject: VT-100 device driver wanted

Does anyone have a device driver that implements VT-100 escape sequences?

 -or-

Does anyone have a piece of C code that interprets VT-100 escape sequences?

Perhaps I am displaying my ignorance.  I am running with Nansi right now,
and when when I tell our Unix that I'm a vt-100, it sends something silly
that causes Nansi to switch into 40 column mode.  Is NANSI supposed to be
vt-100?  'Cause it sure doesn't appear that way from my end.

-russ

GEnie:    BH01
BITNET:   BH01@CLUTX
Internet: bh01@clutx.clarkson.edu
uucp:     decvax!sii!trixie!gould!clutx!bh01

[NANSI is NOT a VT-100 device driver.  Rather, it is an improvement over
the ANSI.SYS program supplied with DOS.  A VT-100 emulator is also
required.  Is one available?  gph]

------------------------------

Date:    Thu 10 Sep 87 08:54:26 GMT+2
From:    XFCASSAM%HUTRUU0.BITNET@wiscvm.wisc.edu
Subject: Turbo-C OBJ and LIB files

Can anybody out there tell me what the difference is between
OBJ and .LIB files in Turbo-C? Can you make .LIB files yourself?

Regards, Anneke Sicherer-Roetman

------------------------------

Date:      Thu, 10-Sep-1987 11:02:15.34 CDT
From:      <gottlieb%TAMVXOCN.BITNET@wiscvm.wisc.edu>
Subject:   FTP from SIMTEL20 to a VAX 11/750 on BITNET

     I am trying to transfer binary files from DOD's SIMTEL20 to my VAX
11/750 running VMS 4.5.  We are using the FTP command 'quote "type l 32"'
but the files we receive seem to contain several extra bytes.  Has anyone
done this and had this problem?  Can anyone help me?  How do you get files
from the SIMTEL20 archives onto your PC???

                                         Thanks

[I have transferred megabytes from SIMTEL20 via FTP to the C-70 host
located in Taegu.  Normally, I tell the user FTP 'TYPE L' and let it sort
out the differences between its word size and that of SIMTEL20.  (At first,
I tried TYPE L 32 and TYPE L 36 but had problems with the files.)  After
the desired file is at my 'host', I use the Kermit Protocol portion of my
Communications software (straight Kermit programs are available from
cu20b.columbia.edu in directory KER:MS*.*) to download to my PC.]

------------------------------

Date: Fri, 11 Sep 87 11:08:11 EST
From: munnari!elecvax.oz.au!8490368@uunet.UU.NET
Subject: MACE and Hard Disk Problems on a COMPAQ 286

I have a question and am not sure whether it has been answered before, but
I will give it a go.

     I am running a Compaq 286 Portable under MS-DOS 3.2, fitted with a
factory 20Mbyte Hard Disk.  Recently my supervisor decided to run Mace to
clean up a quite fragmented disk.  However Mace decided to "spit the dummy"
and did not complete the job, giving a sub-directory with two "." entries
and two ".." entries.

     What I would like is any advice on using Mace under DOS 3.2 (which
might have been the cause?) and information on how to fix up that corrupted
directory handle.  Also any bugs that come to mind in DOS 3.2 would be
helpful.

Thanking you in anticipation,

Mike Finlayson
School of Electrical Engineering and Computer Science
University of New South Wales
Kensington, N.S.W
Australia.
(Also: Trials and Assessing Unit
       Royal Australian Navy
       54 Miller St
       North Sydney, N.S.W
       Ph +61 2 922 0375)

------------------------------

Date:     09/11/87  0824
From:     <guil%FRCICG71.BITNET@wiscvm.wisc.edu>
Subject:  PC Kermit 2.29

Is there a version of Kermit-Pc newer than the version 2.29 (May 26, 1986)
If yes, how get it ?

BITnet : GUIL@FRCICG71

[There is a 'beta' version of Kermit 2.30 (MS-DOS Kermit 2.29C) available
in 'BOO' format from the KER: Library at cu20b.columbia.edu on the ARPAnet.
Files necessary are KER:MSTIBM.BOO, MSBPCT.PAS (Turbo-Pascal) and
MST29C.DOC.

If you don't have Turbo-Pascal, snarf the files MSBPCT.BAS and MSBPCT.BOO
(BOO'd file of MSBPCT.C), use MSBPCT.BAS to un-BOO the C version and rename
to MSBPCT.EXE.

These are available from the Kermit Library via FTP and ANONYMOUS login.
If you're coming from BITNET, request files MST29C * via CUMVA for KERMSRV
access.]

------------------------------

Date:         Fri, 11 Sep 87 09:35:14 EDT
From:         Randy Schrickel <RAAS%APLVM.BITNET@wiscvm.wisc.edu>
Subject:      Two displays on a PS/2 Model 60

I have 2 monitors connected to a Model 60: a monochrome (8512?) hooked up
to the VGA, and a color (8513?) hooked up to the expansion display card.
The problem is, how do I separate the 2 displays?  That is, the mode co80
and mode mo80 commands used to work (these commands don't seem to do
anything now).

I have software that uses the color for graphics and the mono for text (as
usual), but it won't run.  Setting up 1-2-3 for 2 monitors sends both into
la-la land, but the program is still running (I can type commands to 1-2-3
and exit the program OK).  Setting up for one monitor gives me the same
display on both screens (which is what I usually get with DOS, other
programs, etc.). Has anyone tried this and had any luck?

I think all the magazine reviewers that say everything runs fine haven't
tried using 2 monitors.

Any help would be greatly appreciated.

------------------------------

Date:     Fri, 11 Sep 87 12:18 N
From:     <MSCHENK%CLSUNI51.BITNET@wiscvm.wisc.edu>
Subject:  Smalltalk on IBM PC/AT

I am looking for a Smalltalk environment for the IBM PC/AT.

I recently tried to contact a company named "SoftSmarts, inc." which
advertised (a few years ago) for a Smalltalk-80(TM) running on an IBM(TM)
PC/AT. With no success.

Does anyone know ...
 ... whether this company still operates?
 ... of some other PC/AT versions of Smalltalk?

Thank you in advance,

Marc Schenk
Assistant-Professor
University of Lausanne
CH - 1015 Dorigny

MSCHENK@CLSUNI51 (BITNET)

------------------------------

******************************
End of Info-IBMPC Digest

------------------------------

-------