HDTenEightyP/NetNews huggingface dataset:
From: ara@zurich.ai.mit.edu (Allan Adler)
Newsgroups: comp.os.msdos.programmer
Subject: ansi.sys incompatible with previewers
Date: 3 Sep 92 05:47:04 GMT
Distribution: comp
Organization: M.I.T. Artificial Intelligence Lab.



I installed various TeX previewers on an 80386 MSDOS machine with AMI bios.
They worked fine until I installed ANSI.SYS to make demacs work. Once
I installed ANSI.SYS, they would show the first page of the 
file but the arrow keys and numeric keypad didn't function any
more to move around in the document. Eventually, I got around this
without understanding it any better by replacing ANSI.SYS with
TANSI.SYS (Trident ANSI.SYS), which turned out to still work with demacs
and to be compatible with the previewers.

For some reason, today I noticed that the previewers were not compatible with
TANSI.SYS any more.

Can anyone think of any reason why TeX previewers should be incompatible with
ANSI.SYS?

Is ther any way to figure out systematically what the source of the
incompatibility is?

Allan Adler
ara@altdorf.ai.mit.edu
Newsgroups: comp.os.msdos.programmer
From: ccx062@cch.coventry.ac.uk (Chris Taylor)
Subject: Re: Help required to restore IO.SYS
Organization: Coventry University
Date: Thu, 27 Aug 1992 09:35:11 GMT

In article <1992Aug26.153551.25091@bnr.uk> ahemming@bmdhh116.bnr.ca (Andrew Hemming) writes:
>Hi,
>  About six months ago I upgraded to DOS 5, all worked fine until
>a couple of months ago. There was I debugging my final year University
>project when I started to have problems. Every now and again, when I
.
.
>  Does anyone out there know how I can restore my copy of IO.SYS other than
>FORMAT C: /S. I have tried the obviouse.
>

SYS C:

	-Chris
	


-- 
------------------------------------------------------------------------------
		Chris Taylor:	ChrisT@cck.cov.ac.uk  
	Coventry University, Computing Services.    Tel: (0203) 838644
------------------------------------------------------------------------------
From: mlevis@ringer.cs.utsa.edu (Mike Levis)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Novice question: how to boot from a bat file?
Date: 30 Aug 92 23:16:43 GMT
Organization: University of Texas at San Antonio

In article <1992Aug30.205151.18716@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>In article <adgn1#p.messina@netcom.com> messina@netcom.com (Tony Porczyk) writes:
>>begin 666 reset.com
>>1ND``CMJ[<@#'!S02Z@``__\`
>>It's not too long :-), after uudecoding it should be 17 bytes long.
>
>Yes I know it is certainly not too long, but whether just a few
>characters or hundreds of lines, please do not use this practice. 
>Here is the why:
[...]
>Prof. Timo Salmi

I don't think that the uue prog was inappropriate.  It is much
shorter than the source code I see posted (which I don't mind
at all, BTW).

P.S.  I optimised the reset.com and here is the source code:
	sub	ax, ax
	mov	ds, ax
	mov	word ptr [0472h], 1234h   ; mov word ptr ds:[472h],1234h
	db	0EAh, 00, 00, 0FFh, 0FFh  ; jmp FFFF:0000
This one is only 15 bytes long.

-- 
==== Mike Levis   mlevis@ringer.cs.utsa.edu ====
::   ftp syrinx.umd.edu  (128.8.2.114)  for   ::  .--.
::   Rush lyrics,  gifs,  and  information.   :: (OS/2)
:::: Get the Rush FAQL in dir /rush/special ::::  ~--~
From: rover@cs.uoregon.edu (Rick Overman)
Newsgroups: comp.os.msdos.programmer
Subject: RCS DOS port wanted
Keywords: RCS DOS VERSION CONTROL PORT UNIX
Date: 28 Aug 92 22:46:26 GMT
Organization: University of Oregon Computer and Information Sciences Dept.

Does anyone know where I can get a port of RCS for DOS?
Please e-mail replies, thanks.



-- 

_______  __________________________________________________________
   _   /|
   \'o.O'    Rick Overman
Newsgroups: comp.os.msdos.programmer
From: raistlin@wixer.cactus.org (Eli Boaz)
Subject: Re: Environment variables when using system(...) command
Organization: Real/Time Communications
Date: Wed, 2 Sep 92 20:52:55 GMT

In article <1992Sep1.194508.10559@sactoh0.sac.ca.us> sap@sactoh0.sac.ca.us (Stephan A. Puga) writes:
>If an environment variable is set before a program is run and the
>program makes use of the system(...) command, how can I use the
>environment variable in the system command?  I am writing a program
>to be used on a network and there is a variable "username" set
>before the program is run (this variable by the way is very
>important to how WordPerfect 5.1 runs on the network), my program
>invokes WP51 and tries to pass it the username variable, but it
>doesn't work!  Is there no way I can get the new "local" command
>shell to use the same "old" command shell's variables?

Well, first off, you need to get the environment variable into a program
variable. (I do not know how to do this in C, but getenv() looks like
it would be the correct choice under Turbo C/Borland C)

Then, concatonate the program variable (say "john") so that your
system command will look like: system(syscmd);
where syscmd="d:\wp51dir\wp.exe john ..." or something similar...

I have done something similar to this a while back while writing
a login program and it's utilities for my pc in Turbo Pascal.

hope this helps,


-- 
Eli Boaz                      | Line noise provide by S.W. Bell Telephone!
raistlin@wixer.cactus.org     | "Anyone not wearing 2 million sunblock is
...!cactus.org!wixer!raistlin |  going to have a REAL BAD DAY, get it?" -T2
----------------------------------------------------------------------------
Newsgroups: comp.os.msdos.programmer
Subject: Differences in versions of COMMAND.COM (Was Re: 4DOS diversion (Was..
From: phys169@csc.canterbury.ac.nz
Date: 31 Aug 92 14:42:10 +1200
 <1992Aug19.132543.7617@swlvx2.msd.ray.com> <4082@cruzio.santa-cruz.ca.us> <1992Aug22.181032.11678@ctr.columbia.edu>
Organization: University of Canterbury, Christchurch, New Zealand

I've noticed a few (very few) differences between MS-DOS and 4DOS/DRDOS command
interpreters too.  One affects the way you can check for a directory existing
by testing if the file dirname\.. exists, but I don't think the difference Timo
Salmi mentioned comes from the different COMMAND.COM - rather what the
operating system considers to the the reason for error; IORESULT from a RESET
in Turbo Pascal shouldn't have anything to do with what command interpreter is 
running... at least as far as I can see from /pc/pd2/post10.zip.

But the differences between them isn't great (not when you look at differences
from one version of MSDOS to the next), and (as somebody said) if it breaks a
program then the program was probably going to break anyway some day.

That sounds a bit harsh towards the programs, and biased in favour of
replacements for command.com.  Well, I expect MSDOS will change a lot in the
future, as well as a lot of new look-alikes, which is a good thing. I'd like to
see a list of the "undocumented" tricks that people reasonably expect of DOS
and command interpreters, which programmers stick to AND writers of new DOSes
and command shells take notice of. So I wouldn't like DOS to be limited by lots
of old programs expecting unreasonable compatibility, nor would I like to see
programs have to restrict themselves to just the documented DOS calls.

By the way, In article <1992Aug22.181032.11678@ctr.columbia.edu>, kibirev@csa.bu.edu (oleg kibirev) 
wrote:
> ... Hmmm, on my computer it took about the same time for DRDOS to display
> A:\> prompt. Or to traverse the search path. At least without SUPERPCK
> DRDOS 6.0 disk performance is _horrible_ compared to MSDOS 5.0.

This a well-known bug/limitation/whatever that has been discussed before. Some
DR bloke, I think, said something about DRDOS 6 (not 5?) taking care not to
directly transfer multiple disk sectors into high or upper memory.  I can't
remember the details, but the result is that one sector is read per revolution
of the disk! The answer is to use SuperPCK with the /T option, and I think that
it is only a problem with some configurations, and that using DRIVER=... also
fixes it.


Mark Aitchison, University of Canterbury, New Zealand.
Newsgroups: comp.os.msdos.programmer
Subject: Re: Reading ALT keys with bioskey in TC++?
From: dueck@brandonu.ca
Date: 31 Aug 92 15:15:37 CST
Organization: Brandon University, Brandon, Manitoba, Canada

In article <1992Aug25.184207.7825@lclark.edu>, harrison@sun.lclark.edu (Mark Harrison) writes:
> 
> Hi.  I am reading ALT+<key> from the keyboard with bioskey (in TC++ 3.0.)
> But that gives me values that map to the physical layout of the keyboard. 
> Is there an easy way to translate this value into one that will tell me
> the Ascii code of the key?  For instance, how do I transform 0x3100
> (ALT+N) to get the ascii code of N?  Will I need to write a function that
> will do this for all the ALT values I want to check for?  If so, then no
> problem.  I just don't want to reinvent any wheels.
> 
The easiest way is to look at the keyboard status flags right after obtaining
a character from the keyboard. You can obtain them via interrupt 16, function 2.
This call returns the contents of 40:17 in AL. Bit 3 (mask 0x80) is set if an
ALT key is depressed. So:

   if (kbhit()) {
      ch = getch();
      _AH = 2;
      __emit__(0xcd, 0x16);
      if (_AL & 0x08)
         ALT was down
      }

Gery Dueck
dueck@brandonu.ca
From: ralf+@cs.cmu.edu (Ralf Brown)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Results of the smallest TSR contest
Date: 3 Sep 92 02:53:27 GMT
Article-I.D.: cs.BtzEp4.5n3.2
Organization: School of Computer Science, Carnegie Mellon

In article <1992Sep2.213536.28873@zooid.guild.org> Ross Ridge <ross@zooid.guild.org> writes:
}Ralf.Brown@B.GP.CS.CMU.EDU writes:
}>}In the category : HLL with Assembly
}>}  Ross Ridge
}>}  64 bytes for a TSR counter
}>
}>I didn't see this one.  That must be in a UMB, as DOS won't let a program go
}>TSR with less than 96 bytes.
}
}Actually, strictly speaking its not a TSR as it doesn't use the MS-DOS
}Terminate and Stay Resident service.  What it does is copy a simple ISR
}to the end of conventional memory, or to a UMB if available.  

True enough, but it does manage to terminate and stay resident even if it
doesn't use the DOS service.

BTW, AMISLIB will also allow a TSR to load at the top end of conventional
memory or in a UMB as well as at the low end with a partial PSP.  Though
the TSRs you build with it are somewhat larger than the absolute minimum,
you get the advantages of a standardized interface and the ability to
unload in any order.
-- 
Internet: RALF+@CS.CMU.EDU   |The University would disclaim this if it knew...
FIDO: Ralf Brown 1:129/26.1  |
BIT: RALF%CS.CMU.EDU@CARNEGIE|"Success has a simple formula: do your best,
AT&Tnet: (412)268-3053 school| and people may like it."   -- Sam Ewing
From: Jon Freivald <jaf@jaflrn.UUCP>
Newsgroups: comp.os.msdos.programmer
Subject: Re: How to change file attributes using Turbo C ??
Date: Thu, 27 Aug 92 00:50:50 EDT
Organization: The Wizzard's Cave, East Meadow, NY

rccarm00@mik.uky.edu (ron c carman) writes:

>    I want to be able to change/set the attributes (Hidden, system, etc)
> of the files which are used/created by my programs (written in Borland's
> Turbo C).  How do I go about this?

Look in your library reference under chmod().

=============================================================================
		   Jon Freivald ( jaflrn!jaf@uunet.UU.NET )
	 Nothing is impossible for the man who doesn't have to do it.
=============================================================================
Newsgroups: comp.os.msdos.programmer
From: frotz@dri.com (Frotz)
Subject: Re: using DR DOS 6 Script utility
Reply-To: frotz@novell.com
Organization: Desktop Systems Group/Novell, Monterey CA/USA
Date: Wed, 2 Sep 92 20:55:19 GMT

Marco Simionato <simion@iveuncc.unive.it> writes:

]I have DR DOS 6 on my 386sx machine, which is connected to a PostScript
]Apple Personal LaserWriter NTR. The Script utility allows me to print
]text files from the Dos command line. This utility can be installed as
]TSR, so that it will intercept and elaborate all jobs directed to the
]printer. Despite this, I cannot have files printed from basic Dos apps,
]such as MS Edit or DR DOSBOOK. The fact is that, to be installed as a
]TSR, Script requires two parameters: an input peripheral and an output
]peripheral. The two parameters cannot be the same. Now, my printer is
]connected to LPT1. If we assume that, for example, MS Edit prints by
]default to LPT1, I would have to tell Script to take all jobs directed to
]LPT1, elaborate them and send them to, say, LPT2 - which I just don't
]have.

I see the confusion.  I use it all the time and don't pay attention to
the manual or the usage;-}

The correct usage on a single port machine for script is:

	SCRIPT LPT1

This takes all data sent to LPT1, converts it to postscript and then
outputs it to the actual port.  I believe that the interception point
is INT17.  Anyone writing to the port below this will probably bypass
SCRIPT, but you'd have to check the trapped interrupts to verify that.
--
John "Frotz" Fa'atuai	frotz@novell.com		(email@domain)
Desktop Systems		uunet!novell.com!frotz		(bang address)
  Group/Novell		NOVELL:FROTZ  or  FROTZ@NOVELL	(MHS address)
c/o TS Dept.		408/645-2067			(vmail)
80 Garden Court		408/649-8209			(fax)
Monterey, CA  93940

Newsgroups: comp.os.msdos.programmer
From: yogi@cs.ubc.ca (Yossi Gil)
Subject: Re: Another MsDos batch programming challenge
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Fri, 4 Sep 92 03:28:36 GMT

ts@uwasa.fi (Timo Salmi) writes:

>In article <israel.715477510@unixg.ubc.ca> israel@unixg.ubc.ca (Robert B. Israel) writes:
>>BTW, Yossi's solution should work if you run it as "FOO.BAT" rather than as
>>"FOO".  

As I have said, it is fairly easy to make it work even if invoked as
FOO as opposed to FOO.BAT. It is perhaps slightly more difficult to make it
work if invoked as FOO.EXE, as (I think) was possible in some early
dos versions.

>Allow me a quick check question.  Have you actually tested this on
>your PC.  Gotcha or vice versa? :-) :-)

Yes, I tested it. It works. It relies on the way DOS does batch file:
	
	1. Open file.
	2. Seek in file to current statement. 
	3. Interpret statement. 
	4. Close file.
	5. Execute statement
	6. Goto 1 if not done.

This is why Batch Programming is so inefficient.

--
Joseph (Yossi) Gil                 {alberta,uw-beaver,uunet}!ubc-cs!yogi
Dept. of Computer Science          yogi@cs.ubc.ca (cs.ubc.ca=137.82.8.5)
6356 Agricultural Road., Univ. of B.C.,             Tel: +1-604-822-8175
Vancouver, British Columbia, V6T 1Z2, Canada.       Fax: +1-604-822-5485
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.misc
From: pat@jts.com (Patrick Perroud )
Subject: Disk Drive Purchase?
Organization: JTS Computer Systems Ltd.
Distribution: na
Date: Wed, 26 Aug 1992 18:36:36 GMT

I will be purchasing a disk drive in the near future and was wondering if
anybody had any thoughts on the type, speed etc. (ESDI vs. SCSI).
I was looking in the 200MB range. My present system config is 386SX-16,
40MB ESDI drive. I may in the near future be upgrading to a faster system,
eg. 20-33MHZ or better and would like to use the disks, so this may be a
factor in selecting the disk ie. speed etc. Also cost may be a factor.

Any suggestions would be greatly appreciated.

Thanks,



Pat P.

        ____ ___   |Patrick C. Perroud             	Software Engineer
      /  /  /   `  |JTS Computer Systems LTD           
     /  /   `--.   |4211 Yonge St., Suite 620, Willowdale, Ontario M2N 2A9
 |__/  /   ,___/   |E-mail: pat@jts.com  Ph:(416)512-8910  Fax:(416)512-6519

-- 



Pat P.
Newsgroups: comp.os.msdos.programmer
From: sherman@panix.com (Sherman Chan)
Subject: Power C - Opinions sought
Date: Tue, 1 Sep 1992 02:52:29 GMT
Organization: PANIX Public Access Unix, NYC

I'd like to ask the opinions of the net on the Power C compiler.  I am
looking for a cheap C compiler right now, and at $20 it seems like the
thing.  But, is it any good?  I mean, would I be better off just being
majorly super cheap and just looking for a PD compiler and using the $20
to buy blank disks?  I would be using the compiler in a very limited
environment, an Amiga running MSDOS 5.0 through a software emulator,
which provides the following environment:

8088 compat
2 720K drives
MDA display adaptor

-Sherm

Email responses will be edited and reposted if I get enough information.
From: cej@dstos3.dsto.gov.au
Newsgroups: comp.os.msdos.programmer
Subject: BC3 Nested switches in interrupt fns problem
Date: 2 Sep 92 20:21:52 GMT
Organization: Defence Science and Technology Organisation

Has anyone had any trouble with nested switch statements inside interrupt fns
in BC++3.0 ? I had one such situation in a serial interrupt which needed to
buffer incoming multibyte commands. The inner switch was executing the default:
when it shouldn't have, plus what it was supposed to execute! Yes, I _did_
have breaks in the right places! My solution was a number of if() statements
instead of the switch. Can't tell you any more, as it is hard to debug
interrupt fns !

--
Chris Jones                                  E-mail: cej@dstos3.dsto.gov.au
CSS/CD/ERL                                    Phone: +61 8 259 6758
DSTO Salisbury, South Australia                 Fax: +61 8 259 6328

Disclaimer: The opinions expressed are purely personal and do NOT represent
            the official view of DSTO.

"I'm going to put the shame file in the sludge file!  Or is that the sludge
 file in the shame file? Shame, sludge, sludge, shame, ..."
    Derrin Hunch, Fast Forward
Newsgroups: comp.os.msdos.programmer,comp.os.ms-windows.programmer.tools
From: btbg1194@uxa.cso.uiuc.edu (Bradley T Banko)
Subject: 48 line editing under VGA?
Organization: University of Illinois at Urbana
Date: Fri, 4 Sep 1992 19:07:10 GMT

I think that DOS 5 Quick Basic has a command line option to bring up
a "maximum lines/screen" edit mode in Quick Basic.  Are there ways of
doing this with other common editors, such as MicroEmacs or with Windows
text editors?

Thanks.

Brad Banko


-- 
Brad Banko;  Dept of Physics;  U of Illinois;  b-banko@uiuc.edu, KB8CNE
=========================================================================
	Tatiana Gutsu for President!
Xref: sparky comp.os.msdos.programmer:8733 comp.lang.c:12687
From: HUESTIS@MPLVAX.SRI.COM (David L. Huestis)
Newsgroups: comp.os.msdos.programmer,comp.lang.c
Subject: MSC 6.0 has trouble with 32-bit switch/case
Date: 24 Aug 92 00:38:37 GMT
Followup-To: comp.os.msdos.programmer
Organization: Molecular Physics Laboratory, SRI International, Menlo Park, CA

/* When Microsoft C 6.0 compiles the following simple program 
   the compiler gets confused in constructing the comparisons
   for the 32-bit switch/case statements.  It appears to use
   the fact that B1, B2, and B3 all have the same value in the
   high 16-bits, leading potentially to shorter faster code,
   but it loses track of the logic/branching thread by subtracting
   values from 'dx' rather than comparing.  Compile with /Fc
   Replacing the switch/case with if() statements leads to correct
   execution.
   
   The program gives the following results:
   
      for A1 expected 0 got 0
      for A2 expected 1 got 1
      for A3 expected 2 got 2
      for B1 expected 2 got 2
      for B2 expected 1 got 3
      for B3 expected 0 got 3

   ------------------------
      
   David L. Huestis
   SRI International
   <huestis@mplvax.sri.com>

   --------------------------------------------------------------------
*/

#include <stdio.h>

#define A1 0x0A0001UL
#define A2 0x0A0002UL
#define A3 0x0A0003UL
#define B1 0x0B0001UL
#define B2 0x0B0002UL
#define B3 0x0B0003UL

int tsw(unsigned long sw)
{
      switch(sw)
        {
          case A1 : case B3 :
            return( 0 ) ;
            break ;
          case A2 : case B2 :
            return( 1 ) ;
            break ;
          case A3 : case B1 :
            return( 2 ) ;
            break ;
            
          default :
            break ;
        }
      return(3) ;
}

main()
{
      printf("for A1 expected 0 got %d\n", tsw(A1) ) ;
      printf("for A2 expected 1 got %d\n", tsw(A2) ) ;
      printf("for A3 expected 2 got %d\n", tsw(A3) ) ;
      printf("for B1 expected 2 got %d\n", tsw(B1) ) ;
      printf("for B2 expected 1 got %d\n", tsw(B2) ) ;
      printf("for B3 expected 0 got %d\n", tsw(B3) ) ;
}
Newsgroups: comp.os.msdos.programmer
From: yawei@bronze.ucs.indiana.edu (~{QG9p~})
Subject: PRINT.EXE a binary file?
Organization: Indiana University
Date: Thu, 3 Sep 1992 03:10:21 GMT


I have the need to dump megabytes of bitmap image to some slow
dot matrix printers. I thought this might a neat idea: first
dump the image to a disk file, then pass the file name to
PRINT.EXE via the DOS multiplex interrupt calls so that it can
be printed in the background. Everything worked perfectly 
until some bytes with values 0x0D or 0x1B sneaked into the files.

It turned out that PRINT.EXE was only equiped to handle non-binary
files! (This was confirmed after checking the manuals.) An 
otherwise useful program is thus seriously handicapped.

I wonder whether anyone has discovered anything undocumented that
might allow me to get PRINT.EXE to do what I wanted? 

On a similar note, can anyone recommend any PD print spooler
that can handle that much data? PD utility is probably the next
best thing in terms of user's ease of access.

  Ya-Gui Wei

Xref: sparky comp.os.msdos.programmer:8936 comp.os.msdos.misc:4981
Organization: Middle East Technical University - Computer Center
Date: Tuesday, 1 Sep 1992 12:20:42 TUR
From: Pinar Aydemir <A10742@TRMETU.BITNET>
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.misc
Subject: Why ms-dos is non reentrant

I almost hear everyday that msdos is non-reentrant.
It is non re-entrant so dont call a dos funcion from a Interrupt Service
Routine.
Since It is non reentrant, bla bla bla.

I looked at some books about OS, and the definition of reentrancy is
given as being unmodified (pure) code.So, what makes msdos non reentrant ?
Any information  is appreciated.
-Yasemin
Newsgroups: comp.os.msdos.programmer
From: yogi@cs.ubc.ca (Yossi Gil)
Subject: Re: Another MsDos batch programming challenge
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Fri, 4 Sep 92 08:49:39 GMT

ts@uwasa.fi (Timo Salmi) writes:

>In article <1992Sep4.032836.7299@cs.ubc.ca> yogi@cs.ubc.ca (Yossi Gil) writes:
>>Yes, I tested it. It works. It relies on the way DOS does batch file:

>When I put as you suggested
> cd >> %0
> echo echo %%set%% >> %0
> set set=^Z
>into foo.bat and then type foo.bat and then check with set,
>nothing.  What obvious am I missing?

The ^Z is an "End of File". The first statement modifies the third to
be 
	set set=CURRENT DIRECTORY  
and the second statement creates a fourth statement which would echo
the environment variable "set".

--
Joseph (Yossi) Gil                 {alberta,uw-beaver,uunet}!ubc-cs!yogi
Dept. of Computer Science          yogi@cs.ubc.ca (cs.ubc.ca=137.82.8.5)
6356 Agricultural Road., Univ. of B.C.,             Tel: +1-604-822-8175
Vancouver, British Columbia, V6T 1Z2, Canada.       Fax: +1-604-822-5485