HDTenEightyP/NetNews huggingface dataset:
From: gay@selkirk.sfu.ca (Ian D. Gay)
Subject: Re: Mouse programming
Keywords: Mouse
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 5 Oct 1992 16:24:03 GMT

stuartw@ccu1.aukuni.ac.nz (Stuart Woolford) writes:


> A friend of mine has a small problem with the useage of Msoft mouse drivers...

>How do you write a routine in pascal ( or C...asm...etc ) which will be called
>by the standard callback function of the driver ( when a button is pressed, etc
>), and which can still address the programs global variables, the problem is
>that, when the routine is called, DS points at the MOUSE DRIVERS data segment,
>and I at least could not think of an easy way to address the programs global
>data, which will NOT be at a fixed address :-(


I have used the following as inline assembler with Turbo-C. It works. 
I couldn't think of a pure C way to do it.

    push ds
    mov  ds seg DGROUP

    ......

    pop ds

This works because T-C keeps its global variables in a group called 
DGROUP. Basically what you have to do is get ds loaded with a 
_constant_ of the correct value, since no registers have what you want 
when the call occurs. The above code generates such a constant (fixed 
up at link time, of course).


>Also, he said that there is a problem with the mouse in all 256 color VGA modes
>( under TP 6.0, using BGI's ), any comment ????

Are BGI's supposed to support the mouse? The usoft mouse driver 
doesn't really support anything but the standard IBM video modes, i.e. 
only 320x200 (yecch!) if you want 256 colours. You can do it yourself, 
the hard way, by only using the lowest level mouse calls, and 
drawing/erasing the pointer yourself, as required.


>any replies appreciated...

>------------------------------------------------------------------------------
>stuartw@ccu1.aukuni.ac.nz

>   >>>>In VI Where Available<<<<
>------------------------------------------------------------------------------
From: ceharris@csugrad.cs.vt.edu (Carl Harris)
Newsgroups: alt.msdos.programmer
Subject: Re: SUMMARY:  recommend reliable FORTRAN compiler for DOS
Date: 5 Oct 92 22:07:37 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA

I'd like to toss in my vote for Ryan-McFarland FORTRAN.



-- 
+---------------+---------------------------------------------------+
| Carl Harris   |program (tv).  To engage in an activity similar to |
| CS @ VA TECH  |banging one's head against a wall, but with fewer  |
|               |opportunities for reward.                          |
Newsgroups: alt.msdos.programmer
From: robert@solan.unit.no (Robert Schmidt)
Subject: Compression algorithms
Organization: Norwegian Institute of Technology
Date: Mon, 28 Sep 92 13:59:57 GMT

Hi!

As a part of my Data structures and Algorithms course, I came across
the Huffman algorithm for finding an optimal, variable-length coding tree,
for compressing data.

I implemented this using C++ classes (a heap and a binary tree), and although
it was fast, the compression ratio didn't impress me much, as you can
well imagine.

I was wondering if anyone have assembler, pascal, c or c++ sources for
compression.  I'll appreciate anything, even if it doesn't compress
very good, or is very slow.  I've used run-length encoding before, and have
glanced at LZ coding.

If I get enough nice replies, I'll collect them and send them to some binary
archives or ftp sites (if such collections doesn't exist already, of course).

And one more thing:  Please reply via e-mail!


-- 
Cheers from Robert Schmidt, aka Ztiff Zox, aka Buuud (IRC).  E-mail to 
robert@solan.unit.no, snail-mail to Stud.techn. Robert Schmidt, Stud.post 170,
Norwegian Institute of Technology, 7034 Trondheim, NORWAY          

Warlords: Now do you think my .sig is boring enough?
From: vincent@datmuc.UUCP (vincent)
Newsgroups: alt.msdos.programmer
Subject: Re:  TesSeRact
Date: 30 Sep 92 13:14:55 GMT
Followup-To: vincent@datmuc.dat.de, or vincent@datmuc.uucp
Organization: DAT

Anybody knows anything about TesSeRact?

I got an "arc" package and the readme file write that the source for
the demo can be compiled with TC or MSC C 5.0 (wow!), Well I tried
the .exe demo provided. It works fine. Then I recompiled w C700 and
got an 'undefined' by the linker (only 1), I then put an '-' for fun
in front of the said 'undefined' and re cl.  (It worked), Ran the
program and blub, blub, blub! Run time error, R6000, Stack overflow.

The Version is 1.10 I believe.

FYI this is a (It would seam from the doc) very powerful library to write
TSR programs.

vincent
From: pynq@quads.uchicago.edu (George Jetson)
Newsgroups: alt.msdos.programmer
Subject: Re: Toggling NumLock
Date: 3 Oct 92 16:06:00 GMT
Reply-To: pynq@midway.uchicago.edu
Organization: D. J. Dougherty & Associates

In article <1992Oct3.111826.18851@informatik.uni-wuerzburg.de> schoof@dec8.informatik.uni-wuerzburg.dbp.de (Jochen "Joscho" Schoof) writes:
>From article <BvEx5v.Atx@csugrad.cs.vt.edu>, by ceharris@csugrad.cs.vt.edu (Carl Harris):
>> While simply turning off the NumLock bit in the BIOS' keyboard status
>> variable requires only 16 bytes or so, turning off the appropriate 
>> indicator lights on the keyboard iff the machine is an AT-class box takes

I'm sure this is simply a typo ---------------------------^
Or, in Unix ed, we would say:
s/A/X/p

>> several additional instructions.  Hence, NUMOFF.COM is about 40 bytes long.
>[some lines deleted]

************************************************************************
A note to new readers:  the weasely :-) symbol is frowned upon in this
group.  Any questions, see Phil Gustafson who will gladly rearrange your
diodes for you.
			- From the AFU FAQ -

	- pynq@quads.uchicago.edu, who is still costing the net
	  hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
Newsgroups: alt.msdos.programmer
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Subject: Re: mv.exe
Organization: Warsaw University Physics Dept.
Date: Tue, 29 Sep 1992 12:58:59 GMT

Sorry, there are few bugs in my MV.PAS: when copying file, need
Reset(fi,1); and Rewrite(fo,1); - otherwise Turbo Pascal uses default
record size 128; need check IoResult after almost every operation (at
least after the Reset(fi,1); because it is not true what Borland's
manual states as explanation what causes $I- compiler option: "An I/O
error thus does not cause the program to stop, but suspends any further
I/O until the standard function IOresult is called." - in fact further
I/O is not suspended and Rewrite creates output file after Reset which
failed because file was not present; additionally Rename to different
device causes error 'Not same device' even if renamed file don't exist
- final result is empty file created on target device if source don't
exist...). Additionally, it is valuable to use GetFTime/SetFTime to
set target file date/time to be same as source...
All these problems if trying COPY using the MV.PAS, disable possibility
to copy (don't $Define COPY) and can use the program without any problem.
Newsgroups: alt.msdos.programmer
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Subject: Re: How to get keys from keyboard without removing them
Organization: Warsaw University Physics Dept.
Date: Mon, 5 Oct 1992 17:35:56 GMT

>>>>> On Thu, 1 Oct 1992 01:50:23 GMT, FREE1178@vmd.cso.uiuc.edu said:
F>   I need to check the keyboard buffer and store keypresses in a buffer
F> to be stored in a file.  I want to do this as an ISR.  I was planning
F> on writing it in C and then porting it to Assembler.  The question
F> is how to check the keys in the keyboard buffer without removing them.

If you mean the keyboard buffer where BIOS puts keystrokes (on AT computer
there is also keyboard buffer in keyboard itself) it is easy: if you want
be sure to catch all keystrokes write ISR for int 9 which calls previous
ISR and then examines keyboard buffer input pointer, if it was changed
then data pointed by it before servicing interrupt is the keystroke,
otherwise no new data was entered (shift key or key was released or key
which is ignored was pressed). Exception is break (Ctrl-ScrollLock) which
clears all from keyboard buffer. If it is enough to catch keypresses read
by int 16, write ISR connected to this int. Example ISR for int 9:
mov cs:ds_save,ds / mov cs:bx_save,bx / mov bx,cs / mov ds,bx
pop ds:ip_save / pop ds:cs_save / pop ds:f_save / mov bx,40h / mov ds,bx
mov bx,ds:[1Ch] / pushf / call previous_ISR / cmp bx,ds:[1Ch]
jz nothing_new / push ax / mov ax,ds:[bx] / ... / pop ax
nothing_new: mov bx,cs / mov ds,bx / push ds:f_save / push ds:cs_save
push ds:ip_save / mov bx,ds:bx_save / mov ds,ds:ds_save / iret
(it doesn't include check for the break - need write ISR for int 1B).
From: ricky@mindvox.phantom.com (Richard Velez)
Newsgroups: alt.msdos.programmer
Subject: Adding files together
Date: 6 Oct 92 00:48:02 GMT
Organization: [Phantom Access] / the MindVox system

Hi, Can someone send me via E-Mail some information on address two files 
together and making it one, I just got some binary file in 10 parts, nad 
and my memory wont let my editor pass 2800 lines , HELP I make it into 2 
files 5 in each, with I will like to combine, :), Thanks...

===============================================================
 Richard Velez                      Electronic Mail
 South Bronx, Homeboy!               Richard Velez - 1:278/712
 Born and Raise in New York City     Ricky@MindVox.Phantom.Com
===============================================================
Newsgroups: alt.msdos.programmer
From: dalekim@Ingres.COM (FREEBIRD!)
Subject: stdprn and laser printers
Reply-To: dalekim@Ingres.COM (Dale Kim)
Organization: Ask Computer Systems Inc., Alameda CA 94501
Date: 28 Sep 92 23:24:57 GMT


I'm using Microsoft C 6.0 to dump text to a printer using the 'fprintf'
statement to the stream 'stdprn.'  The expected output is about 58 lines
long, and is followed by a form feed character.

This works fine for dot-matrix printers, but I've tried this on an HP
Laser Jet, and a Desk Jet, and they both eject a page with only 1 line
on it.

It works when I dump the text to a file, and then use a system call to
the 'print' command, but I'm interested in knowing why my original code
doesn't work correctly.  Does anyone know what's happening, and how I
can correct it with a minimum of code changes?  Thanks a lot.

Dale Kim
dalekim@ingres.com
ASK Computer Systems
Ingres Division

Newsgroups: alt.msdos.programmer
From: mariusk@idt.unit.no (Marius Kjeldahl)
Subject: Re: Compression algorithms
Reply-To: mariusk@idt.unit.no (Marius Kjeldahl)
Organization: Div. of CS & Telematics, Norwegian Institute of Technology
Date: Tue, 29 Sep 92 15:11:18 GMT

|> Actually I ran the Huffman cost analysis on my HUFFMAN.CPP source file.
|> The size went from about 9100 bytes to 5800 bytes.  That's good, and pretty
|> near usable!  I tried it again on the 23000 byte HUFFMAN.EXE
|> file, which was reduced to nearly 21500 bytes.  That was what didn't impress
|> me.
|> 

Just a comment on compressing executables. Most microprocessors (well
CISCs anyway) have their instruction set optimized just like Huffman
coding (the most common instructions have the shortest instruction
length) and that is why it gives you bad results when compressing
executables.

Marius (mariusk@lise.unit.no)..



Newsgroups: alt.msdos.programmer
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Subject: Re: Monochrome VGA?
Organization: Warsaw University Physics Dept.
Date: Tue, 29 Sep 1992 13:21:58 GMT

>>>>> On 25 Sep 92 18:40:52 GMT, dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL) said:
DAVID> Hi.  256K colors means 64 shades each for red, green, and blue.  Unless you've
DAVID> got a really fancy monochrome VGA monitor, the monitor will only look at one
DAVID> of those signals (I think green for the IBM VGA monochrome monitor).

I suppose the card has analog outputs for Red, Green and Blue. Can add few
resistors and connect it to analog input mono monitor and get more shades
than eye can distinguish (how many gray shades you can distinguish ?
using resistors can get different shade for each of these 256k colors if
we don't consider noise which is surely bigger than 1/256k of signal but
it makes no sense to try display so many shades... just use two resistors,
one few times less than input impedance of monitor and second several times
bigger than the input impedance, connect one end of each to VGA outputs and
second to monitor input, you will get about thousand shades).
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Newsgroups: alt.msdos.programmer
Subject: Re: Programming challenge
Date: 6 Oct 92 14:08:16 GMT
Distribution: alt
Organization: Warsaw University Physics Dept.

>>>>> On Mon, 5 Oct 1992 18:14:10 GMT, jt@fuw.edu.pl (Jerzy Tarasiuk) said:
>>>>> On 30 Sep 92 18:00:46 GMT, bright@nazgul.UUCP (Walter Bright) said:
Walter> I have heard that there is a "well-known trick" for evaluating
Walter> 	(a > b) ? a : b
Walter> in assembler language without using any jump instructions. I haven't
Walter> been able to discover what that trick is. Does anyone know?
Jerzy> Probably something like: mov r1,a / mov r2,b / sub r2,r1 / cmc
Jerzy> sbb r3,r3 / and r3,r2 / add r3,r1 / mov result,r3
Jerzy> The SUB sets CF when a>b, CMC complements the CF, after the SBB
Jerzy> if a>b r3 is 0 (and then AND gives 0, ADD gives r1=a), otherwise
Jerzy> r3 is 0xFFFF (and then AND gives b-a, ADD gives b).
Jerzy> This all for unsigned arithmetic only... Jerzy Tarasiuk

I thinked what to do if SIGNED arithmetic compare is to be used and
I found few solutions of the problem: 1. make compare then push flags,
pop them to register (cannot use LAHF because need overflow flag which
is in bit 11 of flag register) and try extract XOR(bit11,bit7) to put
it in CF and further as for unsigned... very complicated; 2. XOR both
values with 8000h and SUB will set CF as we need; 3. sign extend values
to 32-bit (using CWD instruction), and make 32-bit subtraction to get
value in range FFFF0001h..0000FFFFh, use high order 16 bits for the AND.
I don't know what is more efficient: 2 or 3, would need code it and see.
Remember to move the 8000h to register instead putting it in code 3
times in method 2, use XCHG instead MOV in method 3.   Jerzy
From: banshee@natinst.com (Jeff Kellam)
Newsgroups: alt.msdos.programmer
Subject: Re: Stack Overflow in Turbo C
Date: 5 Oct 1992 07:45:48 -0500
Organization: National Instruments, Austin, TX
NNTP-Posting-Host: eagle.natinst.com

In article <WAYNE.92Oct4013500@dew.cs.odu.edu> wayne@dew.cs.odu.edu (C Wayne Huling) writes:
>I am using turbo C, and am having a stack overflow, my books tell me how to 
>find the problem, but now how to solve the problem.  Any suggestions?
>
>
>		Wayne

There are three ways to eliminate a stack overflow problem.

1)  Make more of the data static, either via the static keyword, or moving
it outside the scope of the function.

2)  Reduce the number of recursions.  If your program doesn't have recursions,
    this probably won't help.

3)  Increase the stack size.  See Turbo's Library Reference (global variable
    section) for more information.

Jeff Kellam
From: klangevi@cs.ulowell.edu (The Raven)
Newsgroups: alt.msdos.programmer
Subject: Re: stdprn and laser printers
Date: 29 Sep 92 18:54:58 GMT
Organization: University of Massachusetts at Lowell Computer Science

Sorry, this isn't quite a followup, and since I'm new, I don't know how
to post to newsgroups yet (I mostly just followup, anyway).  This sort
of has to do with printers, though.  I need to locate a printer file for
use with WordPerfect 5.1 for an Epson LQ-570 printer.  If anyone has one
or knows where I can FTP one, please let me know.  I haven't had any
success so far.

							-Kev
Newsgroups: alt.msdos.programmer
From: jsteele@netcom.com (John Steele)
Subject: Re: Toggling NumLock (C source included)
Date: Mon, 28 Sep 92 22:33:57 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In <1992Sep28.163323.10278@digi.lonestar.org> kgallagh@digi.lonestar.org (Kevin Gallagher) writes:

>In article <27SEP199221155761@pavo.concordia.ca> m_rheau@pavo.concordia.ca (RHEAUME, MICHEL) writes:
>>As simple as it sounds, I can't think of a way to
>>toggle the NumLock key (through software of course!).

>The 1st Edition of PC Magazine's DOS Power Tools book comes with a disk
>containing two 46 byte com files entitled NUMOFF.COM and NUMON.COM.
>Unfortunately, they did not include the source.  However, I think these are
>probably available for download from the PC Magazine BBS.

Here's some Microsoft source to turn it off (should work under Borland's 
also, but I haven't tried it):

/*
 *  NUMOFF.C - Turns the NumLock off
 *
 *  cl -Ox numoff.c
 */

#if !defined(MK_FP)
#define MK_FP(seg,ofs)  ((void far *) (((unsigned long)(seg) << 16) | \
                        (unsigned)(ofs)))
#endif

main ()
  {
  *(int far *) MK_FP (0x40, 0x17) &= 0xDF;
  }

Enjoy,
  John
-- 
#include <disclaimer.h>			/* route all flames to /dev/null  */
/**************************************************************************/
/*   Systems Analyst      | John Steele     email: jsteele@netcom.com     */
/* Video Business Systems |                                               */
/*   1-800-255-3088       |    Most people spell COBOLSUX incorrectly...  */
/**************************************************************************/
From: kgallagh@digi.lonestar.org (Kevin Gallagher)
Newsgroups: alt.msdos.programmer
Subject: Re: Toggling NumLock
Date: 28 Sep 92 16:33:23 GMT
Organization: DSC Communications Corp, Plano, TX

In article <27SEP199221155761@pavo.concordia.ca> m_rheau@pavo.concordia.ca (RHEAUME, MICHEL) writes:
>As simple as it sounds, I can't think of a way to
>toggle the NumLock key (through software of course!).

The 1st Edition of PC Magazine's DOS Power Tools book comes with a disk
containing two 46 byte com files entitled NUMOFF.COM and NUMON.COM.
Unfortunately, they did not include the source.  However, I think these are
probably available for download from the PC Magazine BBS.

Notice I said the 1st Edition.  The 2nd Edition of the book, which has been
updated to cover MS-DOS 5.0, no longer has these two programs on the software
disks that come with the book.

I am sure there are public domain programs which do the same thing, but I
don't personally know of any.

Newer systems provide a setup option which allows you to select the default
setting which NUM LOCK should have at the completion of a system boot.
Perhaps your's has this option and you just didn't notice.

-- 
----------------------------------------------------------------------------
Kevin Gallagher        kgallagh@digi.lonestar.org OR ...!uunet!digi!kgallagh
DSC Communications Corporation   Addr: MS 152, 1000 Coit Rd, Plano, TX 75075
----------------------------------------------------------------------------
Newsgroups: alt.msdos.programmer
From: nelson@paradyne.com (Bill Nelson)
Subject: Upgrade Dilemma
Organization: AT&T Paradyne, Largo, Florida
Date: Tue, 29 Sep 1992 15:31:18 GMT

I don't know if this is the correct place to post this, but here it goes:

Last night I tried upgrading my IMS 286 machine (Phoenix BIOS 3.x, and DOS 
3.3) with a rip roaring 40 meg HD partitioned into 2 separate drives (due
to DOS 3.3) to DOS 5.0.  Of course, as in anything I do with my machine I 
had problems.

First, after backing up my drive(s) I tried to simply upgrade to DOS 5.0
from DOS 3.3.  I got an error which stated that I had an incompatabile
hard drive please refer to section 2.4 on disk 3 (for 3.5" floppies).

Section 2.4 said:

       If you are using DOS 3.x on a system that has a Disk Manager 
       partition greater than 512MB, contact Ontrack Computer Systems
       to get an upgraded version of Disk Manager and instructions for
       making the partition compatabile with MS-DOS 5.0.  Otherwise,
       do the following:
          1.  Back up your current DMDRVR.BIN and XBIOS.OVL device
              drivers.
          2.  Replace the DMDRVR.BIN and XBIOS.OVL files by using
              the EXPAND command to expand and copy the DMDRVR.BI_
              and XBIOS.OV_ files from Disk 6 for 5.25" disks or 
              from Disk 3 of 3.5" disks.
          3.  Type the following:
                   setup /u

(I don't have an XBIOS.OVL device, but I did back up the DMDRVR.BIN).

I did this, and still had the same problem.  So I figured, Why not simply
format the harddisk and start from scratch?   I deleted the primary DOS
partition, created a new primary DOS partition using the maximum size
possible (which I assumed was the entire 40 meg disk) and formatted the 
disk.  

I installed DOS 4.01 onto the vacated disk and tried to upgrade to DOS
5.0 (all I have is the upgrade to 5.0).  I still got the same problem.
(Same error message!)

I figured, that I could reload all my applications software (from DOS 
3.3 days) and then upgrade to 5.0 when I got my problems figured out.  
But to add insult to injury, I found that there wasn't enough space on my 
HD to reinstall my software.  I assume that all of the HD wasn't formatted
as I had assumed in the beginning.

HELP!!!!!!!!

--
| Bill Nelson    |                                  | Opinions expressed do not necessarily |
| AT&T Paradyne  |    This space intended blank!    | reflect those of my employer; in fact,|
| (813) 530-8696 |                                  | they may not represent mine either.   |
+----------------+----------------------------------+---------------------------------------+
Newsgroups: alt.msdos.programmer
From: dlittle@sscvx1.ssc.gov (DENNIS LITTLE)
Subject: Q Basic Question
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: Superconducting Super Collider Laboratory
Date: Wed, 30 Sep 1992 16:24:00 GMT

I'm in the process of writing a utility that will be getting a
path to a file and then reading all filenames into a temp.dir
and the following isn't returning with an error as expected

shell "dir " + path$ + "> ~temp.dir"
open "~temp.dir" for input as #3

apparently, when going into a shell, error messages aren't sent
and I need a way to check the path to see if it exists... Any
ideas would be greatly appreciated.

me
Newsgroups: alt.msdos.programmer
From: schoof@dec8.informatik.uni-wuerzburg.dbp.de (Jochen "Joscho" Schoof)
Subject: Re: Toggling NumLock
Organization: University of Wuerzburg, Germany
Date: Wed, 30 Sep 1992 09:30:17 GMT

From article <1992Sep28.163323.10278@digi.lonestar.org>, by kgallagh@digi.lonestar.org (Kevin Gallagher):
> In article <27SEP199221155761@pavo.concordia.ca> m_rheau@pavo.concordia.ca (RHEAUME, MICHEL) writes:
>>As simple as it sounds, I can't think of a way to
>>toggle the NumLock key (through software of course!).
> 
> The 1st Edition of PC Magazine's DOS Power Tools book comes with a disk
> containing two 46 byte com files entitled NUMOFF.COM and NUMON.COM.
> Unfortunately, they did not include the source.  However, I think these are
> probably available for download from the PC Magazine BBS.
[some lines deleted]

I really wonder how this can be as big as 46 Bytes. You can easily write
that thing using MS-DOS' debug (yep, it is good for something) in 12
bytes, if I remeber it correctly. I don't have it at hand now, but I'll
post it tomorrow.

- Jochen

-- 
---------------------------------------------------------------------------
Jochen Schoof                    schoof@sundae.informatik.uni-wuerzburg.de
Lehrstuhl f. Informatik II +-----------------------------------------------
Universitaet Wuerzburg     | It's worse than that: he's dead, Jim!  -Bones
Newsgroups: alt.msdos.programmer