HDTenEightyP/NetNews huggingface dataset:
From: falk@peregrine.Sun.COM (Ed Falk)
Newsgroups: comp.os.msdos.programmer
Subject: Re: advanced beginner needs book recomendations
Date: 28 Jul 1992 06:55:27 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: peregrine

In article <l6uh17INNoto@exodus.Eng.Sun.COM> falk@peregrine.Sun.COM (Ed Falk) writes:
>
>However, the guy at the store talked me into a huge monster
>of a book called "PC Intern", which he swears contains *everything*.
>He seems to be right, there are chapters on every kind of hardware
>you can imagine...

I have been asked for more info, so I thought I'd post it.  The book
is "PC Intern", by Michael Tischer, published by Abacus.  ISBN
1-55755-145-6.  It looks good so far, but I'm only about 1/6 of
the way through it.

		-ed falk, sun microsystems
		 sun!falk, falk@sun.com
	terrorist, cryptography, DES, drugs, cipher, secret, decode,
	DSS, FBI, NSA, CIA, NRO, SDI, communist, proletariat.
Newsgroups: comp.os.msdos.programmer
From: wiegand@rtsg.mot.com (Robert Wiegand)
Subject: Re: Help reading a DOS file
Reply-To: motcid!wiegand@uunet.uu.net
Organization: Motorola Inc., Cellular Infrastructure Group
Distribution: comp.os.msdos.programmer
Date: Wed, 22 Jul 1992 18:54:37 GMT

dao@d62iggy.mitre.org (David A. Ondzes) writes:


>I need some help. One of my games writes it data to a file, and I would
>like to read this file. When I type the file to the screen it shows up
>as a bunch of happy faces etc ... so I am assuming it is a binary file.
>Is this correct assumption ? I can make out some text in the file. I have
>looked at the file with various hex edit programs to find out where the data
>I want is.
> 
>	How do I read in the data ? I tried using fscanf(fd,"%x",&int). I would
>like to be able to read in 2 hex digits at a time, because this is how I
>saw the file with the hex editors mentioned above.

>	Any help involing reading files that are not ascii text would also
>be appreciated.


>Please send replys to 
>picasso@bass.bu.edu


>Thank you
>David Ondzes

First, make sure you open the file with a file type of "binary" not "text".
Second, try using "fgetc" to read the file a byte at a time.


-- 
------------------------------------------------------------------------------
Robert Wiegand - Motorola Inc.
uunet!motcid!wiegand
Disclamer: I didn't do it - I was somewhere else at the time.
Newsgroups: comp.os.msdos.programmer
From: mats@infolog.se (Mats Lordin)
Subject: Interpreter
Organization: Infologics AB
Date: Wed, 29 Jul 1992 06:27:53 GMT

I would appreciate ideas from anyone that has know-how on how to 
implemented an interpreter. Any good books you could recommend? 
Are there any examples or source code that I might get my hands on?
I will most propably do the work in C.

As I mentioned, any ideas, tips or tricks are greatly appreciated!

Thanks.

Mats Lordin
Infologics AB
P.O. Box 91
S-191 22 Sollentuna, SWEDEN

E-mail:mats@infolog.se

Xref: sparky comp.os.msdos.programmer:8207 bit.listserv.dbase-l:777
Newsgroups: comp.os.msdos.programmer,bit.listserv.dbase-l
Subject: dBase IV multiple index files?
From: Alexandre Pechtchanski <APPMS@CUNYVM.BITNET>
Date: Friday, 31 Jul 1992 16:34:49 EDT
Organization: City University of New York/ University Computer Center

=========================================================================
Hi, everybody:
I've heard a statement that seems pretty doubtful to me:
"... With .MDX files, all indexes are updated automatically, with
only one DOS File Handle, instead of one DOS File Handle for each index.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This frees up RAM and ... to make program more efficient (read faster)."
^^^^^^^^^^^^^^^^^                              ^^^^^^^^^^^^^^^^^^^^^^
I was always pretty sure that no matter what you do you have to allocate
one DOS file handle (either explicitly or implicitly) for each file you
access.  For dBase it spells one handle for each .DBF + one for each
.NDX etc.  The only way (IMHO) to circumvent it is to use one handle
for different files at different time, but it sure will lead to
_in_efficiency of program!
Can anybody confirm/disprove the above statement? (I mean the quoted
one, also all are welcome to spill flames on me for my apparent
stupidity ;-) )

    Thanks in advance
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alex Pechtchanski, GCRC System Manager   voice: (212) 241-1804
Mount Sinai Medical Center, New York  -------------------------
INTERNET: DESNICK@MSVAX.MSSM.EDU      #include <std.disclaimer>
BITNET:   APPMS@CUNYVM                
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.os.msdos.programmer
From: hlj@hal.nta.no (Harald Ljoen FBA)
Subject: Re: 8237A DMA Chip on the PC
Keywords: 8237A DMA Chip on the PC
Reply-To: hlj@hal.nta.no
Organization: Norwegian Telecom Research
Date: Wed, 22 Jul 92 09:35:02 GMT

In article <1992Jul22.015106.230532@cs.cmu.edu>, ralf+@cs.cmu.edu (Ralf Brown) writes:
>In article <tfiske.711742881@qualcom> tfiske@qualcom.qualcomm.com (T.J. Fiske) writes:
>}The 8237A DMA chip on the PC:
>}on the AT and higher models, there are 8 dma channels.
>}I need to program channel 5, since I need to do 16 bit
>}dma transfers.  Anyways, to progam the target address
>}correctly, it needs a "page" address at port 0x8b.
>}What is this page address, and how can I do an address
>
>The high eight bits of the 24-bit linear address, which you compute as
>	((long)segment)<<4 + offset
>
>(of course, this computation applies only in real mode)

For 16 bit channels, the page registers contain bits 17 - 23 (the upper *7*
bits of the 24-bit linear address). The 8237 address registers are programmed
with address bits 1-16, while bit 0 is forced to 0 since 16-bit DMA
transfers are always to even addresses. This scheme also has the implication
that the page size is 128 kbytes, as opposed to 64 kbytes for 8-bit transfers.

-- 
***** hlj@hal.nta.no (Harald Ljo"en) expressing his private opinions ******
Newsgroups: comp.os.msdos.programmer
From: kibirev@csa.bu.edu (oleg kibirev)
Subject: Re: moved my ibmdos.com ....
Organization: Computer Science Department, Boston University, Boston, MA, USA
Date: Tue, 21 Jul 1992 16:15:37 GMT
X-Posted-From: csa.bu.edu
X-Posted-Through: sol.ctr.columbia.edu

In article <1992Jul19.162010.8233@qiclab.scn.rain.com> 70465.203@compuserve.com writes:
>
>As many users of 4dos (and other shels that take the place of
>COMMAND.COM could tell you, DOS 5.0's SYS takes *whatever* program
>is pointed to by the COMSPEC environment variable and copies it to
>the disk under the *name* COMMAND.COM! 
>
>Arguably, the copying could be considered the "correct" behavior, 
>and in that case, to boot without a CONFIG.SYS the renaming is
>necessary. But as some of these shells require overlay files and
>the like, this is *not* a good idea.
>
>I'd suggest that in the next version or revision, SYS should check
>and if the command processor *isn't* COMMAND.COM, it should prompt
>the user and ask if he wants <filename> copied to the disk. If not,
>then have it ask him for the path to COMMAND.COM and copy that.
>
>Trust me, this *has* resulted in very puzzled users with non-bootable
>disks!
>
I'd suggest that in the next revision of these shells requiring overlays,
they prompt user for the pass of overlay files instead of crashing. Or
better put all overlays in one file, as plain Microsoft LINK does.

						Oleg Kibirev
Newsgroups: comp.os.msdos.programmer
From: pynq@quads.uchicago.edu (George Jetson)
Subject: Re: Is this a "make" limitation?
Reply-To: pynq@midway.uchicago.edu
Organization: D. J. Dougherty & Associates
Date: Tue, 21 Jul 1992 17:07:02 GMT

In article <1992Jul21.162641.5897@tamsun.tamu.edu> tpradeep@cs.tamu.edu (Pradeep K Tapadiya) writes:

>I am wondering if I can increase my developement time and reduce the
>wear and tear on the disk by using a better makefile construct.

(Don't you want to decrease your developement time [or do they pay you
by the hour...?])

>   cl -c a.c
>   cl -c b.c
>   cl -c c.c
>
>   and so on for all those source files which are out of date.
>Obviously, for each such source file there is an overhead of
>loading and releasing the compiler. A better construct would be
>  cl -c a.c b.c c.c ...

Borland's MAKE allows "batching" of files.  That is, you can write:

	bcc -c {x.c }
	bcc -c {y.c }
	etc

and it will collect them intelligently, if possible.

The other thing, that does make a massive difference, is to put the
compiler on a RAM disk.

(When compiling DVGLUE, this is an absolute essential!  Though, one of
these days, I'm going to re-write the DVGLUE makefile to use batching.)

************************************************************************
Please don't drink the battery acid, it tastes bad and will hurt you.
Also, don't bite the tyres, especially when the bike is moving.
(Our lawyers made us put this in this manual.)

	- pynq@quads.uchicago.edu, who is still costing the net
	  hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
Newsgroups: comp.os.msdos.programmer
From: sh0002@porsche (Scott Hou)
Subject: Needed: Run Time Lib for Graphics
Organization: Medtronic, Inc.
X-Newsreader: Tin 1.1 PL4
Date: Wed, 22 Jul 1992 20:23:59 GMT

Hello, all.  I'm posting this for someone else.  Does anyone know of or has used
run time library routines for outputing graphics to the display.  It must work
with Microsoft C, do various types of charts at a high level (don't want to do
any low level graphics), support autoscaling, able to print/plot to different
printers and plotters (dot-maxtrix and laser), runs in DOS and/or Windows
environment, and not require individual run-time license to run.

Please email me directly. Thanks in advance.

--
Scott Hou                          phone: 612-574-8660
Consulting at Medtronic, Inc.      email: scott.hou@pace.medtronic.com
Newsgroups: comp.os.msdos.programmer
From: danc@loon.geog.ubc.ca (Dan Ciarniello)
Subject: Borland C++ 3.0 scanf()/gets() bug.
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Thu, 23 Jul 1992 18:18:20 GMT

I've come across what I believe is a bug in Borland C++.  The following 
program fragment does not work as one would expect.

        scanf("%s", var1);
	gets(var2);

The scanf() statement executes correctly but gets() assigns a null string to 
var2 without waiting for input from the keyboard and execution continues with
the next statment.  If the scanf() is removed, gets() works as advertised.
A work around that I have found is to simply include a dummy call to gets():

	scanf("%s", var1);
	gets(var2);
	gets(var2);

The second call to gets() works correctly.

If a subsequent call to scanf() is made, another dummy call to gets() is
required for gets() to work again.

Has anyone ever come across this before (please e-mail)?

Dan.
Newsgroups: comp.os.msdos.programmer
Subject: How easy is file I/O from device drivers in CONFIG.SYS at boot time ?
From: L.Chisholm@massey.ac.nz (Len Chisholm)
Date: Wed, 22 Jul 92 08:22:08 GMT
Organization: Massey University, Palmerston North, New Zealand
Keywords: CONFIG.SYS device drivers file I/O
Summary: I want to do file I/O at boot time from a device driver in CONFIG.SYS
X-Reader: NETNEWS/PC Version 2c

Hi there,

I am interested in doing file operations from a CONFIG.SYS loaded device
driver at BOOT time to load configuration information.

It is obviously possible as QEMM'S LOADHI.SYS must read other device
drivers and the OPTIMISE command causes LOADHI to write statistics to a file.

What contortions are required to do this safely , and what limitations are
involved ( if any ) ?

Thanks in advance,

-- 
-------------------------------------------------------------------------
|  LEN CHISHOLM , Systems programmer  | EMail: L.Chisholm@massey.ac.nz  |
| Department of Production Technology | Phone: +64 6 3505262            |
|         Massey University           | FAX:   +64 6 3505604            |
|   Palmerston North, New Zealand     |                                 |
-------------------------------------------------------------------------
Newsgroups: comp.os.msdos.programmer
From: yev_g@athena.mit.edu (Yevgeny Gurevich)
Subject: Re: BC++ syntax highlighting????
Organization: Massachusetts Institute of Technology
Date: Fri, 24 Jul 1992 20:46:51 GMT

In article <1992Jul24.170313.15643@ugle.unit.no> robert@solan.unit.no (Robert Schmidt) writes:
>
>Several people tell me that BC++ 3.0 highlights comments, reserved words
>etc by using different colors.
>

Only the Borland 3.1 products (Borland C++, Turbo C++, Turbo
C++/Windows) support color syntax highlighting.

>(I know some Microsoft articles sport such highlighting...)

As far as I know, versions 6.0 and 7.0 of Microsoft C do NOT have this
highlighting.



-- 
[ Yevgeny Gurevich ]
Xref: sparky comp.os.msdos.programmer:8069 alt.msdos.programmer:2067
From: dowling@ncifcrf.gov (Paul Dowling)
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer
Subject: Code to format floppy disks
Date: 24 Jul 92 18:55:26 GMT
Followup-To: poster
Organization: NCI Supercomputer Center, Frederick, MD


	I'm looking for code to format a floppy drive.  I've been trying
some code with int 13, but it hasn't been working.  Even if I format only
part of the disk after the DOS format it still doesn't work.  Once I
reformat with DOS the disk is fine.  The DOS error I get is sector not
found.  If you have any code or ideas send them along.

__________________________________________________________________________
> Paul Dowling - Systems Manager  <|>                                    <
> dowling@ncifcrf.gov             <|>  "Nothing is either good or bad,   <
> "Do you have a Cray Y-MP 8 on   <|>   but thinking of it makes it so." <
>  YOUR desk?"                    <|>      - Shakespeare                 <
>__________________________________V_____________________________________<

Newsgroups: comp.os.msdos.programmer
From: dmurdoch@QueensU.CA (Duncan Murdoch)
Subject: Re: changes to exe (binary) file
Organization: Queen's University, Kingston, Canada
Date: Thu, 30 Jul 1992 16:35:13 GMT

In article <1992Jul30.152020.8261@menudo.uh.edu> cosc16to@menudo.uh.edu (Andy Hakim) writes:
>In article <1992Jul29.125540.7401@hou.amoco.com> jim@n5ial.chi.il.us writes:
>>
>>I've seen lots of programs (usually shareware types) that allow you to
>>make configuration changes, insert registration info, etc., directly into
>>the compiled exe file.  

>To figure out the offset:  (DEFAULT_OFFSET in example)  compile the
>program, then use a program such as LIST to scan for a sequence of
>matching bytes ( 100 118 138 )  The HEX DUMP mode of LIST is handy.
>Next, go back to your source file, and update the correct offset.
>An alternative way to figure out the offset is to use info from .map files.

Those are both quite dangerous.  Plenty of people use PKLITE or LZEXE or
another .EXE compressor to modify .EXE files; if you blindly go reading
and writing at a specific location, you'll mess up badly.  A better
solution is to append the data to the .EXE file; the unbuggy compressors will
think it's an overlay, and leave it alone, or refuse to work.  You
should also be sure to put a signature in the record, so you can double
check that whatever calculation you end up with is correct.

If you want to be really nice to your users, you'll give them the option
of reading the config info from a config file, too.  That way it's easy
to maintain multiple different configurations.

A nice way to do this (both ways) is using a Turbo Vision resource file,
if you're using Borland's Pascal or C++.  It's very easy to use a config
file if present or your .EXE if not, and all the signature checking is
built in.

Duncan Murdoch
dmurdoch@mast.queensu.ca
Newsgroups: comp.os.msdos.programmer,alt.msdos.programmer,comp.os.msdos.apps,comp.editors
From: yogi@cs.ubc.ca (Yossi Gil)
Subject: SLIM editor filter problems related to Novell? 
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Wed, 29 Jul 92 16:37:46 GMT

[  SLIM is the big brother of TERSE, the 4K editor, announced
recently.  Both are available for anonymous ftp download from
cs.ubc.ca:/pub/pikcup/trs140f.zip and cs.ubc.ca:/pub/pickup/update.zip
(for some minor config updates, and more error messages related to the
<Alt-f> command)  ]

One of SLIM users reported a problem with the filter command.
I haven't been able to reproduce the problem, and I haven't heard any
other similar complaints. I wonder if any one out there had experienced
similar difficulties, and if any hints could be provided to help me hunt
down this bug.

The filter command runs an external filter (UNIX like program which reads
its stdin, process it, and produces stdout), feeding input to it from
the editor buffers, and caputering its output to another editor buffer.
The net effect is that the currently marked block is replaced with the
output of the filter when applied to that block. This magic is implemented
by simply trapping the READ and WRITE calls to DOS.

The main symptom is that the input is not fed into the filter. Instead,
it appears that the filter, at least sometimes, (LIST /s is an example)
is expecting input from the keyboard. At other occassions, output is not
produced at all. The bug is not completely determinstic, but a completely
flawless execution was never observed by this user.

Simple instructions to try this are: invoke slim on a file, mark 2-3
lines, press [Alt-F], type wc, hit [Enter], and watch for the content
of the marked block replaced with the the line, word and chars counts
of the marked block.  [Hitting Keypad-*] should undo this operation.
[Keypad-*] again will redo it.  You may try other filters as well "LIST
/s", "DIR", etc.

The only non-standard thing in this user system is Novell netware.

    1. Could it be that Novell is untrapping DOS calls? 

    2. How does it do it?

    3. How can one disable this ``feature''?

Any help would be greatly appreciated.

Yossi
--
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
From: gclapp@javelin.sim.es.com (Glenn Clapp)
Subject: Re: Polygon Question...
Organization: Evans & Sutherland Computer Corporation
Date: Tue, 21 Jul 1992 22:10:38 GMT

In article <1992Jul21.094844.1@camins.camosun.bc.ca> morley@camins.camosun.bc.ca writes:
>Hi!
>
>Ok, this should be an easy one...  Given 3 X,Y points that form a triangle,
>what is the simplest (fastest) way to determine if they are clock-wise or
>counter-clock-wise?  I'm not interested in general polygons of N points,
>just plain old triangles.  Yes, this is for use in a graphics app.
>
>Thanks...
>
>MARK
>morley@camins.camosun.bc.ca
>

Traverse the polygon, calculating 3 cross products (v1->v2 X v2->v3,
v2->v3 X v3->v1), and (v3->v1 X v1->v2), and if the cross products are
positive, the polygon is counterclockwise, otherwise they will be negetive.
Also, if you have a sign flip between the different cross products, then
the polygon is not convex.

-- 
| The real democratic American idea is not that everyone shall be on a     |
| level with every other, but that everyone shall have liberty, without    |
| hinderances, to be what God made him.             -- Henry Ward Bleecher |
|-------------              ----------- ----------              -----------|
Newsgroups: comp.os.msdos.programmer
From: burge@qdeck.com (Bill Burge)
Subject: Re: MSC v7.0 CodeView problems with DesqView
Organization: Quarterdeck Office Systems, Santa Monica CA
Date: Wed, 22 Jul 1992 17:30:11 GMT
Keywords: MSC 7.0,CodeView,DesqView

In article <1992Jul21.140444.7931@xraylith.wisc.edu> bodoh@xraylith.wisc.edu (Daniel J. Bodoh) writes:
>In article <franke.711642420@andrej> franke@andrej.informatik.rwth-aachen.de (Christian Franke) writes:
>>We wave problems with Microsoft C/C++ 7.0 CodeView 4.0 for DOS
>>under Desqview V2.42
>>

It might also be worth trying the /CV switch on DV.  THis enables some 
special video and keyboard handling for MS Codeview.

Bill	burge@qdeck.com


>We use DV with 386MAX (comes with MS-C 7.0) instead of QEMM
>>which works properly with all our applications.
>>The 386MAX is necessary because MS-C needs DPMI and QEMM doesn't provide it.
>
>Quarterdeck has just announced a driver which will allow QEMM do DPMI.
>It will be available free of charge from BBS's, etc.  I don't know what
>the name of it is yet...
>-- 
>Dan Bodoh                                        Center for X-ray Lithography
>Grad Student                                  University of Wisconsin-Madison
>    Vote Libertarian in November: get rid of the IRS and the speed limit!

Newsgroups: comp.os.msdos.programmer
From: carll@ms.uky.edu (Carl Lafferty)
Subject: qemm and direct memory
Keywords: qemm direct
Summary: How do I do direct memory moves with qemm installed???
Date: Wed, 22 Jul 1992 12:55:42 GMT
Organization: University Of Kentucky, Dept. of Math Sciences

I have a problem that I can not seem to find a reasonable solution for. 

I am writing several programs using turbo pascal 6.0 on my machine.  They 
involve using memory moves into variables that I have allocated memory for
using GETMEM and nearly everytime I use one of these I keep getting an illegal
instruction picked up by QEMM.  The programs work fine when I am not using
qemm and on my machine but when I take them to my machine at work where it
is used then they go crazy.

I would put more exact messages here but I can not remember them.  I will get
them if anyone thinks it will help.


Any ideas??? 

Carl Lafferty

Newsgroups: comp.os.msdos.programmer
From: walk@mrcnext.cso.uiuc.edu (Todd Walk)
Subject: Int 21h, function 42h (file pointer seek) internals wanted
Organization: University of Illinois at Urbana
Date: Wed, 22 Jul 1992 17:30:03 GMT

Could someone tell me EXACTLY what Int 21h, function 42h (file pointer seek)
does?  I need to know what calls it makes, what tables it updates, how to
get to those tables, and anything else.  Thanks!


					Todd Walk
					walk@mrcnext.cso.uiuc.edu

Xref: sparky comp.os.msdos.programmer:8053 comp.os.msdos.misc:4502
From: bob@bdofed.UUCP (n)
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.misc
Subject: Blanking the screen
Date: 24 Jul 92 16:25:39 GMT
Organization: Etobicoke Board of Education, Ontario


Has anyone ever written a screen saver for MS-DOS in C? What
do you look for to say the system has been idle? Is there a fast way
to save the current screen and then restore it?

	thanx
		bob	(uunet.ca!bdofed!bob)

Newsgroups: comp.os.msdos.programmer
From: af458@yfn.ysu.edu (Jon K. Salmon)
Subject: Re: screen saver routines
Organization: Youngstown State University/Youngstown Free-Net
Date: Sat, 25 Jul 1992 06:49:53 GMT


Sam Shim writes:
>   I'm planning on incorporating a screen saver into my program.
>From what I gather, I'll need to hook onto 2 interrupts, 0x1C and
>0x09.  My hook to interrupt 0x1C will increment a counter every
>time it is called and if the counter is greater than a certain
>amount of time, blank the screen.  My hook to interrupt 0x09 will
>unblank the screen and clear the counter if the screen is already
>blanked, otherwise it will just clear the counter.  Can someone
>tell me if this will work or have any suggestions/improvements?

Sounds like the right direction to me.  There is a PC Magazine
utility (DIMMER) which might provide some additional information
about the interrupt handlers if you need it, even though the
screen blanking routine itself is VGA specific.  The source is
assembly.  I can mail the source if you like.  Lemme know.

-- Jon