HDTenEightyP/NetNews huggingface dataset:
From: baardkjo@idt.unit.no (B}rd Kjos)
Subject: Help: How to (not) identify a network drive
Followup-To: comp.os.msdos.programmer
Reply-To: baardkjo@idt.unit.no
Organization: Div. of CS & Telematics, Norwegian Institute of Technology
Date: Wed, 16 Dec 92 14:13:07 GMT

I've written a device driver implementing a RAM disk. The driver uses
an add-on board with up to 320 MB DRAM for storage. My problem is,
MS-DOS has got this stupid idea it is a network drive, and certain
programs (e.g. CHKDSK, Norton Disk Doctor ) does not accept the disk.
Could anyone out there help me with the following, please:

How does MS-DOS identify a network drive?

Why is my drive identified as a network drive when the Media Descriptor
Byte i return says "Fixed disk" (0f8h)?

How do i get MS-DOS to understand "the true nature" of my driver?

-- 
=============================================================================
| Baard Kjos                             | Phone: +47 7 59 3470             |
| Div. of Comp. Sci. and Telematics      | Fax:   +47 7 59 4466             |
| The Norwegian Institute of Technology  | Email: Baard.Kjos@idt.unit.no    |
| N-7034 Trondheim                       |                                  |
| NORWAY                                 |                                  |
=============================================================================
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: comp.os.msdos.programmer
Subject: Re: how do YOU print out source?
Date: 16 Dec 92 06:12:00 GMT
Article-I.D.: qiclab.1992Dec16.061200.10343
Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.

esova@magnus.acs.ohio-state.edu (Edward R Sova) writes:

>I have Borland's TC++1.0, and BC++2.0 at work, they (Borland) 
>have a terrible way to print out source code!  When I print 
>out code, I'd like to have page header's, line numbers, 
>pagination, date/time stamp, printer control for condensed 
>print for those really ugly nests, and have it all spooled up 
>so I can keep going.  Now that doesn't seem to much to ask 

I use Source Print from Aldebaran Laboratories. It's in the 
Programmers Warehouse catalog (or was last time I looked).

It handles C, FORTRAN, BASIC, Modula 2, dBase, Pascal...

It will indent, bold-face or capitalize keywords (and you can
define extra "keywords"). It'll also do stuff like draw lines
linking the begining and end of things like if-then sequences,
cases, loops, etc or generate a table of contents listing the
routines and what page they start on. Or generate a cross-reference
listing for all variables and functions/procedures.

It *won't* spool stuff, but it can print to a file. (heck, with 
the right options, I use it for reformatting source!)

-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)
From: olsont@stein.u.washington.edu (Todd Olson)
Newsgroups: comp.os.msdos.programmer
Subject: Using Xlib  (mode X programming library)
Date: 15 Dec 92 18:47:52 GMT
Organization: University of Washington, Seattle

Has anyone been using Xlib--the mode X programming library?
If so,  what have you been using for a graphics editor to create
sprites/backgrounds/fonts etc for this package?  Any suggestions
would be very helpful.  Thanks!
Todd Olson
olsont@stein.u.washington.edu
Newsgroups: comp.os.msdos.programmer
From: dwm@sound.demon.co.uk (David Martin)
Subject: Re: DOS CONSOLE OUTPUT
Reply-To: dwm@sound.demon.co.uk
Cc: comp.os.msdos.programmer@sound.demon.co.uk
X-Mailer: cppnews $Revision: 1.20 $
Organization: Sound & Vision BBS (UK) 0932 252323
Date: Sat, 12 Dec 1992 21:00:17 +0000

In article <1992Dec11.073326.10891@tc.cornell.edu> you write:
>    I am using fortran CALL FSYSTEM ('DOS COMMAND')
>to run various dos commands like MKDIR etc.  How do I get
>DOS to NOT write to the console during such operations, the
>console will be used for graphics application.  
> 
I started a thread 'Redirection to NUL from exec()' which you may have
seen, addressing the same problem from Turbo Pascal. I got lots of C
code and I was able to translate it quite easily into TP. I wish you
luck with Fortran, because I don't know a thing about it!

However, here is the pseudocode for the definitive solution:

1.  Open the device 'NUL' with whatever opens a file in Fortran.
2.  Get a copy of StdOut's filehandle with the dos service that does this,
    to a variable, eg. OrigStdOut. In C this is the dup() function. In TP
    I had to write my own. You can access it at the interrupt level by
    setting register AH to 45h, BX to the file handle you want a copy of
    (ie. 1=StdOut), and calling interrupt 21h. The copy of the (StdOut's)
    file handle is returned in AX.
3.  Call the dos service to duplicate a file handle, to equate NUL with
    StdOut, so the two move in unison. In C this is dup2(). In TP, again,
    I had to write my own... You set AH to 46h, BX and CX to the two
    handles of NUL and StdOut (1) respectively, and call 21h.
4.  Repeat 2 and 3 with StdErr (2) instead of StdOut.
5.  Close NUL.
6.  Do whatever, ie. CALL FSYSTEM ('DOS COMMAND')
7.  Execute step 3 again with BX = OrigStdOut and CX = StdOut then again
    with BX = OrigStdErr and CX = StdErr.
8.  Close OrigStdOut and OrigStdErr.

Reiterating, in a pseudo-language of my own invention:

1.  NulsHandle = open('nul')
2.  OrigStdOut = dup(1)
3.  dup2(NulsHandle,1)
4.  OrigStdErr = dup(2)
5.  dup2(NulsHandle,2)
6.  close(NulsHandle)
7.  call fsystem ('dos command')
8.  dup2(OrigStdOut,1)
9.  dup2(OrigStdErr,2)
10. close(OrigStdOut)
11. close(OrigStdErr)

I hope that that makes sense to you!

                  +--------------------------------------+
                  |          - David Martin -            |
                  |   InterNet : dwm@sound.demon.co.uk   |
                  +--------------------------------------+
From: corvett@csa.bu.edu (Sungyeup Kim)
Newsgroups: comp.os.msdos.programmer
Subject: Summery of 1kbyte
Date: 10 Dec 92 16:25:24 GMT
Organization: Computer Science Department, Boston University, Boston, MA, USA

wow, thank you everybody who reply to me.
I got about 20 reply.
Most people said 1 kbyte is 1024 bytes(2^10) but some people said
1 kbyte is 1000 bytes.
I think 1024 bytes is correct. 
Thanks again ! :)
--
Sungyeup Kim
corvett@csa.bu.edu
Newsgroups: comp.os.msdos.programmer
From: cgordon@vpnet.chi.il.us (gordon hlavenka)
Subject: QB 4.5 inp() weirdness
Organization: Vpnet Public Access
Distribution: usa
Date: Thu, 17 Dec 1992 03:01:58 GMT

Here is a short code fragment:

''''' Start of code

defint a-z

com.port=&H3fe

print "Reading 'com.port':";inp(com.port)
print "Reading '&H3fe':";inp(&H3fe)
print "Reading 'int(com.port)':";inp(int(com.port))

system

''''' End of code

Guess what:  The first line gives incorrect results -- it's not
reading port &H3fe!  (I'm trying to read the RI pin; I know &H3fe is
not the _data_ port!)


What's going on here?  What is the difference between com.port (an
integer variable) and int(com.port)?

-- 
----------------------------------------------------
Gordon S. Hlavenka           cgordon@vpnet.chi.il.us
Vote straight ticket Procrastination party Dec. 3rd!
Newsgroups: comp.os.msdos.programmer
From: ejohnfel@csws17.ic.sunysb.edu ()
Subject: Wanted: Reference for EGA and VGA programming
Originator: ejohnfel@csws17.ic.sunysb.edu
Organization: State University of New York at Stony Brook
Date: Thu, 17 Dec 1992 01:52:35 GMT

Greetings all,

	I am in need of a good source of information about low level calls
and practices concerning EGA and VGA cards (for example, direct port
manipulation). I would appreciate any suggestions for books on the subjects,
or even anyone offering to let me "pick your brain".

						Tanx all,
+------------------------------+---------------------------------------------+
| Name : Eric G. Johnfelt      | "It is amazing that the purest and greatest |
| Rank : Sophmore @ SUNY SB    |  of all human qualities, always seems to    |
| Ser.#: ejohnfel@ic.sunysb.edu|  escape us!"                 -Unknown       |
+--->> Disclaimer <<--*Read*---+---------------------------------------------+
| *The opinions expressed here |      errare humanum est : ne cede malis     |
|  come direct from Elvis & the| vea victis : ULTIMA RATIO REGUM : DEI GRATIA|
|  martians who kidnapped him! |            Homey don't play 'dat            |
+------------------------------+---------------------------------------------+
Newsgroups: comp.os.msdos.programmer
From: gay@selkirk.sfu.ca (Ian D. Gay)
Subject: Re: Calling convention: C vs PASCAL
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 14 Dec 1992 18:15:41 GMT

dmurdoch@mast.queensu.ca (Duncan Murdoch) writes:

>>Waht difference does this make for execution time? The cleanup code has to be
>>executed for every invocation, whether it is included with the callers or the
>>called code. Of course it does make difference for the code size.

>A Pascal routine with 20 bytes of parameters can return and clean up with 
>the single instruction:

>     retf 20

>On all 80x86 cpus, this takes the same time (plus or minus a cycle) as the 
>plain retf.  The advantage comes because that's all that's needed; a return 
>from a C convention routine must be followed by manual adjustment of 
>the stack pointer.

e.g.  sub sp, 20   ... which takes 2 cycles on a 386. You will have 
to have a very short called routine before you can see any difference.

>Duncan Murdoch
Newsgroups: comp.os.msdos.programmer
From: eball12@ursa.calvin.edu (Edward Ball)
Subject: Bypassing BIOS key interrupts...
Organization: Calvin College
Date: Wed, 16 Dec 1992 00:29:07 GMT

I've noticed that in some games (Star Control II, for example) multiple
key presses can be detected at the same time, on or off.  I can only
assume they use the BIOS key scan codes for pressing and releasing keys.
My questions is, how do you bypass the standard keypress buffer (or 
whatever it is called) and just read the scan codes without having to
worry about pulling such keypresses off the buffer or worrying about
repetition speed or anything like that?  I just want to know when a key
is down, and when it is no longer down.  I'm sure it can be done...
anyone have any ideas???

--
-- Edward Ball, .sigless Knight -------------------- eball12@calvin.edu --
                                                                        --
From: kr@jet.uk (Kenneth Reed)
Newsgroups: comp.os.msdos.programmer
Subject: Running DOS in Virtual 8086 mode
Date: 17 Dec 92 08:43:59 GMT
Organization: Joint European Torus

I'm tinkering with Protected Mode programming on the 386 and I'm
trying to call DOS functions. I'm almost there ... but not quite.

I can get into VM mode OK and call *some* DOS functions just fine, for
example keyboard input and screen output, but others do strange
things. For example, if I try accessing the hard disk I get a critical
error saying that the drive door is open!

I know the answer is that there must be a bug in my code but I just
can't see it. The fact that some interrupts work fine (even hardware
interrupts are being processed OK) but others don't has got me
baffled.

If anyone has had similar problems, and can give me a pointer in the
right direction to look, it would be most appreciated.

Regards

Ken

-- 
- Ken Reed, Joint European Torus, Abingdon, Oxfordshire, UK
  kr@jet.uk
- Disclaimer: Please note that the above is a personal view and should not 
  be construed as an official comment from the JET project.
From: smhkotmans@mswe.dnet.ms.philips.nl
Newsgroups: comp.os.msdos.programmer
Subject: How to program the mouse in SVGA mode?
Date: 16 Dec 92 10:30:46 +0100
Organization: Philips Medical Systems Nederland

Hi Netters,

I have a question regarding graphical mouse programming in 640x480 or 800x600
SVGA mode.
In VGA mode, my program can show and manipulate the mouse cursor just fine.
When i switch over to SVGA mode, the mouse cursor is not visible any more
although the mouse driver still reports the mouse as being present.

What extra/completely different must i do to get the mouse working correctly
in SVGA mode?

If this matters: 
    I'm using INT 33h calls in a C program in combination with an 
    ATi Wonder XL video card with bus mouse.


Thanks in advance,
Henk Kotmans
From: mcs@wet.UUCP (Gil Nardo)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Math error in BC++?  Help!
Date: 17 Dec 92 19:08:19 GMT
Distribution: usa
Organization: Wetware Diversions, San Francisco

sonix@schunix.uucp (Duane Morin) writes:
> This is driving us NUTS!! Will someone please take a look at the following 
> code and see if they can figure out why it does what it does?  Thank you.
> 
> The following code segment shows a snippet of a program that needs
> to calculate
> the log base 2 of 128 (which happens to be 7).  The problem is that the 
> code works fine on a 386DX/40, with 387 installed, and does NOT work on 
> a 486DX/33!  Help??
> 

I included a shortened version of your program.  I did not completely
solved it but I do have some clues as to what's causing the problem.
After compiling with the assembly output option, I found that at
least two methods can be used to make it return the answer of 7.

One method is to pop the answer off of the co-processor stack and
pop it back on using the fstp and fld instructions prior to the
call to N_FTOL (float to long, near call version). This method
is equivalent to the two step processes of as shown in the code.

The other method is to substitute N_FTOL with the use of fistp
(store and pop stack as integer) and followed by the use of the
lower part of the of the quad word as the result.

I would guess at this point that the function N_FTOL inadvertantly
modifies either the rounding or the precision bits of the
co-processor control word. I will leave it to you and others to
figure out why this happens on the 486 chip and not
on the 386/387 chips, mainly because I need to get back to work.

----------
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <float.h>

// The following constants are normally defined within the program:

#define LOG2 (log(2))
#define LOGN(y)        (log ((double)y) / LOG2 )
main()
{
 	double l;
	int i;

	l = LOGN(128);
	i = (int)l;
	printf("two step = %d\n", i); // this comes up with 7

	i = (int)(LOGN(128));
	printf("one step = %d\n", i); // this comes up with 6?

	return(0);
}

-- 
Gil Nardo                  | mcs@wet.com
Migrant Computing Services | (415)664-1032
1032 Irving Street, #435   |-----------------
San Francisco, 94122       | Supernova = *!
Newsgroups: comp.os.msdos.programmer
From: jamesc@borland.com (James Chuang )
Subject: Re: Copy Protection Information
Originator: jamesc@genghis.borland.com
Organization: Borland International
Date: Wed, 16 Dec 1992 22:54:44 GMT

I think we've already found the ultimate in copy protection:  The size of the
files.  Carmen Santiago on CD is over 140MB in size, and costs 70 dollars.
As far as I know, Hard Disk is not that cheap yet.  As long as it cost more
to store a program than get it on CD ROM, the CD ROM will be an efficient
copy protection mechanism.  Too bad the CDs are too slow, but that should
be fixed soon.....

jamesc

-- 
==============================================
#include <Disclaimer.h>
==============================================
// If someone asks if you are a god, you say YES!
From: pshuang@zurich.ai.mit.edu (Ping Huang)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Calling convention: C vs PASCAL
Date: 11 Dec 92 21:37:38
Organization: M.I.T. Artificial Intelligence Lab.
Distribution: usa
NNTP-Posting-Host: freeside.ai.mit.edu
In-reply-to: zzang@stat.ufl.edu's message of Fri, 11 Dec 92 22:50:15 GMT

In article <1992Dec11.225015.26304@eng.ufl.edu> zzang@stat.ufl.edu (zzang) writes:

 > Hello, the C pushs the arg from right to left onto the stack when
 > calling a function.  the PASCAL pushs the args from left to right.  I
 > was told that the C calling convention results in larger as well as
 > slower program.  (due to some cleanup work of the stack after call??)
 > 
 > can someone tell me why ?

The C calling convention permits variable length parameter lists (c.f.
the printf() family in the C run-time library, and check your compiler
documentation if it supports the set of macros which allows you to write
your own functions with similar capabilities), because the leftmost
parameters, which are specified, are at the top of the stack, so the
called function doesn't need to know how many more parameters are on the
stack to be able to access the specified ones. The Pascal convention
does not permit this.

However, the price for this flexibility is that the called function
cannot contain code to pop the parameters off the stack at its epilogue,
so the code calling the function must do so. Therefore, if you don't
take advantage of variable-length parameters lists, compiling a function
with Pascal-passing-convention as opposed to C-passing-convention means
that the resulting executable code will be smaller -- in the former
case, the code to pop the parameters from the stack appears once, in the
latter case, the code appears as often as your program code lists a call
to the function (note this is different from how many times your program
actually calls the function at run-time).

--
| Ping Huang (INTERNET: pshuang@martigny.ai.mit.edu) speaking for himself.
| "One Thing to name them all, One Thing to define them,
|  One Thing to place them in environments and bind them..."
From: cyberman@exucom.com (Stephen R. Phillips)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Normal MSDOS multitasking!
Date: 15 Dec 92 01:34:41 GMT
Organization: ExuCom MultiMedia Inc.
X-Newsreader: TIN [version 1.1 PL7]


Chris (cbusch@ub.d.umn.edu) wrote:
: 
:    Apparantly MSDOS multitasks with the use of the pipe "|".  Is this
: true?  How does the | really work?  For example: "type this.txt | more"
: has 'type' and 'more' being ran simultaneously (apparantly).  How is
: this so?
: 
	1:	NO it's not a true pipe and it's NOT multitasking.

	2: it creates a temporary file and spools it up tell the first
program is finished then it redirects stdin for the next program to
the temp file and runs that program.  AND so one.  Until it completes
the task. 

	It's an illusion.

-- 
This is my sig file!
Read rec.games.programer!
From: bern@Uni-Trier.DE (Jochen Bern)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Normal MSDOS multitasking!
Date: 15 Dec 92 20:27:26 GMT
Organization: Theor. CS, FB IV / CS, Univ. of Trier, Germany (Internet TI.Uni-Trier.DE)
Originator: bern@kleopatra

In <1992Dec14.234659.21162@vpnet.chi.il.us> cgordon@vpnet.chi.il.us (gordon hlavenka) writes:
>In article <5831@krafla.rhi.hi.is> einari@rhi.hi.is (Einar Indridason) writes:
>>No, that is not a multitasking.  MeSsy-DOgS handles the pipe line with
>>something like this:
>>Run first program to completion, with standard output redirected to a 
>>temporary file.
>>Wait until first program has finished.
>>...(etc.)
>A little experiment to demonstrate this:  Do a 'DIR/P', then compare
>the output to 'DIR | MORE'.

Another Proof: Try Piping when you "are" currently on a write-protected Floppy.
Will fail with "write Error". Regards,
								J. Bern
-- 
 /  \  I hate NN rejecting .sigs >4 lines. Even though *I* set up this one. /\
/ J. \ EMail: bern@[TI.]Uni-Trier.DE / ham: DD0KZ  / More Infos on me from /  \
\Bern/ X.400 Mail: S=BERN;P=Uni-Trier;A=dbp;C=de  /   X.400 Directory, see \  /
 \  /  Zurmaiener Str. 98-100, D-W-5500 Trier    /     X.29 # 45050230303.  \/
Newsgroups: comp.os.msdos.programmer,comp.os.msdos.misc,comp.unix.msdos,comp.unix.dos-under-unix
From: jrhall@cbnewsk.cb.att.com (john.r.hall)
Subject: borland c++ under Sun PC emulator
Organization: AT&T
Distribution: usa
Date: Wed, 16 Dec 1992 15:08:38 GMT
Followup-To: poster


If you have had experience in using PC-based Borland C++
on a Sun workstation using Sun's PC emulator under OpenWindows,
please send email to me at jhall@ihlpm.ih.att.com.
Thanks,
--John R. Hall
Newsgroups: comp.os.msdos.programmer
Subject: Re: Copy Protection Information
From: cctr132@csc.canterbury.ac.nz
Date: Thu, 17 Dec 1992 00:47:37 GMT
Organization: University of Canterbury, Christchurch, New Zealand

In article <18580@mindlink.bc.ca>, Marc_North@mindlink.bc.ca (Marc North)
writes:

> Can someone please point me to where I can find information about how to
> implement a copy protection system into my programs? I've searched high and
> low, both electronically and in print media and I cannot seem to find any
> references to even concepts, let alone specific techniques in this matter.
> 
> My aim is to include some sort of code into my program that would, ideally,
> render any unauthorized copy of an executable unusable.

Stop wasting your time.

If you are dead set on copy-protecting your program, bite the bullet and
buy dongles.  The simple reason is that anything that can be done with
software can be undone with software and its unlikely that you could
come up with something sufficiently "different" from all the previous
attempts to achieve s/w only copy protection --in a reasonably short
time frame-- that the cost of dongle's would quickly be outweighed by
your additional development time.  As you are unlikely to devise
something that either won't be quickly cracked by someone else or that
isn't already "broken" by an existing copy-protection breaker, you might
as well admit defeat before you begin.

Also, note that many people won't purchase/use copy-protected s/w.  This
is not because they are pirates or out to defraud you.  In fact, the
implicit assumption on the vendor's part that the customer is likely to
be up to something nefarious can be sufficiently off-putting in itself. 
Historically copy-protection systems have had a poor run, in that they
often fail to work correctly on certain combinations of hardware, or
they conflict with other valid software, etc, etc.

I'm not saying that dongles are -necessarily- any better in this regard,
but they seem to be more stable -- the other day I was talking to
someone who has SEVEN dongles hanging off his printer port!  Still, some
people tend to balk at dongle-protected s/w too, so it's not a panacea.

To get away with any kind of copy- (or dongle-) protection these days
you basically have to have a "captive market" -- you must have the only
app for a certain job, or by far the clearly most impressive one (the
"industry leader" syndrome), or be doing the work on contract to the
purchasers.  These conditions apply in (some) "vertical" or niche
markets, but that's virtually it.

I'd suggest you rethink unless your product clearly fits one of the
categories described in the last paragraph.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
 n.fitzgerald@csc.canterbury.ac.nz  TEL:+64(3)364 2337, FAX:+64(3)364 2332
Newsgroups: comp.os.msdos.programmer
From: jennrich@kastor.itp.uni-hannover.de (Oliver Jennrich)
Subject: Re: DOS CONSOLE OUTPUT
Organization: Institut fuer Theoretische Physik, Uni Hannover
Date: Tue, 15 Dec 1992 14:16:35 GMT

brown@NCoast.ORG (Stan Brown) writes:
: In article <1992Dec11.073326.10891@tc.cornell.edu> homer@theory.TC.Cornell.EDU (Homer Smith) writes:
: >    I am using fortran CALL FSYSTEM ('DOS COMMAND') 
: >    For example if you copy a file, it always says '1 file copied.'
: >    NOTHING must go to the terminal but what I send to it.
: 
: Most commands will suppress output if you add ">NUL" (note spelling: one
: L, not two) at the end.  COPY, alas, is not one of these.
                           ^^^^
For sure, it IS, at least MS-DOS 3.21+
Just tested! ;-)


-- 

+-------------------------------------------------------------------------+
|  -oje-  Oliver Jennrich                     Institut f"ur theor. Physik |
|  jennrich@kastor.itp.uni-hannover.de        Universit"at Hannover       |
Newsgroups: comp.os.msdos.programmer