HDTenEightyP/NetNews huggingface dataset:
From: joe@proto.com (Joe Huffman)
Subject: Re: Borland -> Zortech: Do it ?
Organization: Prototronics @ Sandpoint, Idaho
Date: Sat, 11 Apr 1992 19:44:24 GMT

nlonginow@falcon.aamrl.wpafb.af.mil writes:

>been thinking about going to a 32-bit Compiler, like Zortech. This, as
>opposed to using Borland (or Microsoft) followed by a DOS Extender 
>(like Pharlap). The problem with the DOS extender route is being unable to
>make use of the excellent debugging tools provided by Borland (and
>Microsoft) on the runtime code. I'd like to stay with a well rounded
>development and debugging environment, but ...  ANy ideas of the 
>Zortech product ? (C++, that is)

The only vendors with a way to generate 32-bit apps from C++ code for MSDOS
right now are Zortech and DJGPP (GNU).  At least that I know of.  Watcom
and Metaware are working on similar products, but have not been released
yet.

Zortech has a royalty free 32-bit DOS extender (DOSX), so you don't need 
purchase a DOS extender from Phar Lap (or Rational Systems, or whoever). 
But it doesn't have a debugger or virtual memory.  You can purchase the 
Phar Lap DOS extender for Zortech and use the Zortech debugger.  The 
Zortech debugger is quite good.  Phar Lap has a debugger also, but the 
last time I looked it (version 3.0, 4.1 is shipping now) it was only a 
little better than SYMDEB.  Also, the last time I checked, the Phar Lap
extender had royalties/license fees to be paid when you sold your 
application.

Another alternative is to purchase the X-32VM DOS extender from FlashTek, 
Inc.  It is compatible with Zortech's DOSX, royalty free, with virtual 
memory and a debugger interface and works with the Zortech debugger.  You 
can purchase the X-32VM extender as a "competitive upgrade" to DOSX for 
$69.00.  It will be shipping on or before May 1, 1992.  More information
can be obtained from 'x-32vm@proto.com'.

Disclaimer:  I work for FlashTek.

-- 
uunet!proto!joe
joe@proto.com
Newsgroups: comp.os.msdos.programmer
From: stevea@coyote.datalog.com (Steve Albany)
Subject: MS/PC-DOS Dead? Hardly...
Organization: Datalog Consulting, Tucson, AZ
Date: Fri, 17 Apr 92 08:15:45 GMT

        The original poster of this thread totally spaced out the fact that 
there is an incredible software base already established in the DOS World. 
Where there is software, there are users, and where there are users, there 
will always be programmers?
        Will MS/PC-DOS go bye-bye? Sure. Not tomorrow, not next year, not 
five years from now. But eventually it will. People said the C64 was dead 
three years ago, and yet, there are still scads of people who still swear by 
those machines (why I don't know, but hey, its their business)...
Newsgroups: comp.os.msdos.programmer
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Subject: Re: Moving directories
Organization: University of Waterloo
Date: Tue, 7 Apr 1992 14:47:35 GMT

In article <29e0441a@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes:
>
>You read it right.  I don't know of any way to convince DOS to move a
>subdirectory on its own.

I had to think for a while before I could figure out why this would be, but
I did finally come up with a reason:

If you move a file by renaming it, all you have to do is delete its entry
from one directory and add it to another.  Moving a directory also requires
a change to the thing being moved:  the ".." entry has to point to the parent.

This has made me think of a weird case that might mess up a mover:  is it
possible in DOS to have a subdirectory write protected without having its
parent directory write protected?  

Duncan Murdoch
dmurdoch@watstat.waterloo.edu
Newsgroups: comp.os.msdos.programmer
From: sidney@borland.com (Sidney Markowitz)
Subject: Re: "Sticky" keyboard in Borland C++ 3.0
Organization: Borland International
Date: Tue, 14 Apr 1992 04:11:52 GMT

SORROW%oak.decnet@pine.circa.ufl.edu writes:
>Could someone tell me what the sticky keyboard problem is?  I have
>a Northgate OmniKey keyboard which supports sticky keys normally,
>but I have this feature disabled....since using 3.0 of BC++ thought
>the shift or ctrl keys occasionally get "stuck" in BC++...but I thought
>it was a problem with my kbd...is this the problem?

The problem you are seeing is what I am calling the "sticky keyboard
problem". I received a truly wonderful thorough analysis of the
problem from creasey@oz.dg.com who conducted timing tests of keyboards
and interrupt service routines to track down similar problems with
other software.

Jack, if you're reading this, mail to you bounced badly, but thank you
and I would like a copy of your timing software.

As a result of his analysis, I hope to have the problem cleared up
completely in the update to BC++ 3.0 that we are releasing to support
Windows 3.1, if it isn't too late to get it in there and tested.

The blame can't be laid only on the keyboard, keyboard BIOS, memory
managers, BC++, device drivers or TSR's that hook INT 9, but any or
all of them can be a factor. The basic problem is that an extended
keyboard non-numeric pad cursor key can send up to four scan codes
spaced 2 milliseconds apart from one keystroke, and the way most TSRs
and device drivers that hook INT 9 work, it's easy to end up losing a
keystroke and putting the keyboard BIOS out of synch. Since the BC++
IDE runs in protected mode and switches to real mode on every keyboard
interrupt, it adds the mode-switching time on top of everything else,
which may be enough to lead to symptoms where none were before.

Now that I have the details what is happening, I have something to try
that I hope will prevent the problem while BC++ is running if it isn't
ocurring without BC++.

 -- sidney markowitz <sidney@borland.com>
From: toma@sail.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.os.msdos.programmer
Subject: system hanging up in disk bios routine
Date: 6 Apr 92 21:11:43 GMT
Reply-To: toma@sail.labs.tek.com
Organization: Tektronix, Inc., Beaverton,  OR.

I've written a TSR that reads from the serial port and writes data to the
hard disk. The TSR only runs from the timer interrupt (0ch) when the 
"indos" flag is clear and the disk bios routine has not been entered (I have
my own flag to check), OR from the 28H interrupt. I carefully set and restore
the PSP, DTA, critial and ctrl-break int routines, and the ctrl-break flag
around the code. I use my own stack.

Now, when the system is heavily loaded by leaning on a key (I don't take
the keyboard over), and heavy disk use from the TSR (the serial port is 
running 9600baud, and data is being stored on the disk), often the system
will appear to "hang" for up to 30 seconds -- it is in the TSR, doing a
DOS disk request, and sitting in the Disk BIOS (the disk light is on, as
well). Then the system seems to recover and starts running again, with 
data loss from the serial port, of course, and an occasional, rare, disk
corruption :-(.

The situation is worsened by running on slower machines (one would expect
that).

Does anyone have any idea what's happening? And is there a cure?

Please reply direct to me. I'll summarize if requested.

Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply


-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply
From: robert@solan.unit.no (Robert Schmidt)
Newsgroups: comp.os.msdos.programmer
Subject: Re: "Sticky" keyboard in Borland C++ 3.0
Keywords: keyboard,problem,borland
Date: 7 Apr 92 13:21:00 GMT
Organization: Norwegian Institue of Technology

In article <osPqiB1w164w@vicuna.ocunix.on.ca>, frampton@vicuna.ocunix.on.ca (Steve Frampton) writes:
 > Ready to give up and "live with it", I was fortunate to get some mail 
 > from someone experiencing the same problem...and the solution worked!
 > 
 > 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.
 > ------------------------------------------------------------------------
 > 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"


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!
     e-mail to robert@solan.unit.no
 snail-mail to Stud.techn. Robert Schmidt, stud.post 170,
               Norwegian Institute of Technology, Trondheim, NORWAY
Newsgroups: comp.os.msdos.programmer
From: zcookbruc@cc.curtin.edu.au
Subject: 32bits and BORLAND
Organization: Curtin University of Technology
Date: Sun, 12 Apr 1992 13:43:56 GMT

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.

I also have the problem of needing to write ADS interface programs for AUTOCAD
and would be forced to move to ZORTECH, or HIGH C to do this.

Are BORLAND planning to give us a 32bit compiler, and If so which of the many
standards will it follow.

	...BRU
Newsgroups: comp.os.msdos.programmer
From: walk@mrcnext.cso.uiuc.edu (Todd Walk)
Subject: Re: DOS is dead.
Organization: University of Illinois at Urbana
Date: Thu, 16 Apr 1992 16:44:06 GMT

noesis@ucscb.UCSC.EDU (60276000) writes:


>>I think Russ's point is that people will stop buying DOS in favor of a
>>real operating system, be it OS/2, UNIX, or NT.  I would not be so 
>>optimistic about DOS's demise tho.  Maybe 2-3 years and most development
>>for DOS-based platforms will stop.
>>
>Let's see, what do most people do in an OS? launch programs. from this
>standpoint, TRSDOS was 5K and everything most people needed. Now DOS is
>everything most people need. Why <<<NOT>>> go to windows / os2 / unix?
>money mostly. DOS is about $35.00 and requires about 1808K harddisk and
>256K RAM. Windows-NT, according to the press release will require 100M
>harddisk and 6-10M RAM. the Unix flavors i've seen require 40M harddisk
>and 4M+ RAM to be useful.
     ^^^						    ^^^
Try 200M+ hard disk and 8M+ memory.

					Todd Walk
					walk@mrcnext.cso.uiuc.edu

Xref: sparky comp.os.msdos.programmer:5326 comp.os.msdos.apps:2825 comp.sys.ibm.pc.hardware:13630
From: sorrow@maple.circa.ufl.edu
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.apps,comp.sys.ibm.pc.hardware
Subject: Stability of QEMM-386 6.0
Date: 11 Apr 92 21:26:45 GMT
Article-I.D.: math.1992Apr9.011522.6296
Reply-To: SORROW%oak.decnet@pine.circa.ufl.edu
Organization: The CIRCA Underground

I have QEMM-386 5.11, which has proven to be very very stable and works
with everything I own.  I bought 386^Max 6.02, which has DPMI support,
but I ditched it after two days because it refused to work with Windows
3.0 or with BC++ 3.0 ( rebooted occasionally for the hell of it ).  I've
been leary of upgrading to QEMM-386 6.0, since I've heard it has many
many bugs, and the latest version is 6.02...how is it?

Has anyone had problems with it, or without it?  The new STEALTH feature
is meaningless to me ( performance hit is not worth it ), and the 
squeeze fit is just as meaningless.  If I get the upgrade it will be
because it has either a.) more support for newer products, b.)
significantly less memory overhead, c.) significantly less bugs than
QEMM-386 5.11, or d.) more performance.

Any opinions via e-mail requested.

Brian
From: ts@uwasa.fi (Timo Salmi)
Newsgroups: comp.os.msdos.programmer
Subject: Re: tricky batch - help
Date: 8 Apr 92 11:57:03 GMT
Organization: University of Vaasa, Finland

In article <92097.223002L28BC@CUNYVM.BITNET> L28BC@CUNYVM.BITNET writes:
>I am trying to find a way to prompt a user to enter a filename.  The computer
>will then search for an existing filename and insert the filename and path
>into a variable.  Does anyone know or have an idea how to search for the files
>and insert their filename and path into a varialbe, if they exist or not ?

If the usual giving the file name from the command line is not
acceptable for your task then you will have to write a program that
reads the users input and writes it to an environment variable of
the parent task.  That is not easy to do but if you are writing your
auxiliary program in Turbo Pascal I have a SetEnv routine in a
public TPU of mine.

...................................................................
Prof. Timo Salmi
Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
From: dubs_cif@troi.cc.rochester.edu (Jeremy DuBois)
Newsgroups: comp.os.msdos.programmer
Subject: Problem with TCC/BCC and macro definitions
Summary: A problem with defining macro functions in TCC and BCC
Keywords: TCC Turbo Borland problem macros C
Date: 16 Apr 92 03:27:26 GMT
Organization: University of Rochester - Rochester, New York


  Hi guys/gals, My father has run into a problem upgrading from Turbo C to
Turbo C++. Yeah, I know upgrading to Turbo C++ instead of Borland C++ is a
little silly, but you know these old-timers ;)

  Anyway, here is the problem.  He's got a lot of #defined macro functions
in his programs, and he calls them with parameters that are also #defines.
This works fine unless he trys to pass more than one parameter as a single
#define.  Here's an sample of code that won't preprocess:

-------
#include <stdio.h>

#define MACROFUNC(x,y) x+y
#define MACROPARAM 5,1

void main()
{

  printf("%d\n",MACROFUNC(MACROPARAM));
}
-------

  Now he claims the Turbo C used to let him do this, but Turbo C++ says
that there aren't enough parameters to the macro function call.
  I tested it with my copy of Borland C++, and with sun's cc, and gcc on the
universities sun 4's, and they all behave the same way as Turbo C++ (i.e.
they won't compile.)
  Finally, my question is: Does anybody know if there is a way to make Turbo
and/or Borland C++ to act like the old Turbo C and compile this, or does my
father have to go and change all of his source code to work with Turbo C++?

			  Thanks for any help you can provide.
--
/ Jeremy DuBois \ 
-----------------------------------------------------------------------
| dubs_cif@uhura.cc.rochester.edu | University of Rochester, New York |
-----------------------------------------------------------------------
From: pellouch@alumni.cs.colorado.edu (Philip Pellouchoud)
Newsgroups: comp.os.msdos.programmer
Subject: Question about reading a bus mouse...
Summary: Reading the status of a bus mouse...
Keywords: mouse
Date: 17 Apr 92 05:58:32 GMT
Organization: University of Colorado, Boulder

Hi!  Got a question, pretty simple, but then again, so is
my pea brain!  :-)

I am trying to read the x-y position and button presses.
I am using turbo c++ and have a logitech bus mouse.  There
are no obvious provisions in Borland's c++ to read any of the items.

I have looked at the location where the driver is installed: 0D52:0000,
but the values don't change when I move the mouse or click the buttons
(infinite loop, continually printing out values.).  Anyway, sorry if this
is an FAQ, but I don't read this group, so any replies should please be
sent to "pellouch@alumni.cs.colorado.edu"

Thanx in advance,

-Phil
Newsgroups: comp.os.msdos.programmer
From: jdishaw@acme.claremont.edu
Subject: Re: Serial and Parallel Ports
Organization: Pomona College
Date: 16 Apr 92 22:11:33 PDT

In article <johnr.703398126@wambenger>, johnr@cs.uwa.oz.au (John Redman) writes:
> This is probably a very basic kind of thing to
> ask, but --
> 
> 	How do I go about reading and sending
> 	information from/to serial and parallel
> 	ports?
Actually it is not a very basic kind of thing, but rather a very good question.
Working with either port is rather tricky.  Lets consider the parallel port
first.  The parallel port, as setup up by default on the PC, has 12 output
pins and 5 input pins (if I remember correctly).  Depending on the chip 
used in your PC and how it is setup, you might be able to redefine which pins
are input and which are output.  The serial port has essential a transmit
pin, a receive, and a couple signal pins.
The tricky part now is recovering the information from the ports.  The easiest
method is to constantly poll the port and see if a new byte has arrived.
This unfortunately sucks up some CPU time and also precludes high speed
data transfer.  The preferred method to use is to set-up an interrupt service
that gets called whenever a incoming byte is recevied.  Transmitting is usually
pretty easy.  You stick the byte to be transmitted and that is it.  If you
want high speed communication (especially on a serial port), you might have
to setup an interrupt service that feeds the port whenever a byte has been
transmitted.  Thus the ideal setup is to double buffer the port you want to
use.
If you want information on the parallel port, a good person to talk to is
fdeck@grumpy.helios.nd.edu.  I've done some work, but I haven't gotten my
double buffering code to work yet so I wouldn't be the best person to talk 
to.

-james dishaw
JDISHAW@POMONA.CLAREMONT.EDU
Newsgroups: comp.os.msdos.programmer
From: zcookbruc@cc.curtin.edu.au
Subject: Re: Bug of Turbo C 2.0?
Organization: Curtin University of Technology
Date: Wed, 15 Apr 1992 09:53:10 GMT

In article <1992Apr15.045942.9349@ux1.cso.uiuc.edu>, klg0582@uxa.cso.uiuc.edu (Ken-Huang Lin) writes:
> 
>   I was writing a program using Turbo C 2.0.  The program seemed to be
> working.  However, after I moved part of the code into a function, it
> gave me this run-time error message when the program reached the same
> code now in the function:
> 
> "scanf: floating point formats not linked"
> 
>   I downloaded the patch "tc2pat.arc" and applied it.  Only some
> patches would work.  The file "patfloat.bat", which is supposed to fix
> "floating point formats not linked" problem, said "Incorrect file or
> version of program file".  (The compiler is version 2.01.)  Does
> anyone have any clue?
> 
> Ken H. Lin
> khlin@uiwpls.ece.uiuc.edu

here's a guess based on sources I've seen of other C libraries:

Some libraries, because of size problems, don't have atof(), atod(),
dtoa(), ftoa() in the main C library, instead they have a dummy function
that says somthing along the lines of "floating point foramts not linked".

The way to cure this (In the cases I've delt with) is to link in the maths
library, if possible before the c library (est way to ensure linkage order
in TC 2 is to use TLINK).

I personally have never had the problem with any versions of TURBO/BORLAND C
this may be because I always use TLINK.

Sorry I can't give you accurate "i've done it information".

...BRU
Newsgroups: comp.os.msdos.programmer
From: sidney@borland.com (Sidney Markowitz)
Subject: Re: Microsoft compiler?
Organization: Borland International
Date: Fri, 10 Apr 1992 21:16:24 GMT

<9204082048.AA03956@xuucp.ch.apollo.hp.com> nelson_p@APOLLO.HP.COM writes:
>   Currently I use Borland C++ 3.0.  It's been a little buggy
>   but they've already sent me ome patch disk and I'm getting
>   by OK.     Their latest bug (that TDW does not work with 
>   Windows 3.1) is more serious because it prevents me from
>   upgrading to the Windows 3.1 and Borland hasn't announced
>   a release date for a fix

I wouldn't call it a bug. Microsoft changed something in Windows 3.1
and the WINDEBUG.DLL that we licensed from them won't load under it.
I have uploaded our replacement DLL that should work with both WIndows
3.0 and 3.1 to the Simtel20 archives where it should appear just as
soon as the archive maintainer makes it public. If you are not a Turbo
Pascal programmer, look for the file TDWIN31.ZIP in pd:<msdos.turbo-c>
directory on wsmr-simtel20.army.mil or in corresponding directories on
wuarchive.wustl.edu and oak.oakland.edu. If you use Turbo Pascal for
Windows, look for TPWN31.ZIP in the pd:<msdos.turbopas> directory. It
contains the same DLL plus a number of TP units for Win 3.1.

I will also upload TI868.ZIP, which is an informational file on using
BC++ 3.0 with Windows 3.1, to the turbo-c subdirectory of the archives
as soon as I get a chance. You can also get that from the Borland toll
free techfax number which should be in the BC++ 3.0 documentation.

These files are interim measures until we release the BC++ update kit
for Windows 3.1, but they should suffice until then.

 -- sidney <sidney@borland.com>
From: lape@cs.utk.edu (Bryon S. Lape)
Newsgroups: comp.os.msdos.programmer
Subject: Re: DOS is dead.
Date: 17 Apr 92 20:43:04 GMT
Organization: University of Tennessee, Knoxville - CS Department
NNTP-Posting-Host: duncan.cs.utk.edu

In article <1992Apr16.182359.26504@exu.ericsson.se> exuhag@exu.ericsson.se (James Hague) writes:
>Jason Packer writes:
>>
>all these new operating systems and GUIs keep getting bigger and
>better, I have yet to see any equivalent advances in the associated
>software.  Word processors for Windows aren't a great leap over
>those for DOS.  The same goes for everything else.  What you end
>up getting are larger, slower applications with roughly the
>same functionality.

	Ever use PageMaker for MS-DOS?  Did not exist until Windows 3.0.
(ok, there is an OS/2 version).  What of Excel?  PowerPoint?  etc...


bsl

-- 
-----------------------------------------------------------------------------
Racism knows no colour.
-----------------------------------------------------------------------------
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.os.msdos.programmer
Subject: Re: TOO LARGE AN .EXE
Date: 13 Apr 92 17:38:14 GMT
Organization: Academic Computer Centre Utrecht

In <1992Apr13.160648.20088@nuscc.nus.sg> eletanjm@nuscc.nus.sg (Tan Jin Meng @ NUS) writes:

>I am working on an application whose .exe file whose size is ballooning
>rapidly. The development tool is MSC6.0.

>Any way that I can reduce the size of the executable by 
>	1)	using some other linker
>	2)	Any other method??????

>HELP!!

There are about two options that I know of. One of them is to upgrade
to MSC 7.0 which is capable of generating tighter (but slower) .EXE files.
Another one (assuming you don't use overlays) is using a .EXE compressor.
There are many floating around of which DIET.EXE (freeware) seems to
be the best.

PS DONT MISUSE LARGE LETTERS IN YOUR REQUEST

Nico 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.
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer