HDTenEightyP/NetNews huggingface dataset:
From: Ross Ridge <ross@zooid.guild.org>
Subject: Re: studying executables
Organization: ZOOiD BBS
Distribution: comp
Date: Sun, 6 Sep 1992 23:24:08 GMT

ara@zurich.ai.mit.edu (Allan Adler) writes:
>For years I have had an interest in understanding, in the absence of any
>documentation, what a given executable does.

Try running it.

>I understand that one can simply use a debugger, preferably a smart one,
>and follow it step by step in the hope of discovering what the code does.

Boring.  

>First, it seems to me that every compiler and every assembler must have its
>own idiosyncratic way of producing the executable. Is that true?

For compilers yes, for assemblers no.  With assemblers every byte of
the execuatable is under the programmers control.

>If so, then it might be possible to have a database of idiosyncrasies
>that lets one figure out what compiler or assembler produced the executable.

For compilers, it's easy just look at the startup code.  Every compiler
and compiler version has there own, pretty much unique start up code.
What makes this even is easier is the fact that this start up code often
contains giveaway copyright strings.

>For each compiler, there might be a specific decompiler that takes into
>account the special features of that compiler. Also, if by some miracle
>the code was compiled but not optimized, it seems like it would retain
>more features of the original.  Or if compiled with C and debugging
>information was not stripped from the executable, that would be quite
>helpful. Knowledge of the source language and the specific compiler seems
>like it would be quite helpful.

With BASIC you might have some luck, the code probably was a mess of
GOTO's anyways, but with other languages reverse compiling isn't going
to get you anything more intellegible then a simple disassembly.

>The second idea is that even if one knows nothing about the source language
>or the compiler, one can still imagine tools that will give an overview
>of the structure of the program. The trouble with debuggers and disassemblers
>is that they work at the lowest level, one instruction at a time. Imagine
>instead an attack on the entire executable.

[ much thought on how to "attack" an entire executable deleted ]

>Admittedly this does not solve the problem, but I feel that automating what
>I have described would put one in a position to take the next step.

You're talking about a whole mess of heuristics, something better
performed by a human than a computer.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.os.msdos.programmer,comp.lang.c++,comp.sys.ibm.pc.programmer
Date: Tue, 15 Sep 1992 23:34:32 -0400 
From: Stefan Monnier <sm86+@andrew.cmu.edu>
Subject: Re: Why no source control in Borland
	<aldavi01.716533318@starbase.spd.louisville.edu>

Excerpts from netnews.comp.lang.c++: 15-Sep-92 Re: Why no source control
i.. Arlie Davis@starbase.spd (1569)

> Or is this being done already and am I years behind??
> -- 
> lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null


I don't know for you, but DOS is years behind !!


	Stefan Monnier

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------





Newsgroups: comp.os.msdos.programmer
From: brown@NCoast.ORG (Stan Brown)
Subject: Re: Novice question: how to boot from a bat file?
Organization: Oak Road Systems, Cleveland Ohio USA
Date: Mon, 7 Sep 1992 00:03:33 GMT

In article <2aa3698c@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes:
>In article <1992Aug31.214211.20267@midway.uchicago.edu>, pynq@quads.uchicago.edu (George Jetson) wrote:
>}Anyway, somebody ought to get Ralf to post the one true solution to the
>}auto-reboot program.
>
>It's in the FAQ.

And it's as good as it is because Ralf contributed to it, both in posted
articles and in private email.

Ralf has been responsible for improvements in many of the answers in the
FAQ.
-- 
Stan Brown, Oak Road Systems                      brown@Ncoast.ORG

"Never try to teach a pig to sing.  You'll only waste your time and
annoy the pig."  Heinlein wrote it; I'd like to know the original source.
Newsgroups: comp.os.msdos.programmer
From: davis@pacific.mps.ohio-state.edu ("John E. Davis")
Subject: malloc overhead?
Reply-To: davis@pacific.mps.ohio-state.edu  (John E. Davis)
Organization: "Dept. of Physics, The Ohio State University"
Date: Wed, 9 Sep 1992 01:10:40 GMT

Hi,

   I have a simple question that I have never seen addressed but is also
important. If I malloc some space of length size, how much additional overhead
is there?  That is, the amount of ``free'' memory will drop by size + d_size;
what is d_size? I know this may depend on the memory module etc, so for the
sake of argument, assume that I am talking about farmallocs in the large
memory module.

Thanks,
--
     _____________
#___/John E. Davis\_________________________________________________________
#
# internet: davis@amy.tch.harvard.edu
#   bitnet: davis@ohstpy
#   office: 617-735-6746
#
Newsgroups: comp.os.msdos.programmer,comp.lang.c
From: alpha@waggen.twuug.com (Joe Wright)
Subject: Re: BC++2.0 lseek problem(ALSO:lseek() question)
Organization: ALPHA, Box 68621, Va. Beach, VA 23455
X-Newsreader: Tin 1.1 PL5
Distribution: usa
Date: Sun, 13 Sep 1992 04:38:39 GMT

Using open() and read() and lseek() will usually guarantee
non-portability.  These are OS functions, not C functions.
More specifically, they are Unix functions and not MSDOS
functions.  I strongly reccommend fopen(), fseek(), etc.

That aside, the main reason that seek doesn't work the same
on Unix text files and DOS text files is that DOS uses two
characters, \r\n, to terminate a line while Unix uses only \n.
So the DOS text file has a few more characters in it than
the Unix one.

-- 
Joe Wright  alpha@waggen.twuug.com  alpha@wyvern.twuug.com
Newsgroups: comp.os.msdos.programmer
From: uzun@crash.cts.com (Roger Uzun)
Subject: Int 13h Read Sectors/Write Sectors to HD
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 06 Sep 92 18:29:18 PDT

When you do a write/read sectors request to/from the Hard Disk,
using int 13h, does the BIOS auto step through the cylynders/heads
if your request spans such a boundary.
For example if a disk has 4 heads, 17 sectors/track and you
ask to read 80 sectors starting at head 0, cylynder 20, sector 1,
will the BIOS give you hd 0 secs 1-17, hd 1 secs 1-17, hd 2
secs 1-17, hd 3 secs 1-17, then go on to the next cylynder (21)
and give you the remaining sectors from hd 0 of that sector?

Just how smart is the read/write sector command of int 13h


-Roger
--------------------------------------------------------------
bix: ruzun
NET: uzun@crash.cts.com
Newsgroups: comp.os.msdos.programmer,comp.editors
From: ez6806225@ntuvax.ntu.ac.sg
Newsgroups: comp.os.msdos.programmer
Subject: 3-D Studio mapping
Date: 5 Sep 92 05:26:43 GMT
Organization: Nanyang Technological University - Singapore

Any one knows how to do texture mapping using CEL and GIF files on an object in
3-D Studio? Also, how do I create a mapping file (e.g. CEL).
From: beaurega@ireq.hydro.qc.ca (Denis Beauregard)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Results of the smallest TSR contest
Date: 7 Sep 92 16:54:19 GMT
Organization: Institut de recherche d'Hydro-Quebec, Varennes, Canada

OK.  Well, I checked in my office PC for a true _useful_ TSR program.
If we accept that a TSR is not necessary using the TSR command, then
the place wasted by PSP is saved.  This improves somewhat what the
smallest possible will be.

In that context, the program will be the assembly code of the program, 
plus the 5 bytes for the memory control block, with a 16-bytes border.

I wrote such a TSR that takes some 40 bytes.  It is working (my colleague
needed it to bypass a bug in his machine BIOS) while the example I gave
was not (I just tried to evaluate what was the smaller, just to see if
64 was the smallest possible).  This TSR which I called PATCH19 works
on one machine (i.e. patch is useless on other machines which have not
the same bug), is in Assembler (Borland supports _AX etc., but the program
was using many co-processor instructions) and was useful.  

Anyway, there are 2 conclusions to that contest : the smallest TSR is
32 bytes (the memory manager will give you 16 bytes or more and will
use 5 of 16 more bytes).  Thus, if you can patch something in 27 bytes
and can be sure the MCB is just below the memory block you get, then the
program will be the smallest.  I just wonder if in future releases of DOS,
the MCB header will be movable, in which case the patch must be 16
bytes to be the smallest.

Obviously, if you want to do something useful (not necessary something the
computer user will notice), you may need more than 32 bytes!  But some
patches will need only a few bytes and _are_ useful.

Second conclusion is that the smallest TSR will not use the TSR facility
provided by DOS.  Thus, maybe a suggestion for the FAQ list (even if not
an FAQ!) : to get the smallest TSR, try 1st to allocate a memory block,
and if no one found, then use the PSP.

Finally, not a conclusion, but merely a comment : there seems to be no
straight frontier between HLL and Assembler.  In Borland C, you can
use registers.  In Intel PLM, you can use pseudo-instructions like
enable() or disable().  Years ago, I dreamed of an Assembler language
supporting direct HLL calling convention.  But, today there are HLL
compilers supporting many Assembler features.

-- 
  \_\    Denis Beauregard  *  internet:beaurega@ireq.hydro.qc.ca
 /   \   Genealogiste officiel : Beauregard/Jarret/Jarest/Vincent
J   __>  Un Quebec renouvele dans une Amerique renovee
\_.-===                                                  Opinions ? Et pis non !
Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.misc
From: jaegerwl@wckn.dorm.clarkson.edu (Bill Jaeger)
Subject: Re: Can I Intercept Stuff Going To A Printer Into A file.??
Organization: Clarkson University
Date: Wed, 16 Sep 1992 02:22:23 GMT


>hjanssen@cbnewse.cb.att.com (hank janssen) writes:
>> For all you MSDOS wizards out there. Maybe a stupid question.
>> I have an application that prints out data from a very old DB system.
>> I need to get the output of a list from the database in a flat file.
>> (THe database is very old, and i have no DB access routines)
>> 
>> I can print pre-made lists. But they always go to the printer.
>> Is there aneasy way for me to intercept the stuff going to the printer
>> and route it to go to a file.
>> 

I don't know if it'll work for you, but I've had reasonable success with
a program called VPRINT.  It does just what you want - it redirects printer
output to a file.

You can find VPRINT at WUarchive (wuarchive.wustl.edu) in the
/mirrors/msdos/geoworks directory, I believe.

Hope this info helps!

					-Bill


-----------------------------------------------------------------------------
-Bill Jaeger
 jaegerwl@logic.camp.clarkson.edu	Clarkson University, Potsdam New York
 jaegerwl@wckn.dorm.clarkson.edu        WCKN Television, Potsdam New York

 "Only by attempting the absurd can we achieve the impossible"
					- Pyro to The Illuminator, 1990
------------------------------------------------------------------------------

--
------------------------------------------------------------------------------
-Bill Jaeger
 jaegerwl@logic.camp.clarkson.edu	Clarkson University, Potsdam New York
 jaegerwl@wckn.dorm.clarkson.edu        WCKN Television, Potsdam New York
Xref: sparky comp.os.msdos.programmer:9101 comp.os.msdos.misc:5068
From: andyross@infopls.chi.il.us (Andrew Rossmann)
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.misc
Subject: Re: Disk Drive Purchase?
Date: Sun, 06 Sep 92 09:50:02 CDT
Organization: INFOPLUS support, Wheeling, IL

amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes:

> 2. It a recent microsoft technical seminar, we were presented with the
>   following info, fact or fiction, I don't know for sure...  The 32 bit
>   disk swapping enhancement of windows 3.1, will _never_ be compatible
>   with existing scsi drives or controllers.  A ESDI driver is being worked
>   on, and may be available sometime.  Sometime may or may not = Never.
>   ESDI drives have the advantage that as you have more money, and things
>   come down in price, faster and faster controllers (cached controllers,
>    etc...) can be purchased.

  That's odd. My computer has a 110M ESDI with an Ultrastor 12F controller.
It runs 32-bit access with no problems. On the other hand, the controller
responds to many of the IDEINFO type programs. Maybe Windows thinks it's an
IDE.

> 3. IDE drives and controllers, could already be windows 32 bit disk access
>    compatible.  IDE drives and controllers are about as fast as they are
>   ever going to be, or are capable of being.  However, they do have plenty
>   of throughput, and i/o headroom for faster systems, today.  They will
>    start showing age, as systems keep doubling in speed, and larger and
>   larger software becomes available.  On the other side, the tremendous
>   cost of ESDI drives and controllers will be a serious drawback to the
>   wide acceptance of these systems.

  ???? IDE drives are only using a fraction of the power available to them.
With their full 16-bit parallel access, you are limited only by the bus
speed. I wonder if there are any drives that really tax the bus, yet.

  Does anyone know if there is going to be a 32-bit version of IDE for EISA
or even local-bus??

--
Andrew Rossmann            | Sysop of Infoplus BBS, +1 708 537 0247
andyross@infopls.chi.il.us | Infoplus Support, latest version available
 uunet!infopls!andyross    | by logging in as infoplus. [v32bis/v42bis]
                      NO new taxes...NO new gambling
Newsgroups: comp.os.msdos.programmer
From: rnichols@cbnewsg.cb.att.com (robert.k.nichols)
Subject: Re: Print to stdout in binary mode?
Summary: Need to force the driver into binary mode via int21, func 4401h
Keywords: stdout,binary
Organization: AT&T
Date: Wed, 16 Sep 1992 01:32:20 GMT

In article <BuLKyI.Jz8@news.cso.uiuc.edu> gordon@osiris.cso.uiuc.edu (John Gordon) writes:
>
>	Hi.  I am trying to make a C program write to stdout in binary mode,
>and can't figure out how to do it.  The problem is that I am writing to a
>device which expects lines to be terminated by a linefeed, *not* an LF/CR
>pair.  I would like to do this to stdout, to be able to pipe it.  I suppose 
>I could write to an intermediate file, if I had to, though.  Can anyone
>figure out a way?  I tried writing to "con", but that can't be redirected.
...

I fought this battle, too, and finally discovered that I had to make an
int21 call to force the driver into binary mode.  Just using normal I/O
calls to set binary mode didn't work.  Here's my code fragment:

	int c,n;
	FILE *prn;	/* usually opened as device "PRN" in "wb" mode,
			   but might be stdout */

	c = setmode(fileno(prn),O_BINARY);	/* One would think that this
						   would suffice */

		/* Ensure that the driver is REALLY in binary mode */
	n = fileno(prn);
	_asm {
		mov	bx,n
		mov	ax,4400h		/* 4400: get device data */
		int	21h
		mov	c,dx
	}
	if(!(c & 0x20)) {    /* If not in binary mode (and it NEVER is) */
		c = c & 0xff | 0x20;		/* set the BINARY mode bit */
		_asm {
			mov	bx,n
			mov	ax,4401h	/* 4401: set device data */
			mov	dx,c
			int	21h
		}
	}


Yes, I know that the code could have been simpler, but I was experimenting,
and once I found the magic combination I never bothered to clean it up.
(Why optimize code that executes once during a program's initialization?)

Bob Nichols
AT&T Bell Laboratories
rnichols@ihlpm.ih.att.com
Newsgroups: comp.os.msdos.programmer
From: jenk@microsoft.com (Jen Kilmer)
Subject: Re: 32-bit DOS
Date: 07 Sep 92 06:05:54 GMT
Organization: Microsoft Corporation
Summary: random scribblings
Keywords: 32-bit, DOS, Advanced Operating Systems

In article <1992Sep3.211915.1977@asd.com> scott@asd.com (Scott Barman) writes:
>In article <4117@cruzio.santa-cruz.ca.us> aki@cruzio.santa-cruz.ca.us writes:
>>Are the guys in Redmond smart enough to realize that there is need
>>for both a gooey picture thingie _AND_ a DOS-like creature??
>
>Are you kidding?  The idiots from Redmond were smart we'd have a
>complete multitaksing system and wondering if they could figure out how
>to do virtual memory by now.  If they did that, they'd only be 5 years
>behind in operating system development!
>-- 
Scott, Aki...

now, now...as I was telling a stressed-out friend in the DOS
group..."it's not like DOS is anything important...it's only 
the most-used OS in the world"...

sigh....

-jen
My name's not Bill, I don't have Billions, And I don't speak for Microsoft





Newsgroups: comp.os.msdos.programmer
From: gin503@cdc835.cdc.polimi.it (Maurizio Sartori Masar)
Subject: BC++ Far new()
Date: Tue, 8 Sep 1992 13:00:20 GMT
Organization: C.d.C., Politecnico di Milano
Keywords: new()


From Borland C++ 3.00 Run Time Library :

/* filename - new.cpp */
void *operator new( size_t size );              //    use  malloc(size)

/* filename - newf.cpp */
void far * operator new( unsigned long size )   //  use  farmalloc(size)

/* filename - CS.LIB */
NEW             size = 83
        operator new(unsigned int)        set_new_handler(void(near*)())
        __new_handler
NEWF            size = 77
        operator new(unsigned long)



Question : how can I call the far version of 'new()' from a small memory
           program ?


					Maurizio

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  ))    ))    ))     )))))      ))    )))))))      Maurizio Sartori Masar
  )))  )))   ))))   ))         ))))   ))    ))
  ))))))))  ))  ))   ))))))   ))  ))  ))    ))   gin503@cdc835.cdc.polimi.it
  )) )) ))  ))))))        ))  ))))))  )))))))
  ))    )) ))    )) ))    )) ))    )) ))  ))       Politecnico di Milano
  ))    )) ))    ))  ))))))  ))    )) ))    ))            ITALY
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
  ))    ))    ))      ))))))    ))    )))))))      Maurizio Sartori Masar
  ))))))))  ))  ))   ))))))   ))  ))  ))    ))   gin503@cdc835.cdc.polimi.it
  )) )) )) ))))))))       )) )))))))) ))))))       Politecnico di Milano
  ))    )) ))    ))  ))))))  ))    )) ))    ))            ITALY
From: bu254@cleveland.Freenet.Edu (Stephen Groundwater)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Questions about malloc and free and memory models
Date: 7 Sep 1992 19:59:28 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: bu254@cleveland.Freenet.Edu (Stephen Groundwater)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, beders@wip-sol.dfki.uni-sb.de (Jochen Bedersdorfer) says:

>
>Huhu,
>
>NO, DON`T TRY TO UNDERSTAND OR EVEN GET IN CONTACT WITH SEGMENT CONFLICTS.
>Ever heard about a 32-bit flat memory model ?
>There You have no problem with memory models, near, far or even
>huge pointer. You can malloc as much memory as you want.
>Try to get OS/2, gcc (the GNU C Compiler) for OS/2 and
>IBM Toolkit and you would be VERY happy.
>
>Lately I converted a program that runs in compact model
>to flat model and I could delete very much stuff about
>pointers and segmentation verification.
>And it runs MUCH faster...
>
>SO GO BUY OS/2 !
>
>Greetings, :)ochen
>--
>
You still got Segments in OS/2 it's just weel disguised, you're going to
run out of memory eventually with only a paltry 4GB to access, and then 
you'll have to relearn about sectors/selectors again. You think 4Gb is
a lot today, but in a few years you'll be gasping for breath, and
generally suffering from claustrophobia in such a small space.
Get NT, on a MIPS or Alpha you can access exo-bytes!

Steve
Newsgroups: comp.os.msdos.programmer
From: skimmel@iiic.ethz.ch (Stefan Martin Kimmel)
Subject: NetBios Interface for Windows 3.1 and MS C/C++ 7.0
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Distribution: comp.os.ms-windows.misc comp.sources.wanted comp.protocols.tcp-ip.ibmpc
Date: Mon, 14 Sep 1992 09:13:26 GMT

I am looking for an interface (DLL) to Netbios under Windows 3.1 using
MS C/C++ 7.0, that makes programming easier (hiding interrupt calls in
functions, transferring large amount of data with single statement ...)

Does anybody know of such an implementation (full source code would be
appreciated), that is PD or commercial. Any pointers will be appreciated.

Please respond via email to skimmel@inf.ethz.ch

Please respond via email to skimmel@inf.ethz.ch

Thank you
                         Stefan Kimmel
Xref: sparky comp.os.msdos.programmer:9261 comp.os.msdos.misc:5169
From: ralf+@cs.cmu.edu (Ralf Brown)
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.misc
Subject: Re: Disk Drive Purchase?
Date: 11 Sep 92 04:04:14 GMT
Article-I.D.: cs.BuEBB3.2Kr.2
Organization: School of Computer Science, Carnegie Mellon

In article <exuptr.476.716143831@exu.ericsson.se> exuptr@exu.ericsson.se (exuptr@exu.ericsson.se) writes:
}In article <BuCBp5.1MF.2@cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes:
}>In article <exuptr.458.716059101@exu.ericsson.se> exuptr@exu.ericsson.se (exuptr@exu.ericsson.se) writes:
}>}In article <2aab4eed@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes:
}>}Now this one makes sense.  Except that BIOS does not limit you to 1024
}>}cylinders, that is DOS.  So theoretically you could have 2048 x 64 x 63.
}
}>Sorry, but that is indeed a BIOS limit, since the BIOS only uses ten bits
}>to specify the cylinder (there are a couple of BIOSes which use twelve
}>bits, but they aren't "standard").  
}
}Find me a 386 with bios that will not support a 1224 cylinder drive.

<reach>.  I'm touching one....

The cylinder number is stored discontiguously in the registers to the BIOS
call; bits 8 and 9 go in the high two bits of the register holding the
sector number.  On those BIOSes which support the nonstandard extension to
twelve bits, bits 10 and 11 go in the high two bits of the register holding
the head number.

}>DOS is simply using the standard BIOS
}>interface--you could always write a device driver that knows about the
}>two nonstandard cylinder bits if you have such a BIOS.
}
}Which almost everyone does, which is why Disk Manager works and can format

No, Disk Mangler installs an extension to the BIOS which uses an extra call
to access cylinders beyond 1023.

----------13EE-------------------------------
INT 13 - SWBIOS - SET 1024 CYLINDER FLAG
        AH = EEh
        DL = drive number (80h, 81h)
Return: CF clear
           AH = 00h
Notes:  the following INT 13 call will interpret the cylinder number as 1024
          less than the desired cylinder
        flag cleared by all INT 13 calls except AH=EEh
        SWBIOS is a TSR by Ontrack Computer Systems; Disk Manager also supports
          these calls
        also supported by HyperDisk v4.01+ and PC-Cache v5.5+, in order to allow
          caching of drives using SWBIOS to access more than 1024 cylinders

}things like the MAXTOR XT-4380.  I haven't seen a BIOS that cannot do this
}since 1987.  Admittedly I stay away from older AT's and PS/2's.
}
}Realistically, what machine today has this limitation?

My machine with a 1989 Phoenix BIOS.  If it isn't a problem, why are all the
big IDE drives sector-translated to 1024 or fewer cylinders (like the one in
my system now)?


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