HDTenEightyP/NetNews huggingface dataset:
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Subject: Re: Stack Overflow in Turbo C
Organization: Warsaw University Physics Dept.
Date: Tue, 6 Oct 1992 14:28:41 GMT

>>>>> On 4 Oct 92 12:12:17 CDT, haydedr@wkuvx1.bitnet said:
h> 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?
h> Well, you could increase your stack size.  To do this in Turbo C++
...
h> extern unsigned _stklen = 543210U;

Note unsigned has range from 0 to 0xFFFF(=65535U), don't try use
bigger values because compiler will truncate high-order bits. 
Also note not every memory model allows 64kB stack.
Cheers, Jerzy
Xref: sparky alt.msdos.programmer:2516 comp.sys.ibm.pc.programmer:473 comp.os.msdos.programmer:9740 comp.os.os2.programmer:5465 comp.msdos.programmer:65
From: rjm@dciem.dciem.dnd.ca (Robert J. Manley)
Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc.programmer,comp.os.msdos.programmer,comp.os.os2.programmer,comp.msdos.programmer
Subject: DOS Extender network development libraries
Summary: Looking for PharLap compatible TCP/IP development libs
Keywords: DOSX Extender PharLap TCP/IP Zortech 386
Date: 5 Oct 92 15:33:55 GMT
Followup-To: alt.msdos.programmer
Organization: NTT Systems Inc., Toronto, Canada

Hello netters.

I am in desperate need of TCP/IP development libraries compatible with
Zortech's DOSX memory model.  From what I understand, code compiled for
this model should also be linkable with object libraries developed for
the PharLap 386 DOS extender.

Any comments, suggestions, or ideas would be GREATLY appreciated.
Thanks in advance.

Robert.
-- 
# Robert J. Manley,  rjm@dretor.dciem.dnd.ca		#
# #include <std_disclaimer.hpp>			#
# NTT Systems Inc., Toronto, Ontario, CANADA		#
#	Windows : OS/2 :: old hooker : innocent bride	#
From: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
Newsgroups: alt.msdos.programmer
Subject: Re: Toggling NumLock
Date: 28 Sep 92 14:49:45 GMT
Reply-To: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
Organization: North Carolina State University, Project Eos
Originator: dspascha@c00393-346dan.eos.ncsu.edu


Hi.  Just zero out the word at address 0040:0017h and this will turn everything
(caps/num/scroll lock, insert toggle, etc.) off.  Here's some assembly-language
code you can try:

; NONUMLOK.ASM.

		.model		tiny

Code		segment
		assume		cs:Code
		org		100h
Start:		mov		ax,40h
		mov		ds,ax
		mov		word ptr ds:[17h],0
		mov		ax,4C00h
		int		21h
Code		ends
		end		Start

Tschuess,
David Paschal
From: m_rheau@pavo.concordia.ca
Newsgroups: alt.msdos.programmer
Subject: Hard Disk Classification
Date: 6 Oct 92 09:47:00 GMT
Organization: Concordia University
News-Software: VAX/VMS VNEWS 1.41

I'm posting this message for a friend who has the following
problem (apologies if this is not the most appropriate usergroup):

He bought a second-hand hard drive, a Seagate ST-1102A.
He doesn't know how to configure the hard drive in setup.
He would like to know cylinders, etc, and even how many megs
so he doesn't configure it incorrectly.  Does someone out there
have this model's specs?

A question of my own: Would configuring it incorrectly be damaging
in any way to the disk?

Thanks in advance for any help

Andrew .   ... M_RHEAU@PAVO.CONCORDIA.CA



Newsgroups: alt.msdos.programmer
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:50:17 GMT

gay@selkirk.sfu.ca (Ian D. Gay) writes:

>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

sorry, not thinking, that should be
     push ds
     mov ax, seg DGROUP
     mov ds,ax
since you cant load a constant to a segment register



>    ......

>    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: bright@nazgul.UUCP (Walter Bright)
Newsgroups: alt.msdos.programmer
Subject: Re: Phar Lap DOS Ext and BC++
Date: 29 Sep 92 16:25:16 GMT
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle

In article <1992Sep22.111452.8413@julian.uwo.ca> schmidt@cogsci.uwo.ca (William Schmidt) writes:
/Phar Lap 386 is compatible with other C's, but all of them more obscure.
/(Meta Ware High C, Watcom C-386) Note that these are 32 bit Cs. Phar Lap
/markets Meta Ware High C/C++ and their extender for $995.
/I wish I knew more of the capabilities of these C packages (i.e. graphics
/support etc?).

Zortech (Symantec) C/C++ supports generating 32 bit native DOS applications.
A 32 bit DOS extender is included. Also included is the FG library for graphics.
Newsgroups: alt.msdos.programmer
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Subject: Re: Wanted:  recommend reliable FORTRAN compiler for DOS
Organization: Warsaw University Physics Dept.
Date: Thu, 1 Oct 1992 13:05:49 GMT

>>>>> On 30 Sep 92 02:40:33 GMT, rebeccal@csugrad.cs.vt.edu (Rebecca S. Lawrence) said:
RSL>  The Engineering department at Virginia Tech requires that freshman engineers
RSL> use WatFor as their fortran compiler. I have heard varing reports on how 
RSL> good it is. Keep in mind that they get the educational version. But it should

Oh, no! I remember WATFOR (Waterloo Fortran) is most unreliable compiler 
I have seen. It has one nice thing: can edit program like in Turbo
Pascal/C/... but results from running correct program compiled using it
are usually incorrect! Most reliable I have seen is LAHEY, next is
Microsoft Fortran (but MS F. doesn't detect integer overflow).
Newsgroups: alt.msdos.programmer
From: robert@solan.unit.no (Robert Schmidt)
Subject: Re: Compression algorithms
Organization: Norwegian Institute of Technology
Date: Tue, 29 Sep 92 11:29:49 GMT

In article <kauffman.16.717709476@slab.unt.edu>, kauffman@slab.unt.edu (DON KAUFFMAN) writes:

 > 	Maybe I missed the clue boat.   I thought that the optimal
 > 	code for compressing a data set also produced the optimal
 > 	compressed data set.  Is this not true?  I understand that
 > 	in some cases there would be a more optimal algorithm than
 > 	Huffman's, such as a variation of Huffman's that used
 > 	samples of different lengths.  How could you NOT be impressed
 > 	by its compression ratio, though?  The first thing that
 > 	I imagine is that you didn't compress the coded bits into
 > 	packed bytes, but saved them as their ascii values, '0',
 > 	and '1'.  If that's the case, packing the bits would produce
 > 	a coded file 1/8 of its current size, depending on the size
 > 	of the original data set.  Was that your problem?  

Heh, what do you take me for?  :-)

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.

I have long experience in using programs like PKZIP, LHA and ARJ, and I am
perhaps expecting too much of a simple algorithm like Huffman's.  But the
fact is that all those programs compressed the above files to approx. 50-65
percent of the original sizes.
 
I guess combining Huffman coding with LZ coding would be a good idea, and
I have heard that that's what's been done in LHA.  I think that boils
down to what you refer to as variable-sample Huffman.

-- 
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: m_rheau@pavo.concordia.ca (RHEAUME, MICHEL)
Newsgroups: alt.msdos.programmer
Subject: Toggling NumLock
Date: 28 Sep 92 02:15:00 GMT
Organization: Concordia University
News-Software: VAX/VMS VNEWS 1.41

As simple as it sounds, I can't think of a way to
toggle the NumLock key (through software of course!).

It's not anywhere in the ASCII charts, buy I'd like 
to do this through software since it's on everytime
I boot my machine, and I'm getting too lazy to reach
alllll the way over to the keypad to kill it.

anyone? anyone?

A N    D        R                E                                       W

sig(h)  
Newsgroups: alt.msdos.programmer
From: rg9538@ehsn5.cen.uiuc.edu (Ronald E Garnett)
Subject: Re: stdprn and laser printers
Organization: University of Illinois at Urbana
Date: Tue, 29 Sep 1992 02:32:09 GMT

dalekim@Ingres.COM (FREEBIRD!) writes:


>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


First Guess:  Is there a significant time period between writing lines
to STDPRN (ie a few seconds)?  If so, there could be a question of
printer timeout.  I don't believe that the HP's have a method of simply
dumping out the hex characters they receive.  But if they did, then you
could run your program and see EXACTLY what the printers are getting.
This might reveal an extra form feed or whatever!

If you happen to have access to an IBM 4029 Laser Printer, then try using
it instead (for testing purposes).  It has a hex dump mode, and can show
you every character that the printer gets.  It's very handy when 
troubleshooting these things!

A third idea is to find one of those little neat utilities for redirecting
the standard LPT1 or STDPRN to a file.  PC Mag has this in their utils I
believe.  If you could do this, it would hopefully be equivalent to the
hex dump from the printer.  

Good Luck!!

Ron Garnett,
University of Illinois at Champaign-Urbana
From: terry.walter@outlan.ersys.edmonton.ab.ca (Terry Walter) 
Newsgroups: alt.msdos.programmer
Subject: I NEED
Date: 30 Sep 92 01:39:00 GMT
Reply-To: terry.walter@outlan.ersys.edmonton.ab.ca (Terry Walter) 
Distribution: world
Organization: Outland BBS-UUCP

I need some help.  I am using an external variable (%1) and in my
bat(ch) file In want it to search (%1) for for sometext and if it finds
it, exit, and if it doesn't say so.

eg.

LOOK.BAT TEXTFILE.TXT

 (looking in %1)=TEXTFILE.TXT search it to see if it finds .TXT
   if it does, print this is a text file.
   if not, print this is not a text file.

   can someone help
            
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: Sat, 3 Oct 1992 11:18:26 GMT

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
> several additional instructions.  Hence, NUMOFF.COM is about 40 bytes long.
[some lines deleted]

Sorry, Carl, but that's simply wrong! My 12-or-some-more-bytes routine
toggles the bit as well as the LED. Hope I won't forget to take it with
me on monday... (BTW: I owe a 386-machine which seems AT-class to me).

- 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
From: rebeccal@csugrad.cs.vt.edu (Rebecca S. Lawrence)
Newsgroups: alt.msdos.programmer
Subject: Re: Wanted:  recommend reliable FORTRAN compiler for DOS
Date: 30 Sep 92 02:40:33 GMT
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA


 The Engineering department at Virginia Tech requires that freshman engineers
use WatFor as their fortran compiler. I have heard varing reports on how 
good it is. Keep in mind that they get the educational version. But it should
be decent for simple compilations.

-----
Becky Lawrence                |  I saw you two days ago, I saw you 
rebeccal@csugrad.cs.vt.edu    | yesterday, I saw you today, but I 
VPI & SU                      | must see you tomorrow as well....
Blacksburg, VA                |     I LOVE YOU KEVEN
-------------------------------------------------------------------
"The world tells boys to conquer the world, and girls to wear clean
panties. A man dressed as a bat is a he-man, but a woman dressed as
a cat is a she-devil. I'm just living down to expectations. Life's
a bitch - and so am I."   -----CATWOMAN
-- 
-----
Becky Lawrence                |  I saw you two days ago, I saw you 
rebeccal@csugrad.cs.vt.edu    | yesterday, I saw you today, but I 
VPI & SU                      | must see you tomorrow as well....
Newsgroups: alt.msdos.programmer
From: wayne@dew.cs.odu.edu (C Wayne Huling)
Subject: Stack Overflow in Turbo C
Organization: Old Dominion University, Norfolk, VA, USA
Date: Sun, 4 Oct 1992 06:35:00 GMT

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
From: branagh@cs.mcgill.ca (Wayne BRANAGH)
Newsgroups: alt.msdos.programmer
Subject: Virus Construction Kit
Date: 2 Oct 92 21:55:38 GMT
Distribution: usa
Organization: SOCS - Mcgill University, Montreal, Canada

Does anyone have a copy of the Dark Avenger's virus developer's kit
(called the Mutation Engine)? 

I saw it mentioned in PC Magazine and I'd really like to see what comes
in the package (code wise). If it's widely available would someone point
me to an ftp site or mail me a copy? 

I'm sure it's shareware :-). 

Cheers,
Wayne
branagh@binkley.cs.mcgill.ca
Newsgroups: alt.msdos.programmer
Subject: How DOS executes batch files [was: Another MsDos batch programming chal
From: ccdps@levels.unisa.edu.au
Date: 29 Sep 92 08:11:44 +0930
Followup-To: alt.msdos.programmer,comp.os.msdos.programmer
 <1992Sep4.032836.7299@cs.ubc.ca> <1992Sep4.213842.14734@mits.mdata.fi> 
 <1992Sep7.211129.702@csc.canterbury.ac.nz> <18812.2ac80fc0@levels.unisa.edu.au>
Organization: University of South Australia
XPosted: ccdps@levels.unisa.edu.au
XNewsgroups: comp.os.msdos.programmer

In article <1992Sep7.211129.702@csc.canterbury.ac.nz>, cctr132@csc.canterbury.ac.nz (Nick FitzGerald, CSC, Uni. of Canterbury, NZ) writes:
> In article <1992Sep4.213842.14734@mits.mdata.fi>, kennu@mits.mdata.fi
> (Kenneth Falck) writes:
>> In article <1992Sep4.032836.7299@cs.ubc.ca> yogi@cs.ubc.ca (Yossi Gil)
> writes:
  [deleted]
> The actual DOS batch processor is a tad more involved than Yossi's
> outline suggests.  Whilst the following may not seem much different from
> what Yossi suggests, some subtle implications of batch processor
> operations are more clearly apparent from it.  To the best of my ability
> to tell, the following is a more accurate outline:
>
>  1.  Open file
>  2.  Read first line
>  3.  Note number of -chars- read thus far
>  4.  Parse line (for redirection, etc)
>  5.  Close file
>  6.  Execute command
>  7.  Open file
>  8.  Read to number of chars recorded in 4.
>  9.  Read to next EOL or EOF
> 10.  If command is null and EOF goto 12.
> 11.  Loop to 3.
> 12.  Close file
>
 [STUFF deleted]

I have done some quick checks with a crude interrupt tracer to
determine what happens with REMs and labels. I have the following
modifications:

  1.  Open file
  2.  Read line
  3.  Note number of -chars- read thus far
  4.  Parse line (for redirection, etc)
  5.  If line is a label, note position and do step 2
  6.  If line is a forward GOTO, keep reading until label found, then do step 2
  7.  If line is a backward GOTO...? (I haven't tested this yet)
  8.  Close file
  9.  Execute command
 10.  Open file
 11.  Read to number of chars recorded in 3  [I think Nick meant 3 here, not 4]
 12.  Read to next EOL or EOF
 13.  If command is null and EOF goto 15.
 14.  Loop to 3.
 15.  Close file

This confirms what simple ECHO ON observation says: REMs get executed and labels
don't. At UniSA we have for years been skipping rather long documentation
sections in our LAN batch files with a GOTO, because the batch processor
*doesn't* close and open the file to read every line regardless. This also
supports the very old trick of using ": " to begin a comment rather than
a REM. The space after the ":" ensures that there are no confusions between
real label names and comments.

--
 Dan Shearer                        email: Dan.Shearer@UniSA.edu.au
 Computer Centre                    Phone: +61 8 302 3479
 University of South Australia      Fax  : +61 8 302 3385
From: kauffman@slab.unt.edu (DON KAUFFMAN)
Newsgroups: alt.msdos.programmer
Subject: Re: Compression algorithms
Date: 28 Sep 92 19:44:36 GMT
Organization: School of Library & Info Sci, UNT

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

>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.

	Maybe I missed the clue boat.   I thought that the optimal
	code for compressing a data set also produced the optimal
	compressed data set.  Is this not true?  I understand that
	in some cases there would be a more optimal algorithm than
	Huffman's, such as a variation of Huffman's that used
	samples of different lengths.  How could you NOT be impressed
	by its compression ratio, though?  The first thing that
	I imagine is that you didn't compress the coded bits into
	packed bytes, but saved them as their ascii values, '0',
	and '1'.  If that's the case, packing the bits would produce
	a coded file 1/8 of its current size, depending on the size
	of the original data set.  Was that your problem?  

>
>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!
>

	I would honor your request to reply via e-mail, but I
	wanted to ask everyone else out there the same question:
	Is there a more optimal coding algorithm?

						Don Kauffman
Newsgroups: alt.msdos.programmer
From: mbk@netcom.com (Miles Kehoe)
Subject: Re: HELP Appendin two files
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 6 Oct 1992 20:18:45 GMT

ricky@mindvox.phantom.com (Richard Velez) writes:

> I receive yesterday a 10 part binary file, and I will like to append 
>them together the problem is that I could only use my text edit to append 
>5 at a time, due to my low in memory, which I only have 1 meg, anyway I 

The text editor probably won't handle binary files. you can use
the doc command:

copy/b part1/b+part2/b+part3/b+.....partn/b combo/b

The 'plus' character appends the source documents 'added' together
and the /b tells dos to strip control-z from end of file and to not
interpret control-z as eof during the copy; and the combo/b tells
dos to not add a control-z to the output file.

Good luck.

mbk
From: chtan@solomon.technet.sg (Tan Choong Hwee)
Newsgroups: alt.msdos.programmer
Subject: Setup Toolkit Under DOS & Windows
Date: 28 Sep 92 12:54:55 GMT
Organization: National University of Singapore
X-Newsreader: TIN [version 1.1 PL6]


Dear netters,

I'm looking for some kind of toolkit for writing setup program for DOS and
Windows environments. I came across MS Setup Toolkit, InstallIt, and 
InstallShield. Would like to hear from you any experience and opinion you
may have on these tools and any other similar toolkit in the market (I'm
sure there are many such tools).

Please reply by email. Any help is very much appreciated.

Hope this is not a FAQ.

Regards,
Tan C H
From: haydedr@wkuvx1.bitnet
Newsgroups: alt.msdos.programmer
Subject: Re: Stack Overflow in Turbo C
Date: 4 Oct 92 12:12:17 CDT
Organization: Western Kentucky University, Bowling Green, KY

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?


Well, you could increase your stack size.  To do this in Turbo C++
version 3.0 for DOS (I'll bet it's the same, though, for all versions
of Turbo C), you have to set the global variable _stklen, declared in 
DOS.H, to a new value.  For instance,

/*-----------------------------------*/
#include <stdio.h>
#include <dos.h>


extern unsigned _stklen = 543210U;

int main(void)
{
   printf("The stack size is %u\n", _stklen);
   return 0;
}
/*-----------------------------------*/

That should do it.  If you increase your stack to the size I used
above, and you still overflows, then you may want to check your code
for some infinite loops or other things of that nature.

Cheers,
Ross Hayden                          HAYDEDR@WKUVX1.BITNET
Newsgroups: alt.msdos.programmer