HDTenEightyP/NetNews huggingface dataset:
From: hmiller@osiris (Harry Miller)
Newsgroups: comp.os.msdos.programmer
Subject: Protected Mode C++ and Fortran
Keywords: Protected Mode, C++, Fortran
Date: 10 Apr 92 18:48:49 GMT
Article-I.D.: ux1.1992Apr10.184849.9197
Organization: University of Illinois at Urbana

I'm starting a project where I'll need to do protected mode programming
in both C++ and Fortran (horrible, isn't it).  Rewriting the Fortran part
of this work is not an immediate option unfortunately.

Zortech C++ looks like the best bet for C++, but I have no idea about
accessing Fortran with it. Anyone tried this yet.

Also, what about protected mode Fortran compilers.  What are the good and
bad ones out there.

I would like to stay away from MicroSoft if possible.  There Fortran is
suppose to be pretty good, but I don't trust new packages, that is C++
7.0.

Thanks in advance.

Harry E. Miller ----------------- just a jerk lurking on the net
hmiller@osiris.cso.uiuc.edu ----- where to send the hate mail
From: frampton@vicuna.ocunix.on.ca (Steve Frampton)
Newsgroups: comp.os.msdos.programmer
Subject: Re: "Sticky" keyboard in Borland C++ 3.0
Keywords: keyboard,problem,borland
Date: 8 Apr 92 09:22:23 GMT
Organization: Vicuna Systems, Kingston, ON (613) 547-5066

robert@solan.unit.no (Robert Schmidt) writes:

> In article <osPqiB1w164w@vicuna.ocunix.on.ca>, frampton@vicuna.ocunix.on.ca (
>  > For those people experiencing keyboard problems under BC++ 3.0 (and other 
>  > software products), if you are using the Quarterdeck QEMM Memory Manager 
>  > software, try adding the following:
>  >   IGNOREA20 UNUSUAL8042
>  > to your 'device=c:\qemm...' statement in your CONFIG.SYS file.
> 
> I have yet to try if this helps me, but did you get any explanation on what
> was wrong/what those options actually do?
> 
> -- 
> Regards from Robert Schmidt, PC C/asm is my game, fast graphics is my 
> pain  -  Watch for my VGA/SB demo!

Huh?  You mean you're using QEMM and you don't have any documentation for 
it?  Hmmm...  :-)

Options:
  IGNOREA20 - "does not trap the 8042.  By default, QEMM.SYS traps the 
  8042 ports for the purpose of detecting programs which attempt to 
  manipulate the state of the A20 line.  Programs do this to access 
  extended memory.  However, sometimes keyboard problems arise as a 
  result.  The IGNOREA20 (or IA) instruction disables support of 
  HIMEM.SYS, but it may serve to remove some keyboard-related problems    
  as a trade-off.  QEMM 386 supports XMS, and so there is no good reason 
  to load HIMEM.SYS [anyway]."
  UNUSUAL8042 - "specifies that the computer has a "non-standard" 8042 
  keyboard controller.  If setting QEMM.SYS to ON or running DESQview 
  disables the keyboard then the UNUSUAL8042 (or U8) switch should be     
  specified."

Hope this helps.

------------------------------------------------------------------------
Steve Frampton (frampton@vicuna.ocunix.on.ca), Kingston, Ontario, CANADA
"Sometimes I tune my car radio to static and pretend I'm flying an F-16"
From: chip@ac.dal.ca
Newsgroups: comp.os.msdos.programmer
Subject: Re: Problem with exec'ing a Turbo Pascal program
Date: 13 Apr 92 01:18:09 GMT
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

> An explanation of this behaviour would be appreciated.  Our
> experiments have indicated that when a Turbo Pascal program is
> exec'ed it gets given all of RAM even though there is a compiler
> directive that told it to only allocate a small heap :-(

The Turbo Pascal program needs to have a line added to the beginning of
the source code.

Add a line like:  {$M stack, minheap, maxheap}

Then recompile the code.  This will let you set the amount of memory that
Turbo Pascal will try to access.  If this switch is not set, it will try
to grab all available memory.

Hope this help.
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Borland -> Zortech: Do it ?
Date: 14 Apr 92 08:34:11 GMT
Organization: Academic Computer Centre Utrecht

In <29e9bab6wnr062@ark.abg.sub.org> ralf@ark.abg.sub.org (Ralf Stephan) writes:

>nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
>> 
>> If you start using ZOrtech at least DON'T trow away your Borland package. Al
>> notice Borland C++ dor OS/2 2.0 is comming and this will generate 32 bit cod
>> probably Zortech will be sooner (althought if you are in a hurry you can
>> considder a C++->C translator and C/Set 2 or Watcom C 9.0 for OS.2 2.0.
>             ^^^^^^^^^^^^^^^^^^

>Could you or one recommend a (perhaps free) C++-to-C-translator?
Well I would only do it if you are in a hurry since the C++->C translator
is I believe a DOS app (althought OS/2 runs it better than DOS of cource). 
ClockenSpiel C++ is the only one I know of for the PC. I know of no
free version, sorry.

>Thanks!     --Ralf


Nico E. de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (coming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: markh@csd4.csd.uwm.edu (Mark William Hopkins)
Newsgroups: comp.os.msdos.programmer
Subject: Re: C compiler reviews needed
Date: 15 Apr 92 03:42:17 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee

In article <595@grivel.une.oz.au> scavanag@neumann.une.oz.au (Steven Cavanagh) writes:
>I'm thinking of getting a C compiler very soon, and I need YOUR
>opinions one which one is best and why. Please tell me any bad
>points about the ones you know as well.
>
>(This is for the IBM, for those reading this in comp.lang.c)

Power C is $20 with optional add-ons, library source for extra, and a good
reference.  Need I say more :)
Newsgroups: comp.os.msdos.programmer
From: sidney@borland.com (Sidney Markowitz)
Subject: Re: 32bits and BORLAND
Organization: Borland International
Date: Tue, 14 Apr 1992 04:22:43 GMT

zcookbruc@cc.curtin.edu.au writes:
>I'm interested in hearing BORLANDs views on this (Am I even in the correct
>newsgroup?)
>
>For a while I've been hearing vague promisses from my local BORLAND office
>the BORLAND C++ would give me the option for 32bit code. (This implies to me
>that it would have to support some DOS extender, and behave socially towards
>other 32bit programs E.G. 386max, QEMM, etc). I've been waiting for the day
>especially since trying to use TD386, I have to re-configure my system
>(incidentally loosing memory, and networking) to use the debugger. This isn't
>a particularly good way to do things when debugging networking programms, or
>programms that use EMS.

Borland's Director of Product Management for Languages said in an open
forum that Borland expects to offer a 32-bit version of BC++ that supports
the Win32s API by the end of the year. He didn't provide more details.

But you don't need to reboot to use your debugger now for your 16 bit
work: TD386 may be incomapatible with 386 memory managers, but it's
TDH386.SYS that gives you access to hardware breakpoints, and
TD286.EXE will use that capability if TDH386.SYS is loaded. You can
even load TDH386.SYS high. The only significant difference between
TD386 and TD286 is that the latter occupies about 70K of low memory,
but you should get more than that back from your memory manager
anyway.

 -- sidney markowitz <sidney@borland.com>
 [disclaimer: I don't speak for Borland, I'm just quoting a
              spokesperson]
From: zonnevel@dutiws.tudelft.nl (622622)
Newsgroups: comp.os.msdos.programmer
Subject: WANTED: LEX and YACC
Date: 8 Apr 92 16:17:06 GMT
Organization: Delft University of Technology,The Netherlands


Hi there all you msdos'ers I'm posting this for a friend of mine. He is
looking for two tools that are avaiable on unix but wants them for his
dos machine.

These tools are called LEX and YACC and they are used to make a compiler
for a specific language, which you define yourself and then give to LEX and
YACC which turn out I guess a lexicographic analyser for your language.

If any of you know about this being avaiable on msdos please email me
at zonnevel@dutiws.tudelft.nl because I normally do not read this newsgroup.

Greetings, Bart (zonnevel@dutiws.tudelft.nl).

short sig
Newsgroups: comp.os.msdos.programmer
From: zcookbruc@cc.curtin.edu.au
Subject: Re: Need a Good Program Editor
Organization: Curtin University of Technology
Date: Wed, 15 Apr 1992 08:55:07 GMT

In article <1992Apr13.025250.11985@casbah.acns.nwu.edu>, sforslev@casbah.acns.nwu.edu (Susanne Forslev) wrote:
}I have a consulting client who has a 54 mb DIF file that was lunched in
}three or four places.  Thanks to the Norton Utilities, I fixed a couple
}places, but I can only substitute instead of actually delete the bad
}records.  What I need is a good editor that can handle a file this large
}without taking 3 hours to load, so that I can get the file in a decent

Another editor you could try if you're realy in a JAM is the BORLAND C IDE
compiler editor (NOT TURBO C). It readly blew my socks off when I found
a PC editor that could actually do paged editing (but to find it in a compiler
is realy impressive !).

The other you might try is DEMACS (With a LARGE amount of free disk to act as
a page file).

Another is to find someone with a VAX, and do it with EDT, TECO, TPU, or any
other paging editor.

...BRU
Newsgroups: comp.os.msdos.programmer
From: mmshah@im.lcs.mit.edu (Milan Shah)
Subject: TC and TD failing with Fatal EMS error?
Organization: MIT Lab for Computer Science
Distribution: comp
Date: Fri, 17 Apr 1992 06:18:17 GMT


Hello all!

I need to dust off my copy of TC 2.0 and TD 2.0 to do some
work for a client. So I installed it, and they both fail with
Fatal EMS error. 

The problem seems to be with running EMM386.EXE that came with
DOS 5. I run EMM386.EXE with the NOEMS option. If I drop that
option, TC and TD work fine. 

Is this a known problem? Is the only fix to run EMM386 without
the NOEMS option? Or did Borland issue a patch to fix this?

Incidentally, I don't want TC or TD to use Expanded Memory. I
don't know why they complain, and why there is no switch to
tell them not to use expanded memory.

Thanks for any help!

Milan
Newsgroups: comp.os.msdos.programmer
From: kibirev@csa.bu.edu (oleg kibirev)
Subject: Re: 386 SX Bug
Organization: Computer Science Department, Boston University, Boston, MA, USA
Reply-To: kibirev@csa.UUCP (oleg kibirev)
Keywords: 386SX, BUG, INTEL
Date: Thu, 16 Apr 1992 15:51:57 GMT

In article <3544@cruzio.santa-cruz.ca.us> aki@cruzio.santa-cruz.ca.us writes:
#
#/**************************************************************************
#   When the CPU gets to CALLing the hardcoded addr, it will not return.
#   It gets lost in never never land. It seems,  that the address is not
#   correctly stored to the target memory location with the MOV command.
# 
#   I solved the problem by adding some NOP statements between the MOV and
#   the CALL.
# 
#   Aki Korhonen, January 5th, 1992.
# 
#   PS. Check out PC-BENCH 1.4 and the soon-to-be-released PC-DIAG!
#***************************************************************************/
# 
#  asm     mov ax, segm
#  asm     mov bx, 0
#  asm     mov di, offset offs_tavu
#  asm     mov cs:[di], bx
#  asm     inc di
#  asm     inc di
#  asm     mov cs:[di], ax
# 
#  asm     db 0x9A        /* CALL FAR, next two words are: OFFS, SEGM */
#  asm    offs_tavu:
#  asm     dw 0
#  asm     dw 0
#
It's not exactly a bug. 80?86 has a lookahead buffer to read a few
next instructions while the current one is executing. As a result, if
you modify nearby code, CPU may execute the old version from the
buffer. In your case it's CALL 0000:0000, so no wonder computer ends
in hyperspace. The quick fix is jmp $+2 before offending code to
flush the buffer. However, because jmp is rather slow, I usually try
to rearrange code so that instruction is modified long before
execution.

The worst thing is that the size of the lookahead buffer grows from
one CPU to another, so you can end up with code working on 286, but
not 386. 

It took me quite a while to figure this out when I had a simular problem
with my code. Just imagine my surprise when the program worked fine
when I single-stepped through it, but refused to run for serious!

						Oleg Kibirev
						kibirev@CSA.BU.EDU
From: nbb@sersun1.essex.ac.uk (Bosanquet-Bryant N F)
Newsgroups: comp.os.msdos.programmer
Subject: Turbo pascal-pull down windows in graphics mode-help with source
Date: 9 Apr 92 10:34:42 GMT
Reply-To: nbb@essex.ac.uk (Bosanquet-Bryant N F)
Organization: University of Essex, Colchester, UK


Greetings fellow netters,

I've started to write a program using both text and graphics modes.  Why I use
text mode I'm not sure.  Anyway, the program must use graphics mode, but I
also switch things on and off, currently from a small text block saying what
key to press.

What has been suggested to me of which I had previously thought about, is to
use some pull down menus or the like.  Therefore I would be most grateful for
any help/pointers/pointers to specific archive files, so that I could possibly
incorperate this in my program.

I've been looking at the qwik/pull files at simtel20 but to have nice pull down
menus, it has to be in text mode.  Of course it would be nice to have something
like this, but currently any cheap and dirty method would be a starting point.

I'm a bit nieve (sp?) about this so, any help just to save the screen area,
draw window, ...functions..., and restore screen, would be most helpful.
I'm currently using TPv5.5, but TP6.0 is supposed to be in the post, running
on a pc with a vga monitor.

Please respond by mail     nbb@uk.ac.essex

Many thanks    Nigel
From: sam4628@zeus.tamu.edu
Newsgroups: comp.os.msdos.programmer
Subject: Mouse 'ghost' when displaying text
Date: 6 Apr 92 12:48:00 GMT
Organization: Texas A&M University, Academic Computing Services
News-Software: VAX/VMS VNEWS 1.41

I'm writing a simple text interface which uses a mouse (no experience
whatsoever with mouse programming). The problem is that the mouse
occasionally leaves a 'ghost' behind. This seems to be mainly a problem
when text is being displayed. I've tried turning the mouse pointer display
off prior to screen writes and back on afterwards, but the problem persists.
The setup is:
    Logitech series 9 mouse w/ 6.0 driver
    BC++3.0 program using int 33h
Any suggestions would be greatly appreciated!


------------------------------------------------------------------------
| Steven A. McCluney                 |"Strange women lying in ponds    |
| sam5628@zeus.tamu.edu              | distributing swords is no basis |
| I'm a grad student, so my opinions | for a system of government!"    |
|    are worthless anyway            |          Dennis, to King Arthur |
------------------------------------------------------------------------
From: markh@csd4.csd.uwm.edu (Mark William Hopkins)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Need help on TSR's
Date: 16 Apr 92 08:10:23 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee

In article <1992Apr15.033850.16536@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
>If it's being run on a DOS, the problem is likely the DOS.  System calls are
>usually critical regions in DOS.  If two processes happen to be concurrently
>accessing the same critical region, they could destroy the integrity of the DOS.
>
>That might be the problem.

In article <1992Apr15.235445.9454@sequent.com> furballs@sequent.com writes:
>1) You can call South Mountain Software (201) 762-6965 and order
>Hold Everything, which is a TSR library to spawn context switching
>on the fly under TSR's, or
>
>2) You can build into your TSR the ability to save the sate of the
>machine and DOs itself and handle the context switch, plus all the
>associated house keeping needed to juggle multiple threads.
>
>Having done both, I can recommend #1 as the greatest time saver and
>least stress inducer. These guys have already done the home work.
>Don't reinvent the wheel.

Isn't "don't reinvent the wheel" where you ask last semester's student to take
your exam for you because "they've already done it before"?

I'd recommend #2.  Doing #1 totally defeats the purpose, which is to get
experience in this and become an expert.  There's no substitute for learning
or thinking through a problem and this one provides a substantial learning
experience which will so significantly expand a programmer's personal
repertoire as to suddenly make an entire field of programming accessible.
All competent programmers need to master this (process control, synchronization,
multitasking) or something equivalent and do something like this at least once.
There's other items that need to be done at least once: 1 Editor, 1 Compiler or
Assembler, 1 Database program, 1 Real-time/Control program, and several other
areas.

Time is cheap.  Knowledge, experience, and expertise is the real currency.
It's an excellent investment.

On a diversion...

There's also an interesting phenomenon that not too many people are aware of:
when you know enough about enough in a diverse enough range of areas, a
threshold is crossed where everything else becomes dramatically more
accessible and transparent.  At that point all of a sudden everything you know
in one field applies as critical problem-solving insight in every other field
you know.  It doesn't even matter anymore whether you know something or not
because the learning curve on learning itself will have been rounded.  That's
the point from where "don't reinvent the wheel" starts to look like a joke.

Maybe not everyone wants to build up to that threshold, but it's definitely
not a waste of time.  In purely selfish terms, it will lead to substantial
profitability in a world like today's.  And today's world badly needs more
people like this.
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Programming in 386/486 protected mode
Date: 11 Apr 92 21:08:13 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle

In article <1992Apr10.061620.1080@proto.com> joe@proto.com (Joe Huffman) writes:
/Zortech C++ currently doesn't produce 32-bit apps under Windows.  Only 
/32-bit apps for DOS (OS/2 2.0 support is rumored to be in beta).  I'm not 
/sure about Watcom.

With the addition of Rational Systems' BigWin product, Zortech can be used
to develop 32 bit Windows apps running under Windows 3.0 or 3.1.

At Comdex, we demonstrated 32 bit Zortech C++ for OS/2 2.0 and Windows NT.
From: hcbarth@afterlife.ncsc.mil (Bart Bartholomew)
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer
Subject: Re: program to send dial code to modem
Date: 11 Apr 92 07:31:49 GMT
Organization: The Great Beyond

The problem is not all that hard, assuming you have a Hayes-
compatible modem.  Hayes modems respond to ascii sequences
to perform standard commands.  I leave the speed, parity, etc.,
to you to set up.  You need to send the following sequences
to your modem:
the characters crlf, three plusses ('+') followed by a one second
delay, the (optional) string atx4e1 should be sent once, the
sequence atc0dp#######crlf, where the ##'s are the number you
want, which can include things like area codes, etc.  Most modems
will ignore dashes'-' in the number, but I don't know if you can
depend on that.  In the sequence atc0dp (Attention, turn off carrier,
dial pulses) you can use atc0dt for touch-tones instead.
The case doesn't matter much, except you should use all upper or
lower; some modems don't like it mixed.
The three plusses at the start of a line (after the crlf) followed
by the one second delay, alert the modem to go to command mode and
wait for further orders.  This sequence is deemed unlikely to occur
in normal traffic.  The 'at' confirms that a command follows.
x4 enables dial tone and busy detects.  e1 turns on character echoing,
which I find handy for debugging.  e0 turns of character echoing.
	All this should have been in the manual for the modem.
How you get the characters to the modem is up to you; you can 
write a program, print to com1: or whatever, use echo to com1,
copy a file to the appropriate com port, whatever.  Naturally, 
if your modem is on com2, use that instead.  Note that some 
computers don't work properly for com3 and com4.
	Bart

-- 
"It's not the thing you fling, it's the fling itself" - Chris Stevens
 If there's one thing I just can't stand, it's intolerance.
*No One* is responsible for my views, I'm a committee. Please do not
infer that which I do not imply.  hcbarth@afterlife.ncsc.mil
From: timlee@public.btr.com
Newsgroups: comp.os.msdos.programmer
Subject: Re: Programming in 386/486 protected mode
Date: 11 Apr 92 04:08:25 GMT
Reply-To: timlee@btr.com (Timothy J. Lee)
Followup-To: comp.os.msdos.programmer

crichmon@sedona.intel.com writes:
|
|                                             Also, CodeBuilder doesn't
|include any library documentation.  They want you to buy a MicroSoft C 6.0
|reference set ( it at least lists that as one of the needed items (along
|with a 386/486 computer) on the outside of the box).

WHY didn't Intel Code Builder (ICC) come with any library documentation???
Granted, the library is a functional clone of Microsoft C 6.0 (MSC)
library, but the MSC library reference that ICC recommends is close
to useless.
From: space@bwdlh522.bnr.ca (Scott Pace)
Newsgroups: comp.os.msdos.programmer
Subject: What will I lose?
Date: 14 Apr 92 14:39:28 GMT
Organization: Bell Northern Research, Ottawa, Canada
Originator: space@bwdlh522


After being absent from PC development for 2.5 years, I am looking at doing
some programming for DOS.  Windows and OS/2 are not a consideration.  I
would be doing smallish programs.

Question:  If I buy Quick C, what do I lose out on over the full blown MSC
package?  Does QC come with Codeview, and if so, will CV use EXPANDED
memory for symbol tables etc (assume a 386 machine)?

Does Borland have anything that is close in price to QC, with similar
tools?


Thanks for the help.

(amazing how much changes in 2.5 years!!!)
-- 
Scott Pace, Bell Northern Research, Ottawa, Canada, (613) 765-2631
space@bnr.ca - the final frontier                         DoD# 650
Newsgroups: comp.os.msdos.programmer
From: Ralf.Brown@B.GP.CS.CMU.EDU
Subject: Undocumented Tseng-4000 video mode
Date: Wed, 15 Apr 92 02:40:10 GMT
Organization: Carnegie Mellon University School of Computer Science
Summary: mode 3Dh = 1280x1024x16
Originator: ralf@B.GP.CS.CMU.EDU

I stumbled across the following undocumented video mode on my Boca Super
X VGA, which is a Tseng ET4000 chipset with 1M RAM, a Sierra HiColor
DAC, and the Tseng ET4000 BIOS version 3.00.

Mode 3Dh (which can also be set with "VMODE 3D", an undocumented switch)
sets a 1280x1024 graphics mode with 16 colors and 128x64 text (using an
8x16 character cell).  Not bad for a card which advertises itself as
capable of a top resolution of 1024x768.  Unfortunately, the BIOS text
support is buggy in this mode, only scrolling the top third of the
screen and clearing the top 3/4 on a "CLS".

FRACTINT worked just fine after I hacked the appropriate data table
into the card's VESA driver, which luckily comes with source code.

-- 
{backbone}!cs.cmu.edu!ralf  ARPA: RALF@CS.CMU.EDU  FIDO: Ralf Brown 1:129/26.1
BITnet: RALF%CS.CMU.EDU@CARNEGIE   AT&Tnet: (412)268-3053 (school)   FAX: ask
DISCLAIMER?  Did   |  Hansen's Library Axiom: The closest library doesn't
I claim something? |                          have the material you need.